SaaS企業はなぜ「顧客の声を聞いているのに成長しない」のか ── 御用聞き開発と仮説検証の構造的断絶

関連記事：

第1章：「顧客の声を聞いている」のに成長しない

「顧客の声を聞いてプロダクトを作っています」──シリーズA前後のSaaS企業で、これを言わない経営者はいない。顧客インタビュー、VoC収集、NPS。ツールも仕組みも揃っている。CSが吸い上げた要望はバックログに積まれ、開発チームが順番に消化していく。プロセスとしては回っているように見える。

なのにARRが伸びない。チャーンが止まらない。シリーズBの調達に必要なトラクションが出ない。

前回の記事では、この問題を「人材のインセンティブ構造」から論じた。ビジネス側には決裁者レベルの商談を作る力が組織的に不足しやすく、プロダクト側には顧客の業務構造を深く理解するインセンティブが設計されていない、という構造だ。

本記事では、その帰結としてプロダクト開発の現場で何が起きるのかを論じる。

第2章：「言われたものを作る」と「市場が求めるものを作る」の違い

御用聞き開発と仮説検証型開発の違い

「顧客に言われた機能を作る」と「市場が求める機能を作る」は、日常の開発現場では区別されにくい。どちらも顧客の声から始まり、開発チームが機能を作る。バックログに積まれるチケットの見た目は同じだ。

だが、この二つのプロセスには構造的な違いがある。

顧客に言われた機能を作る（御用聞き開発）は、目の前の顧客が「これが欲しい」と言ったものをそのまま実装することだ。顧客Aが「ダッシュボードにこのグラフを追加してほしい」と言えば、そのグラフを追加する。顧客Bが「CSVエクスポートの項目を増やしてほしい」と言えば、項目を増やす。要望を受け、チケットを切り、実装し、納品する。

市場が求める機能を作る（仮説検証型開発）は、複数の顧客の声や行動データの裏にある共通の課題を抽出して、「この課題をこう解けば、まだ出会っていない顧客にも刺さるはずだ」という仮説を立てて検証することだ。顧客Aが「グラフが欲しい」と言い、顧客Bが「レポートを自動化したい」と言い、顧客Cが「経営会議用の数字をすぐ出したい」と言ったとき、その裏にある共通課題──「データを意思決定に使える形にするまでの手間」──を抽出し、個社の要望とは異なる切り口で解く。

Eric Riesが『The Lean Startup』（2011年）で体系化した「Build-Measure-Learn」のフレームワークは、この仮説検証型のプロセスそのものだ。仮説を立て、最小限のプロダクト（MVP）で検証し、結果から学んで次の仮説を精緻化する。

二つを分けるのは「Why」の有無

この二つの間にあるのは「Why」だ。

顧客が「この機能が欲しい」と言ったとき、その要望をそのまま受け取るのか、「なぜそれが必要なのか」「本当に解きたい課題は何か」を掘るのか。

掘った結果、顧客自身が言語化した要望とは異なる解き方が見つかることがある。そしてその解き方の方が、他の顧客にもスケールする可能性がある。SaaSの価値は1対Nの構造にある。一社のために作った機能は一社にしか価値を提供しないが、構造的な課題を解く機能は全ての顧客に価値を提供しうる。

「Whyを掘る」と書くと簡単に聞こえるが、実際にはこれがプロダクトマネジメントの中で最も難しい仕事の一つだ。顧客の業務構造を深く理解していなければ、何が個社固有で何が業界共通かの切り分けができない。前回の記事で論じた「ドメイン知識の蓄積が構造的に不足している」問題が、ここで直接効いてくる。

御用聞きと「初期顧客への深い対応」の境界

ここで一つ重要な留保がある。初期フェーズのSaaS企業が少数の顧客の要望に深く応えること自体は、御用聞きとは限らない。

いわゆる「ランド&エクスパンド」──少数の顧客に深く入り込み、その顧客のオペレーションを徹底的に理解した上で、同じ構造を持つ他の顧客に横展開する──は、仮説検証の一形態だ。違いは、その対応の目的にある。「この顧客を満足させること」が目的なら御用聞きだが、「この顧客を通じて業界共通の課題構造を理解すること」が目的なら仮説検証だ。

