第8回:初期費用を小さくし、確実性を上げる｜ゼロリセットで考える、強い会社の設計論

本稿の用語

用語	意味
プレPMF	PMFの一つ前の段階。 プロダクトを本格的に作る前に、課題の深さ、支払意思、 継続性などを検証するフェーズ
POC	技術的・概念的に実現できるかを確かめるための試作・検証。 「概念実証」と訳される
MVP	最小限の機能を備えた製品。市場の反応を見るために、 必要最低限の状態でリリースする
ROI	投じた費用に対して、どれだけの効果が得られるか。投資対効果
リファラル	社員や経営者の人脈による紹介・推薦を通じて、人を採用すること

前回まで、強い会社の構造と、その前提となる生成AIの話を書いてきました。ここから先は、その構造をどう立ち上げるか、という方法論の話に入ります。今回は、初期費用を抑えながら、確実性を上げる事業開発の話です。

スタートアップに失敗はつきものです。これはよく言われることですし、自分もその通りだと思います。新しいことをやる以上、不確実性は必ず残ります。ただ、本当に問題なのは、失敗そのものではなく、高すぎるコストを払った後で、間違いに気づくことだと考えています。

業界では、BtoB製造業向けの本格的なソフトウェア開発に、3億円から6億円規模の費用がかかることが珍しくありません。エンジニア、プロダクトマネージャー、デザイナー、営業、サポート、インフラ、セキュリティ、外部連携、管理機能。一つひとつは妥当に見えても、積み上げれば簡単にこの規模になります。

ここで起きやすいのは、これだけの費用と時間をかけて作ったものが、思ったほど使われないことに、完成してから気づくという状況です。導入されにくかった、支払意思が弱かった、現場に定着しなかった、想定していた課題はそれほど深くなかった。学習として、これは遅すぎます。

経営は、期待値のゲームだと思っています。期待値は、成功したときのリターンだけで決まるのではなく、成功確率、失敗時の損失、学習速度、再挑戦できる回数によって決まります。初期費用を小さくできれば、同じリスクを取っても、挑戦の質がまるで変わります。失敗しても致命傷にならない。早く学べる。修正できる。次の仮説に進める。これは、戦略の話というより、生存の話です。

重要なのは、失敗をゼロにすることではなく、失敗から学ぶ費用を、できる限り小さくすることだと思っています。

業界で3億円規模かかる開発も、構造の見直しによって一桁近く圧縮できる手応えがあります。これは魔法ではなく、順番を変える、という話です。いきなり大きく作らない。最初から完成形を目指さない。顧客が本当に価値を感じる部分を見極める。UI・UXと要件定義によって、実装前にできる限り深く検証する。これに加えて、パートナー企業との協力関係も、開発費の圧縮には大きく効いていますが、ここは次回で詳しく書きたいと思います。

この事業開発を成立させるために必要な要素を、自分なりに整理すると、四つに収まります。

一つ目は、事業・商品の魅力です。

ここで言う魅力は、「面白そう」という意味ではありません。顧客に明確な痛みがあり、その痛みが十分に大きく、現状の代替手段に不満があり、導入したときのROIが大きく、複数の会社に共通する課題であり、一社専用ではなく横展開できる普遍性がある。こういう状態のことです。

BtoB製造業向けソフトウェアでは、特に普遍性が重要だと思っています。一社の特殊事情に深く入りすぎれば受託開発になり、抽象化しすぎれば現場で使われない一般論になります。現場に深く刺さりながら、一社専用にはならない。個別の業務に向き合いながら、その裏側にある共通構造を見つける。ここに、プロダクト化の本当の勘所があるのだと思います。

二つ目は、プレPMFです。

