仮説ドリブンPM：コンサル流「検証思考」でプロジェクトの無駄を削る

コンサルタントと普通のPMの仕事の進め方で最も大きな違いの一つは「仮説ドリブン（Hypothesis-Driven）」のアプローチだ。コンサルタントはまず「おそらく答えはこれだ」という仮説を立てて、その仮説が正しいか間違いかを検証するための最小限の作業をする。

一方、多くのPMは「まず情報収集から」「全体を整理してから」という網羅型のアプローチを取りがちだ。これは時間がかかる上に、集めた情報の多くが意思決定に使われない。

仮説ドリブンとは何か

仮説ドリブンとは「まず答えを仮定し、それを検証する作業に絞り込む」という思考法だ。

通常の作業フロー：情報収集 → 分析 → 洞察 → 仮説 → 意思決定

仮説ドリブンの作業フロー：仮説設定 → 検証に必要な情報だけ収集 → 検証 → 意思決定（または仮説修正）

2番目のフローの方が時間を大幅に短縮できる理由は、「使わない情報収集」が完全になくなるからだ。

場面1：プロジェクト遅延の原因特定

仮説なしのアプローチ：全タスクの状況を網羅的に収集・整理して、どこに問題があるかを探す。

仮説ドリブン：「おそらく開発フェーズの工数見積もりが甘いのが原因だ」という仮説を立て、開発フェーズの計画工数vs実績工数だけを確認する。仮説が正しければ即座に対策を取れる。間違っていれば次の仮説に進む。

場面2：要件定義の優先順位付け

仮説なし：ヒアリングをすべてのステークホルダーに対して網羅的に行う。

仮説ドリブン：「最も重要な要件は決済機能の信頼性だ（なぜなら競合との差別化ポイントがここにあるから）」という仮説から始める。決済機能に関するヒアリングを深掘りして、仮説を検証してから他の要件に進む。

場面3：チームの生産性低下の原因特定

仮説ドリブン：「コミュニケーションロスが原因ではなく、スコープの頻繁な変更が原因だ」という仮説を立て、直近1ヶ月の仕様変更履歴だけを調べる。

良い仮説の条件は「検証可能であること」と「具体的であること」だ。

仮説設定の手順：

仮説の書き方テンプレート：

仮説：[主語]が[行動]している/していないことが、
     [結果]の原因だ

検証方法：[具体的なデータや観察方法]
検証期限：[日程]
判定基準：[何が正しければ仮説が正しいと判断するか]

例：「エンジニアが詳細設計書を読んでいないことが、実装の手戻りの原因だ。検証方法：直近3件の手戻り案件のコードレビューコメントを確認する。判定基準：手戻りの80%以上が設計書に記載されていた内容なら仮説を支持する。」

書籍紹介

著者: 木部智之 — 「再生工場」と呼ばれた著者による炎上プロジェクトの火消し術86を収録

仮説ドリブンにおいて「仮説が間違っていた」は失敗ではない。間違いを確認したことで「正しくない方向への時間の無駄遣い」を早期に止められたと考える。

大切なのは「検証のたびに仮説を精緻化していく」プロセスだ。

仮説 → 検証 → 「仮説が違った」 → 次の仮説（より精緻化された）→ 再検証

このサイクルを2〜3回回すと、「正解に近い仮説」にたどり着ける。

個人で使うだけでなく、チーム全体で仮説ドリブンを採用すると効果が倍増する。

週次ミーティングでの活用： 「今週の課題について、まず各自の仮説を1分で発表してから議論を始める」というルールにするだけで、議論の焦点が明確になり、会議時間が短縮される。

提案・報告に仮説を明示する： 「調査結果によると…」ではなく「仮説：〇〇が原因。検証結果：〇〇のデータが仮説を支持している」という形式で報告するよう統一する。

仮説ドリブンアプローチは「考える時間を増やして、無駄な作業時間を削る」という意識の転換だ。「まず手を動かす」という日本の職場文化に逆らう側面もあるが、限られたリソースで最大のアウトカムを出すためのPMのスキルとして、意識的に鍛える価値がある。