自分自身、複数のSaaS企業でバックログの運用を見てきた中で、この境界が明確に設計されていないケースが多かった。「初期顧客の要望に応えている」のか「仮説を検証している」のかが区別されないまま開発が進み、気づけば個社最適化が進んでいる。この二つを分けるのは、バックログの一つ一つに「この対応は何を検証しているのか」という問いが紐づいているかどうかだ。

第3章：御用聞き開発に流れる構造的な力学

なぜ御用聞きの方が「楽」なのか

御用聞き開発には、組織力学的に流れやすい構造がある。

第一に、責任の所在が曖昧になりやすい。 顧客に言われた機能を作って失敗しても、「顧客の要望通りに作った」という免罪符がある。判断の責任を誰も取らなくていい。一方、仮説に基づいて作った機能が外れた場合、仮説を立てた人間──PdMやCTO──の判断が問われる。

第二に、社内の合意コストが低い。 「顧客がこう言っている」は組織内で最も強い根拠になりやすい。セールスが「この機能がないと失注する」と言い、CSが「これがないとチャーンする」と言えば、それに反論するのは難しい。仮説に基づく開発は「顧客はそう言っていないが、こう解くべきだ」と主張することであり、社内の反発を引き受ける覚悟が必要になる。

実際にこの力学はこう現れる。PdMが「この機能は個社固有の要件で、他社には不要」と判断しても、セールスが「この顧客は年間契約の更新を控えている。この機能がなければ解約される」と経営会議で主張すれば、PdMの判断は覆される。実装後、その顧客は更新するが、同じ機能を使う他の顧客は現れない。半年後、要望を出した顧客自身もその機能をほとんど使っていない。このような力学は、規模や業界を問わず繰り返されている。

第三に、短期的には成果が見えやすい。 顧客の要望を実装すれば、その顧客は一時的に満足する。「顧客の声を聞いて改善しました」という報告がしやすい。仮説検証は、外れることの方が多い。短期的な成果が見えにくく、組織内で「何をやっているのかわからない」と見なされやすい。

仮説に基づく開発に対する組織的な反発

ここに、あまり語られない力学がある。仮説に基づく開発は、組織の中で反発を受けやすい。

仮説を立てるということは、PdMやCTOが「これが正しい」と主張することだ。それは暗黙のうちに、「セールスが持ってきた顧客の声は、そのままでは正しくない」と言っていることになる。「エンジニアが作りたいものと、作るべきものは違う」と言っていることにもなる。

前回の記事で論じたように、日本のSaaS企業ではPdMの権限が組織的に確立されていないケースが多い。プロダクトの方向性に対する最終的な意思決定権がPdMに設計されていない。すると、PdMが仮説に基づいて優先度を決めても、セールスの声で覆されたり、エンジニアが「自分の方が正しい」と判断して勝手に別の実装を進めたりする。

この力学の下では、仮説を立てて主張するより、顧客の声をそのまま流す方がはるかに摩擦が少ない。PdMの役割が「顧客が言っています」と伝言する機能に矮小化され、バックログの管理業務に収斂していく構造が生まれやすい。

第4章：御用聞き開発がSaaSを壊すメカニズム

個社最適化のスパイラル

御用聞き開発が続くと、SaaSの構造が内側から壊れていく。

フェーズ1：機能の断片化。 顧客Aのために作った機能、顧客Bのために作った機能が、整合性なく積み上がっていく。プロダクトの設計思想が希薄なまま機能が増えるため、UIは複雑化し、コードベースは肥大化する。

フェーズ2：保守コストの増大。 個社向けの機能が増えるほど、保守とサポートのコストが増える。エンジニアのリソースが新規開発ではなく保守に食われる。CSのオンボーディング工数が増え、一社あたりのサポートコストが上がる。

フェーズ3：スケーラビリティの喪失。 SaaSの価値は「同じプロダクトを多数の顧客に提供する」ことで限界費用を下げることにある。だが、個社向け機能が増えた結果、実質的に「顧客ごとにカスタマイズされたプロダクト」になっていく。これは受託開発と同じ構造だ。売上は1対1で人件費に比例し、SaaSの粗利構造が失われる。

