ひとことで言うと#
複数の仮説を 「影響度(Impact)」「不確実性(Uncertainty)」「検証コスト(Cost)」 の3軸でスコアリングし、最も少ないコストで最も大きな学びが得られる仮説から順番に検証する意思決定フレームワーク。
押さえておきたい用語#
- 仮説(Hypothesis)
- 「〇〇すれば△△になるだろう」という検証可能な予測のこと。事実ではなく、実験で確かめるべき予測。
- 影響度(Impact)
- その仮説が正しかった場合にビジネスに与えるインパクトの大きさを指す。売上・利用者数・コスト削減額などで評価する。
- 不確実性(Uncertainty)
- その仮説が正しいかどうかの確信度の低さのこと。「分からないこと」が多いほど不確実性が高く、検証の価値が大きい。
- 検証コスト(Cost)
- 仮説を検証するために必要な時間・費用・人員である。低コストで検証できるものから先に着手する。
仮説優先順位付けの全体像#
こんな悩みに効く#
- やりたいことが多すぎて、何から検証すればいいか分からない
- 「声の大きい人の意見」で施策の優先順位が決まってしまう
- 大きなコストをかけて検証したが、得られた学びが少なかった
基本の使い方#
チームが持っている仮説をすべて書き出す。曖昧なアイデアも仮説の形に変換する。
良い仮説: 「トップページにチャットボットを設置すれば、問い合わせ数が 30% 減る」 悪い仮説: 「チャットボットを入れたらいいかも」
仮説は 検証可能(実験で確かめられる)かつ 反証可能(間違っていることを証明できる)であることが条件。通常 10〜20個 の仮説を出す。
チームで議論しながら、各仮説に点数をつける。
影響度(1〜5): この仮説が正しければ、どれだけビジネスインパクトがあるか?
- 5: 売上に直結する大きな変化
- 1: あったら便利だが、KPIへの影響は小さい
不確実性(1〜5): この仮説が正しいかどうか、どれだけ分からないか?
- 5: 全く予測がつかない(=検証する価値が大きい)
- 1: ほぼ確実に正しい(=検証する必要が低い)
検証コスト(1〜5): この仮説を検証するのにどれだけリソースが必要か?
- 1: 1日、ゼロコストで検証できる(=優先度UP)
- 5: 数ヶ月、大きな開発が必要
優先度スコア = 影響度 × 不確実性 ÷ 検証コスト で計算し、上位 3つ から着手。
各仮説に対して「最小限の実験」を設計する。本格的な開発ではなく、プロトタイプ、A/Bテスト、ユーザーインタビュー、フェイクドアテストなど、最も低コストで仮説を検証できる方法を選ぶ。
実験後は結果を記録し、次の仮説に進む。仮説が正しければ本格投資、間違っていれば早期に方向転換する。
具体例#
BtoB SaaS企業のプロダクトチーム。営業・CS・経営層からの機能要望が 25個 たまり、どれから開発すべきか議論が紛糾していた。
25個を仮説に変換し、3軸でスコアリング。上位3つ:
| 仮説 | 影響度 | 不確実性 | コスト | スコア |
|---|---|---|---|---|
| Slack連携で利用率が上がる | 4 | 5 | 2 | 10.0 |
| ダッシュボード刷新でNPSが上がる | 5 | 4 | 5 | 4.0 |
| AI要約で作業時間が減る | 5 | 3 | 4 | 3.8 |
Slack連携が最優先になった理由: 影響度が高く、「本当に使われるか」が最も不確実で、かつBotの簡易版を 1週間 で作れる低コスト検証が可能。
1週間でSlack Bot のプロトタイプを作り、既存顧客 30社 にベータ提供。利用率は 72% で仮説は正しかった。本格開発に進み、リリース後にDAUが 23% 向上した。
もし「声の大きい経営層」の推すダッシュボード刷新(開発工数 3ヶ月)から着手していたら、Slack連携の検証は半年遅れていた。
化粧品D2Cブランド(月商 3,000万円)。マーケティングチームが「やりたい施策」を 12個 抱えていたが、予算は月 200万円 しかない。
仮説優先順位付けの結果、上位:
- 「定期購入の初回割引を 50% → 70% にすれば、CVRが 20% 上がる」(スコア: 12.5)
- 「LINE公式でリマインドを送れば、2回目購入率が 15% 上がる」(スコア: 10.0)
- 「インフルエンサー施策でCPAが下がる」(スコア: 4.0)
仮説1を1週間のA/Bテストで検証。結果: CVRは 18% 向上(仮説ほぼ正しい)。ただし初回割引の拡大で利益率が低下するため、2回目購入率の改善(仮説2)とセットで実行。
2ヶ月後、CVR +18% × 2回目購入率 +12% の複合効果で、LTV(顧客生涯価値)が 22% 向上。インフルエンサー施策(仮説3)は検証の結果CPAが想定より高く、見送りに。低コストの検証で 200万円 の予算浪費を防いだ。
製造業(従業員 500名)の情報システム部。全社DXとして 8つの施策 が提案されていたが、予算と人員の制約で同時に進められるのは 2つ まで。
スコアリングの結果、上位:
- 「紙の品質管理表をタブレット化すれば、記録ミスが 50% 減る」(I:5 × U:4 ÷ C:2 = 10.0)
- 「在庫管理をリアルタイム化すれば、欠品が 30% 減る」(I:5 × U:3 ÷ C:4 = 3.8)
仮説1は既製のタブレットアプリ(月額 5万円)で2週間のパイロットが可能。1つのラインで試した結果、記録ミスが 60% 減少し、仮説を上回る結果。全ラインに展開。
仮説2は検証コストが高い(在庫システムの改修に 3ヶ月)ため、まず在庫データのExcel分析で「本当に欠品の原因が情報遅延か」を検証。分析の結果、欠品の 70% は情報遅延ではなく「発注ロットサイズの不適切さ」が原因と判明。システム改修ではなくロットサイズの見直し(コストほぼゼロ)で欠品が 40% 減少した。
仮説の優先順位付けがなければ、在庫システムに 2,000万円 かけて本質的でない改修をするところだった。
やりがちな失敗パターン#
- 影響度だけで優先順位を決める — 「インパクトが大きい」だけで選ぶと、検証コストの高い仮説ばかりが優先され、学習サイクルが遅くなる。3軸のバランスが重要。
- 不確実性の低い仮説を先に検証する — 「ほぼ確実に正しい」仮説を検証しても新しい学びがない。不確実性の高い仮説こそ検証の価値がある。
- 仮説のスコアリングを一人で行う — 個人のバイアスが入りやすい。チームで議論しながらスコアをつけることで、多角的な評価ができる。
- 検証結果を記録しない — 実験の結果と学びを記録しないと、同じ仮説を繰り返し検証することになる。仮説ログを作成し、チームで共有する。
まとめ#
仮説優先順位付けは、「何から試すか」を感覚ではなく構造で決める仕組みである。影響度×不確実性÷検証コストのシンプルな計算で、最も効率的な学習順序が見える。リソースが限られているからこそ、最も少ないコストで最も大きな学びが得られる仮説から着手する。この順序を間違えると、数ヶ月と数百万円を無駄にするリスクがある。