ひとことで言うと#
プロダクトの成功には多くの「前提(仮説)」が隠れている。それらを洗い出し、最もリスクの高い仮説から順番に検証することで、「作ってから失敗に気づく」のコストを劇的に下げるフレームワーク。
押さえておきたい用語#
- アサンプション(Assumption)
- プロダクトが成功するために**「真でなければならない」と暗黙に前提としている仮説**のこと。意識されていない前提ほどリスクが高い。
- リープ・オブ・フェイス(Leap of Faith)
- 検証なしに**「きっとそうだろう」と信じて飛び越えている最もリスクの高い仮説**を指す。ここを最優先で検証する。
- ピボット(Pivot)
- 仮説が間違っていたと判明した際に、戦略の方向を大きく転換するアプローチ。失敗ではなく「学びに基づく方向修正」。
- MVP(Minimum Viable Product)
- 仮説を検証するために必要な最小限の製品やプロトタイプのこと。学びを得ることが目的であり、完成品を作ることが目的ではない。
アサンプションテストの全体像#
こんな悩みに効く#
- 半年かけて作った機能が全く使われなかった
- 「顧客が欲しいと言っていた」を根拠に開発したが、実際は売れない
- どの仮説から検証すべきか、優先順位が分からない
基本の使い方#
**プロダクトが成功するために「真でなければならないこと」**をすべてリストアップする。
- 顧客仮説: ターゲット顧客が実際に存在するか? その課題を持っているか?
- 課題仮説: その課題は十分に深刻で、お金を払ってでも解決したいか?
- ソリューション仮説: 自社の解決策は課題を実際に解決するか?
- ビジネス仮説: 十分な市場規模があるか? 利益が出る価格で売れるか?
ポイント: 「当たり前だろう」と思っているものほど危険な仮説。意識的に疑ってみる。
各仮説を2軸で評価して、検証の順番を決める。
- リスク(不確実性): その仮説が間違っている可能性はどれくらいか?
- インパクト: その仮説が間違っていた場合、ビジネスへの影響はどれくらいか?
- 「リスク高 × インパクト大」の仮説から最優先で検証する
ポイント: すべてを検証する時間はない。致命的な仮説を3つ選んで集中する。
仮説ごとに、最も安く速く検証できる方法を選ぶ。
- インタビュー: 顧客仮説・課題仮説の検証に(5〜10人で傾向が見える)
- ランディングページテスト: 需要の有無を事前に検証
- プロトタイプ: ソリューション仮説をUIモックで検証
- MVPリリース: 最小限の機能で実際に使ってもらう
- データ分析: 既存データから仮説を検証できないか確認
ポイント: **検証の粒度は「投資額に比例」**させる。100万円の投資なら5人のインタビューで十分。1億円なら本格的なMVPを。
検証結果を客観的に評価し、Go/No-Go/Pivotを判断する。
- 仮説が正しかった: 次のリスクの高い仮説の検証に進む
- 仮説が間違っていた: ピボット(方向転換)するか、撤退するか
- 判断がつかない: 検証方法を変えて再テストする
ポイント: 事前に「何がどうなったら仮説が正しい/間違いと判断するか」を決めておく。後付けの解釈は危険。
具体例#
ビジネスアイデア: 65歳以上向けに、毎日の血圧・体重・食事を記録して家族と共有できるアプリ。開発費見込み2,000万円。
洗い出した仮説と検証:
| 仮説 | リスク | インパクト | 検証方法 | 結果 |
|---|---|---|---|---|
| シニアがスマホアプリを日常的に使える | 高 | 大 | 65歳以上20名にインタビュー | △ LINEは使えるが新規アプリのDLが壁 |
| 健康データを家族と共有したいニーズがある | 中 | 大 | 同インタビューで確認 | ◎ 子世代からの強いニーズあり |
| 毎日の記録を継続できる | 高 | 大 | 紙の記録シートで2週間テスト | × 3日で半数が脱落 |
| 月額500円を払う意思がある | 中 | 中 | アンケート(50名) | ○ 子世代が払うなら許容 |
判断: 「毎日の記録」は続かない → 受動的な健康モニタリング(ウェアラブル連携)にピボット。アプリのDLハードルは高い → LINEボットでの提供に変更。
仮説検証なしで開発していたら、2,000万円を「使われないアプリ」に費やすところだった。インタビュー20名+2週間の紙テストで、わずか30万円で致命的な前提の誤りを発見できた。
背景: 従業員15名のスタートアップ。「中小企業の営業マネージャーは、商談のパイプライン管理に苦労している」という課題仮説でCRM開発を計画。
仮説マッピング:
| 仮説 | リスク | インパクト | 優先度 |
|---|---|---|---|
| 営業マネージャーがパイプライン管理に週3時間以上費やしている | 高 | 大 | ★★★ |
| 既存CRM(Salesforce等)に不満がある | 中 | 大 | ★★ |
| 月額5,000円/ユーザーで導入意思がある | 中 | 中 | ★ |
最優先仮説の検証: 営業マネージャー15名にインタビュー。
判明した事実:
- パイプライン管理に時間をかけているのは15名中わずか3名
- 12名が最も時間を費やしていたのは「日報・週報の作成と集約」(週平均4.5時間)
- CRMには「入力が面倒で営業が使ってくれない」という不満が最多
「パイプライン管理」ではなく「日報・週報の自動化」にピボットすべきだと判明した。15名のインタビューに費やした約10万円と2週間が、6ヶ月分の開発方向を救ったことになる。修正後のMVPは初月から有料ユーザー8社を獲得した。
背景: 創業120年の酒蔵(従業員12名)。ECで日本酒のサブスクリプションサービスを検討中。月額3,500円で毎月おすすめの1本を届けるモデル。
洗い出した仮説:
| 仮説 | リスク | インパクト | 検証方法 |
|---|---|---|---|
| 日本酒のサブスクに月3,500円払うユーザーがいる | 高 | 大 | LP+事前登録フォーム |
| 毎月1本では飽きずに継続してくれる | 高 | 大 | 既存顧客20名に月1本を3ヶ月送付 |
| 蔵元のストーリーが差別化になる | 中 | 中 | LP上でストーリーの有無でA/Bテスト |
検証結果:
- LP事前登録: 3,000アクセス中、事前登録82件(CVR 2.7%)→ 需要あり
- 3ヶ月テスト: 20名中16名が「続けたい」と回答。ただし「毎月1本では物足りない。2本選べるプランが欲しい」が9名
- ストーリーA/Bテスト: 蔵元紹介動画ありのLP版がCVR+45%
月1本プランに加えて月2本セレクトプラン(月額5,800円)を追加して正式ローンチ。初月から契約者48名を獲得し、月商約22万円でスタート。事前のLP検証+小規模テストの総コスト約15万円で、数百万円の開発判断の確度を大幅に高められた。
やりがちな失敗パターン#
- 確証バイアスで検証する — 「正しいと証明したい」気持ちで検証すると、都合の良いデータだけ見てしまう。反証を積極的に探す姿勢が重要
- 仮説を言語化しないまま開発に入る — 暗黙の前提がチーム内で共有されず、失敗してから「そんなの当たり前だと思ってた」となる。仮説は必ず書き出す
- 完璧な検証を求めすぎる — 統計的に完璧な検証には時間もお金もかかる。「十分な確信が持てるか」で判断し、素早く次に進む
- 検証結果に感情的に抵抗する — データが「方向転換すべき」と示しているのに、「もう少し続ければうまくいくはず」と引きずる。事前に判断基準を決めておくことで、感情を排除した意思決定ができる
まとめ#
アサンプションテストは「正しいものを作る前に、作ろうとしているものが正しいか確かめる」フレームワーク。仮説を洗い出し、リスクの高いものから最小コストで検証し、データに基づいて判断する。半年かけて作ってから失敗するより、2週間で仮説が間違っていると分かる方がはるかに良い。