SaaSの粗利率のベンチマークは75%以上が健全とされ、上位層は85〜90%に達する。一方、プロフェッショナルサービスや個社カスタマイズの比率が高い企業では、この水準を大きく下回る。Benchmarkitの分析では、サービス収益がTotal Revenueの15〜20%を超え、かつサービス粗利率が30%未満の場合、Total Gross Marginは中央値の77%を下回るとされている。個社最適化が進んだSaaS企業の粗利率が低いのは、構造的にSaaSではなく受託に近づいているからだ。

フェーズ4：プロダクトの増殖。 一つのプロダクトが個社最適化で行き詰まると、「新しいプロダクトを作ろう」という判断が生まれやすい。だが、仮説検証の能力が組織にないまま新プロダクトを作っても、同じことが繰り返される。プロダクトの数だけが増え、どれも中途半端になり、開発リソースが分散する。

このフェーズ1〜4のスパイラルには、フェーズ2からフェーズ1に逆流する経路もある。保守コストの増大に対して「もっと機能を追加して顧客の要望に応えよう」とする判断が下されると、断片化がさらに加速する。この逆流ループに一度入ると、開発リソースの大半が保守と新規の個社対応に食われ、構造的な課題に取り組む余裕がなくなる。

ただし、このスパイラルが不可逆とは限らない。個社最適化を経由して汎用化に転換する経路は存在しうる。少数の顧客向けに作り込んだ機能の中から、業界共通の構造的課題を事後的に抽出し、プロダクトを再設計するケースだ。これが機能するには、「個社向けに作ったものの中から共通構造を見出す」というプロセスが意図的に設計されている必要がある。意図なく個社最適化を続けた結果たまたま汎用化できた、という経路は構造的に期待しにくい。

さらに大きな視点での反例もある。SalesforceやSAPのように、カスタマイズ性そのものをプラットフォームの価値として設計し、個社対応をエコシステム（SIパートナー、AppExchange等）に委ねるモデルだ。このモデルでは、個社最適化はベンダー自身のリソースを食わず、むしろプラットフォームの粘着性を高める。ただし、これは膨大な開発リソースとパートナーエコシステムを前提とした構造であり、数十人規模のスタートアップが取れる戦略ではない。本記事が論じているのは、そのスケールに到達する前のフェーズでの構造だ。

「御用聞き」がプロダクト戦略レベルで起きるとき

ここまでは個社の機能要望に応える「御用聞き開発」を論じてきたが、同じ力学がプロダクト戦略レベルでも起きることがある。

業務領域によっては、顧客の業務が本質的に複雑で、関連する要素が多いことがある。たとえばHR Techの領域では、採用管理、勤怠管理、給与計算、労務手続き、人事評価、エンゲージメント測定など、多くの要素が絡み合っている。建設テックでも、施工管理、図面管理、工程管理、安全管理、原価管理と、関連要素が多い。「全部揃っていないと現場が回らない」という顧客の声は、実態を反映していることが多い。

だが、「市場にニーズがある」ことと「一つのスタートアップが全部作るべきである」ことはまったく別の話だ。

数千人規模の大企業がフルスイートで提供するのは合理的だ。開発リソースも、ドメイン知識も、サポート体制も揃っている。だが、数十人規模のスタートアップが同じことをやろうとすれば、一つ一つが薄くなるだけだ。スタートアップがやるべきは、複雑な領域の中で「ここだけは誰にも負けない」という一点を作り、その一点を深掘りして育てることだ。

ところが、顧客が「全部欲しい」と言い、セールスが「フルスイートでないと売れない」と言い、競合が「うちは全部揃っています」と言う。この圧力に負けて横に広げた結果、どのプロダクトも競合に劣る中途半端な状態になる。最初の一点で築いた優位性すら、リソース分散によって維持できなくなる。

個社の機能要望にそのまま応えるのが御用聞き開発なら、市場の「全部欲しい」にそのまま応えようとするのは御用聞きの事業戦略だ。どちらも「Whyを掘らずにWhatを足す」という同じ構造に根ざしている。「なぜ顧客は全部欲しいと言うのか」「その中で本当に自社が解くべき課題はどれか」「一点突破でシェアを取ってから広げる方が合理的ではないか」──この問いを立てずに、言われるままプロダクトを増やしていけば、フェーズ4の増殖に直結する。

