assumption-audit について
assumption-auditは、戦略や事業ケース、製品要件をまとめるチーム向けの検証スキルです。仮定と証拠を記録し、計画のストレステストや確率の調整を通じて、重要な主張の根拠を確認します。
主な機能
- 01重要な仮定を列挙し事実と区別
- 02証拠と判明時点を記録
- 03反証を探しインセンティブを点検
- 04プレモーテムとバックキャスティング
- 05確率をパーセンテージで調整
- 06脆弱性と削減可能な要素を監査
活用シーン
- 01戦略メモの確定前に根拠を確認
- 02予測に依存する提案を評価
- 03重大な意思決定の失敗要因を予測
- 04ブレインストーミング後に案を検証
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ joellewis/ skill-library --skill assumption-auditインストール後、Claude Code で/assumption-auditを入力して読み込まれたか確認します。
詳細
概要
Assumption-audit は、結果による評価(成果を基準に意思決定を評価すること)や後知恵バイアス(物事が起きた後で、予測できていたと感じること)を防ぐ「エビデンスゲート」です。何が分かっていて、何が推測なのかを正直に説明するよう促します。
鉄則
NO SIGN-OFF WITHOUT VALIDATION EVIDENCE FOR EVERY KEY CLAIM
エビデンスのない主張は脆弱性です。監査されていない前提は脆い戦略を生み、最初の変動で崩壊します。
状態遷移図
digraph assumption_audit_flow {
"Start" [shape=doublecircle];
"Step 1: Inventory Key Assumptions" [shape=box];
"Step 2: Evidence Mapping (Knowledge Tracker)" [shape=box];
"Step 3: Stress-Test (Pre-mortem)" [shape=box];
"Step 4: Probability Calibration" [shape=box];
"Gate: Claim-Evidence Match" [shape=diamond];
"Step 5: Fragility Audit (Via Negativa)" [shape=box];
"Done: Audit Passed" [shape=doublecircle];
"Start" -> "Step 1: Inventory Key Assumptions";
"Step 1: Inventory Key Assumptions" -> "Step 2: Evidence Mapping (Knowledge Tracker)";
"Step 2: Evidence Mapping (Knowledge Tracker)" -> "Step 3: Stress-Test (Pre-mortem)";
"Step 3: Stress-Test (Pre-mortem)" -> "Step 4: Probability Calibration";
"Step 4: Probability Calibration" -> "Gate: Claim-Evidence Match";
"Gate: Claim-Evidence Match" -> "Step 5: Fragility Audit (Via Negativa)" [label="matched"];
"Gate: Claim-Evidence Match" -> "Step 1: Inventory Key Assumptions" [label="mismatch"];
"Step 5: Fragility Audit (Via Negativa)" -> "Done: Audit Passed";
}
このスキルを使用する場面
- PRD、戦略メモ、ビジネスケースを最終決定する前。
- 推奨案が将来予測や市場の「確実性」に依存している場合。
- 「なんとなくそう思う」や「明らかにそうだ」と言っていることに気付いたとき。
- 間違った場合の損失が重大となる、影響の大きな意思決定の前。
このスキルを使用しない場面
- 失敗のコストより監査のコストのほうが高い、影響が小さく取り消し可能な意思決定(タイプ 2 の意思決定)の場合。
- 純粋に創造的な作業(例:ブレインストーミング)の場合。監査文化がアイデア創出を妨げる可能性があるためです(アイデア創出の後、選定の前に使用してください)。
中核プロセス
ステップ 1:主要な前提を洗い出す
- 主要な主張をすべて特定する: 提案の基盤となっている要素を列挙します。
- 判断ミスを確認する: 判断ミスの 28 の原因をチェックリストで確認します(例:アンカリング、社会的証明、インセンティブによるバイアス)。(出典:Bevelin, Seeking Wisdom)
- 事実と信念を区別する: 検証済みの事実と、情報に基づく推測を明確に区別します。(出典:Duke, How to Decide)
ステップ 2:エビデンスをマッピングする(Knowledge Tracker)
- Knowledge Tracker を使用する: 何を、いつ知っていたかを正確に記録します。これにより、後知恵バイアスによって実際より多くのことを知っていたと思い込むのを防ぎます。(出典:Duke, How to Decide)
- ダーウィンの黄金律: 望む結論に反する事実、つまり反証エビデンスを積極的に探し、記録します。(出典:Bevelin/Darwin, Seeking Wisdom)
- インセンティブを監査する: 「今、この信念が自分やチームにとって都合がよいのは、どのようなインセンティブがあるからか」と問いかけます。(出典:Sivers, Useful Not True)
ステップ 3:ストレステストを行う(プレモーテムとバックキャスティング)
- プレモーテムを実施する: 1 年後の今、このプロジェクトが壊滅的な失敗に終わったと想像します。最も可能性の高い失敗原因を特定するため、さかのぼって考えます。(出典:Duke, Thinking in Bets)
- バックキャスティングを実施する: プロジェクトが大成功したと想像します。この成功が実現するために、何が必ず起きていなければならないでしょうか。現在の計画は、その必須条件を満たしていますか。(出典:Duke, Thinking in Bets)
ステップ 4:確率を適切に見積もる
- 曖昧な表現をなくす: 「可能性が高い」「おそらく」「たぶん」などの言葉を、正確な確信度の割合(例:「70%の確信がある」)に置き換えます。(出典:Duke, How to Decide)
- 期待値を計算する: 可能であれば、成功確率に想定される利益を掛け合わせ、リスクを取る価値があるかを確認します。(出典:Duke, Thinking in Bets)
ステップ 5:脆弱性を監査する(Via Negativa)
- Via Negativa を適用する: 計画が失敗する要因を減らすために、削除または簡素化できるものを特定します。(出典:Taleb, Antifragile)
- スキン・イン・ザ・ゲームを確認する: 前提を立てた人は、その前提が間違っていた場合にコストを負担する人でもありますか。(出典:Taleb, Antifragile)
- バーベルを構築する: 計画の中核は堅牢で安全なものにしつつ、変動を捉えるために、上振れの大きい小規模な「オプション」を設けます。(出典:Taleb, Antifragile)
スキル間の呼び出し
必須のサブスキル:using-skills — 監査の規律を維持するため。
推奨サブスキル:devils-advocate — 前提に対して敵対的な観点から圧力をかけるため。
推奨サブスキル:decision-frameworks — 最終承認を構成するため。
合理化の一覧表
| 考え | 実態 |
|---|---|
| 「必要な調査は済ませました。これがうまくいくことは分かっています。」 | これは「確定的な楽観主義」であり、運や隠れた変動要因の役割を無視しています。 |
| 「知識の記録ツールは必要ありません。なぜこれを選んだのか覚えています。」 | 記憶は「後知恵バイアス」を生み出す装置であり、自分が正しかったと思えるように過去を書き換えます。 |
| 「プレモーテムは悲観的すぎます。チームの士気を下げてしまいます。」 | 失敗が避けられない状況でチームの士気を実際に下げるのは、脆弱性を放置することです。 |
| 「期待できる利益がとても大きいので、多少間違っていても問題ありません。」 | 脆弱なシステムの損失は「凹型」です。「多少間違っている」だけで、完全な破滅につながる可能性があります。 |
危険信号
次のような考えが浮かんだら、立ち止まってください。近道をしようとしています。
- 「信じてください。これは勘で分かります。」 → 直感は、監査されていないバイアスにすぎないことがよくあります。
- 「ほかの人もみんなこうしています。」 → 社会的証明バイアスが、証拠の不足を覆い隠しています。
- 「その問題に直面したら考えましょう。」 → 必要なプレモーテムを避けています。
診断チェックリスト
- 「可能性が高い」とされる結果すべてに、具体的な確率(パーセンテージ)が設定されていますか?
- 失敗の要因を特定するために、プレモーテムを実施しましたか?
- 最も重要な仮定のうち、上位3つを裏付ける証拠が文書化されていますか?
- 「ヴィア・ネガティバ」のチェックで、安全性のために取り除くべきことが少なくとも1つ見つかりましたか?
- 「ナレッジトラッカー」で、当時分かっていたことと、現在分かっていることが区別されていますか?
参考資料
- Duke, Thinking in Bets, 第1章(結果による判断)、第6章(未来のテント設置)
- Duke, How to Decide, 第3章(後知恵バイアス)、第4章(確率)、第5章(プレモーテム)
- Taleb, Antifragile, 第11章(バーベル戦略)、第20章(リンディ効果)、第23章(自分自身もリスクにさらす)
- Bevelin, Seeking Wisdom, 第2部(誤判断の心理学)、付録4(チェックリスト)
- Sivers, Useful Not True, (有用性と真実の違い)
コメント
Markdown 対応