ポストモーテムとは

ポストモーテムは、プロジェクトの完了後や重大なシステム障害の発生後に行われる、事後検証プロセスのことです。これは、発生した事象の経緯、原因、および対応結果を客観的に分析・記録することで、組織としての学習を促し、将来の再発防止や業務改善に役立てるための重要な運用管理手法を指します。

ポストモーテムの概要と意義

ポストモーテム（Post-mortem）は、元来「検死」を意味する用語ですが、ITおよびビジネスの分野では「プロジェクトや障害の振り返り」として定着しています。特に、SRE（サイト信頼性エンジニアリング）の文脈では、サービス停止などのトラブルを糧に、システムの信頼性を向上させるための不可欠な文化とされています。

1. 目的：非難なき文化の醸成

ポストモーテムの最も重要な原則は、個人を非難すること（Blame）ではなく、システムやプロセスの欠陥を特定することにあります。これを「指弾なきポストモーテム（Blameless Post-mortem）」と呼びます。

• 心理的安全性の確保: 失敗を正直に報告できる環境を作ることで、隠蔽を防ぎ、真の原因に辿り着くことができます。
• 組織の成長: 個人の経験をドキュメント化し、組織全体の共有知とすることで、同様のミスを防ぐ防波堤となります。

障害対応におけるポストモーテムの構成要素

標準的なポストモーテム報告書には、以下の項目が含まれます。

1. 概要とタイムライン

事象がいつ発生し、いつ検知され、いつ復旧したのかを時系列で詳細に記述します。

2. 影響範囲

どのサービスの、どの程度のユーザーに、どのような影響（エラー率の増加やレスポンスの遅延など）を及ぼしたかを定量的に記録します。

3. 根本原因の分析（Root Cause Analysis）

「なぜ」を繰り返す手法などを用いて、表面的な事象の裏にある真の原因を掘り下げます。

• 直接的な原因: 例として「特定のプログラムのバグ」など。
• 背景となる要因: 例として「コードレビューのプロセスの不備」や「テスト環境の不足」など。

4. 教訓とアクションアイテム

分析結果に基づき、今後どのような具体的な対策を講じるかを決定します。これには、担当者と完了期限を明確にする必要があります。

プロジェクト管理におけるポストモーテム

障害対応だけでなく、開発プロジェクトの終了時に実施されるポストモーテムも重要です。

評価項目	分析の内容
成功要因	計画通りに進んだ点や、予想以上の成果が出た理由。
課題と反省点	予算や納期の超過、技術的な困難が生じた背景。
効率の指標	実際の工数と見積工数の乖離率など。

プロジェクトの効率を定量的に評価する場合、以下の式のような「工数乖離率」が算出されることがあります。

ポストモーテムを成功させるための鍵

単に報告書を作成するだけでなく、以下の運用が重要となります。

1. 迅速な実施: 記憶が鮮明なうちに（通常は事象発生から数日以内）開催すること。
2. 共有の徹底: 報告書を組織内で公開し、誰でも閲覧・検索可能な状態にすること。
3. アクションの追跡: 決定された改善策が実際に実行されたかを定期的に確認すること。

ポストモーテムは、失敗をネガティブな経験で終わらせず、組織のレジリエンス（回復力）を高めるための前向きな投資であると言えます。

関連用語

お問い合わせ

システム開発・アプリ開発に関するご相談がございましたら、APPSWINGBYまでお気軽にご連絡ください。