この罠は、ホリゾンタルSaaSに限った話ではない。バーティカルSaaSでも同じ構造が生まれる。特に陥りやすいのが物流テックだ。「物流向けSaaS」は一見バーティカルだが、物流の中には倉庫管理、配送最適化、ラストマイル、3PL管理、荷主向けシステムなど、それぞれ異なるオペレーションと課題を持つセグメントが存在する。しかも物流は荷主・倉庫・運送会社・ドライバーと関与者が多く、「あの機能もこの機能も必要」という圧力が構造的に強い。「物流向け」と括った時点で、実質的にはバーティカルの中でホリゾンタル化していく。どのセグメントにも中途半端に手を出し、どれも専業プレイヤーに勝てない。バーティカルに攻めること自体は正しくても、その中でさらに「誰の、どんな規模の、どんな課題を解くのか」まで絞らなければ、結局は同じ問題に行き着く。バーティカルSaaSの構造的な難しさについては、以前の記事「ラクスルが印刷で勝ち物流で苦戦する理由」でも、業界ごとの壁の違いという観点から論じている。

この構造は、前回の記事で論じたBPaaS化と同根の問題だ。プロダクトで解決すべきことを「人で埋める」か「新しいプロダクトで解決しようとする」かの違いはあるが、どちらも「仮説検証をしてプロダクトを育てる」という本質的な作業を回避している点では同じだ。

「成長しているように見える」という罠

厄介なのは、御用聞き開発を続けている間、一時的に数字が伸びることがあることだ。

顧客の要望を叶えるたびに、その顧客の満足度は上がる（少なくとも短期的には）。新しい機能をリリースするたびに、マーケティング素材が作れる。「今期は〇個の新機能をリリースしました」という報告ができる。

だが、これは成長ではなく膨張だ。売上に対してサポートコストが比例して増えていくため、粗利は改善しない。個社向け機能を訴求しても、その機能が刺さる見込み顧客は限定的で、新規獲得のスケーラビリティがない。

VCがシリーズBで見るのは、この「膨張と成長の区別」だ。ARRが伸びていても、粗利率が低く、NRR（Net Revenue Retention）が伸びず、顧客獲得の再現性が見えなければ、「このプロダクトはスケールしない」と判断される。NRRの業界中央値はベンチャー支援SaaSで106%前後、B2B SaaS全体では101%とされ、上位層は120%を超える（ChartMogul 2,100社超の分析、Benchmarkit 2024年実績）。御用聞き開発の度合いとNRRの直接的な相関を示すデータは存在しないが、個社向け機能は他の顧客のアップセル・クロスセルにつながりにくく、拡張収益が構造的に生まれにくいと考えられる。

シリーズAから先に進めない企業の多くが、この構造に嵌まっている。

第5章：仮説検証はなぜ難しいのか ── 能力の問題ではなく、構造の問題

「やればいい」では解決しない理由

ここまで読んで、「仮説検証をやればいいじゃないか」と思うかもしれない。だが、仮説検証が回らないのは個人の能力の問題ではなく、組織の構造に起因している。

仮説を立てる機能が組織に設計されていない。 仮説を立てるには、顧客の業務構造を深く理解した上で、「個社の声」と「市場の構造的課題」を切り分ける能力が必要だ。前回の記事で論じたように、Web系キャリアのエンジニアにはドメイン知識の蓄積が構造的に不足している。加えて、PdMにコンサル出身者が就くケースでは、ドメイン知識はあってもプロダクト開発プロセスを回す経験が不足していることが多い。仮説を立てるべき役割に、仮説を立てるための素材や経験が蓄積されていない。

仮説の検証サイクルを回すプロセスがない。 仮説検証は「仮説を立てる → 最小限のプロトタイプを作る → 顧客に当てる → 結果を見て修正する」というサイクルを高速で回すことだ。だが、多くのSaaS企業ではこのサイクルが設計されていない。バックログは「顧客要望の一覧」であって「仮説の一覧」ではない。開発サイクルは「要望を実装してリリースする」ことに最適化されていて、「仮説を検証して学びを得る」ことに最適化されていない。

仮説が外れたときの組織的な受容力がない。 仮説検証は、外れることの方が多い。外れたこと自体が学びであり、次の仮説の精度を上げる。だが、「仮説が外れた＝失敗」と捉える組織では、仮説を立てること自体が避けられるようになる。

