アサンプションテスト

英語名 Assumption Testing
読み方 アサンプション テスティング
難易度
所要時間 2〜4時間(仮説整理)+ 検証期間
提唱者 エリック・リース(リーンスタートアップ)、デビッド・ブランド(仮説マッピング)
目次

ひとことで言うと
#

プロダクトの成功には多くの「前提(仮説)」が隠れている。それらを洗い出し、最もリスクの高い仮説から順番に検証することで、「作ってから失敗に気づく」のコストを劇的に下げるフレームワーク。

押さえておきたい用語
#

押さえておきたい用語
アサンプション(Assumption)
プロダクトが成功するために**「真でなければならない」と暗黙に前提としている仮説**のこと。意識されていない前提ほどリスクが高い。
リープ・オブ・フェイス(Leap of Faith)
検証なしに**「きっとそうだろう」と信じて飛び越えている最もリスクの高い仮説**を指す。ここを最優先で検証する。
ピボット(Pivot)
仮説が間違っていたと判明した際に、戦略の方向を大きく転換するアプローチ。失敗ではなく「学びに基づく方向修正」。
MVP(Minimum Viable Product)
仮説を検証するために必要な最小限の製品やプロトタイプのこと。学びを得ることが目的であり、完成品を作ることが目的ではない。

アサンプションテストの全体像
#

アサンプションテスト:リスク×インパクトで仮説を優先順位づけ
リスク(不確実性)→インパクト →最優先で検証リスク高 × インパクト大モニタリングリスク低 × インパクト大余裕があれば検証リスク高 × インパクト小後回しリスク低 × インパクト小顧客仮説課題仮説BIZ仮説Step 1: 仮説を洗い出す顧客・課題・ソリューション・ビジネスの4分類でリストアップStep 2: マトリクスで優先順位リスク × インパクトで評価し右上の仮説を最優先で検証
アサンプションテストの進め方フロー
1
仮説洗い出し
成功に必要な前提をすべてリストアップ
2
優先順位付け
リスク×インパクトで最重要仮説を3つ選ぶ
3
最小コスト検証
インタビュー・LP・プロトタイプで素早く検証
Go / Pivot判断
事前に決めた基準で客観的に意思決定

こんな悩みに効く
#

  • 半年かけて作った機能が全く使われなかった
  • 「顧客が欲しいと言っていた」を根拠に開発したが、実際は売れない
  • どの仮説から検証すべきか、優先順位が分からない

基本の使い方
#

ステップ1: 前提となる仮説を洗い出す

**プロダクトが成功するために「真でなければならないこと」**をすべてリストアップする。

  • 顧客仮説: ターゲット顧客が実際に存在するか? その課題を持っているか?
  • 課題仮説: その課題は十分に深刻で、お金を払ってでも解決したいか?
  • ソリューション仮説: 自社の解決策は課題を実際に解決するか?
  • ビジネス仮説: 十分な市場規模があるか? 利益が出る価格で売れるか?

ポイント: 「当たり前だろう」と思っているものほど危険な仮説。意識的に疑ってみる。

ステップ2: 仮説をリスクとインパクトで優先順位付けする

各仮説を2軸で評価して、検証の順番を決める

  • リスク(不確実性): その仮説が間違っている可能性はどれくらいか?
  • インパクト: その仮説が間違っていた場合、ビジネスへの影響はどれくらいか?
  • 「リスク高 × インパクト大」の仮説から最優先で検証する

ポイント: すべてを検証する時間はない。致命的な仮説を3つ選んで集中する

ステップ3: 最小コストの検証方法を設計する

仮説ごとに、最も安く速く検証できる方法を選ぶ

  • インタビュー: 顧客仮説・課題仮説の検証に(5〜10人で傾向が見える)
  • ランディングページテスト: 需要の有無を事前に検証
  • プロトタイプ: ソリューション仮説をUIモックで検証
  • MVPリリース: 最小限の機能で実際に使ってもらう
  • データ分析: 既存データから仮説を検証できないか確認

