postmortem

ポストモーテム

使用しない場合： インシデントがまだ進行中の場合（まず解決に注力してください）、責任を押し付けようとしている場合（責任追及をしない文化に反します）、または学びの価値がない些細な問題の場合です。

ワークフロー

このチェックリストをコピーして、進捗を管理してください。

Postmortem Progress:
- [ ] Step 1: Assemble timeline and quantify impact
- [ ] Step 2: Conduct root cause analysis
- [ ] Step 3: Define corrective and preventive actions
- [ ] Step 4: Document and share postmortem
- [ ] Step 5: Track action items to completion

ステップ 1：タイムラインをまとめ、影響を定量化する

事実を集めます。検知時刻、発生時刻、主な出来事、解決時刻を確認します。影響を定量化します。影響を受けたユーザー数、継続時間、収益／SLA への影響、顧客からの苦情を確認します。単純なインシデントには、resources/template.md を使用してください。複数の原因や連鎖的な障害を伴う複雑なインシデントでは、高度なタイムライン再構成の手法について resources/methodology.md を確認してください。

ステップ 2：根本原因分析を実施する

「なぜ？」を 5 回問い、症状から根本原因にたどり着くか、複数の要因が関与する複雑なインシデントでは特性要因図を使用します。ガイダンスについては、根本原因分析の手法を参照してください。人的ミスではなく、システムの障害（プロセスの不備、安全策の欠如）に焦点を当てます。

ステップ 3：是正措置と予防措置を定義する

各根本原因について、再発を防ぐための措置を特定します。具体的であり（「テストを改善する」ではなく）、担当者が明確であり、期限が設定されている必要があります。すぐに実施する修正と長期的な改善に分類します。フレームワークについては、是正措置を参照してください。

ステップ 4：ポストモーテムを文書化して共有する

テンプレートを使用してポストモーテム文書を作成します。タイムライン、影響、根本原因、措置、うまくいった点を含めます。学びにつなげるため、広く（エンジニアリング、プロダクト、リーダーシップに）共有します。チームミーティングで発表し、議論します。ナレッジベースに保管します。

ステップ 5：アクション項目を完了まで追跡する

担当者を割り当て、期限を設定し、プロジェクトトラッカーに追加します。スタンドアップまたは週次ミーティングで進捗を確認します。すべてのアクションが完了するまで、ポストモーテムを終了しないでください。resources/evaluators/rubric_postmortem.json を使用して品質を自己評価します。最低基準：平均スコア ≥3.5。

よくあるパターン

インシデントの種類別

本番環境の停止（システム障害、ダウンタイム）：

• タイムライン：検知 → 調査 → 緩和 → 解決
• 影響：影響を受けたユーザー数、継続時間、SLA 違反、収益損失
• 根本原因：設定ミス、デプロイの問題、インフラストラクチャの限界がよく見られます
• 措置：モニタリング、ランブック、ロールバック手順、キャパシティプランニングを改善する

セキュリティインシデント（侵害、脆弱性）：

• タイムライン：侵害の発生 → 検知（遅れることがよくあります）→ 封じ込め → 修復
• 影響：漏えいしたデータ、コンプライアンス上のリスク、評判への損害
• 根本原因：セキュリティ管理策の欠如、アクセス管理の不備、未修正の脆弱性
• 措置：セキュリティ監査、アクセスレビュー、パッチ管理、トレーニング

プロダクト／プロジェクトの失敗（ローンチ、期限）：

• タイムライン：計画 → 実行 → ローンチ／期限 → 期待に対する結果
• 影響：収益目標の未達、ユーザー離れ、労力の浪費、機会損失
• 根本原因：要件の不備、非現実的な見積もり、認識のずれ、不十分なテスト
• 措置：課題の発見、見積もり、ステークホルダーとの認識合わせ、検証プロセスを改善する

プロセスの失敗（運用、手順）：

• タイムライン：プロセスの開始 → 破綻点 → 影響の顕在化
• 影響：遅延、品質上の問題、手戻り、チームの不満
• 根本原因：不明確なプロセス、手順の欠落、引き継ぎの失敗、ツールの不備
• 措置：プロセスを文書化し、ワークフローを自動化し、コミュニケーションとトレーニングを改善する