なぜ「外れた＝失敗」と捉えるのか。これは意識の問題ではなく、評価と報告の構造に起因している。四半期ごとのOKRやKPIで「機能をN個リリースした」「顧客の要望をN件処理した」が成果指標になっていれば、仮説が外れた試行は「成果ゼロ」と計上される。開発チームが経営に報告する際に「3つの仮説を検証し、2つは棄却、1つは有望」と言えるフォーマットが存在しなければ、外れた仮説は隠されるか、最初から立てられなくなる。Riesが『The Lean Startup』で「イノベーション会計」と呼んだのは、まさにこの種の学習プロセスを組織的に計測する仕組みのことだ。

CTOとPdMの不在が致命的になるフェーズ

シリーズA前後──PMFを達成した（あるいは達成したとみなされた）段階で、シリーズBに向けてスケールを目指すフェーズ──は、CTOとPdMが最も機能すべきフェーズだ。このフェーズでの仕事は「作る」ことではなく「何を作るかを見極める」ことだからだ。

CTOが技術の意思決定だけでなく、プロダクトの仮説検証に関与しなければ、開発チームは「来た要望を順番に消化する」作業に埋没する。PdMが顧客の声を「伝言」するだけでなく、構造的な課題を抽出して仮説に変換しなければ、バックログは御用聞きの記録簿になる。

前述の通り、「この課題は個社固有か、業界共通か」「この機能はスケールするか、しないか」を判断できる機能が組織に設計されていない。設計されていても、その判断を組織として通す権限が備わっていない。結果として、セールスの声やエンジニアの好みが開発の方向性を決め、プロダクトは一貫性を失っていく。

第6章：ピボットは仮説検証ではない

「何度もピボットしてきた」という自己認識

ピボットと仮説検証の区別自体は、スタートアップの文脈で広く語られている。だが、この区別が重要なのは、本記事で論じている御用聞き開発の構造と直接つながるからだ。

SaaS企業の創業者が「何度もピボットして、やっと刺さるプロダクトを見つけた」と語ることがある。一見すると、これは仮説検証を繰り返してPMFに到達したストーリーに見える。だが、ピボットと仮説検証は似て非なるものだ。

ピボットとは、方向転換だ。 プロダクトAがうまくいかなかったから、プロダクトBに切り替える。BもダメだったからCに。この行為自体は経営判断として正しい場合もある。だが、ピボットは「次に何をやるか」を決める行為であって、「なぜ前がダメだったか」を解明する行為ではない。

仮説検証とは、学習のサイクルだ。 「この課題を、この顧客に、このソリューションで解けるはずだ」という仮説を立て、最小限のプロトタイプで検証し、結果を分析して次の仮説の精度を上げる。外れた仮説からの学びが蓄積され、組織の理解が深まっていく。

PDCAのCheck/Actが抜けたピボットの構造

この区別が重要なのは、多くのスタートアップが「ピボットした」と自己認識していることの中身が、実際には「作ってみた → うまくいかなかった → 別のものを作ってみた → またうまくいかなかった」の繰り返しである場合が多いからだ。

PDCAサイクルに当てはめると、Plan（仮説）→ Do（実行）→ Check（検証）→ Act（改善）のうち、CheckとActが抜け落ちている。「Do → Do → Do → Do」だ。方向だけ変えて、同じやり方を繰り返す。

仮説検証が機能している組織では、ピボットの前に以下のプロセスがある。

1. なぜうまくいかなかったのかを構造的に分析する。 顧客の課題設定が間違っていたのか、ソリューションの方向性が間違っていたのか、ターゲット顧客のセグメントが間違っていたのか。

2. 前の試行から得た学びを言語化する。 「この業界の顧客は、この課題には金を払わない」「この機能は刺さるが、この価格帯では採算が合わない」。

3. 学びを踏まえて、次の仮説の精度を上げる。 前回の失敗を繰り返さない形で、次に何を検証すべきかを設計する。

このプロセスが回っていれば、ピボットのたびに仮説の精度が上がり、PMFに近づいていく。だが、このプロセスが回っていなければ、ピボットはただの方向転換であり、次のピボットでも同じ種類の失敗を繰り返す。

ピボットの回数とPMFの距離は比例しない

