postmortem

事後分析

目次

1. 目的
2. 利用するタイミング
3. 概要
4. ワークフロー
5. よくあるパターン
6. ガードレール
7. クイックリファレンス

目的

何が起きたのか、なぜ起きたのか、影響の定量化、根本原因の分析、責任者が明確な実行可能な再発防止策を記録し、失敗を学びの機会へと変える、非難のない事後分析を実施します。

利用するタイミング

このスキルを使う場面：

インシデントの状況

• 本番環境での障害、システム障害、またはサービスの品質低下が発生した
• セキュリティ侵害、データ損失、またはコンプライアンス違反が発生した
• 製品のローンチに失敗した、プロジェクトが期限に間に合わなかった、または取り組みが期待を下回った
• 顧客に影響するバグ、品質問題、またはサポート上の危機が発生した
• 深刻な被害につながる可能性のあったニアミスが発生した（予防的な事後分析）

学習目標

• 再発を防ぐため、根本原因（症状だけではなく）を理解する必要がある
• 個人のミスではなく、組織的な問題を特定したい
• 関係者や監査担当者向けに、タイムラインと影響を記録する必要がある
• 失敗から得た知見をもとに、プロセス、システム、または慣行を改善したい
• 組織的な学習文化を築いている（非難ではなく、透明性を重視する）

タイミング

• インシデントの解決直後（記憶が新しいうちに、48 時間以内）
• 再発する問題や慢性的な問題について、定期的なレビューを行う
• パターンを特定するため、すべてのインシデントを四半期ごとにレビューする
• プレモーテム形式：大規模なローンチの前に、失敗したと仮定して事後分析を書く

次の場合は使用しないでください：

• インシデントがまだ継続中（まず解決に集中し、その後に事後分析を行います）
• 個人の責任を追及したり、罰したりすることが目的（非難のない文化に反します）
• 学びにつながらない軽微な問題（重大なインシデントに限って実施します）

概要

事後分析とは、失敗について構造的かつ非難のない形で分析し、次の問いに答えることです：

• 何が起きたのか？ 検知から解決までのイベントのタイムライン
• どのような影響があったのか？ 被害の定量化（影響を受けたユーザー数、失われた収益、継続時間）
• なぜ起きたのか？ 5 Whys、フィッシュボーン図、またはフォールトツリーを使った根本原因分析
• 再発をどう防ぐか？ 担当者と期限を明記した、実行可能な項目
• うまくいったことは何か？ インシデント対応で良かった点

主な原則：

• 非難しない：個人ではなく、システムやプロセスに注目します。人は間違えますが、システムは回復力を備えているべきです。
• 実行可能である：是正措置は具体的で、担当者が決まり、進捗が追跡できる必要があります。
• 透明性を保つ：組織的な学習を促すため、広く共有します。
• 迅速に行う：記憶が新しいうちに実施します（解決から48時間以内）。

簡単な例：

インシデント：データベース障害、2時間の停止、5万人のユーザーに影響

タイムライン：

• 14:05 - 自動デプロイを開始（設定変更）
• 14:07 - データベースの接続プールが枯渇し、エラーが急増
• 14:10 - アラートが発報し、オンコール担当者に通知
• 14:15 - エンジニアが調査し、不適切な設定を特定
• 15:30 - ロールバックを開始（手順書が不明確で遅延）
• 16:05 - サービスが復旧

影響：2時間の停止、5万人のユーザーがアクセスできず、収益損失は推定2万ドル

根本原因（5 Whys）：

1. なぜ障害が発生したのか？ 不適切な設定がデプロイされた
2. なぜ不適切な設定だったのか？ 接続プールのサイズが10に設定されていた（本来は100）
3. なぜ値が間違っていたのか？ 設定テンプレートに誤りがあった
4. なぜテンプレートに誤りがあったのか？ 新しいチームメンバーが本番環境の値に不慣れだった
5. なぜ検知できなかったのか？ 設定をステージング環境でテストしていなかった

是正措置：

• デプロイパイプラインに設定検証を追加する（担当者：Alex、期限：3月15日）
• 本番環境に近い負荷を再現するステージング環境を作成する（担当者：Jordan、期限：3月30日）
• ロールバック手順を手順書に追加する（担当者：Sam、期限：3月10日）
• オンボーディングのチェックリストに本番環境の設定確認を追加する（担当者：Morgan、期限：3月5日）

うまくいったこと：アラートがすぐに発報し、チームは5分以内に対応し、円滑なコミュニケーションが行われた

ワークフロー

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

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 時間以内に文書化して共有
• ✓ 対応項目を完了まで追跡

よくある誤り：

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