swing-mortem

事前検死

まず失敗したと仮定してから逆算し、リスク、早期警告、回避策を明らかにすることで、楽観バイアスを克服する将来の失敗分析です。

Gary Klein の事前検死の手法に基づいています：「うまくいくか？」と尋ねるのではなく（この問いは楽観バイアスを引き起こします）、このスキルでは「今から 6 か月後、これは完全に失敗しました。何が起きたのでしょうか？」と問います。

swing-review との主な違い：

• swing-review は現在の状態を調べます — 「今、何が問題なのか？」
• swing-mortem は未来を調べます — 「後になって、何が問題になるのか？」
• 敵対的レビューは既存の欠陥を見つけます。事前検死は、まだ存在していない欠陥を予測します。

ルール（絶対）

1. 一般的なリスクを挙げてはいけません。 失敗シナリオごとに、具体的なテクノロジー、数量、期間、または条件を明記する必要があります。「データベースがスケールしない可能性がある」は禁止です。「30 秒以上接続を占有する長時間実行の分析クエリにより、同時接続ユーザーが 2,000 人を超えたときに PostgreSQL の接続プールが枯渇する」は許容されます。
2. 5 つのカテゴリーにまたがるシナリオを、ちょうど 5 つ作成してください。 技術、組織、外部、時間、前提の各カテゴリーから 1 つずつです。カテゴリーを省略してはいけません。また、1 つのカテゴリーに複数のシナリオを含めてはいけません。
3. 先行指標は観察可能かつ測定可能でなければなりません。 「問題に注意する」は禁止です。指標ごとに、何を測定するのか、どのしきい値が危険を示すのか、どこで観察するのかを明記する必要があります。
4. サーキットブレーカーには具体的な発動条件を含めてください。 「問題が起きたら」は禁止です。発動条件はすべて、具体的なしきい値を持つ測定可能な条件にする必要があります。
5. swing-mortem の要約は必須です。 分析の BLUF です。末尾に記載し、最も大きなリスク、その先行指標、回避策を 1 段落にまとめる必要があります。
6. 完全な失敗を前提としてください。 部分的な失敗でも、「期待を下回る成果」でもありません。前提とするのは完全な失敗です。この極端な捉え方が、創造的なリスク特定につながります。表現を和らげてはいけません。
7. 網羅性より具体性を重視してください。 各カテゴリーにつき、深く分析したもっともらしい失敗シナリオを 1 つ挙げるほうが、浅いシナリオを 5 つ挙げるより価値があります。広さより深さを重視してください。

手順

次の 6 つのフェーズを順番に実行します。フェーズを飛ばしてはいけません。

フェーズ 1：失敗の枠組みを設定する

分析を始める前に、時間的な枠組みと文脈を定めます。

FAILURE FRAME
─────────────
Subject: [what is being analyzed — plan, decision, architecture, launch]
Timeframe: [when failure is discovered — default 6 months, adjust to context]
Failure statement: "It is [timeframe] from now. [Subject] has failed completely.
Not partially underperformed — completely failed. The team is conducting a
post-mortem. What went wrong?"

対象が曖昧すぎる、または広すぎる場合は、先に確認の質問を 1 つしてください。「プロジェクトを分析して」は曖昧すぎます。「ユーザーサービスを MongoDB から PostgreSQL に移行する計画を分析して」なら実行可能です。

シナリオを作成する前に、次の情報を集めます。

• コードやアーキテクチャが存在する場合は、現実に即したシナリオにするため、関連ファイルを読む
• プロジェクト計画が存在する場合は、スケジュールと依存関係を確認する
• 過去の意思決定が文書化されている場合は、その判断の根拠と制約を確認する

具体的な資料がある場合は、想像だけでシナリオを作成してはいけません。

フェーズ 2：失敗シナリオの作成

各カテゴリーから 1 つずつ、失敗シナリオをちょうど 5 つ作成します。各シナリオは、一般的なリスクのラベルではなく、具体的で現実味のある筋書きにする必要があります。

