pre-mortem

プレモーテム — 作る前に失敗を想定する

まだ起きていないプロジェクトの振り返りです。「すべてのリスクを列挙して」というプロンプトでは見落とされる、現実的なリスクを明らかにします。

MIT SloanでのGary Kleinの研究を起源とし、現在ではAWSや、オペレーションが成熟した他の組織で標準となっています。

プレモーテムの5つのステップ

Step 1. 6か月後の未来を想像する

プロジェクトはリリースされました。誰の目にも明らかな、世間に知られた失敗です。Redditにはその話題のスレッドが立っています。CEOは何が問題だったのか尋ねています。

Step 2. 事後検証の新聞見出しを書く

1文で、具体的かつ明確にします。例：

• ❌ 悪い例：「品質に多少の問題がありました。」
• ✅ 良い例：「2026-09-12、StripeのWebhookハンドラーが生の本文ハッシュで重複排除していたため、ネットワークの一時的な障害中にStripeが配信を再試行した結果、3万人の顧客に二重請求が発生した。」

見出しを書くことで、失敗の原因を具体的に特定せざるを得なくなります。

Step 3. この失敗が起きた個別の理由をすべて列挙する

10〜15個の理由をブレインストーミングします。具体的に書きます。各項目には以下を含めてください。

• 実在するコンポーネント／ファイル
• 実際に起きた失敗モード（競合状態、スキーマ不一致、認証情報の期限切れ）
• 実際の人的要因（オンコール担当者がアラートに気づかなかった、ランブックが古かった）

「テストが不十分だった」のような曖昧な表現は避け、「重複排除キーの衝突ケースに対するプロパティベーステストを書かなかった」のように置き換えます。

Step 4. 発生可能性 × 重大度で順位付けする

原因ごとに、次のスコアを付けます。

• 発生可能性： 1〜5（1＝10年に1度、5＝毎月）
• 重大度： 1〜5（1＝見た目の問題、5＝データ損失／規制違反）
• リスクスコア： 発生可能性 × 重大度

リスクスコア上位3件が、最優先で軽減すべきリスクです。

Step 4b. リスクを分類する — Tigers / Paper Tigers / Elephants

スコアを付けたら、各リスクを次の3種類に分類します。

🐯 Tigers — プロジェクトを頓挫させかねないと、あなた自身が考える現実的な問題

• 証拠、過去の経験、または明確な論理に基づいている
• 夜も眠れなくなるほどの懸念である
• 具体的な対策が必要
• 各Tigerを緊急度で分類する：
  • Launch-Blocking：リリース前に必ず解決する（コア機能の障害、規制上のブロッカー、データ完全性のリスク）
  • Fast-Follow：リリース後30日以内に必ず解決する（パフォーマンスの問題、二次機能）
  • Track：リリース後に監視し、問題になった場合に修正する（エッジケース、あれば望ましい機能）

📄 Paper Tigers — 他の人が指摘するかもしれないが、現実のリスクではないとあなたが考える懸念

• 表面的にはもっともらしいが、可能性が低い、または誇張されている
• 多くのリソースを投入する価値はない
• 関係者の認識を合わせ、同じ議論の繰り返しを避けるために記録する価値はある
• それぞれについて、現実のリスクではないと考える理由を説明する

🐘 Elephants — チームが認識しているものの、率直に話し合っていないこと

• 不都合な懸念：技術的負債、チーム内の緊張、非現実的なスケジュール、誰も気に入っていない設計
• 不確かな問題 — 問題かどうか分からないが、誰も調査していない
• リリース前に明確に表面化させる必要がある — 放置されたElephantはリリース後にTigerになります

Step 5. 上位3つの原因それぞれについて、計画にガードレールを記載する

各ガードレールは、計画に加える具体的な変更です。

• その原因を検出できたはずのテスト
• サーキットブレーカー／機能フラグ
• ランブックの項目
• 具体的なSLOを設定した監視アラート

上位3つの原因を時間／予算内に軽減できない場合は、ユーザーにエスカレーションします：「この計画では、Xのリスクを軽減策なしで受け入れます。」

テンプレート — PLAN-*.mdに追加

## Pre-mortem

Six months from now, this project failed. Headline:

> <one-sentence failure headline>

### Top reasons (likelihood × severity)

| Cause | L | S | Risk | Mitigation in plan |
|---|---|---|---|---|
| <specific cause> | 4 | 5 | 20 | <Task #N: write idempotency test> |
| ... | | | | |

### 🐯 Tigers (real risks — require action)

| Tiger | Classification | Mitigation | Owner | Due |
|-------|---------------|-----------|-------|-----|
| <risk> | Launch-Blocking | <concrete action> | <team/person> | <date> |
| <risk> | Fast-Follow | <concrete action> | <team/person> | <date> |
| <risk> | Track | <monitoring approach> | <owner> | post-launch |

### 📄 Paper Tigers (overblown — document to align stakeholders)

- **<concern>**: Not a real risk because <reason>. If <condition> changes, revisit.

### 🐘 Elephants (unspoken — needs open discussion)

- **<concern>**: Nobody is talking about this. Suggested conversation: "<how to raise it>".

### Accepted risks (no mitigation)

- <risk> — accepted because <budget/scope reason>. Owner: <name>.

アーキタイプ別のよくある失敗パターン

クイックスタート — アーキタイプごとに最もよくある事前検討での失敗原因：

アーキタイプ	よくある失敗
fintech / commerce	冪等性キーの衝突；リトライの集中による二重課金
healthcare	デバッグログからPHIが漏えい；ベンダーとのBAAが未締結
web3	オラクルのデータが古い；ボンディングカーブでのフラッシュローン攻撃
mlops	トレーニングとサービングの間のスキュー；モデルドリフトを検出できない
iot-embedded	復旧手段のない地域でOTAによりデバイスが使用不能になる
data-platform	到着が遅れたデータが正しい値を上書きする
ai-system / agent-product	プロンプトインジェクションにより他のユーザーのデータが窃取される
enterprise-saas	RLSの不備によるテナント間のデータ漏えい
cli-tool	確認なしで実行される破壊的なフラグ（rm -rfに相当）
library	マイナーバージョンの更新で後方互換性が失われる

事前検討におけるアンチパターン

❌ 漠然としたリスク。「パフォーマンスが問題になるかもしれない。」具体的に示してください。どの操作が、どの負荷で問題になるのか、SLOは何かを明確にします。

❌ 天災のようなリスク。「AWSが停止する可能性がある。」そのとおりですが、対策につながりません。軽減できることに焦点を当ててください。

❌ **防御的なリスト。**網羅的に見せるために、すでに軽減済みのリスクを列挙することです。現在の計画ではまだ対処できていないリスクだけを挙げてください。

❌ **見出しを省略する。**見出しがなければ、チームは失敗シナリオが現実に起こり得ると信じません。

省略するケース

• nano project_size — 事前検討はオーバーヘッドになります。
• テストカバレッジが十分な純粋なリファクタリング — ガードレールはすでに整っています。
• 1行で再現できるバグ修正 — リスクの範囲が明確です。