【ラクスル×LayerX】SaaSの失注率は「MSP開発」で激変する!『LayerX インボイス』に学ぶ、SaaS立上げのストーリー

登壇者
牧迫 寛之

大阪大学法学部卒。グリー株式会社に新卒入社し、決済・基幹システムのプロジェクトマネージャー。2014年より株式会社Gunosyに参画。複数の新規事業開発を推進後、投資先であるインドネシア・ジャカルタにて事業会社で3年間のハンズオン支援。 帰国後の2018年、LayerXに参画し、2019年執行役員就任。ビジネスサイドの責任者としてLayerX インボイスの立ち上げを担当。

関連タグ

2021年10月、あのラクスルがLayerXを招き、SaaSプロダクト立ち上げの勉強会を開いた。話を聞いたFastGrow編集部は同席取材を申し込み、その一部始終を記録した。

ラクスルは、LayerXのSaaSプロダクト導入を一度見送っている。だが2021年1月の『LayerX インボイス』本格リリース後に改めて説明を受け、5月に二度目のトライアルを実施、8月からの導入を決めたという。勉強会の進行を務めたラクスルの平佐賢宗氏は、ビフォーアフターを受けてLayerXのプロダクト開発への本気度の高さ、PDCAサイクルの速さを実感。今後の発展にも期待しているという。こうした経緯から勉強会にLayerXを招き、プロダクト開発の背景を聞く機会を設けた。

ラクスルが導入を一度見送ったように、『LayerX インボイス』は初めから順調な歩みで進んできたわけではない。プレゼンを行ったLayerXの執行役員、牧迫寛之氏が、LayerX インボイスの立ち上げストーリーを通して示したのは大きく4点。「実開発に入る前にインセプションデッキを作ること」「MVPとMSPの差分を意識すること」「営業やCSとプロダクトチームとの距離の近さ」「導入はゴールではなく始まりであり、運用に乗るプロセスをCSを含めて取っていくこと」だ。では、詳しく見てみよう。

  • TEXT BY WAKANA UOKA
SECTION
/

業務効率化のペインは業務プロセス内のデジタル化だった

SaaSプロダクト『LayerX インボイス』が提供している価値は、「請求書処理の効率化」である。つまり、受け取った請求書の処理を、圧倒的に楽にする、というサービスだ。導入企業は半年間で10倍超に増え、ラクスルの他、弁護士ドットコムやGoodpatch、ヤプリなどが導入している。

急拡大を見せるLayerX インボイスだが、牧迫氏は、プロダクトができるまでに暗中模索期・探索期・ローンチ期・拡大期の4つのフェーズがあったと言う。そして、その前段階には実は会社として大きな戦略の転換(事業ピボット)があった。その理由を、牧迫氏は次のように説明する。

牧迫私たちは以前まで、大企業のブロックチェーンに関する研究開発に対して、コンサルティングというかたちで支援を行ってきました。

とある企業様とのプロジェクトで、「ブロックチェーン技術を活用した企業間取引の効率性を改善するサービス」を検討していたんです。そこで全体の業務プロセスの話を整理していくと、一部の業務にブロックチェーンのような新技術を採り入れたところで、その前後の業務には紙や手入力を要する作業が残されたままになってしまうことに気がつきました。

効果が出たとしても、局所的なものでは相手企業にとって意味がないのではないか、と新たな課題を認識できたんです。なので、その前後の作業コストを何とかした方がいい、コーポレート領域のデジタル化支援が急務ではないかということで、「研究開発支援」から「SaaSプロダクトの開発・提供」というピボットに至ったんです。

ただ、「請求書の処理」と言われてもイメージはつきにくいため、牧迫氏はその背景を補足した。

この領域では、「デジタル化」とは異なる「電子化」という言葉が使われているという。そうした前例を、新たなSaaSプロダクトを開発する上で、どのように意識すべきなのだろうか?

牧迫請求書を例にすると、請求書そのものをPDF化することを電子化と呼びます。電子化により請求書のペーパーレスは実現しますが、それだけでは足りないと私たちは強く感じていました。

請求書処理のプロセスには、スタート地点である「受け取り」と、ゴール地点となる「保管」の間に、「データ化・申請・承認・回収・仕訳・支払・消込」といった業務もある。請求書のPDF化だけでは、これらがすべて手入力や紙のまま残されてしまうため、不十分だと言えます。効率化を進めるには、間となる業務プロセスをデジタル化し、手入力をなくすことが肝要なんです。