「何度もピボットした」こと自体は、PMFに近づいている証拠にはならない。重要なのはピボットの回数ではなく、各ピボットの間に何を学んだかだ。

5回ピボットしても、毎回「うまくいかなかったから別のことをやる」だけなら、5回目のピボット先が正解である確率は1回目と変わらない。ランダムウォークだ。一方、1回のピボットでも「前回の失敗はターゲット顧客の選定ミスだった。業務構造を調べた結果、この業界のこの規模の企業にこそ刺さるはずだ」という分析があれば、2回目の精度は格段に上がる。

ただし、ここには反論もある。試行回数を増やすこと自体に、セレンディピティや市場タイミングとの遭遇確率を高める効果がないとは言えない。実際に「たまたま当たった」企業も存在するだろう。問題は、偶然でたどり着いた場合、「なぜ刺さったのか」を構造的に理解できていないことだ。理解できていなければ、スケールさせる方法も、次のプロダクトに応用する方法もわからない。

第7章：「最初のプロダクトが売れてしまった」という不幸

PMFなしに売れる市場の存在

ここまでの議論に対して、「うちの最初のプロダクトはPMFしたが、二つ目以降がうまくいかない」という反論があるかもしれない。だが、最初のプロダクトが本当にPMFしていたのかを疑う必要がある。

SaaSの領域には、プロダクトが参入する前から市場の課題が明確に存在し、ソリューションの方向性も広く認知されているカテゴリがある。名刺管理、経費精算、勤怠管理、電子署名。これらの市場では、「この課題にこのソリューションが刺さるか」を検証する必要性が低い。課題もソリューションも既に見えている。

こうした市場で最初のプロダクトが売れた場合、それは「仮説を立てて検証した結果、市場に刺さった」のではなく、「既に存在する市場に参入してポジションを取った」のかもしれない。営業力と、わかりやすい差別化ポイント（価格、UI、保証制度など）で一定の顧客基盤を築けてしまう。

これは「仮説検証なしに売れた」成功体験だ。

成功体験が次のプロダクトを殺す

問題は、この成功体験が組織の行動パターンとして定着することだ。

最初のプロダクトが「顧客の声を聞いて機能を追加していたら売れた」という経験をした組織は、二つ目以降のプロダクトでも同じアプローチを取る。だが、二つ目のプロダクトが「既に市場が存在するカテゴリ」に属しているとは限らない。新しい課題を解くプロダクトや、既存カテゴリとは異なる切り口で市場を作るプロダクトでは、仮説検証なしに売ることはできない。

ところが、組織には仮説検証の能力が育っていない。最初のプロダクトで不要だったから。顧客の声をそのまま聞くプロセスは整っているが、顧客の声の裏にある構造的課題を抽出するプロセスは存在しない。

結果、二つ目のプロダクトも御用聞き開発に陥る。それがうまくいかないから三つ目を作る。三つ目もうまくいかない。プロダクトの数だけが増え、どれも育たない。開発リソースは分散し、一つ一つのプロダクトの改善速度が落ちる。

この「プロダクトを増やしてどれも育たない」パターンは、日本のSaaS企業で少なくない。複数のSaaS企業にプロダクト側から関わる中で、この構造を何度か目にしてきた。体系的な調査に基づく主張ではなく、複数の現場での観察からの仮説だが、再現性のあるパターンだと考えている。その根本にあるのは、最初のプロダクトが「仮説検証なしに売れてしまった」ことで、組織に仮説検証の文化が根づかなかった、という構造だ。

第8章：シリーズAから先に進めない構造的理由

シリーズAまでは「作って売る」でなんとかなる

シリーズAの調達は、プロダクトのプロトタイプと初期顧客の存在があれば成立することが多い。創業者の熱量、プロダクトのビジョン、初期トラクション。VCが見るのは「この市場に、このチームが挑む価値があるか」だ。PMFの達成が厳密に求められるわけではない。

だが、シリーズBに進むには質的な転換が必要になる。VCが見るのは再現性だ。「なぜ売れたのか」を構造的に理解し、「どうすればもっと売れるか」を設計できているか。顧客の獲得と維持が属人的ではなく、仕組みとして回っているか。