ポイント: **検証の粒度は「投資額に比例」**させる。100万円の投資なら5人のインタビューで十分。1億円なら本格的なMVPを。

ステップ4: 結果を判定し、次のアクションを決める

検証結果を客観的に評価し、Go/No-Go/Pivotを判断する

  • 仮説が正しかった: 次のリスクの高い仮説の検証に進む
  • 仮説が間違っていた: ピボット(方向転換)するか、撤退するか
  • 判断がつかない: 検証方法を変えて再テストする

ポイント: 事前に「何がどうなったら仮説が正しい/間違いと判断するか」を決めておく。後付けの解釈は危険。

具体例
#

例1:シニア向け健康管理アプリの仮説検証

ビジネスアイデア: 65歳以上向けに、毎日の血圧・体重・食事を記録して家族と共有できるアプリ。開発費見込み2,000万円。

洗い出した仮説と検証:

仮説リスクインパクト検証方法結果
シニアがスマホアプリを日常的に使える65歳以上20名にインタビュー△ LINEは使えるが新規アプリのDLが壁
健康データを家族と共有したいニーズがある同インタビューで確認◎ 子世代からの強いニーズあり
毎日の記録を継続できる紙の記録シートで2週間テスト× 3日で半数が脱落
月額500円を払う意思があるアンケート(50名)○ 子世代が払うなら許容

判断: 「毎日の記録」は続かない → 受動的な健康モニタリング(ウェアラブル連携)にピボット。アプリのDLハードルは高い → LINEボットでの提供に変更

仮説検証なしで開発していたら、2,000万円を「使われないアプリ」に費やすところだった。インタビュー20名+2週間の紙テストで、わずか30万円で致命的な前提の誤りを発見できた。

例2:BtoB営業支援ツールの課題仮説検証

背景: 従業員15名のスタートアップ。「中小企業の営業マネージャーは、商談のパイプライン管理に苦労している」という課題仮説でCRM開発を計画。

仮説マッピング:

仮説リスクインパクト優先度
営業マネージャーがパイプライン管理に週3時間以上費やしている★★★
既存CRM(Salesforce等)に不満がある★★
月額5,000円/ユーザーで導入意思がある

最優先仮説の検証: 営業マネージャー15名にインタビュー。

判明した事実:

  • パイプライン管理に時間をかけているのは15名中わずか3名
  • 12名が最も時間を費やしていたのは「日報・週報の作成と集約」(週平均4.5時間)
  • CRMには「入力が面倒で営業が使ってくれない」という不満が最多

「パイプライン管理」ではなく「日報・週報の自動化」にピボットすべきだと判明した。15名のインタビューに費やした約10万円と2週間が、6ヶ月分の開発方向を救ったことになる。修正後のMVPは初月から有料ユーザー8社を獲得した。

例3:地方の酒蔵がD2Cサブスクの仮説を検証

背景: 創業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万円で、数百万円の開発判断の確度を大幅に高められた。

やりがちな失敗パターン
#

  1. 確証バイアスで検証する — 「正しいと証明したい」気持ちで検証すると、都合の良いデータだけ見てしまう。反証を積極的に探す姿勢が重要
  2. 仮説を言語化しないまま開発に入る — 暗黙の前提がチーム内で共有されず、失敗してから「そんなの当たり前だと思ってた」となる。仮説は必ず書き出す
  3. 完璧な検証を求めすぎる — 統計的に完璧な検証には時間もお金もかかる。「十分な確信が持てるか」で判断し、素早く次に進む
  4. 検証結果に感情的に抵抗する — データが「方向転換すべき」と示しているのに、「もう少し続ければうまくいくはず」と引きずる。事前に判断基準を決めておくことで、感情を排除した意思決定ができる

まとめ
#

アサンプションテストは「正しいものを作る前に、作ろうとしているものが正しいか確かめる」フレームワーク。仮説を洗い出し、リスクの高いものから最小コストで検証し、データに基づいて判断する。半年かけて作ってから失敗するより、2週間で仮説が間違っていると分かる方がはるかに良い。