他領域でも「電子化」という名で、あるいは「DX」と謳っていながら、局所最適にとどまる事例は少なくないだろう。本質的な課題をいかにして特定するか、が、SaaSプロダクト開発において重要だということがわかる。

SECTION
/

インセプションデッキでチームメンバーの目線を揃えよ

ピボットを経た2020年5月、LayerXはCTO、エンジニア、経理の3名で検討チームを組成。翌月から世界トップクラスの各種SaaSプロダクトの調査を開始した。見えてきたのは、クライアントが業務で使用するSaaSプロダクト間のデータ連携に関する課題だった。

牧迫いろいろなSaaSプロダクトがある中で、共通の台帳、データベースがないというのは大きな課題だろう、と。これではサービス間でデータを渡すのにコストがかかってしまいます。特に、マスターデータの連携には重いコストがかかるでしょう。この課題解決にブロックチェーン事業の知見が活かせるんじゃないか、これまで培ってきた技術を使って作れるのではないかと構想していました。

7月にはメンバーを増員。プロダクトのかたちは未定だったものの、コーポレート領域のDXサービスを開発することは決定した。

次に取り掛かったのは「インセプションデッキ」の作成だ。LayerXでは、プロジェクトキックオフの前に、このインセプションデッキを作ることが非常に多いという。「プロジェクトマネージャーの方はご存知のフレームだと思う」と前置きし、牧迫氏は次のように内容を説明した。

牧迫インセプションデッキは、チームメンバーが「なぜ、このサービスを作るのか」の目線を合わせるために作るものです。「我々はなぜここにいるのか」「エレベーターピッチ」「トレードオフスライダー」「やる・やらないリスト」「夜も眠れなくなるような問題は?」の可視化を目指しました。これはエンジニアだけでなく、ビジネスサイドも含めあらゆる立場の人が合意した方針ですよ、と明文化するのがインセプションデッキの役割なんです。

その中の「やる・やらないリスト」を具体例として紹介しますね。「やる」に挙げたのは、スピードを重視することや泥臭くカスタマーサクセスを追求すること、全員カスタマーサクセスといったことです。これらを、プロダクト開発を始める前から「必ずやること」として明文化していました。

一方で、「やらない」には、過度なドキュメンテーション、過度な品質管理をし過ぎないという文言が含まれています。

また当社の開発チーム内には、サービスを使われるであろう規模感の企業で働いたことがある経理担当がほぼいない状況でした。なので「具体的なことはお客さんに聞かなければわからないという意志をきちんと持って進めましょう」とインセプションデッキ内で明確な方針として決めていました。

SECTION
/

「こうなればいろいろ便利」では 前に進まない、
解決案はあえて絞れ

インセプションデッキでチームメンバーの意思決定に軸が作られ、目線合わせがなされた。このあとの時期を牧迫氏は「探索期」と呼ぶ。この期間に、LayerXでは100社超にヒアリングを実施。各会社の業務フローと課題をヒアリングする他、検討中のソリューションについて紹介し、実現されたら使うかどうか、感触も確かめていった。

牧迫初期に考えていたコンセプトは、「基幹業務と基幹システムをつなぐ何かを提供しています」です。つまり、iPaaSのような領域やマスターデータマネジメントのような領域も視野に検討を進めていました。ヒアリングで得た情報から、各業務プロセスに対して利用システム、システムの管理部署、運用者等のリスト化も行っていました。

ただ、初期に我々が企業への提案で伝えてきた要点をまとめると、「御社で使用しているSaaSプロダクトをいい感じにつなげたら便利になるし、使いますよね?」なのですが、「便利そうだ」という反応こそいただけるものの、ソリューションが概念的すぎるため、そこから話を前に進められませんでした。

概念的なソリューションでは、具体的にどういった業務がどのように効率化され、利便性を感じられるのかについて顧客イメージできない。導入を検討しようにも、具体的な利用シーンが思い描けなければ、自社に必要かどうか判断しづらいだろう。

そこで、LayerXが決めたのは対象とする業務領域を「経理に絞る」こと。「いろいろ便利になる」から「経理業務が楽になる」に提案する内容を切り替えたのだ。

牧迫コンセプトは「毎月の支払業務が30分で終わる」。請求書を電子化して紙をゼロに、支払いを自動化することで反復をゼロに、自動消込により目視ミスをゼロにするサービスだと伝えはじめました。