根本原因のカテゴリー別

人的ミス（表面的な原因です。さらに深く掘り下げます）：

• 「人が間違えた」で終わらせないでください
• 次の点を確認します：なぜミスが起こり得たのか？なぜ検出されなかったのか？なぜ防止策がなかったのか？
• 対策：ミスの発生可能性を下げる（チェックリスト、自動化）、ミスの検出率を高める（テスト、レビュー）、ミスの影響を軽減する（ロールバック、冗長化）

プロセスの不備（手順がない、または不明確）：

• 兆候：「Xをすべきだと知らなかった」「手順書にない」「初めてだった」
• 対策：プロセスを文書化する、チェックリストを作成する、承認ゲートを正式化する、オンボーディングを整備する

技術的負債（保守を先送りしている状態）：

• 兆候：「既知の問題」「脆弱なシステム」「回避策が機能しなかった」
• 対策：技術的負債の優先順位を上げる、対応能力の20%を割り当てる、リファクタリングする、レガシーシステムを置き換える

外部依存関係（サードパーティの障害）：

• 兆候：「ベンダーがダウン」「API が失敗」「パートナーの問題」
• 対策：冗長化を追加する、サーキットブレーカーを導入する、グレースフルデグラデーションを実装する、SLA を監視する、ベンダーを分散する

組織的な問題（組織や文化に起因）：

• 兆候：「常に急いでいる」「テストする時間がない」「出荷へのプレッシャーがある」
• 対策：組織の根本的な問題（非現実的な期限、リソースの制約、インセンティブの不整合）に対処する

根本原因分析の手法

5 Whys：

1. 問題を明確にします
2. 「なぜこれが起きたのか？」と問い、答えます
3. 「なぜそれが起きたのか？」と問い、答えます
4. 5回繰り返します（または根本原因が見つかるまで続けます）
5. 根本原因：組織またはシステムのレベルで修正できるもの

例：データベースの停止 → なぜ？設定ミス → なぜ？値が誤っていた → なぜ？テンプレートのエラー → なぜ？新しいチームメンバーが使い方に不慣れだった → なぜ？オンボーディングに設定レビューがなかった

フィッシュボーン図（石川ダイアグラム）：

• カテゴリー：人、プロセス、テクノロジー、環境
• 各カテゴリーで原因をブレインストーミングします
• 調査すべき可能性の高い根本原因を特定します
• 複数の要因が関与する複雑なインシデントに役立ちます

故障の木解析：

• 最上位：障害イベント（例：「システム停止」）
• ゲート：AND（すべての条件が必要）と OR（いずれかの条件で十分）
• 末端：基本原因（例：「設定エラー」OR「ネットワーク障害」）
• 障害から根本原因までの経路をたどります

是正措置の枠組み

措置の種類：

• 即時修正：数日以内に適用（ホットフィックス、手動プロセス、回避策）
• 短期的な改善：数週間以内に完了（監視の改善、手順書の更新、プロセスの変更）
• 長期的な投資：数か月以内に完了（アーキテクチャの変更、新システム、文化の変革）

SMART な措置：

• 具体的：「デプロイを改善する」ではなく「設定の検証を追加する」
• 測定可能：「対応を迅速化する」ではなく「MTTR を2時間から30分に短縮する」
• 割り当て可能：「チーム」ではなく、担当者を明記する
• 現実的：対応能力と制約を踏まえる
• 期限付き：明確な期限を設定する

優先順位付け：

1. 影響が大きく、労力が少ない：すぐに実行します
2. 影響が大きく、労力が大きい：戦略的プロジェクトとして計画します
3. 影響が小さく、労力が少ない：対応能力に余裕があれば実行します
4. 影響が小さく、労力が大きい：見送ることを検討します（コストがメリットを上回る）

予防策の階層（効果の高いものから低いものの順）：

