成長企業だけがやっている「仮説の回し方」

――PDCAは死んだ。その先へ進む企業は、何が違うのか

山口偉大 2026.04.06

こんにちは！山口です。

このニュースレターでは、企業のマーケティングや事業グロース戦略等について分析していきます。時折、ゲストを招いた対談記事なども配信していけたらと考えています。

ビジネス成長の”最強の武器”になるニュースレターを目指して配信していきますので、ぜひ応援のほどよろしくお願いします。

✓ レターのテーマ

・マーケティング
・事業戦略
・企業/事業分析
・汎用的なビジネスノウハウ
・キャリア論

登録する

まずは簡単な自己紹介から。略歴はこんな感じです。基本的には、起業家として活動しながらも「マーケティングや事業開発」が自分のキャリアの軸となっております。

山梨県出身、早稲田大学政治経済学部政治学科卒業。PR会社「株式会社ベクトル」にてPRコンサルタントとして従事したのち、「株式会社Branding Engineer（現株式会社TWOSTONE&Sons）」へ参画、各種人材・DX関連の事業立ち上げや事業部長・経営企画を歴任し独立。上場企業から地方の中堅・中小企業までありとあらゆる業種・規模感の新規事業開発 / マーケティング / ブランディング / PR支援等を実施。その後「Start-X合同会社」を設立。マーケティングや事業開発、クリエイティブ制作等の支援事業と共同・自社事業を複数展開。複数企業の顧問・アドバイザーも兼務。

※SNS発信も頑張っておりますので、ぜひフォローのほどよろしくお願いします！

お仕事のご相談は各種SNSからお気軽に。

X：https://x.com/yamaguchi_take

Facebook：https://www.facebook.com/yamaguchi.takehiro0129

Instagram：https://www.instagram.com/yamaguchi_take/

note：https://note.com/yamaguchi_take

登録する

PDCA という言葉をご存知ですか？

もちろん、知っています。

Plan → Do → Check → Act の循環。

日本企業は 30 年間、この PDCA を「最高の意思決定フレーム」として信仰してきました。

組織研修でも、経営管理の教科書でも、

「PDCA を回すことが、成長の鍵」

と教えられます。

ただし、ここに根本的な問題があります。

PDCA は、「既知の問題」を「既存のフレーム」で改善するためのツールです。

つまり、

Plan：来期の売上目標を設定する
Do：その目標に向かって施策を実行する
Check：目標達成度を確認する
Act：達成できなかった理由を分析し、来期に活かす

という、「予測可能な環境」「既知の変数」を前提としたフレームワークなのです。

ただし現実は、どうか。

2020 年以降の世界では、

ウイルスパンデミック
AI の急速な進化
規制の急変
消費者ニーズの急激なシフト

といった「予測不可能な変数」が、

予想外のタイミングで現れます。

その環境では、PDCA という「計画・実行」型のフレームは、

本来の機能を失ってしまうのです。

計画に 3 ヶ月をかけて、実行に 3 ヶ月かけた時点で、市場環境はすでに変わっている。

では、成長企業は何をしているのか。

彼らは PDCA ではなく、

別の「仮説の回し方」を持っている。

その「仮説の回し方」こそが、

不確実な環境下での最強の意思決定ツールなのです。

このニュースレターでは、その秘密を解き明かします。

***

まず、なぜ PDCA が「有用性を失った」のか、

その根本的な原因を整理しましょう。

PDCA の本質的な問題は、そのフロー構造にあります。

Plan → Do → Check → Act → 次の Plan

この流れは、完全に「線形」です。

1 つのサイクルが完了してから、次のサイクルが始まる。

ただし、現実の市場環境は「非線形」です。

例えば、あなたが新しい広告クリエイティブの PDCA を回しているとしましょう。

Plan（計画）：クリエイティブ A を設計する（1 週間）
Do（実行）：Meta 広告で 2 週間配信する
Check（確認）：CTR や CPA を測定する
Act（改善）：結果に基づいて、クリエイティブ B を設計する

4 週間後、クリエイティブ B の配信が始まります。

ただし、その 4 週間の間に、

Metaの広告アルゴリズムがアップデートされた
競合社が似たクリエイティブを大量配信し始めた
消費者の関心が別のトレンドに移った