PMFという言葉はよく使われますが、いきなりPMFを目指す前に、確認しておくべきことがたくさんあります。そもそも課題は本当にあるのか。その課題は深いのか。今はどうやって解決されているのか。その解決方法にどれだけ不満があるのか。誰が使うのか。誰が予算を持っているのか。いくらなら払うのか。その金額を払うために社内のどの稟議を通す必要があるのか。継続利用される理由は何か。解約されるとしたら何が原因か。これらを、開発前にできる限り確認しておきたい。

ここで一番気をつけたいのは、「欲しいです」という顧客の言葉を、そのまま信じないことです。顧客は悪気なく「欲しい」と言います。便利そうなら欲しい、無料なら使いたい、予算が関係なければ試したい。これは人間として自然な反応です。ただ、事業として知りたいのはそこではなく、本当にお金を払うのか、その金額を払うほど痛みが深いのか、社内で使われ続けるのか、ということです。ここまで確認しないと、事業の確実性は上がりません。

特に大事なのは、「継続される理由は何か」「解約されるとしたら何が原因か」を、開発前に確認しておくことです。第4回で書いた営業インセンティブ設計、第5回で書いたKPIと報酬の連動。これらは、継続を事業の前提に置く構造です。だとすれば、立ち上げの最初の段階から、継続される条件を見極めておかないと、構造は機能しません。プレPMFの段階で継続性まで踏み込んで確認しておくことは、事業構造の思想と、立ち上げ方を、最初から整合させる作業でもあります。

この検証段階で、今もっとも有効だと感じているのは、UI・UXだけを先につくる方法です。AIエージェントを活用することで、実装前にかなり高い精度で画面と操作体験を作ることができます。本番プロダクトではなく、裏側のロジックも、セキュリティも、データ基盤も、まだ存在していません。それでも、顧客から正確なフィードバックをもらうには十分な場合があります。

顧客は抽象的な事業アイデアには反応しにくいのですが、画面があって、操作の流れがあって、自分の業務のどこで使うかが見えると、反応は一気に具体的になります。このボタンは現場の誰が押すのか、この入力項目は現場では埋められない、この画面は管理者には良いが作業者には難しい、このレポートは毎週の会議で使える、このデータ連携がないと導入は難しい。こういうフィードバックが、開発前に取れます。これは前回書いた、AIエージェントを構造の前提に置くことの、具体的な応用例の一つです。

ここで気をつけたいのは、スタートアップの世界には、起業してPOCをやってMOCをつくってMVPを出して、という型として共有された流れがあるということです。この流れ自体が悪いわけではないのですが、型通りに進めることで「検証したつもり」になってしまうのが危険です。POCで検証できたのは技術的にできるかだけかもしれません。MVPで検証できたのは最低限動くかだけかもしれない。顧客に見せたとしても、支払意思までは確認できていないかもしれません。

工程を進めたことと、不確実性が減ったことを、混同しない。次の工程に進むことが大事なのではなく、最も重要な不確実性から順番に潰すことが大事です。その順番をどう設計するかが、たぶん事業開発の本当の仕事なのだと思います。

三つ目は、要件定義です。

初期費用を抑えるうえで、もっとも効くのがここだと感じています。要件定義を外すと、開発費は一気に膨らみます。機能が増え、例外対応が増え、顧客ごとの個別要望が増え、画面が複雑になり、運用も複雑になり、サポートも重くなり、後から作り直しが発生する。結果として、初期費用も保守費用も導入コストも、全部上がります。

ただ、要件定義というのは、顧客の要望をそのまま仕様にする作業ではありません。むしろ逆で、要望の奥にある本当の課題を見極める作業です。顧客が「この機能がほしい」と言ったとき、本当に必要なのは機能ではなく、業務フローの整理かもしれません。「データを見たい」と言ったとき、本当に必要なのはダッシュボードではなく、判断基準の標準化かもしれません。「現場で使いにくい」と言ったとき、本当に問題なのは画面ではなく、権限設計や教育プロセスかもしれません。言われたものをそのまま作るだけでは、事業は強くなりません。

そのうえで、自分が要件定義の本質だと思っているのは、UI・UXから逆算することです。