カテゴリー 1：技術

テクノロジーが期待どおりに機能しませんでした。具体的なテクノロジー、具体的な故障モード、そして故障に至った具体的な条件を挙げます。

カテゴリー 2：組織

チーム、プロセス、またはコミュニケーションが破綻しました。失敗の原因となった具体的なチーム内の関係性、引き継ぎ箇所、またはプロセス上の不備を挙げます。

カテゴリー 3：外部

市場の変化、競合他社の動き、規制の変更、または依存関係の破綻がありました。具体的な外部要因と、その具体的な影響を挙げます。

カテゴリー 4：時間

スケジュールの見積もりが誤っていました。何にどれだけ時間がかかったのか（またはどの機会を逃したのか）と、それによって具体的にどのような連鎖的な結果が生じたのかを挙げます。

カテゴリー 5：前提

中核となる前提が誤りだと判明しました。具体的な前提、その時点で妥当に思えた理由、そして実際にはどうだったのかを挙げます。

各シナリオは次の形式で記述してください。

SCENARIO [N]: [Category] — [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What happened:
[2-4 sentence specific narrative of how this failure unfolded]

Why it was plausible:
[1-2 sentences on why this wasn't obvious beforehand]

Concrete consequence:
[Specific, measurable impact — revenue lost, users affected, time wasted, data compromised]

フェーズ 3：発生可能性 × 影響度マトリックス

各シナリオを評価し、優先度を決定します。

RISK MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | Category       | Scenario             | Likelihood | Impact       | Priority |
|---|----------------|----------------------|------------|--------------|----------|
| 1 | Technical      | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 2 | Organizational | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 3 | External       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 4 | Temporal       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 5 | Assumption     | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |

発生可能性： 高（>50％）、中（15～50％）、低（<15％） 影響度： 壊滅的（プロジェクトの中止、取り返しのつかない損害）、深刻（大幅なやり直し、大きな損失）、中程度（後退するものの、努力すれば回復可能）

優先度の評価：

• 高 + 壊滅的 = P1
• 高 + 深刻、または中 + 壊滅的 = P2
• 中 + 深刻、または高 + 中程度 = P3
• その他すべて = P4

優先度の高い順に上位3つを選び、フェーズ 4～5 で詳細に分析します。同じ優先度の場合は、発生可能性が高いものを優先します。

フェーズ 4：先行指標

上位3つのリスクそれぞれについて、早期警告シグナルを2～3個特定します。これらは、手遅れになる前に障害モードが顕在化し始めていることを示す、観測可能で測定可能な条件です。

LEADING INDICATORS — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Indicator 1: [Name]
  Measure: [What specifically to track]
  Threshold: [At what value does this become a warning]
  Where to observe: [Dashboard, log, metric, report, or manual check]
  Lead time: [How far in advance of failure this signal appears]

Indicator 2: [Name]
  Measure: [What specifically to track]
  Threshold: [At what value does this become a warning]
  Where to observe: [Dashboard, log, metric, report, or manual check]
  Lead time: [How far in advance of failure this signal appears]

すべての指標は**「インターンテスト」**に合格する必要があります。この説明だけを渡された新しいチームメンバーが、しきい値を超えたかどうかを判断できるでしょうか。できない場合は、より具体的にしてください。

フェーズ 5：サーキットブレーカー

上位3つのリスクそれぞれについて、いつ、どのように方針を変更するかを決めるための意思決定フレームワークを定義します。

CIRCUIT BREAKER — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Trigger:
  [Specific measurable condition that activates this circuit breaker.
   Must be a concrete threshold, not "if things go wrong."]

Fallback:
  [The alternative path. What do you switch to? Be specific about
   the replacement approach, not just "find another way."]

Cost of delay:
  [What do you lose by waiting one more week/sprint/month for more
   information before activating the fallback? Quantify if possible.]

Decision owner:
  [Who has authority to pull this trigger? Role, not name.]

フェーズ 6：プレモーテムの要約（BLUF）

分析全体を1つの段落にまとめます。これは最も重要な成果物です。読者がこの段落だけを読んでも、重要な洞察を把握できるようにしてください。

形式：

PRE-MORTEM SUMMARY
━━━━━━━━━━━━━━━━━━

The highest risk to [subject] is [specific scenario from top priority].
You'll know it's happening when [most actionable leading indicator with
threshold]. Your escape hatch is [primary fallback from circuit breaker].
The cost of ignoring this: [concrete consequence]. The cost of acting
too early: [trade-off of the fallback]. Monitor [specific metric] starting
[when] to stay ahead of this risk.

出力形式

## Pre-Mortem: [Subject]

### Failure Frame
> It is [timeframe] from now. [Subject] has failed completely. What went wrong?

### Failure Scenarios

#### Scenario 1: Technical — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 2: Organizational — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 3: External — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 4: Temporal — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 5: Assumption — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

### Risk Matrix
| # | Category | Scenario | Likelihood | Impact | Priority |
|---|----------|----------|------------|--------|----------|
| 1 | Technical | ... | ... | ... | ... |
| 2 | Organizational | ... | ... | ... | ... |
| 3 | External | ... | ... | ... | ... |
| 4 | Temporal | ... | ... | ... | ... |
| 5 | Assumption | ... | ... | ... | ... |

### Deep Analysis (Top 3 Risks)

#### Risk [N]: [Title]

**Leading Indicators:**
1. **[Indicator name]** — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]
2. **[Indicator name]** — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]

