アサンプション・マッピング（Assumption Mapping）は、プロジェクトや製品・サービスのアイデアに潜む「暗黙の前提（仮定）」を洗い出し、「重要度」と「不確実性」の2軸でマッピングすることで、検証すべき仮説の優先順位を決める手法です。

多くのプロジェクトが失敗する原因は、検証されていない前提の上に解決策を構築することにあります。「ユーザーはこの機能を使いたいはずだ」「このニーズは市場に存在する」「このプロセスで実現できる」——これらの「はずだ」は仮定であり、検証されていない仮説です。アサンプション・マッピングは、その仮説を意識の外から意識の上に引き上げます。

なぜアサンプション・マッピングが必要か

問題定義フェーズでは、観察やインタビューで得た情報をもとに「HMW（どうすれば〜できるか）」という問いを立てます。しかしこの問いに答えるアイデアを実行に移す前に、 そのアイデアが機能するために必要な「前提条件」を明示化する ステップが必要です。

200回以上のワークショップ観察で繰り返し確認されてきたパターンがあります。「良いアイデアだ」と確信を持ってプロトタイプを作ったが、テストで根本的な前提が崩れていることが発覚し、一から作り直しになる——というケースです。アサンプション・マッピングは、この「早すぎる確信」を防ぐための構造的なチェックです。

ステップ

Step 1：前提（アサンプション）を書き出す

チームで5〜10分、 「このアイデアが成功するために必要な前提は何か」を付箋に書き出します（1枚1仮定）。

以下の問いが書き出しの助けになります。

ユーザーは誰で、どんな行動をとるか？（「ユーザーは〇〇だ」という仮定）
このサービス・製品は機能するか？（「〇〇で実現できる」という仮定）
ビジネスとして成立するか？（「ユーザーは〇〇のためにお金を払う」という仮定）
組織的に実行できるか？（「パートナーが〇〇に協力してくれる」という仮定）

批判を保留して書き出す量を優先します。最初のセッションでチームが10〜20枚の付箋を出せれば十分です。

Step 2：2×2マトリクスに配置する

縦軸を「重要度（高←→低）」、横軸を「不確実性（高←→低）」にした2×2マトリクスを描きます。

各付箋を、 「このプロジェクトにとってどれくらい重要か」と「これが本当かどうか、今どれくらい分からないか」 の2つの問いで判断しながら配置します。全員で議論しながら位置を決めます。意見が割れること自体が重要な情報です。

Step 3：優先度の高い仮説を特定する

マトリクスの 「重要度：高 × 不確実性：高」の象限に入った仮説が、最も早急に検証すべき仮説 です。これらはプロジェクトの成否を左右するにもかかわらず、正しいかどうかが分かっていない前提です。

「重要度：高 × 不確実性：低」の象限は、重要だが既知の事実として扱える仮説です。「重要度：低 × 不確実性：高」は、不確かだが失敗しても致命的でない仮説です。これらは検証の優先度を下げます。

Step 4：検証計画を立てる

優先度の高い仮説（重要度高×不確実性高）について、 「この仮説をどうテストするか」を決めます。

仮説の種類によって、適切な検証方法は異なります。「ユーザーがこの問題を抱えているか」という仮説はユーザーインタビューで検証します。「このUIで操作できるか」はプロトタイプテストで、「お金を払う意欲があるか」はランディングページとコンバージョン測定で検証できます。各仮説に検証方法と担当・期限をセットで決めることで、アクションプランに変換します。

マトリクスの読み方

重要度	不確実性	対処法
高	高	今すぐ検証する（最優先）
高	低	前提として記録し、監視する
低	高	余裕があれば検証する
低	低	無視してよい

よくある前提の種類

デザイナブルな前提（望ましい）

「ユーザーは月1回以上この問題に直面する」「ユーザーはスマートフォンでこのタスクを完了しようとする」——これらは共感フェーズのリサーチで検証可能な前提です。

ビジネスモデルの前提

「1,000円/月の料金を支払う意欲がある」「法人顧客が10社でユニットエコノミクスが成立する」——これらは市場調査・インタビュー・MVP（最小限の製品）でテストできます。

テクニカルな前提

「現在の技術でリアルタイム処理できる」「既存システムとのAPI連携が可能」——これらはエンジニアリングのスパイク（小さな実験）で確認します。

ファシリテーションのポイント

「正しい位置に置かなければ」という心理的負荷を下げる ことが重要です。「この付箋、右上か左上か迷ってる」という発言が出たら、「迷っているなら境界に置いてみましょう」と促します。完璧な配置より、 「なぜ迷っているか」の議論から出るインサイトの方が価値があります。

「この前提は本当に仮定か、既知の事実か」という問いも有効です。「ユーザーがスマートフォンを持っている」という前提が、データで検証済みなのか思い込みなのかを区別することで、マトリクスの精度が上がります。

「不確実性」を客観的に評価することは難しいため、 「この前提が間違っていたら、どの程度プロジェクトへの影響があるか」という問いで代替する と議論がしやすくなります。

接続する手法

アサンプション・マッピングの後は、優先度の高い仮説を検証するためのプロトタイプ設計に移ります。またリーン・キャンバスと組み合わせることで、ビジネスモデル全体の仮説を一覧化した上でアサンプション・マッピングを行うことができます。

参考文献

Jeff Patton, User Story Mapping, O’Reilly Media, 2014
David J. Bland & Alex Osterwalder, Testing Business Ideas, Wiley, 2019
Eric Ries, The Lean Startup, Crown Business, 2011