pm-assumption-testing

仮説検証スキル

このスキルの動作（最初にお読みください）

これは生成型のスキルであり、「私たちのアイデアを検証しよう」はデフォルトの罠です。反射的な行動は、方法へ飛びつくこと — MVP を構築する、アンケートを実施する、A/B テストを配信する — あるいはそのアイデアが依存する仮説ではなくそのアイデアを検証すること（「これ、好きですか？」という問いには誰もが「はい」と答えます）です。もう一つの失敗は投資のミスマッチです。1 日で決着するはずの問いに答えるためにコードを書き、四半期を廊下での世論調査に賭けてしまうことです。そこでこのスキルはゲートを設けます:

1. 意思決定とその利害を明確にする — これはどの選択に情報を与えるのか、そしてそれはどの程度可逆的で、どれほどコストがかかるのか？ これが、どれほどの厳密さが正当化されるかを決めます。
2. 常に真である中核を適用する — 検証可能な仮説に分解し、最もリスクの高いものに優先順位をつけ、反証可能な形で表現し、成功基準を事前に設定します。
3. 方法を意図的に選ぶ — 忠実度／方法の決定をトレードオフとともに明示します。「とりあえず作ってみる」をデフォルトにしないこと。

その後、計画を pm-assumption-rigor-audit に引き渡して検証します（成功指標については pm-okr-metric-validity-audit も）。あらゆる仮説にあらゆるテスト種別を適用することが失敗モードです — リスクのある信念それぞれに、適切な方法を一つずつ組み合わせてください。

---

ステップ 0 — テストを計画する前にコンテキストを確立する

不明な場合は尋ねてください。回答なしで進める場合は仮定を明示してください:

• これはどの意思決定に情報を与え、どの程度可逆的なのか？ 安価で可逆的な微調整には素早いローファイなチェックが必要であり、高コストで元に戻しにくい賭けにはより強いエビデンスが求められます。厳密さは利害に比例します — 些細な判断を過剰にテストするのは、大きな判断を過少にテストするのと同じくらい間違っています。
• 私たちはどの段階にいるのか？ 課題の検証（誰か気にかけているか？）か、ソリューションの検証（使えるか／関与できるか？）か、実現可能性／スケールの検証（支払うか、持ちこたえるか？）か。各段階は異なる方法の階層を指し示します。
• 信じるに足る飛躍とは何か？ それが偽であればアイデアが破綻する、たった一つの仮説です。何よりも先にそれを名指ししてください。
• リソースとスケジュール — 現実的に今実行できることは何か？ 問いに答える最も安価な方法が勝ちます。

---

常に適用されるコア（あらゆる仮説検証に当てはまること）

• アイデアではなく仮説を検証する。 アイデアを、それが成功するために真でなければならない信念に分解します。「このコンセプトは好きですか？」には丁寧な「はい」が返ってくるだけですが、「ユーザーは厳選された食事に割増料金を払う」は実際に確認できる信念です。
• 5種類の仮説を網羅し、どれがリスクを抱えているかを見つける。 望ましさ（ユーザーはそれを望んでいるか？）、実行可能性（ビジネスにとって良いか？）、実現可能性（我々はそれを構築できるか？）、使いやすさ（ユーザーはそれを使えるか？）、倫理性（害を引き起こす可能性はないか？）。仮説はストーリーマッピング、機会-ソリューション木、理想の顧客プロフィールを通じて生成します。
• 重要度 × 確実性で優先順位をつけ、最もリスクの高いものから検証する。 仮説をグリッド上にマッピングします。重要度が高く、確実性が低いものがリスクを抱えています。快適なものより先に、それらを検証しましょう。（実用的な代替の順位付け：影響が大きくかつ検証が容易なものを最初に、クイックウィンを狙う。）
• それぞれを反証可能な仮説として表現する。 「我々は［ユーザー］にとっての［変更］が［成果］をもたらすと信じる。［指標］が［量］変化したとき、我々が正しいとわかる。」 という形式を使います。ポジティブに（ユーザーがすること）、そして具体的に表現しましょう — これにより本当の失敗条件が強制され、確証バイアスを防げます。
• 検証する前に成功を定義する。 合格・不合格のしきい値を事前にチームで合意しておき、後から結果を都合よく解釈し直せないようにします。
• 問いに答える最も安価な手法から始める。 プロトタイプで済むならコードを書かない。説明で済むならプロトタイプを作らない。必要な確実性に投資を合わせます。
• 仮定の意図ではなく、過去の行動を尋ねる。 「これに使いますか？」より「最近これを扱ったのはいつですか、そのときのことを教えてください」のほうが優れています。表明された意図は偽陽性であり、実際の行動（クリック、登録、予約注文、購入）こそがシグナルです。
• 間違う準備をする。 すべての検証を学びとして捉え、仮説が失敗した場合の代替案を用意します。反証は勝利です — 間違った構築を防げるのですから。
• 記録し、次のステップを決める。 仮説、手法、事前に設定した基準、結果、学んだことを記録 → 確認、調整、ピボット。検証は初期に、そして継続的に行い、陳腐化する一度きりのフェーズとして扱わないこと。

---

文脈に依存する意思決定（表面化させ、自動適用しない）

危険な仮定ごとに、学ぶ必要があることとリスクの大きさに基づいて、1つの手法を対応させます。すべての仮定に対してすべてのテストを実行しないでください。

