pm-assumption-rigor-audit

前提の厳密性監査スキル

このスキルがデフォルトの動作と比べて変えるもの

デフォルトでは、Claude は検証を額面通りに受け入れます — 「アンケートを実施してユーザーに好評だったので、検証済みです」という主張は、異議なく通ってしまいます。最もリスクの高い前提が検証されたのか、その意思決定を支えるのに十分な強度の手法だったのか、「これを使いますか？」という回答を証拠と取り違えていないか、成功はテストの前に定義されていたのか、サンプルサイズは意味を持つだけの大きさだったのか — こうしたことはめったに問われません。この監査は次の4点を強制します。すべての指摘は違反した原則を明示すること。テストが支えようとしている意思決定を判断の単位とすること（厳密さはかけられているものの大きさに応じてスケールする）。証拠の主張はシグナルとノイズの観点で検証すること。そして指摘は、意思決定への損害度に応じて深刻度が評価され、具体的な修正案を伴うこと。

これは評価型スキルです。検証計画、実験、ディスカバリーのアプローチ、あるいは「検証しました…」という主張がレビューされるたびに自動実行されます — また、pm-assumption-testing がテスト計画を生成した後の検証ステップとしても実行されます。

スコープの規律。 直接呼び出された場合（ユーザーがこの監査を名指しした場合）、この関心事のみをレビューしてください — 兄弟となる監査を引き込まないでください。他のレンズと並んで実行されるのは、pm-product-review オーケストレーターまたは生成系スキルが docs/orchestration-policy.md に基づいて呼び出した場合のみであり、そこでは常に該当する PM レンズ — 自動実行に位置づけられます。明示されたスコープが常に優先されます。

---

フレームワーク — 何をチェックし、違反がどのようなものか

1. 最もリスクの高い前提が検証された — 心地よい前提ではなく

前提は重要度 × 確信度でマッピングされるべきです。高重要度 / 低確信度の前提（リーップ・オブ・フェイスの信念）がリスクを担っており、最初に検証されます。無差別にすべてを検証したり、簡単なものを検証したりするのは無駄な動きです。

指摘すべきケース: 土台となる前提（「ユーザーはこれにお金を払う」「これはそもそも課題なのか」）が一度も名指しされず、一度も検証されないまま、簡単で安全な前提ばかりが検証されている。優先順位づけなしに「すべてを検証している」。アイデアは検証されたが、そのアイデアが依存する信念は検証されていない。

• ❌ フードデリバリーアプリを作り、「健康的な食事は好きですか？」（誰もがはいと答える）を調査する一方で、「ユーザーは割増料金を払うか」「アラカルトよりおまかせを選ぶか」を一度も検証しない。
• ✅ 前提をマッピングし、最も重要度が高く確信度が低い前提（「ユーザーはおまかせの健康的な食事に20%多く払う」）を最初に検証する。

2. 前提は反証可能で具体的な命題として表現されている

検証可能な前提は仮説の形式を用います — 「私たちは、[ユーザー]に対する[変更]が[成果]をもたらすと考える。私たちが正しいとわかるのは、[指標]が[量]変化したときである」 — 肯定的に（ユーザーがすること）かつ具体的に表現し、本当の失敗条件を持たせます。

指摘すべきケース: 指標もしきい値もない曖昧な信念（「ユーザーは気に入るだろう」「これはエンゲージメントを改善するだろう」）。否定的な表現（「ユーザーは離脱しない」 — 離脱しないことより、何をするかのほうが検証が難しい）。検証可能な前提であるかのように提示されたアイデア（「チェックアウトを短くする」）。

• ❌ 「ユーザーはオンボーディングを直感的だと感じるだろう。」
• ✅ 「新規ユーザー向けにオンボーディングを簡素化するとアクティベーションが上がると私たちは考える。80%以上が2分以内に完了したとき、私たちは正しいとわかる。」

3. 意思決定のリスクに合わせた手法の忠実度（真実の曲線）

その問いに答えるための、最も安価で最速の手法を選びましょう —— それより安価な手法は選びません。低忠実度（アンケート、インタビュー、ペーパープロトタイプ）は課題を検証します。中忠実度（クリッカブルモックアップ、ランディングページ／ペイントドア、コンシェルジュ／ウィザード・オブ・オズ）はソリューションを検証します。高忠実度（ライブベータ、本番環境での A/B テスト、フル実装）は実現可能性とスケールを検証します。判断の基準は「この意思決定を行うのに十分な確からしさ」であり、「可能な限り最も厳密な手法」ではありません。