**Circuit Breaker:**
- **Trigger:** [specific measurable condition]
- **Fallback:** [concrete alternative]
- **Cost of delay:** [what you lose by waiting]
- **Decision owner:** [role]

[Repeat for each top risk]

### Pre-Mortem Summary
The highest risk to [subject] is [X]. You'll know it's happening when [Y]. Your escape hatch is [Z]. The cost of ignoring this: [consequence]. The cost of acting too early: [trade-off]. Monitor [metric] starting [when].

品質の目安

悪いプレモーテム（避けてください）

## Pre-Mortem: New Microservices Migration

### Failure Scenarios

#### Scenario 1: Technical — It didn't scale
**What happened:** The system couldn't handle the load.
**Why plausible:** Scaling is hard.
**Consequence:** Users were unhappy.

#### Scenario 2: Organizational — Communication issues
**What happened:** Teams didn't communicate well.
**Why plausible:** Communication is always a challenge.
**Consequence:** Things were delayed.

#### Scenario 3: External — Market changed
**What happened:** The market shifted.
**Why plausible:** Markets are unpredictable.
**Consequence:** Revenue was impacted.

### Leading Indicators
- Watch out for scaling issues
- Monitor team communication
- Keep an eye on the market

### Circuit Breakers
- If things go wrong, switch to plan B
- If communication breaks down, have more meetings

なぜ悪いのか：

• すべてのシナリオが一般的で、文字どおりどのプロジェクトにも当てはまります
• 具体的な技術、数値、条件が挙げられていません
• 「スケールしなかった」はシナリオではなく、分類ラベルです
• 先行指標が測定不能な決まり文句です（「注意する」「目を配る」など）
• サーキットブレーカーに発動しきい値も、具体的な代替策もありません
• 「会議を増やす」はサーキットブレーカーではなく、その場しのぎの対処です
• リスクマトリックスも優先順位付けも、スイングモーテムの要約もありません

良いプレモーテム（このようにしてください）

## Pre-Mortem: Migrating Order Service from Monolith to Event-Driven Microservices

### Failure Frame
> It is 6 months from now. The microservices migration has failed completely.
> The team reverted to the monolith. What went wrong?

### Failure Scenarios

