非難のないポストモーテム

定義

インシデント発生後に行う振り返りのプロセス。「誰が間違いを犯したか」を追及するのではなく、「どのようなシステム・プロセス・状況が組み合わさって障害が起きたか」を分析する。

前提思想：エンジニアは自分のベストを尽くして行動している。問題はその人の能力ではなく、システムや環境の設計にある。

なぜ重要か

個人を責めると：

• エンジニアがリスクを避けすぎて開発が止まる
• インシデントを隠す文化が生まれる
• 同じ問題が再発する（根本原因が解決されていないため）

非難のないポストモーテムにより：

• 心理的安全性が高まり、詳細な経緯が共有される
• 本当の根本原因にたどり着ける
• 組織全体の知識として蓄積できる

適用場面

• SEV1/SEV2レベルのインシデント収束後（48〜72時間以内）
• 同じ問題が繰り返し起きているとき
• チームがインシデントを「恥ずかしいこと」として扱っているとき

ポストモーテムの構成要素

1. タイムライン — 何が起き、誰がいつ何をしたかの時系列
2. 根本原因分析 — なぜ起きたか（5 whys など）
3. 影響範囲 — ユーザー数、エラー件数、ダウンタイム
4. アクションアイテム — 所有者・期日・優先度が明確なタスク
5. 検知・対応の遅れ — 何があれば早く気付けたか

良いアクションアイテムの条件

• Owner がいる（「チームで検討」はアクションにならない）
• 測定可能（「改善する」ではなく「X件のアラートをYに削減する」）
• 追跡できる（チケット管理システムに登録）
• 優先度がある（全部P0にしない）

書くべきでない表現

関連概念

• インシデント管理 — ポストモーテムはその最終フェーズ
• インシデントコマンドシステム — 対応フェーズのフレームワーク

出典

Google SRE Workbook（Betsy Beyer他）第10章「Postmortem Culture: Learning from Failure」