といった「予測不可能な変化」が起きていた可能性が高いのです。

その場合、4 週間前の「Plan」に基づいた改善（Act）は、

すでに「時代遅れ」になっているわけです。

もう一つの問題は、PDCA の評価メカニズムです。

PDCA では、「改善」（Act）は、

前のサイクル全てが完了した後に評価されます。

つまり、4 週間のサイクル全体が「成功」か「失敗」かで判定されるのです。

ただし、実際には、

実行の「第 1 週」の時点で、

すでに「このアプローチは上手くいかない」

という兆候が見えているケースが大半です。

その時点で方針を転換すべきなのに、

PDCA の論理では、

「計画は計画。最後まで実行してから評価する」

という判断になってしまう。

結果として、4 週間のリソースが、

本来は不要な施策に費やされてしまうのです。

最後に、最も根本的な問題。

PDCA というフレームは、

「仮説が正しい前提」で設計されています。

つまり、Plan の段階での「仮説の質」は、

PDCA というプロセスでは検証されないのです。

例えば、

「消費者は、サブスク型の音楽配信を求めている」

という仮説で、

Spotify のような事業を立ち上げたとします。

その仮説が正しければ、PDCA を回していれば、

やがて成功に到達するでしょう。

ただし、その仮説が「根本的に間違っていた」場合は、

PDCA をいくら精密に回しても、

成功には到達しないのです。

***

では、成長企業は、何を代わりに採用しているのか。

その仮説の回し方には、明確な「構造」があります。

成長企業が採用している仮説の回し方の第一歩は、

「仮説にはレベルがある」ということを理解すること

です。

具体的には、以下の 3 層があります。

最も根本的な層。

「その事業そのものが、顧客にとって価値があるか」

という仮説です。

例：

「消費者は、サブスク型の音楽配信に価値を感じるか」
「飲食店は、クラウド型の予約管理システムを求めるか」
「個人事業主は、簡単な経理アプリに価値を感じるか」

このレベルの仮説が間違っていれば、

その下のレベル 2 や 3 をいくら精密に改善しても、

事業は成立しません。

「その価値を感じるのは、どんな顧客か」

という仮説です。

例：

「サブスク型音楽配信に価値を感じるのは、都市部の若い世代」
「クラウド予約システムに価値を感じるのは、席数 100 以上のレストラン」
「経理アプリに価値を感じるのは、個人事業主ではなく小規模法人」

このレベルの仮説が間違っていると，

せっかく良い商品でも、「誰に」売ればよいか分からなくなります。

「その顧客セグメントに到達し、購買に至るには、どのような施策が必要か」

という仮説です。

例：

「SpotifyJS セグメントに到達するには、Instagram 広告が有効」
「クラウド予約システムのセグメントに到達するには、飲食業界の展示会が有効」
「経理アプリのセグメントに到達するには、会計士のネットワークが有効」

成長企業が採用している第二のテクニックは，

「ゴールから逆算して、仮説を立てる」

ということです。

一般的な企業は、こう考えます：

「うちは、こういう商品を持っている。

これで、どれくらい売上が出るだろうか」

という「積み上げ方式」です。

一方、成長企業は逆です：

「3 年後に月商 1 億円の事業にするには、

毎月何人のユーザーが必要か」

という「逆算方式」から始まるのです。

例えば、Stripe の場合：

目標設定

「10 年後に、インターネット上の決済流量の 10% を処理する企業になる」

逆算1：市場規模の推定

「2030 年のインターネット商取引の規模は、おおよそ $500 trillion」
「その 10% は $50 trillion」

逆算2：Stripe が処理する取引額

「仮に、Stripe が手数料率 2.9% + $0.30 を得るなら」
「年間収益は、約 $1.5 trillion × 2.9% = $43.5 billion」

逆算3：必要なエンジニアリングリソース

「その規模の取引を処理するには、どれくらいのインフラが必要か」

このように、ゴールから逆算していくと，

「では、今、何をすべきか」という優先順位が自動的に決まるのです。

成長企業が採用している第三のテクニックは，

「仮説の検証を『最小限』『最短』『最低コスト』で実施する」

ということです。

