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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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