assumption-mapper

前提マッパースキル

開発を始める前に、あらゆるプロダクト計画に含まれる未検証の前提を明らかにし、優先順位を付けます。

必須の入力

与えられた情報をもとに進めます。以下のいずれかが不足していても、完全な出力を作成してください。不足分には妥当な前提を補い、(仮定、要確認) と記して、最後に一覧にします。質問を先にするのは、中心となるテーマそのものが欠けていて、書く内容が何もない場合に限ります。

• プロダクト概要、PRD、またはコンセプトの説明（大まかなメモでもかまいません）
• 段階（コンセプト／ディスカバリー／ビルド前／ローンチ後 — どの前提が最も重要かに影響します）

このスキルの位置づけ — 背骨の入り口

これはプロダクト意思決定の背骨の最前段です。assumption-mapper → /prd-template → /rice-prioritisation → /roadmap-narrative。未整理のアイデアや概要を受け取り、次のスキルに一つのことを引き継ぎます。最もリスクの高い前提と、低コストのテストを通過したかどうかです。 共通用語（前提、重要な前提、確信度、出所）は docs/craft/product-decisions.md で一度定義されています。再定義せず、こちらを参照してください。未検証の重要な前提の上に PRD を作成することこそ、このスキルが防ぐべき失敗です。そのため、/prd-template の後ではなく、前に実行してください。

サイクル

4 つのフェーズで構成されます。フェーズ 3 がこのスキルで、それ以外はその準備です。それぞれに完了基準があります。満たすまで次へ進まないでください。

1. 4 つすべての観点から前提を洗い出します。 Desirability（ユーザーはそれを望んでいるか？）、Feasibility（構築できるか？）、Viability（ビジネスとして持続できるか？）、Usability（ユーザーは実際に使えるか？）について前提を抽出します。最も危険なのは、あまりにも当然だと思われていて、誰も書き留めなかった前提です。 完了条件： 各観点につき少なくとも 1 つの前提があり、最も空白の多い観点について概要を読み返しても、新たな前提が出てこないこと。
2. 2 つの軸だけで評価します。 各前提について、重要度（1〜5、誤りだった場合に計画が破綻するか？）と確信度（1〜5、それが真実だとどの程度確信しているか？）を評価します。優先度 = 重要度 − 確信度です。各事実の出所に ([data]/[hunch]) のタグを付けます。 完了条件： すべての前提に両方のスコアと出所タグがあり、最も優先度の高い前提が、本当に最も恐れるべきものであること。テストが最も簡単な前提ではありません。
3. 最もリスクの高い前提を見つけ、厳しく検証します。 優先度が最も高い前提（重要度が高く、確信度が低い）こそ、計画全体を頓挫させる可能性があります。コードを 1 行も書かずに反証できる最も低コストなテストを特定します（選択肢については、開示されている 低コストテスト のリファレンスを参照してください）。 完了条件： 最もリスクの高い前提を 1 つ特定し、今週実施できるテストと、「失敗」がどのような状態かを明確にすること。
4. 引き継ぎます。 優先順位を付けたマップを出力し、/prd-template がどの前提を検証済み、または未解決として扱うべきかを明示します。最もリスクの高い前提が未解決の場合、黙って賭けるのではなく、PRD の未解決の質問に記載します。 完了条件： 後続のスキルが、リスクの高い賭けが何かを再確認せずに、この出力から開始できること。

出力形式

前提マップ：[機能／プロダクト名]

前提	カテゴリ	確信度	影響度	優先度	検証方法
[前提]	[種類]	[1-5]	[1-5]	[スコア]	[方法]

重要な前提（影響度 4 以上、確信度 2 以下）

[詳細な検証の推奨事項を添えた、フラグ付きの項目]

最初に検証すべき前提トップ 3

[具体的な調査方法、見積もり工数、結果によって何が変わるかを含む詳細な推奨事項]

例（一部）

入力：「中小企業の顧客が価値を実感するまでの時間を短縮するため、セルフサービス型のオンボーディングフローを構築しています。」