これが PDCA との決定的な違いです。

PDCA では，Plan の段階で「完全な情報」を揃えようとします。

一方、成長企業は，

「不完全な情報のまま、小規模な実験を始める」

のです。

例えば、AirBnB の初期段階：

PDCA 型の企業ならば：

「都市部の個人が住宅を貸したいニーズがあるかを、大規模市場調査で検証」
「その後、プロダクト開発」
「その後、市場投入」

という 9 ～ 12 ヶ月のプロセスを経たはずです。

一方、AirBnB が実際にやったこと：

Week 1：創業者たちが、自分たちの住宅を Craigslist に掲載
Week 2：数人が借りてくれた。その人たちに直接インタビュー
Week 3：その学びに基づいて、専用ウェブサイトを作成（ほぼ手作業）
Week 4：さらに 10 人から借り手を募集。再び直接インタビュー

このプロセスで、わずか 1 ヶ月で、

「市場に本当に需要がある」という確信を得たのです。

PDCA では 12 ヶ月かかる検証が，

4 週間で完了しているわけです。

成長企業が採用している第四のテクニックは，

「実験開始前に『これが成功条件、これが失敗条件』を明確にしておく」

ということです。

これが極めて重要です。

なぜなら，この「失敗の定義」が明確でないと，

「失敗」を「学習不足」に転換してしまう傾向が，組織には生まれるからです。

例えば，ある企業が新しい広告チャネルをテストするとします。

定義なし：

「結果が出なかった → では，もっと予算をかけてみよう」
「まだ見えない」
さらに 3 ヶ月, さらに予算を投下...

明確な定義あり：

「事前定義：初月の CPA が $20 以下なら成功，$30 以上なら失敗」
「実績：初月の CPA は $35」
「判定：失敗」
「アクション：このチャネルは打ち切り，別のチャネルをテスト」

この「明確な失敗定義」があるかないかで，

組織の学習速度は，10 倍以上変わるのです。

***

では，実際に，自社に「成長企業型の仮説の回し方」を導入するには，

何をすればよいのか。

段階別の実装ガイドを提供します。

まず，最初にすべきは，

現在進行形で立っている「仮説」を，

言語化することです。

多くの企業では，仮説が「暗黙的」なまま進行しているため，

その仮説に気付いてさえいません。

ワークシート：自社の隠れた仮説を言語化する

以下の 3 層について，実際に記述してください。

層 1：ビジネスモデル仮説 「顧客は，以下の価値に対して，対価を払う」

例：「消費者は，移動中に短編動画を視聴したい」
例：「飲食店は，顧客データの統一管理に，月額 5,000 円払う」

層 2：顧客セグメント仮説 「その価値を最も強く感じるのは，以下のセグメント」

例：「20 代都市部女性」
例：「席数 50～100 のカジュアルダイニング」

層 3：実行仮説 「そのセグメントに到達するには，以下の施策が有効」

例：「Instagram・TikTok の動画広告」
例：「飲食業界誌への掲載」

この「言語化」のステップだけで，

多くの企業は「自分たちの仮説の甘さ」に気付くはずです。

層 1（ビジネスモデル仮説）が，本当に成立しているか，

改めて検討します。

なぜなら，多くの失敗は，層 2・層 3 の改善ではなく，

層 1 の根本的な間違いが原因だからです。

検証方法：「なぜ？」を 5 回繰り返す

例：「消費者は，短編動画に価値を感じる」という仮説

なぜ？：移動中に短編動画を見たいから
なぜ？：スマートフォンで手軽に見られるから
なぜ？：長編動画は，中断と再開が面倒だから
なぜ？：...でも，実際には，Netflix で映画を止めて，TikTok を見ている?
なぜ？：...実は，「短編動画」ではなく，「無限にスクロール」できることが価値?

このように「なぜ」を繰り返すと，

「本当の顧客課題」が浮かび上がり始めます。

仮説が言語化され，検証されたら，

実際の「小規模実験」を設計します。

実験の 5 要素

仮説
測定対象
成功基準
失敗基準
実験期間と予算

そして最後に，最も重要なこと：

この実験を，「繰り返す仕組み」を組織に埋め込む

ことです。