意思決定	適用する場面	避ける／適応させる場面	デフォルトの推奨
低忠実度：サーベイ、インタビュー、ペーパープロトタイプ	問題／望ましさのテスト — 誰かが気にかけるか？ 最も早く、最も安価な段階	表明された「〜だったら使いますか？」という意図を需要の証明として扱う	ここから始める。インタビューは Mom Test と組み合わせる（仮定ではなく過去の行動）
ペイントドア／ランディングページ／スモークテスト	構築前に行動シグナル（クリック、サインアップ）で実際の需要を測定する	クリックを、その機能がニーズを満たす、あるいはリテンションにつながる証明として扱う	構築するか否かのゲートとして使う。高い CTR は関心を検証するだけ
中忠実度：クリッカブルモックアップ、コンシェルジュ MVP、オズの魔法使い	ソリューションのテスト — ユーザーが理解／関与できるか。自動化の前に手動で価値を届ける	スケッチで答えが出るのに、プロトタイプの磨き込みに何週間も費やす	コードを書く前に価値提案を検証するために使う
高忠実度：A/B テスト、フィーチャーフラグ、ライブベータ	検証済みのアイデアを最適化またはスケールする。実現可能性と実条件下の行動	誰かがそれを欲しがっているかを発見するために使う（高コストすぎ、遅すぎ）	需要が検証された後に取っておく。適切なサンプル／期間が必要。A/B の統計的厳密性（サンプルサイズ、有意性、ガードレール、ピーキング）については pm-experimentation-ab に引き継ぐ
定性 vs. 定量	なぜには定性（インタビュー、自由回答）。何をには定量（アナリティクス、大規模サーベイ、A/B）	どちらか一方だけに頼る — 純粋な定量はなぜを見落とし、純粋な定性は声の大きい意見を追いかける	両方をクロスチェックする。一致＝ゴーサイン、矛盾＝別のテストを実行
サンプルサイズ／期間／有意性	主張に合わせてスケールする — ユーザビリティのバグには約5ユーザー。コンバージョン／選好にはもっと多く、十分な実行期間が必要	n=10 や1日の期間から一般化する。A/B で有意性を無視する	意思決定に合わせてテストを設計する。可逆的な判断を過剰に作り込まない

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。インストールされている場合にのみ呼び出してください。インストールされていない場合、このスキル自体のコアにすでにこれらのルールが含まれています — ブロックせずにそのまま進めてください。

成果物を作成または改訂した後、完了と宣言するのではなく、監査レンズに引き継いでください。これらは候補レンズです — 姿勢は docs/orchestration-policy.md に従うか、成果物全体を pm-product-review 経由でルーティングしてください。ここでは assumption-rigor が常に関連するレンズ（自動実行） です。その他は提示されるもので、成果物に実際に含まれる内容に紐づきます。ユーザーがこのスキルを特定の1つの目的で呼び出した場合、そのスコープを尊重してください。

• pm-assumption-rigor-audit (自動実行) — 中核的なチェック：最も危険な仮定が対象とされ、反証可能な形で表現され、適切な忠実度の手法と対応づけられ、成功基準が事前に設定され、証拠が正直に読まれているか（サンプル、期間、パターン vs. 逸話）？
• pm-okr-metric-validity-audit (提示 — 仮説が成功指標を挙げている場合) — 各仮説の成功指標：それは真の成果であり、反証可能で、虚栄指標やゲーム可能な数値ではないか？

構成（docs/orchestration-policy.md §9 に準拠）： このスキルはテスト計画を生み出します。広範なディスカバリー手法（pm-discovery）は上流の入力であり、スペックの仮定（pm-product-spec）はそのサブパートを所有するピアです（委譲）。監査が矛盾を表面化させた場合（例：安価な手法では高リスクの問いに実際には答えられない）、目の前の意思決定に向けて解決してください：意思決定が必要とする確実性を正確に買う — それ以上でもそれ以下でもなく。 アイデアから計画までの完全な構築には、pm-idea-to-plan が構成的な正面玄関であり、このテストをスペックの前に配置します — そして PRD に埋もれさせるのではなく、構築ゲートとして前景化します。

---

一般的な do/don't パターン

❌ しないこと	✅ すること
人が気に入るかどうかを尋ねて「アイデアを検証する」	信念に分解し、そのアイデアが依拠する前提をテストする
簡単な・心地よい前提をテストする	重要度 × 確実性をマッピングし、最もリスクの高い（重要度が高く、確実性が低い）ものからテストする
「ユーザーは気に入るだろう」	「[ユーザー] に対して [変更] が [成果] をもたらすと私たちは考える。それは [指標] が [量] 動いたときに正しい」
ユーザーがしないことを表現する	肯定的に表現する — ユーザーがすることのほうがテストしやすい
結果を見てから成功を判断する	テストを実行する前に合否のしきい値を設定する
誰かが欲しがるかを知るためにコードを書く	まず最も安価な方法 — 作る前にペイントドア / プロトタイプ
インタビューで「これにお金を払いますか？」	過去の行動について尋ねる。実際の行動を測定する
一度だけテストを実行し、それで先に進む	早期かつ継続的にテストする。文書化して再テストする
反証された前提を無視すべき後退として扱う	間違うことを想定しておく。それによって意思決定を変える
計画を最終版として出荷する	assumption-rigor + okr-metric-validity に引き継ぐ

---

出典のレッスン（Uxcel）

• Assumption Testing
• Best Practices for Assumption Testing
• Evidence-Based Product Discovery
• Framing the Problem into Hypotheses