1. 排除：危険要因を完全になくします（例：リスクの高い機能を廃止する）
2. 代替：より安全な選択肢に置き換えます（例：セルフホストではなくマネージドサービスを利用する）
3. 工学的対策：保護策を追加します（例：レート制限、サーキットブレーカー、自動テスト）
4. 管理的対策：プロセスを改善します（例：手順書、チェックリスト、レビュー）
5. トレーニング：人に知識を伝えます（単独では最も効果が低いため、ほかの対策と組み合わせます）

ガードレール

非難しない文化：

• ❌ 「エンジニアが不適切な設定をデプロイして障害を引き起こした」→ ✓ 「デプロイパイプラインによって不適切な設定が本番環境に到達した」
• ❌ 「PM が要件を検証しなかった」→ ✓ 「要件検証プロセスが欠けていた」
• ❌ 「デザイナーが間違えた」→ ✓ 「デザインレビューのプロセスで問題を検出できなかった」
• 焦点：どのシステム／プロセスに不備があったのか。誰が間違えたのかではありません。

根本原因の深掘り：

• ❌ 表面的な原因で止める：「バグが障害を引き起こした」→ ✓ 深く分析する：「テストの不足、ステージング環境の不在、リリースを急ぐプレッシャーによりバグがデプロイされた」
• ❌ 単一の原因：「データベースの障害」→ ✓ 複数の原因：「データベース＋フェイルオーバーなし＋アラートの遅延＋ランブックの不明確さ」
• ルール：実行可能なシステム改善にたどり着くまで、「なぜ？」を問い続けます。

実行可能性：

• ❌ 曖昧：「テストを改善する」「コミュニケーションを改善する」「もっと注意する」→ ✓ 具体的：「4 月 1 日までに、主要なユーザーフロー上位 10 件をカバーする E2E テストスイートを追加する（担当者：Alex）」
• ❌ 担当者なし：「チームが文書化する」→ ✓ 担当者あり：「Sam が 3 月 15 日までにインシデント対応ランブックを作成する」
• ❌ 期限なし：「いずれ移行する」→ ✓ 期限を設定：「第 2 四半期末までに移行を完了する」

影響の定量化：

• ❌ 定性的：「多くのユーザーに影響」「大幅なダウンタイム」→ ✓ 定量的：「ユーザー 5 万人（ユーザー基盤の 20％）、2 時間の障害、売上損失 2 万ドル」
• ❌ 指標なし：「顧客体験が悪かった」→ ✓ 指標あり：「NPS が 50 から 30 に低下、サポートチケット 100 件、顧客 5 社が解約（ARR 5 万ドル）」

適時性：

• ❌ 2 週間待つ → 記憶が薄れ、緊急性が失われる → ✓ 記憶が新しいうちに 48 時間以内に実施する
• ❌ 一切フォローアップしない → 対応事項が忘れられる → ✓ 対応事項を追跡し、毎週確認し、完了したらクローズする

クイックリファレンス

リソース：

• resources/template.md - ポストモーテム文書の構成とセクション
• resources/methodology.md - 非難しない文化、根本原因分析の手法、是正措置のフレームワーク
• resources/evaluators/rubric_postmortem.json - ポストモーテムの品質基準

成功基準：

• ✓ タイムスタンプと主要イベントを含む明確なタイムライン
• ✓ 影響を定量化（ユーザー数、期間、売上、指標）
• ✓ 根本原因を特定（個人を非難せず、システムに着目）
• ✓ 是正措置が SMART（具体的、測定可能、担当者が割り当てられ、現実的、期限付き）
• ✓ 非難しない姿勢（システム／プロセスに着目）
• ✓ 48 時間以内に文書化して共有
• ✓ 対応項目を完了まで追跡

よくある誤り：

• ❌ 個人を非難する → 恐怖の文化が生まれ、今後の問題が隠される
• ❌ 表面的な根本原因で終わる → 再発を防げない
• ❌ 曖昧な対応策 → 実際には何も改善されない
• ❌ フォローアップしない → 対応策が完了せず、同じインシデントが繰り返される
• ❌ ポストモーテムが遅れる → 詳細を忘れ、役立ち度が下がる
• ❌ 共有しない → 組織として学べない
• ❌ 防御的な姿勢 → 改善の機会を逃す