多くの企業では，1 つの実験は完璧にやりますが，

2 番目の実験は「なぜか遅くなる」というパターンに陥ります。

理由は，仕組みがないから。

「高速回転」の仕組み 3 つ

テンプレート化
定期会議の組み込み
判定と転換の自動化

***

では，実際に，成長企業はどのように仮説を回しているのか。

具体的な 3 つの事例を見ていきます。

Figma の創業時の状況：

初期仮説：「デザイナーが，同じファイルを複数人で同時に編集できるツールがあれば，

デザインプロセスが劇的に効率化される」

この仮説は「層 1：ビジネスモデル仮説」です。

ただし，Dylan Field（Figma CEO）は，

この仮説が「本当に成立するか」を，

最小限の方法で検証しました。

実験 1：プロトタイプの反応テスト（Week 1-2）

仮説：「デザイナーは，リアルタイムコラボ機能に高い価値を感じるか」
方法：友人のデザイナー 10 人に，シンプルなプロトタイプを見せて意見聴取
失敗基準：「これあれば，Figma に乗り換えるか」と聞いて，10 人中 8 人が「はい」未満は失敗
結果：10 人中 9 人が「これなら乗り換える」と回答
判定：成功 → Scale

実験 2：有料課金の受け入れテスト（Week 3-4）

仮説：「デザイナーは，このツールに月額料金を払うか」
方法：実験 1 の 10 人に「月額 $12 のプランなら使うか」と聞く
失敗基準：「実際に契約する」という行動に，50% 未満なら失敗
結果：9 人中 7 人が実際に月額契約
判定：成功 → Scale

実験 3：セグメント拡張テスト（Week 5-8）

仮説：「デザイナー以外も，このツールに価値を感じるか」
方法：プロダクトマネージャーやマーケターに，同じツールを提供
失敗基準：「デザイナーと同等の満足度」が得られなければ失敗
結果：PMm やマーケターも高い満足度を示す
判定：成功 → 新セグメントでの Scale

このプロセスで，Figma は，

わずか 2 ヶ月で「この仮説は間違いなく成立する」という確信を得たのです。

その後，ブラウザベースのプロトタイプから，

フル機能版への投資を決定し，

今の成功に到達しました。

Stripe の場合，仮説はもっとシンプルでした。

初期仮説：「個人の開発者が，わずか数行のコードで決済処理を統合できたら，

テクノロジーの民主化が進む」

この仮説も「層 1：ビジネスモデル仮説」です。

ただし Patrick Collison は，この仮説を検証するのに，

究極の「最小限実験」を採用しました：

実験：開発者への直接デモ（Week 1-4）

仮説：「開発者は，シンプルな API で決済を統合したいのか」
方法：友人の開発者 10 人に，手作りのデモを見せて反応を聞く
失敗基準：「これなら，既存ツール（PayPal など）を乗り換えるか」と聞いて，50% 未満が「はい」なら失敗
結果：10 人中 9 人が「これなら乗り換える」と回答
判定：成功 → Scale

ただし，ここで重要なのは，

その後の検証プロセスです。

実験の高速化

Week 5-8：プロダクト MVP（Minimum Viable Product）開発
Week 9-12：YCombinator の投資家や起業家向けにデモ
Week 13-16：初期ユーザー 100 人による実際の運用テスト

わずか 4 ヶ月で，「この仮説は本物」という確信を得たのです。

その確信に基づいて，

$2 million の資金調達を決定，

本格的な開発に投資しました。

もし Stripe が PDCA で進めていたら，

Plan：6 ヶ月かけて，完全なビジネスプランと技術仕様書を作成
Do：開発に 1 年
Check：ベータユーザーでテスト（3 ヶ月）
Act：改善

合計 2.5 年のプロセスを経ていたはずです。

実際には，4 ヶ月で「本物」を証明し，

その確信に基づいてスケール投資を決定したわけです。

最後に，Shapeways の例です。

初期仮説：「個人が，自分のデザインした 3D オブジェクトを，

小ロット（1 個～10 個）で製造できるプラットフォームがあれば，

新しい経済が生まれるのではないか」

これは「層 1：ビジネスモデル仮説」として，

かなり大胆です。

なぜなら，当時（2010 年代初頭），