業務領域が絞られたことで、私たちの提案に対する顧客の反応が明らかに変わったのを覚えています。さらに利用イメージをわかりやすく伝えるため、アニメーションのデモを付けたスライドも作成し、ヒアリングを続けました。

SECTION
/

前倒しリリース後に気づいた「MSP不足」

LayerXがラクスルと初回の打ち合わせを行ったのは昨年2020年の11月だ。しかし、α版をトライアルしたあと、ラクスルは本格導入を一度見送っている。このときの背景について、牧迫氏は次のように振り返る。

牧迫当時のラクスルは内製も含めてご検討されており、初回打ち合わせでは「お任せするところがあれば検討する」と回答をもらっています。そこから11月にトライアルを開始し、12月に導入見送りのご返答がありました。

プロダクトの機能面のほか、ラクスル社として当時のプライオリティが予実や発注管理にあったことからお断りされたと認識しています。社内でも足りなかったところを反省しました。

一方で、見送り判断にはなったものの、開発スピードの速さにはこの当時からご注目いただいていました。

『LayerX インボイス』本格ローンチは、ラクスルから導入見送りの判断が出た12月からすぐの翌年1月13日だ。100社ヒアリングをした中で、「これなら使い始めてもいい」と判断した企業を12月末までに数社見つけられたことからリリースを決めたのだという。

当初は3月リリースを想定していたため、大きく前倒ししてのリリースだった。その理由について、牧迫氏は緊急事態宣言が発令される可能性があったことに加え、「出してみなければわからない」という勢いも半分あったと語る。果たして、結果はどうだったのか。

牧迫リリース当初は全くと言っていいほど伸びなかったですね(笑)最初の2カ月ほどはお客さんが一向に増えず、正直かなりしんどかった。私も日に10件ほど商談していて、提案内容と、それで刺さった人、刺さらなかった人はどういう人だったのかをひたすらABテストして検証していました。

コンペに出したら負ける、コンペ無しでも導入に至らない。リリース初期の苦難の背景について、牧迫氏は「MSP不足」が原因だったという。プロダクトにはMVP(Minimum Viable Product)とMSP(Minimum Sellable Product)があり、12月に完成しリリースされたLayerX インボイスが満たせていたのはMVPまでだったというのだ。

牧迫OCR(Optical Character Reader、活字や手書きテキストの画像を、文字コードの列に変換すること)で請求書処理を効率化するという点において、ユーザーの「アハ体験」、つまりこれがあれば便利と感じてもらう体験を実現することはできていました。これはMVPです。経理の仕事が楽になるという価値を伝えられるものはできていたと思います。

しかし、上場企業の経理担当者の方と話していると「内部統制的にこういったものが欲しい」という声が寄せられました。MVP段階ではそうした要望まで考慮していなかったため、競合とコンペになると「なんでできないの?」と思われ負けてしまうんですね。

請求書をアップロードしたらすべて自動化され、手入力がなくなって経理作業が楽になる。その機能の価値は検証できていましたが、運用フローに乗るかどうかは別の話。我々はそこを考慮できていなかったんです。

導入が進まない理由を突き止めたLayerXは、その後2ヵ月ほどMSP開発に注力する。対応が完了したのは、リリースからおよそ3ヵ月後だ。そこから、ようやく導入企業数が増え始める。MSPの観点で足りなかった視点については詳しく聞きたいという声も多く、後のQ&Aコーナーにて触れるので読者の方にはぜひ読んでいただきたい。

牧迫伸び悩んでいた1、2月から体制も拡張し、伸ばす地盤づくりにも取り組んできました。その後、3月から半年で10倍超に成長し明らかに流れが変わりましたね。当時、社内で「ようやく1セグメントへのプロダクトマーケットフィットができたかな」と話していました。

MSP開発に注力したことにより、導入企業数が右肩上がりに増え始めたLayerX インボイスは、4月にラクスルへの再チャレンジを果たす。5月末からトライアルが始まり、8月には本格導入が決定した。

牧迫ラクスル同様、上場企業かつ特定の会計システムを使われている導入企業様は多くいらっしゃったため、懸念される点は大体同じかなと思っていました。MSP開発の中では、このように「A社が必要としていることをB社用にも作る」といった対応も意識していました。これが功を奏しました。

なので結果的に、1月の前倒しリリースは正解でした。当初こそお客様がつかず苦しかったわけですが、その中で集まった声を活かして開発を進めたことで、より良いプロダクトを早くつくっていくことができたんです。