Cartaが10,755社の米国シリーズA企業を分析したデータによれば、シリーズAからシリーズBへの到達率は、4年経過時点で40〜50%程度とされている。裏を返せば、半数以上の企業がシリーズBに到達できていない。この「進めない企業」の中に、御用聞き開発でスケーラビリティを失ったケースが含まれていると考えるのは、不自然ではないだろう。

この再現性は、御用聞き開発からは生まれない。なぜなら、御用聞き開発で得られるのは「顧客Aにはこの機能が刺さった」「顧客Bにはこの機能が刺さった」という個別の事実であって、「なぜ刺さったのか」「他の顧客にも刺さるのか」という構造の理解ではないからだ。

仮説検証が回っていれば、「この仮説は当たった」「この仮説は外れた」「外れた理由はこれだ」という学びが蓄積される。この蓄積が、プロダクトの方向性を定め、セールスの訴求を一貫させ、CSのオンボーディングを標準化する土台になる。御用聞き開発にはこの蓄積がない。

「目先の売上」と「PMFの探索」の構造的対立

シリーズA後の企業は、二つの圧力の間に立っている。

一方には「次のラウンドのためにARRを伸ばせ」という圧力がある。投資家からの期待、ランウェイの制約、社内のコミットメント。この圧力は、目先の売上を取りにいく行動──来た案件を全部取る、顧客の要望を全部叶える──を誘発する。

他方には「PMFを確認し、スケーラブルなプロダクトを作れ」という要請がある。だが、PMFの探索は短期的にはARRに貢献しない。仮説が外れれば、開発リソースを「無駄に」使ったことになる。

多くのSaaS企業が目先の売上の方を選ぶ。これは経営者の判断が間違っているというより、ランウェイが短い状況では構造的にそうならざるを得ない面がある。18ヶ月のランウェイで「仮説検証に6ヶ月使って、3ヶ月で方向転換して、残り9ヶ月でスケールさせる」と計画しても、最初の仮説が外れた時点で組織はパニックになる。

ここに、資金調達の構造が影響している。シリーズAで十分な資金を調達し、24ヶ月以上のランウェイを確保できていれば、仮説検証に投資する余裕がある。だが、調達額が不十分だったり、バーンレートが想定以上に高かったりすると、仮説検証にリソースを割く余裕がなく、目先の売上を取りにいくしかなくなる。

そして、目先の売上を取りにいった結果、プロダクトは御用聞き開発で個社最適化され、スケーラビリティを失い、シリーズBで必要なトラクションが出ない。資金が尽きかけた段階で慌ててコストを切り詰め、「生き延びた」としても、仮説検証の能力は組織に蓄積されていない。

第9章：構造のまとめ

前回の記事で、人材のインセンティブ構造がSaaS企業の成長を阻害する構造を論じた。本記事はその帰結を論じている。

ドメイン知識が蓄積されないから、仮説を立てる素材がない。PdMの権限が確立されないから、仮説を通す力がない。マネジメント層が不足しているから、仮説が外れたときの修正ができない。そして仮説検証が回らないから、プロダクトは御用聞き開発に堕ちる。

御用聞き開発は、短期的にはプロセスとして回っているように見える。顧客の声を聞き、要望を実装し、満足度を上げる。だがその帰結は、機能の断片化、保守コストの増大、スケーラビリティの喪失だ。膨張を成長と錯覚したまま、シリーズBで必要な再現性が生まれない。最初のプロダクトが仮説検証なしに売れた成功体験がこの構造を固定し、二つ目以降のプロダクトでも同じ轍を踏む。

前回と本記事を通して見えるのは、これが個別の問題ではなく連鎖する構造だということだ。人材のインセンティブが歪んでいるから、開発プロセスが歪む。開発プロセスが歪んでいるから、プロダクトがスケールしない。プロダクトがスケールしないから、次のラウンドに進めない。どこか一箇所を直しても、他の箇所が元に戻す力学が働く。

顧客の声を聞くこと自体が問題なのではない。聞いた声を、どう扱うかの問題だ。「言われたものを作る」から「言われたことの裏にある構造を解く」への転換は、シンプルだが構造的に難しい。それを個人の意識改革ではなく、組織の仕組みとして設計できるかどうかが、SaaS企業が次のフェーズに進めるかどうかを分けるのではないかと思っている。

2026年4月