3D プリンティングは「工業用」「大量生産」という前提で，

ビジネス化されていたから。

「個人向け」という仮説は，業界全体が「成立しない」と思っていました。

ただし Shapeways の創業チームは，

この「業界の常識」を疑いました：

実験 1：実際の利用者へのヒアリング（Week 1-4）

仮説：「個人デザイナーは，小ロット製造に，いくら払うか」
方法：アーティスト，デザイナー，ホビイスト 50 人に，アンケートとインタビュー
失敗基準：「平均希望価格」が，製造原価 + 20% 以下なら失敗
結果：平均希望価格は，製造原価 + 200% ～ 300%
判定：成功 → Scale

実験 2：実際の小ロット製造テスト（Week 5-12）

仮説：「実際に 1～10 個の小ロット製造が，経済的に成立するか」
方法：自社で 3D プリンティング機を導入，実際に 10 個以下の製造を受託
失敗基準：「赤字なしで 50 件の受託が完了」しなければ失敗
結果：300 件の受託が完了，全て黒字
判定：成功 → Scale

この「業界常識を疑う仮説」から始まったプラットフォームは，

やがて，3D プリンティング業界全体を再定義する企業へと成長しました。

***

では，仮説の回し方を高速化しても，

仮説そのものが「弱い」なら，意味がありません。

「仮説の質」を高めるために，

成長企業が採用している 5 つのテクニックを紹介します。

最初のテクニックは，

「複数の対立する仮説を，同時に立てて検証する」

ということです。

例えば，あるサブスクサービスが，

「なぜチャーンレート（解約率）が高いのか」

という課題を抱えているとします。

一般的なアプローチ：

仮説 A：「価格が高すぎるから」
検証：価格を 10% 下げてみる
結果：チャーンレートは変わらず

という「1 つの仮説」を立てて検証する方法。

成長企業のアプローチ：

仮説 A：「価格が高すぎるから」
仮説 B：「オンボーディング（初期設定）が複雑だから」
仮説 C：「競合製品の方が UI が良いから」
仮説 D：「実は，チャーンは『製品課題』ではなく『カスタマーサクセス対応の不備』」

という「複数の対立仮説」を同時に立てて，

それぞれを小規模に検証してみる方法。

結果として，仮説 A を検証するより，

4 倍の速度で「本当の課題」が見える可能性が高まります。

二番目のテクニックは，

「顧客は何をしているのか」から仮説を逆算する

ということです。

つまり，顧客へのアンケートや，

自社の予想ではなく，

実際の行動データから仮説を導き出す

のです。

例：ある EC サイトの場合

一般的なアプローチ：

アンケート：「どうすれば購買意欲が高まるか」と聞く
回答例：「レビューが多い商品を見たい」
施策：レビュー機能を充実させる

成長企業のアプローチ：

データ分析：「購買完了ユーザーと，カート放棄ユーザーの行動差」を分析
発見：「購買ユーザーは平均 3 ページ見ているが，カート放棄ユーザーは 1 ページ」
仮説：「実は，『レビューの質』ではなく『購買判断までの時間』が課題」
施策：「購買プロセスを 3 ステップから 1 ステップに簡略化」

実際のデータから逆算した仮説の方が，

顧客アンケートから導いた仮説より，

圧倒的に「当たる確率」が高いのです。

三番目のテクニックは，

「施策が失敗したとき，『なぜ失敗したのか』を，因果関係で深掘りする」

ということです。

これが「学習速度」を 10 倍にします。

例：ある広告キャンペーンが失敗した場合

一般的なアプローチ：

「初月の CPA が $50 だった → 失敗」
「では来月は，別の広告文を試そう」

成長企業のアプローチ：

「初月の CPA が $50 だった」
「なぜ？」→「CPM（1000 インプレッション当たりの広告費）が $5 だったから」
「なぜ CPM が $5？」→「クリック率が 0.5% と低い」
「なぜクリック率が低い？」→「オーディエンスが『ターゲットセグメント』ではなく『興味関心あり』の広いセグメント」
「では，原因は広告文ではなく『オーディエンス設定』」
「改善施策：オーディエンスを再定義する」

この因果関係の深掘りがあると，