やはり、実際の運用要件は、出してみなければわからない。MVP段階でリリースし、中に閉じずに実際のお客様の要望を聞きながら対応していくことが大切だったかなと。

初めは何もないところからSaaSテストや調査をし、ヒアリングをしながらプロダクトの種を見つける。その後は早めにリリースしてユーザーからの声を聞き、早期にMSPを備えて提供スピードを上げていく。これがLayerX インボイス誕生ストーリーの大枠だ。

SECTION
/

即時性のある情報共有がスピーディーな開発の秘訣

もう一つ注目したいのが、リリース前のトライアル時から、ラクスルも評価していたLayerXの開発スピードの速さ。スピーディーな対応を可能としている舞台裏について、牧迫氏はこう語る。

牧迫開発サイクルは2週間単位。新機能のリリース時期は月末月初を避けるようにしています。この時期は経理の方の作業期間なため、万一バグが起きたときに及ぼす影響が大きいですからね。

デイリー、ウィークリー、マンスリーに分けてやるべきことを設けている中で、私たちの開発チームの特徴はデイリーベースで機能追加の相談を行っている点だと思います。セールスカスタマーサクセスチームからエンジニア・プロダクトチームに商談の具体的な報告と不足している機能、「この機能が入れば導入につながる」といったフィードバックを、必ず毎日事業部の夕会で共有できるようにしているんです。

また、夕会だけでなくSlackやAirtableを活用し、機能の最新リリース予定や今後の開発予定情報まで、商談中も即時確認や質問ができるようにしています。なので、お客様から商談中に「この機能は無いの?」と質問があっても、その場で解決できることも多いです。

ウィークリーベースの動きとしても、毎週金曜日にデモ会を開いてるのは特徴的なものかと思います。

デモ会では、その週の開発した機能を営業、カスタマーサクセスに紹介、場合によってはハンズオンで一緒に新しい機能を使ってみる、ということも実施しています。一緒にプロダクトを実際に触る機会を頻度高く設けるようにしています。また、デイリーで上がってきた要望の棚卸や優先順位付けも、金曜に合わせて実施しています。

SECTION
/

鍵を握った「MSP」をメインに盛り上がった質疑応答

本勉強会では、牧迫氏によるSaaS立ち上げに関する説明が終わったあと、質疑応答の時間が設けられた。質疑応答タイムには、ラクスルのSaaS事業責任者や事業開発職メンバーから次々と質問が寄せられ、活発なやり取りが行われた。

まず挙がった質問が、LayerX インボイス躍進のきっかけとなったMSPについて。「LayerX インボイスにとってのMSPとは何か」という問いかけに対し、牧迫氏は次のように答えた。

牧迫LayerX インボイスは経理プロダクトであるため、他の領域と比べ特殊だと思う部分も多いのですが個社毎の運用要件や内部統制の観点で必要な要件が大きかった。これは価値検証の段階では出てこない要望であり、例えば、アプリ連携ができる人は誰なのか、仕訳を入力した際に編集できる人は誰なのかなど、権限管理に関するものが多い。上場企業であれば監査法人に説明している業務プロセスがあり、そこを変えるのはヘビーなプロセスになってしまうこともあります。

そのため、ユーザー側が普段行っている業務の流れを大きく変えないかたちでのプロダクト導入を提案できるか、あるいは業務の流れが変わるとしてもプロダクトの機能等でカバーできるか、という観点で考えることが多かったですね。

また、同じくMSPに関して、「この機能があれば導入するかをストレートに聞いて作っていたのか」「さまざまな要望がある中で、開発判断はどうしていたのか」といった質問も寄せられた。

牧迫欲しい機能については、リリース後の最初の2カ月は、例えばコンペに負けた際にストレートに「この機能があったらうちのサービスを使いますか」と聞いていました。それが、いわゆる運用要件への対応が必要だという気づきにつながっています。

開発判断においては先程説明したような「毎週金曜日の優先順位付け」を経て、最終判断はプロジェクトマネージャーが行っています。ただ、LayerX インボイスはリリースしたばかりのサービスということもあり、導入事例がほしい業界や、目指したいターゲット属性企業に必要とされる機能なのかどうかといった視点で議論することもあります。

議論の結果、将来的に目指したいところと合致するならば優先して開発し、そうでないなら先送りにするといった具合です。

ラクスルのSaaS事業に携わるメンバーからは、「いろいろなところから要望をいただけてありがたいが、Backlogにすべてを入れていったら限りない数になり、プライオリティをどこに置くのかといった問題が起きる。LayerX インボイスでは何にフォーカスをかけているか」といった質問が寄せられた。