どの画面で、誰が、どんな操作で、業務のどこに入ってくるか。顧客がその画面に向き合ったときに、何に価値を感じ、どこに引っかかるか。ここを徹底的に詰めていくと、必要な機能、必要なデータの粒度、必要な処理の順序、必要な連携の輪郭が、自然に決まってきます。先に機能リストを作って後からUIを当てるのではなく、UXから要件を逆算する。これだけで、組み込まれる無駄の量が、かなり変わってきます。

そして、UI・UXから逆算した結果として、無駄が削ぎ落とされ、付加価値が高くなる、という構造になります。「何を削るか」を出発点にするのではなく、「顧客が何に価値を感じるか」を出発点にする。そこから逆算するからこそ、必要なものの輪郭が見え、結果として無駄が消えていく。順序が逆になると、機能リストから引き算する作業になり、本来必要なものまで削ったり、削れない理由を社内で抱え込んだりすることになります。

UXからの逆算は、AIエージェントとも相性が良いのです。AIで画面と操作体験を素早く立ち上げ、顧客の反応を見ながら何度も組み直す。その繰り返しの中で、要件の輪郭が固まっていきます。これも、前回書いた「AIエージェントを構造の前提に置く」ことの、具体的な応用です。

四つ目は、強い初期メンバーです。

ここまで書いてきた三つ、事業・商品の魅力、プレPMF、要件定義は、結局のところ、人が決めることです。事業の魅力を見抜くのも、顧客の本音を引き出すのも、UXから要件を逆算するのも、最後は人の判断にかかっています。だからこそ、初期メンバーの採用は、社長が自らリファラルで行うべきだと考えています。

初期メンバーは、単なる労働力ではありません。会社の判断基準そのものをつくる人で、顧客との信頼関係をつくる人で、要件定義の精度を決める人で、プロダクトの思想を決める人で、将来の会社グループの核になる人です。ここを外すと、どれだけ良い事業アイデアがあっても、実行のところで崩れます。

採用にあたって自分が見たいのは、性格の良さ、エネルギー、地頭の良さ、の三つです。学歴やこれまでの肩書きではなく、現実から学べる人か、顧客価値に素直に向かえる人か、広い仕事を引き受けられる人か、難しい状況の中でも考え続けられる人か。この三つが揃っている人は、業務スキルが多少不足していても、組織の中で短期間に伸びていきます。逆に、ここが揃っていない人を経歴で採ってしまうと、後から取り返すのが本当に難しい。

社長自らリファラルで採るというのは、効率の良いやり方ではありません。ただ、初期の会社においては、効率より精度が圧倒的に大事です。人を間違えると、開発費よりはるかに高くつく。これは経営者なら誰でも、頭では分かっていることだと思います。

この四つを真面目に積み上げると、初期費用を抑えながら、有償でのトライアル契約が複数始まり、ストック収益が積み上がり始めている、という状態は、十分に実現可能だと感じています。少なくとも、自分たちの現状の手応えは、その方向にあります。

初期費用を抑えるというのは、節約のことではなく、確実性を上げる設計のことです。事業の魅力を見極め、プレPMFで支払意思と継続性まで確認し、UXから要件を逆算し、強い初期メンバーで進める。この四つが揃えば、開発前に潰せる不確実性は驚くほど多くなります。

ただ、ここまで頑張っても、ゼロにはできない開発費が、必ず最後に残ります。BtoB製造業向けソフトウェアの場合、品質、セキュリティ、業務システムとの連携、顧客サポート。こうした領域には、構造的にこれ以上は圧縮できないラインがあります。

その残った開発費を、どう調達し、誰とどうリスクを分け合うか。そして、ここまでの開発費圧縮も、実は自分たち単独で成し遂げているのではなく、パートナー企業との協力関係によって支えられている部分が大きいのです。

次回は最終回として、資本参加でも借入でもない、信頼を構造に組み込んだ第三の形について書きたいと思います。