こうした場合に警告します： プロトタイプやペイントドアテストで決着がついたはずの問いに答えるために本番コードを実装している場合（過剰投資）。または、1 日限りのランディングページテストや廊下でのアンケートを根拠に、大きく高コストで覆しにくい賭けに踏み切っている場合（賭け金に対して根拠が脆弱）。構造的に問われた内容に答えられない手法を用いている場合（ニーズを満たす機能だと主張するためにクリックスルーテストを使うなど）。

• ❌ 「誰かが欲しがるかどうかを確かめる」ために 6 エンジニア週を費やして機能を実装する。
• ✅ まずペイントドアテストでクリックスルーを測定し、需要が実在することが確認できてからコードを書く。

4. 表明された意向ではなく行動

「これを使いますか？」「20 ドル払いますか？」と尋ねると偽陽性が生まれます —— 人は役に立ちたいと思うものです。仮定上の将来の意向よりも過去の行動を信頼しましょう（マムテスト：自分のアイデアではなく、相手の生活と具体的な過去のエピソードについて尋ねる）。

こうした場合に警告します： 望ましさや支払い意欲が、仮定上のインタビュー／アンケートの回答のみによって「検証済み」とされている場合。ユーザーに自身の将来の行動を予測させたり、ソリューションを設計させたりするテストを行っている場合。表明された選好が実際の行動（購入、クリック、サインアップ）と同等に扱われている場合。

• ❌ 「インタビュー対象 10 人中 8 人が間違いなく使うと言った → 検証済み。」
• ✅ 「最後にこれに直面したときのことを教えてください」＋ 実際に手を伸ばす行動を測定するペイントドアのクリックスルー。

5. 成功基準はテスト前に定義されていた

チームはテストを実施する前に、どのような結果ならその仮説が正しいと証明できるか —— 具体的で測定可能なしきい値 —— に合意しておく必要があります。

こうした場合に警告します： 合格／不合格のしきい値が事前に設定されていない場合。「成功」が結果が出た後に初めて説明される場合。指標はあるが目標値がない場合（「サインアップがどうなるか見てみよう」）。

• ❌ ランディングページを公開してから、サインアップ 30 件は「十分だと感じる」と判断する。
• ✅ 「成功＝訪問者の 10% 以上が予約購入」と公開前に合意しておく。

6. 結果は願望ではなく証拠として読む

事前に設定した基準に従い、ゴールポストを動かさないようにしましょう。データの基本を尊重します —— サンプルサイズ（n=10 はユーザビリティのバグは見つけられますが、オーディエンス全体のコンバージョンや選好については何も言えません）、期間（1 日限りのテストでは例外的なトラフィックを捉えてしまいます）、そして比較における統計的有意性です。パターン（複数の情報源で繰り返されるもの）と逸話（最も声の大きい単一の意見）を区別し、定性的な結果と定量的な結果を照合しましょう —— 一致はゴーサインであり、対立は別のテストを実施するシグナルであって、都合のよい方を選ぶためのものではありません。

こうした場合に警告します： 「60% 対目標 70% —— まあ十分近い」。少数のユーザーからのコンバージョン／選好の主張。1 日限りやごく短い期間の結果を一般化している場合。声の大きい顧客や経営層の単一の要望が判断を左右している場合。定量はあることを示し、定性は別のことを示しているのに、チームがそのまま進めてしまう場合。曖昧なデータを確証バイアスで読んでいる場合。

• ❌ 「完了率はわずか 55% だったがフィードバックは好意的だったので、出荷する。」
• ✅ 「55% は 70% の基準に届かなかった → 修正して再テストする。基準を再解釈はしない。」

7. 反証結果は実際に計画を変える

テストは学習の機会であり、反証には価値があります — それは誤った構築を防ぎます。反証された仮定は意思決定を変えなければならず（修正、方向転換、または中止）、その結果は文書化されます（仮定、手法、基準、発見、次のステップ）。すでに下された決定にゴム印を押すためだけに実行されるテストは、テストではありません。

次の場合に指摘します： 仮定が反証されたのに何も変わらなかった場合。テストが既定の結論のための芝居だった場合。結果が文書化されておらず、チームが学習も再検討もできない場合。検証が、方向性をまだ変えられたはずの早い段階ではなく、構築後のチェックボックスとしてスケジュールされている場合。

• ❌ ユーザビリティテストが失敗しても、「もうコミットしたから」という理由で元のデザインをそのまま出荷する。
• ✅ 失敗が、コミット前の文書化された修正と再テストを引き起こす。

