pre-mortem

概要

Pre-Mortem（事前検死）は、計画を実行する前に「この計画は失敗した」と仮定し、その失敗から逆算して原因・予防策を洗い出す技法。事後のポストモーテム（何が起きたかを検証する）と対照的に、実行前に楽観バイアスを打ち破ることが目的。

doboku-note（土木試験対策サイト）では、新規施策・note 商品リリース・SNS 戦略転換・大規模コンテンツ投資など、後戻りしにくい意思決定のレビューに使う。「美しい計画書」に隠れた失敗パターンを、実行前に具体的な言葉にする。

引数

$ARGUMENTS — レビュー対象（以下のいずれか）

計画・施策を説明するファイルパス（例: docs/strategy/04_収益化戦略.md）
自由記述の計画概要（ファイルが無い/これから実行する施策のとき）

対象ファイルが無い場合は、ユーザーに施策の要点（何を・いつ・どのくらいの規模で）を確認してから進める。

手順

Phase 1: 対象の理解

引数で指定された対象を読み込む（ファイルがあれば Read、無ければユーザーの説明を整理）
関連する既存ドキュメント（隣接する戦略・過去の類似施策の記録）があれば docs/ 配下を検索して参照する
施策の前提（規模・期間・投入リソース・成功指標）を1段落で要約し、認識のズレがあれば先に確認する

Phase 2: 失敗シナリオのブレインストーム

「この計画が完全に失敗した」前提で、失敗シナリオを5〜10個書く。

見出し: 失敗の本質を1行で（例:「note 有料記事が全く売れず在庫化した」）
過去形で書く: 「〜だろう」ではなく「〜だった」「〜してしまった」
具体的に何が起きたか: 箇条書き2〜4項目
可能な範囲で数字を使う（「あまり売れない」ではなく「初月3本」等、外挿でよい）

検討すべき観点（該当するものだけ）:

需要・市場: 想定読者が実際には検索・購入しない
実行・継続: 運営者一人の工数が続かない、途中で他タスクに埋没する
競合・外部環境: 競合が先に類似施策を出す、プラットフォーム規約変更（note/SNS/検索アルゴリズム）
品質: content-principles や資格別ルーブリックを満たせない粗製乱造
カニバリ: 既存 note 商品・既存記事と競合し共食いする
計測: 効果測定の仕組みが無く「効いたか分からない」まま放置される

Phase 3: 確率×影響評価

Phase 2 の各シナリオに「発生確率」（高/中/低）と「影響度」（致命的/大きい/軽微）を付け、優先度の高いもの（確率高×影響大）から並べ替える。

シナリオ	確率	影響度	優先度
...	高/中/低	致命的/大きい/軽微	...

表は2軸のみ（CLAUDE.md の表ルールに従い4列まで）。

Phase 4: 予防策・早期検知シグナル

優先度の高いシナリオから、各シナリオに対して以下をセットで書く。

予防策（Prevention）: そもそも起きないようにする具体的な仕組み・最小実装（理想論ではなく今週中にできる粒度）
早期検知シグナル: 「いつ・何を見て・どう判断するか」を数値で。例:「公開2週間後に note 販売数が0件なら価格/訴求を見直す」

既に対策済みのものは正当に評価し、無理にリスクを誇張しない。

Phase 5: まとめ

最後に「最悪のシナリオでも大丈夫な理由」を1つの表と1文で締める。

## まとめ: 最悪のシナリオでも「大丈夫」な理由

| 最悪のケース | なぜ大丈夫か |
|---|---|
| ... | ... |

**{この計画が本当に致命傷になる唯一のパターンを1文で}**

良い例・悪い例

良い例（失敗シナリオ）:

「R8予想問題集が発売初月0部だった。理由は告知が note 内 CTA 1箇所のみで、既存フォロワー以外にリーチしなかったため。X/Instagram での告知が計画になく、検索流入も新規記事なしでは伸びなかった。」 → 確率:中／影響度:大きい／予防策:「発売と同時に X・IG で告知投稿を最低3本予約する」／早期検知:「発売1週間後に販売数0なら告知チャネルを追加する」

悪い例（避けるべき書き方）:

「なんとなく売れない気がする」（数字が無い・過去形でない・原因が特定できない・対策に繋がらない）

完了条件

失敗シナリオが5件以上、各シナリオに確率×影響度評価がある
優先度上位のシナリオすべてに予防策と早期検知シグナルが対で列挙されている
「最悪のシナリオでも大丈夫な理由」のまとめがある
数字・過去形・自分事の文体ルールに沿っている（「たくさん」ではなく具体数字、他人事の分析でなく当事者の回顧調）

トーンと姿勢

容赦なく、しかし建設的に: 問題を美化しない。「まだ大丈夫」は禁句
過去形で書く: 失敗シナリオは「〜だった」「〜してしまった」
数字で語る: 「たくさん」ではなく具体的な数字（外挿でよい）
既に対策済みのものは正当に評価する: 無理にリスクを誇張しない

出力先

会話内で完結させてよい。保存する場合は docs/reviews/pre-mortem/{対象名}-{YYYY-MM-DD}.md に1ファイルで保存する（docs/reviews/critical/ の命名慣習に準拠、ディレクトリが無ければ新規作成してよい）。

参照

.claude/skills/management/critical-review/SKILL.md — 批判的レビュー（既存計画の事後評価、対になるスキル。pre-mortem は実行前、critical-review は実行後/現状評価という違い）