仮説	カテゴリ	確信度	影響度	優先度	検証方法
中小企業のユーザーは人の助けなしでオンボーディングを完了できる	ユーザビリティ	2	5	3	モデレーターなしのユーザビリティテスト（n=8）
オンボーディングが速いほど、継続率が高くなる	事業性	3	4	1	現在のオンボーディング所要時間と90日後の継続率をコホート分析
現在のオンボーディングが、価値を実感するまでの時間が長い主な原因である	望ましさ	2	4	2	最近解約した中小企業アカウントのユーザーインタビュー

アンチパターン

• 望ましさに関する仮説だけを取り上げないでください。実現可能性と事業性に関する仮説も、同じように製品を失敗に追い込む可能性があり、見落とされがちです
• まだ疑問が呈されていないというだけで、仮説に高い確信度を付けないでください。証拠がないことは、反証ではありません
• すべての仮説に対して検証方法として「ユーザーインタビュー」を推奨しないでください。定量データ、競合分析、または技術的なスパイクが必要な仮説もあります
• 検証できない仮説を列挙しないでください。マップ内のすべての仮説には妥当な検証方法が必要です。そうでなければ、未知として明示し、リスクとして扱う必要があります

詳細資料

このスキルには補助ファイルが含まれています。利用できる場合は活用してください。

• references/cheap-tests.md — Cheap-Test Catalog：検証規模の適正化。出力を作成する際に適用してください。上記の手法概要で簡略化されている判断基準と調整方法がまとめられています。
• templates/assumption-board.md — 品質ゲートが記載された、記入式の成果物テンプレート。生成を依頼するのではなく、ユーザー自身で文書を作成したい場合に提示してください。

採点基準（0～40）

このスキルの出力は、引き渡す前に採点してください。32点以上がリリース可能な品質です。

評価項目	0	5	10
カテゴリの網羅性	望ましさのみ。計画を失敗に追い込む可能性が最も高い、実現可能性と事業性に関する仮説が欠けている	3つのカテゴリに項目があるが、空のカテゴリについて概要をもとに仮説を再検討していない。網羅性が形だけで、捨て項目が1つあるだけ	4つすべてのカテゴリに実質的な項目があり、概要で見落とされていたカテゴリについて深く掘り下げたことが明確
採点の規律	確信度／影響度の数値に根拠がない、または欠けている。優先度の計算に一貫性がない。重大フラグもない	点数があり、「優先度＝影響度－確信度」が成り立っているが、まだ検証されていない仮説の確信度が高すぎ、重大フラグの適用も一貫していない	採点に妥当な根拠がある（未検証≠確信度が高い）。負の優先度も見える状態にして計算に一貫性があり、「重大」フラグを影響度4以上／確信度2以下に機械的に適用している。チームが好む仮説にも適用されている
検証方法の適合性	すべての項目に「ユーザーインタビュー」（または「調査する」）を貼り付けている	方法はさまざまだが、仮説の種類に合わないものがいくつかあり、サンプル数がない、または工数が見積もられていない	データ監査、バックテスト、フェイクドア、机上確認、スパイクなど、各方法が仮説に適合しており、サンプル数と工数も示されている。検証不能な仮説は未知として明示し、偽のテストを当てはめるのではなく、担当者を明確にしたリスクに置き換えている
意思決定への寄与	上位3項目のリストがない、または結果が何も変えないテストが含まれている	上位3項目と工数が示されているが、「結果によって何が変わるのか」が曖昧、または危険な仮説ではなく、安心できる仮説を検証している	優先度が最も高く、検証可能な仮説を3つ選んでいる。それぞれに工数、該当する場合は事前に定めた判定基準、そして結果によって変わる具体的な意思決定が示されている

品質チェック

• 各カテゴリー（望ましさ、実現可能性、事業性、ユーザビリティ）に少なくとも 1 つの仮定がある
• 影響度が 4 以上／確信度が 2 以下の仮定すべてに「重大」のフラグが付いている
• 各検証方法が具体的である（単に「調査する」ではなく、方法とサンプル数を明記する）
• 優先度スコアに一貫性がある（影響度 − 確信度、数値が高いほど緊急度が高い）

トリガーとなるフレーズの例

• 「プロダクト概要をレビューして、仮定を洗い出して。」
• 「PRD のリスクを監査して。」
• 「隠れた仮定を見つけて。」
• 「プロダクト計画を検証して。」
• 「仮定の分析を実施して。」