次の実験は「正しい仮説」に基づいて実行されるのです。

四番目のテクニックは，

「マイナーな変化の中に，大きなトレンド信号を見つける能力」

です。

例：SNS 分析の場合

一般的なアプローチ：

「Instagram のリール再生数が前月比 10% 増加」
「では来月も同じ施策を続けよう」

成長企業のアプローチ：

「Instagram のリール再生数が前月比 10% 増加」
「なぜ増加したのか，その『信号』を読む」
「コメント分析：『#シーシャ』『#ホースルック』というテーマが増加」
「仮説：シーシャというニッチカルチャーが，TikTok 経由で拡大している」
「大きな仮説：シーシャというカルチャー市場は，国内で成長の初期段階」
「事業決定：シーシャ関連の新規プロダクト開発を検討」

このように，小さなデータ信号から，

大きな市場トレンドを見出す力が，

成長企業と停滞企業の決定的な差になるのです。

最後のテクニックは，

「それはどんな証拠があれば『間違い』だと言えるのか」を事前に決めておく

ということです。

これがないと，仮説は延々と「正当化」され続けます。

例：ある施策の効果測定の場合

弱い設定：

仮説：「Instagram 広告は有効」
测定：「何らかの反応がある → 仮説は成立」
結果：たいていの施策は「何らかの反応」があるので，仮説は常に「正」

強い設定：

仮説：「Instagram 広告は有効」
反証条件：「もし，初月の ROI（投資対効果）が 100% 未満なら，仮説は間違い」
測定：「初月 ROI を計測」
結果：「ROI 85% → 仮説は間違い → 施策終了」

この「反証可能性」を組み込むことで，

組織は「不要な施策を延々と続ける」という罠から解放されるのです。

***

では，最後に，この「成長企業型の仮説の回し方」を，

組織全体の意思決定プロセスに埋め込むには，

何をすればよいのか。

その実装方法を提案します。

最初の施策は，シンプルです：

仮説立案の際に使う「テンプレート」を統一する

ことです。

テンプレート例：

【仮説書】

案件名：__________

層1：ビジネスモデル仮説
顧客は，以下の価値に対して，対価を払う：
（記入）

層2：顧客セグメント仮説
その価値を最も強く感じるのは，以下のセグメント：
（記入）

層3：実行仮説
そのセグメントに到達するには，以下の施策が有効：
（記入）

測定対象：__________

成功基準（この数値以上なら成功）：__________

失敗基準（この数値以下なら失敗）：__________

実験期間：__________

予算：__________

このテンプレートを，全施策に義務化することで，

「なんとなく」の仮説設定が，

自動的に「言語化された」仮説へと転換されるのです。

二番目の施策は，

「週 1 回，現在進行中の全実験の進捗と学びを共有する会議」

を組織に埋め込むことです。

重要なのは，「数字報告」ではなく「学び共有」であること。

会議例：

参加者：施策の責任者 + 経営層

時間：30 分

アジェンダ：

先週の実験結果と学び（5 分）
この学びに基づいた今週の改善（5 分）
他の施策への応用可能性（10 分）
判定（Scale / Kill / Pivot）（10 分）

この会議が週 1 で定着すると，

組織全体の「学習速度」が劇的に向上します。

三番目の施策は，

「施策が失敗したときの『失敗カード』を記録に残す」

ことです。

多くの企業では，失敗は「なかったこと」にされます。

それではなく，その失敗から組織が学ぶ，

という姿勢を示す必要があります。

失敗カード例：

【失敗カード】

施策名：新規チャネル YouTube 広告テスト

仮説：「YouTube は，我々のターゲット層へのリーチが効率的」

実績：初月 CPA $50（目標 $20）

失敗の原因：
1. YouTuberのオーディエンスが，想定セグメントと異なる
2. テキスト広告より動画広告の方が，ブランドイメージに合わない
3. YouTube の広告アルゴリズムが，我々のターゲット層に正確にリーチしていない

組織全体への学び：
「新しいチャネル検証には，『想定オーディエンス』と『実際のオーディエンス』の検証を事前にすべき」

次のアクション：
「次のチャネル検証では，最初の 2 週間を『オーディエンス確認』に充てる」