牧迫非常に難しいが、弊社では一旦顧客からの要望はすべてBacklogに乗せる運用をしています。Backlogは数千存在し、それ毎週棚卸をしていく中で、一定期間が経つと共通点が見えてくる。多くの企業から言われているのであれば、追加すればみんな使うだろうと判断し、Airtable上で投票をしている感じですね。

あとはちょっとぶっちゃけになりますが(笑)、やっぱり導入企業さんを紹介することはマーケティング上で非常に重要なので、その層が導入に必要とする機能はどれだろうと見ていきながら絞り込んでいく感じですね。

SaaSサービスは本格導入前に無料トライアル期間を設けているものがあり、LayerX インボイスもそうした一つだ。有償での契約につなげるため、どのようなコミュニケ―ションを取っていけばいいのかといった疑問も投げかけられた。

牧迫経理プロダクトのため、コミュニケーション頻度にはムラがあります。前提として、経理が忙しい月末月初には積極的には連絡を取りません。(ここの詳細は本当にリアルなため、割愛させていただきます)

SaaSプロダクトで解決する課題の領域の特性に応じて、無料トライアルの進め方や期間を柔軟に変えているのだという。提供する側としては、一律で「〇日間」といったかたちでトライアル期間を決めたいと考えてしまいがちかもしれない。しかしそうではなく、その後の導入やプロダクトのさらなる開発・改善に向け、より良いかたちのフィードバックがもらえるような制度設計が重要である、そんな受け取りもできる。

SECTION
/

導入企業は何を抱え、サービスを見ているのか。
ラクスルの事例から学ぶ

LayerXインボイスの立ち上げストーリーの中でも触れられていたラクスルにおける導入の事例。一度見送ったサービスを導入するに至った背景について、導入企業側であるラクスルの平佐氏からも言及があった。企業側が抱えるペインやシステムを見る上での観点は、一体どのようなものなのだろうか。

平佐各部署において購入したり納品したモノの情報が経理にうまく連携されていないという問題はどこの会社でも起こりうる話と思います。

弊社でも過去には請求書を月初にもらっても誰がどういう経緯で発注したのかがわからず、まずは発注者を探すところからスタート、ということもありました。最近では台帳管理を徹底した結果そこまでの事例は少ないですが、それでも受け取った請求書を見て数字を手入力する作業は依然として残ってしまっていました。

こうした状況が、LayerX インボイスを導入して劇的に改善しました。

1回目にご提案いただいた際に導入を見送った一番の理由は、支払データの確認に手間がかかりすぎるというものでした。LayerXを通さずにfreeeに記帳した振込データとLayerXで生成した振込データを見比べてダブりや欠けが無いかの整合チェックが必要になるという仕様だったため、とても導入は現実的ではないと思い、見送らせていただきました。

その後2度目のご提案を頂いたのはわずか半年後のことだったのですが、上記の問題が解消されていただけではなくfreeeとの連携機能も強化されていてなによりUIも全く別のシステムかと思うほど劇的に向上していて驚きました。合わせて当時リリース直後だった「LayerXワークフロー」もご提案いただき長年の課題でもあった部署間の連携もスムーズにいくことが期待できたため、正式導入を決めました。

導入開始後、円滑に回り始めていると語る平佐氏。今回の導入を通して得た学びは何だったのだろうか。

平佐「全部盛り」の機能を押し付けないということですね。

LayerX の支払データ作成機能は弊社では使わないことにしたのですが、月次の業務フローを抜本的に改善できており、とても満足しています。

また連携させる会計システムに合わせてUIをカスタマイズして作りこんでいる点は本当に驚きました。会計システムと壁を感じさせない見た目なので、違和感なくスムーズに使えるのだと思います。またSlack上で承認できるワークフローはとても便利で他部署のメンバーからも使いやすいと評判です。

今回プロダクト開発やユーザーのサポート体制の裏側をじっくりとお伺いできて、非常に納得するとともに勉強になりました。今回の学びを弊社のプロダクト開発にも活かしていけたらと思っています。牧迫さん、貴重なお話を頂きましてありがとうございました。

こちらの記事は2021年11月15日に公開しており、
記載されている情報が異なる場合がございます。

記事を共有する
記事をいいねする

おすすめの関連記事

会員登録/ログインすると
以下の機能を利用することが可能です。

When you log in

新規会員登録/ログイン