緊張関係に関する注記： 厳密さはリスクに応じてスケールします — 小さく、安価で、可逆的な決定には統計的に有意な実験は必要なく、それを要求すること自体が一つの失敗です。低リスクの判断に適切な高速なローファイテストを指摘しないでください。どちらの方向のミスマッチも指摘します：些細な決定に対する過剰な手法、あるいはコストが高く不可逆的な決定の下での薄弱な証拠。

---

重大度評価

各所見を意思決定への損害 — この検証をそのまま実行した場合に何が犠牲になるか — によって評価します：

重大度	意味
Critical	重要な、または元に戻しにくい投資を、有効なテストなしに支える耐荷重仮定 — 未テスト、表明された意図のみでテスト、ゴールポストの移動、または主張を裏付けるにはサンプルが小さすぎる。意思決定は事実上支持されていない。
Major	正しい仮定は視野にあるものの、その賭けに対して証拠が弱い — 適合しない忠実度の手法、事前に設定された成功基準の欠如、逸話や単一の声に基づく、定性と定量の衝突の無視。
Minor	学習への信頼を損なう衛生面 — 文書化されていない結果、継続的ではなく断続的なテスト、曖昧なままの二次的な仮定。
Cosmetic	それ以外は健全な計画に対する表現の磨き上げ。これらでレポートを水増ししないこと。

重複 — 先送りし、二重に指摘しない：成功指標そのものが有効か（虚栄、ゲーム化可能、反証不能）は pm-okr-metric-validity-audit に属します — この監査は仮定が厳密にテストされたかを確認し、あちらは指標が達成に値するかを確認します。仕様書がその仮定をリスクとしてそもそも表面化したかは pm-spec-quality-audit に属します — この監査はテスト手法と証拠を確認します。競合する賭けの間での優先順位付けの規律は pm-prioritization-rigor-audit に属します。

---

出力形式

## Assumption Rigor Audit — [Plan / Experiment / Claim]
Context: [decision it informs · reversibility/stakes · discovery stage, if known]

### Critical
- [Issue] — what's wrong → fix. (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest decision-damage fixes.

常に優先順位付けされた上位の課題で締めくくります — 平坦なリストは誰の行動にも役立ちません。

---

優れた監査の進め方

1. まずコンテキストを確立する — この検証はどの意思決定を支え、どれほど高コストで可逆的ですか？厳密さはそれに応じてスケールします。可逆的な $0 のコピー修正と、6か月にわたるプラットフォームへの賭けは、同じ基準では測られません。
2. 信仰の飛躍となる仮定を見つける — すべてが依拠している信念を名指しし、それがテストされたのかどうかを確認します。
3. 実際のコストのみを指摘する — 低リスクの判断に対する適切に軽いテストは正しく、欠陥ではありません。
4. 活動だけでなく証拠を問いただす — テストを実行すること ≠ 何かを学ぶこと。サンプル、期間、事前設定された基準、そしてシグナルか逸話かを確認します。
5. 修正は具体的に — 最初にテストすべき仮定、より適した手法、欠けている成功しきい値を名指しします — 「もっと厳密に」ではありません。
6. 列挙せず優先順位を付ける — 意思決定を損なう3つの所見は、15の些細な指摘に勝ります。

---

よくある do/don't パターン

❌ しない	✅ する
「テストしてユーザーに好評でした」を受け入れる	どの前提を、どの手法で、あらかじめ設定したどの基準に対して検証したのかを尋ねる
アイデアそのものを検証対象として扱う	アイデアが依存する信念（望ましさ、実現可能性、実行可能性、使いやすさ、倫理）を検証する
チームに検証しやすい前提を検証させる	重要度が高く不確実性も高い前提が最初に検証されたかを確認する
「これを使いますか？」への回答を検証として通す	仮説上の意向ではなく、過去の行動や実際のアクションを求める
n=10 のコンバージョン主張を受け入れる	サンプル・期間・有意性を、なされている主張に見合ったものにする
事後に「ほぼ十分」を許容する	あらかじめ合意した成功基準を守る。不足 → 修正して再検証
反証された前提が何も変えなかったことを無視する	反証は意思決定を動かさなければならない。学びを記録する
指標そのものが妥当かどうかを再監査する	指標の妥当性は pm-okr-metric-validity-audit に委ねる
小さく可逆な判断に厳密な実験を要求する	判断の重要性に応じて厳密さを調整する
順位づけされていない課題の山を提出する	意思決定への損害で重大度を判断し、上位3つの優先事項を示す

---

出典レッスン（Uxcel）

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