#### Scenario 1: Technical — Kafka consumer lag cascades into order loss
**What happened:** Under Black Friday load (12x normal), Kafka consumer groups
for the order-processing service fell behind by 4+ hours. The dead letter queue
filled its 10GB allocation. 2,340 orders were silently dropped because the
retry policy exhausted its 3 attempts while downstream inventory service was
backpressured. No alert fired because monitoring tracked consumer group status
(STABLE) rather than consumer lag (which had no threshold configured).
**Why plausible:** Load testing only covered 3x normal traffic. The failure
mode — consumer lag + DLQ overflow + silent drop — requires all three conditions
simultaneously, which wasn't in the test matrix.
**Consequence:** $180K in lost orders, 2,340 customer support tickets, and a
forced rollback to the monolith under production load — itself causing a 45-minute
outage during the revert.

#### Scenario 2: Organizational — Domain boundary mismatch between teams
**What happened:** The "order" bounded context was split between Team Alpha
(order creation) and Team Bravo (fulfillment). Both teams independently implemented
inventory reservation — Alpha with optimistic locking, Bravo with pessimistic
locking. The conflict wasn't discovered until integration testing in week 14 of
a 16-week timeline, requiring a 6-week redesign of the inventory domain model.
**Why plausible:** Domain-Driven Design workshops defined bounded contexts on
paper, but the actual code ownership didn't align. No cross-team code review
process existed for shared domain objects.
**Consequence:** 6-week schedule slip, team morale damage from rework, and the
inventory service shipped with a compatibility shim that became permanent
technical debt.

### Risk Matrix
| # | Category | Scenario | Likelihood | Impact | Priority |
|---|----------|----------|------------|--------|----------|
| 1 | Technical | Kafka consumer lag cascade | Medium | Catastrophic | P2 |
| 2 | Organizational | Domain boundary mismatch | High | Severe | P2 |

### Deep Analysis — Risk 1: Kafka Consumer Lag Cascade

**Leading Indicators:**
1. **Consumer lag growth rate** — Measure: max consumer lag across all
   partitions for order-processing group. Threshold: >10,000 messages or
   lag growing >500 msg/sec for 5 consecutive minutes. Where: Kafka
   monitoring dashboard (Burrow or equivalent). Lead time: 2-4 hours
   before DLQ overflow at projected rates.
2. **DLQ fill rate** — Measure: dead letter queue size as percentage of
   allocated storage. Threshold: >30% capacity outside of known incident
   windows. Where: Kafka topic metrics + PagerDuty alert. Lead time:
   1-2 hours before overflow.

**Circuit Breaker:**
- **Trigger:** Consumer lag exceeds 1 hour AND DLQ reaches 50% capacity
  during any traffic event exceeding 5x baseline.
- **Fallback:** Activate synchronous HTTP fallback path for order processing
  (already exists in monolith, needs a feature flag to route traffic).
  Accept the latency penalty (800ms vs 200ms) to guarantee zero order loss.
- **Cost of delay:** Each hour of delay at Black Friday volumes risks ~$30K
  in dropped orders. The fallback path adds 600ms latency but loses zero orders.
- **Decision owner:** On-call SRE lead with VP Engineering escalation.

### Pre-Mortem Summary
The highest risk to the order service migration is Kafka consumer lag cascading
into silent order loss under peak load. You'll know it's happening when consumer
lag exceeds 10,000 messages with a growth rate above 500 msg/sec for 5 minutes.
Your escape hatch is the synchronous HTTP fallback path behind a feature flag.
The cost of ignoring this: thousands of lost orders and a forced rollback under
production pressure. The cost of acting too early: 4x higher latency on order
processing during the traffic spike. Monitor Kafka consumer lag starting 2 weeks
before any projected traffic event exceeding 3x baseline.

なぜ良いのか：

• シナリオに具体的な技術（Kafka、DLQ、楽観的／悲観的ロック）が挙げられています
• 数量が具体的です（負荷12倍、注文2,340件、$180K、10GB、45分）
• 先行指標に明確なしきい値があります（メッセージ10,000件超、500 msg/sec超、容量の30％超）
• サーキットブレーカーに測定可能な発動条件、具体的な代替策、数値化されたトレードオフがあります
• プレモーテムの要約は、経営幹部が行動に移せる、単独で内容が完結した説明になっています
• 障害の説明は単なる分類ではなく因果関係を示し、それぞれ障害がどのように発生したかを説明しています

使用する場面

• プロジェクト計画やスケジュールを確定する前
• 取り消しが困難なアーキテクチャ上の決定を下す前
• 新しい技術を本番環境に導入する前
• 主要な機能のリリースや製品の方向転換の前
• 新しい市場や顧客セグメントに参入する前
• チームの確信が非常に強く、誰も懸念を提起していないとき
• 失敗のコストが分析のコストを上回るほど、リスクが高いとき
• 誰かが「最悪の場合、何が起こるのか」と尋ねたとき

使用しない場面

• 既存コードの問題を扱う場合（swing-reviewを使用してください。現在の問題を調べます）
• 技術の選択肢を比較する場合（swing-researchを使用してください。失敗シナリオではなく、事実を集めます）
• 創造的な代替案を生み出す場合（認知モードが異なるswing-optionsを使用してください）
• 通常のコードレビュー
• 決定を簡単に取り消せる場合（リスクが低ければ、分析する必要はありません）
• チームに必要なのが警告ではなく励ましである場合（場の空気を読みましょう）

注意点

1. 「スケールしませんでした」はシナリオではありません。 すべての失敗について、具体的な技術、具体的な数量、具体的な条件を挙げる必要があります。プロジェクト名を入れ替えてもシナリオが同じように読めるなら、一般的すぎます。
2. 先行指標は、新人テストに合格する必要があります。 説明だけを与えられた新しいチームメンバーが、しきい値を超えたかどうかを判断できますか？ 「問題がないか監視する」では不合格です。「Burrow ダッシュボードでコンシューマーのラグが10,000メッセージを超える」なら合格です。
3. 「問題が起きたら」はサーキットブレーカーではありません。 すべてのトリガーは、具体的なしきい値を持つ測定可能な条件である必要があります。すべてのフォールバックには、「別の方法を探す」ではなく、具体的な代替策を挙げる必要があります。
4. 失敗の枠組みを和らげないでください。 前提とするのは完全な失敗であり、「性能不足」や「課題」ではありません。この極端な枠組みによって、創造的なリスクの洗い出しが促されます。
5. プレモーテムの要約は必須です。 これはBLUFです。経営幹部がその段落だけを読んで行動できるようにしてください。欠けている場合、分析は不完全です。

統合に関する注意

• swing-clarify との連携： 曖昧な依頼に対しては、このスキルを呼び出す前に swing-clarify を実行してください。スコープを明確にすると、より良い結果が得られます。
• swing-review との連携： 相互補完的であり、重複するものではありません。まず swing-mortem を実行して将来のリスクを予測し、次に swing-review で現在の実装を確認して既存の欠陥を見つけます。両方を組み合わせることで、時間軸上のリスク、すなわち未来（swing-mortem）と現在（敵対的レビュー）を網羅できます。
• swing-research との連携： swing-mortem のシナリオが不確かな事実（例：「Kafka はこの負荷に対応できるか？」）に依存する場合は、可能性を評価する前に swing-research を呼び出して、事実関係を検証してください。
• swing-options との連携： swing-mortem で優先度の高いリスクが明らかになった後、swing-options を使って、上位の失敗要因を完全に回避する代替アプローチを生成してください。
• オーケストレーターの戦略チームとの連携： プレモーテムの出力は、リスク評価自体に対する追加のストレステストを行うため、戦略チームのデビルズ・アドボケイトエージェントに直接入力されます。