障害報告書、ポストモーテムの効果的な書き方

※本記事はプロモーションを含みます。

本記事のポイント：ポストモーテムは障害の根本原因を特定し、再発防止につなげるための重要な文書です。効果的な書き方を理解することで、チーム全体の信頼性向上と業務効率化が実現します。読了時間の目安：約8分

ポストモーテムとは何か

ポストモーテム（postmortem）は、英語で「事後検査」や「死後解剖」を意味する言葉です。ITの現場では、本番環境で発生した障害やインシデント後に実施する振り返り文書を指しており、障害が起きた原因を分析し、将来の再発防止策を決定するための重要なプロセスとされています。

ネットワークサービスの運用やシステム運用では、障害の発生は避けられません。重要なのは、その障害からチーム全体が学び、同じ失敗を繰り返さないための仕組みをつくることです。ポストモーテムは単なる「報告書」ではなく、組織の信頼性を高めるための学習文書とされています。

なぜポストモーテムが必要か

多くの企業では、障害が発生すると「誰が悪いのか」を追求しがちです。しかし、責任追及では問題の再発は防げません。重要なのは「何が起きたのか」「なぜ起きたのか」「どうすれば防げるのか」という3つの質問に答えることとされています。

ポストモーテムの目的を明確にしておくと、より効果的な分析が可能になります：

根本原因の特定 — 表面的な原因ではなく、なぜそのような状況が生まれたかを明らかにする
再発防止策の策定 — 同じ障害が繰り返されないための仕組みや変更を計画する
組織学習の促進 — チーム全体で経験や知見を共有し、スキル向上につなげる
顧客信頼の回復 — 迅速かつ透明な対応を示すことで、ステークホルダーの信頼を維持する

効果的な書き方の5つのポイント

ポイント1: 事実に基づく中立的な表現

ポストモーテムで最も大切なのは「誰が犯人か」という視点を排除し、事実だけを記述するという原則です。個人の責任よりも、システムやプロセスの改善に焦点を当てましょう。

良い例：「デプロイスクリプトが本番環境のIPアドレスをステージング環境のものに上書きした。スクリプトレビュー体制がなかったため、エラーが検出されず実行されてしまった」

避けるべき例：「〇〇エンジニアの不注意でスクリプトを間違えた。本当に困った」

事実に基づく表現を心がけることで、後々のメンバーも心理的安全性を感じながら振り返りに参加できるようになるとされています。

ポイント2: タイムラインの正確な記録

障害が発生してから復旧するまでの時系列を、正確な時刻付きで記録することは非常に重要とされています。特に以下の時点は必ず記録しましょう：

時点	記録内容
障害発生時刻	最初に異常が検知された時刻
検知時刻	監視アラートやユーザー報告で気づいた時刻
対応開始時刻	エスカレーション・調査が始まった時刻
原因特定時刻	根本原因が判明した時刻
復旧完了時刻	サービスが正常に戻った時刻

正確なタイムラインがあると、後続の分析時間（MTTR: 平均修復時間）の改善にもつながるとされています。

ポイント3: 「5つのなぜ」で根本原因を掘り下げる

表面的な原因だけでは再発防止策が不十分です。「なぜ？」を繰り返して、真の根本原因に到達する必要があります。これは「5つのなぜ分析」と呼ばれる手法とされています。

例：ネットワーク設定ミスの場合
1. なぜ通信が遮断されたのか？→ ファイアウォール設定が間違っていた
2. なぜ設定ミスが発生したのか？→ 新サーバーの設定時に旧サーバーのテンプレートをコピーしただけだった
3. なぜテンプレートの確認をしなかったのか？→ 設定チェック手順が文書化されていなかった
4. なぜ手順が文書化されていないのか？→ 過去は属人的な知識に頼っていた
5. なぜ属人的運用が続いていたのか？→ 急速な事業拡大で体制整備が追いつかなかった

このように掘り下げることで、単なる「設定を確認する」ではなく、「環境構築マニュアルを整備し、複数人でレビューする体制をつくる」というプロセス改善につながるとされています。

ポイント4: 具体的で実行可能な改善策

ポストモーテムで最も重要な部分は「改善策（Action Items）」です。以下のように具体的に記述しましょう：

改善策の内容 — 「チェック体制を強化する」ではなく「デプロイ前のスクリプトレビューを2名体制で実施」
責任者の明記 — 誰が実行するのかを明確にする（例：「インフラチームリーダー〇〇」）
実施期限の設定 — 「できるだけ早く」ではなく「3営業日以内」など具体的な期限
優先度の分類 — 緊急対応 / 中期対応 / 検討課題として分けておく

曖昧な改善策は、時間経過とともに実施されなくなってしまうという可能性があります。具体性と実行可能性が重要とされています。

ポイント5: 図解・ログの活用

複雑な障害では、テキストだけでは理解しづらいことが多いとされています。以下のような図解を活用しましょう：

通信フロー図 — 障害時の通信がどう流れたか（遮断された箇所の可視化）
タイムライングラフ — CPUやメモリの使用率、通信量の時系列推移
システム構成図 — 関連するサーバーやネットワーク機器の関係図
エラーログの抜粋 — 重要なログを時系列で並べる

社内のみの文書でも、図解があると後日読み返すときに理解が早いとされています。

テンプレートの活用方法

毎回ポストモーテムを一から作成するのは時間がかかります。組織全体で使えるテンプレートを準備しておくと、より迅速で質の高い分析が可能になるとされています。

基本的なテンプレート構成

■ 障害概要
– 障害ID: (例: INC-2026-0502)
– 影響範囲: (例: 本番環境・全ユーザー)
– 影響度（重大度）: (例: Critical / High / Medium / Low)
– 検知から復旧までの時間: (例: 15分)

■ 障害説明
– 概要: (1〜2段落で障害の概要を説明)
– タイムライン: (発生〜復旧までの時系列)
– ユーザーへの影響: (利用できなかった機能など)

■ 根本原因分析
– 直接的原因: (すぐに起きた原因)
– 根本原因: (5つのなぜで到達した原因)
– 図解・ログ: (証拠となるデータ)

■ 改善策
– 短期対応: (今すぐできる対策)
– 中期対応: (1週間〜1ヶ月で実施する対策)
– 長期対応: (プロセスや仕組みの改善)
– 優先度と責任者: (各項目ごとに明記)

■ レビュー欄
– 作成者・作成日: (いつ誰が作成したか)
– レビュー者・レビュー日: (複数人での確認記録)

テンプレート活用のコツ

テンプレートは「枠を守る」のではなく、「最小限の品質を保証する」ツールと考えましょう。以下のようなポイントが大切とされています：

複雑な障害には詳細セクションを追加 — データベース障害なら「ロック状況」「クエリログ」を追加
シンプルな障害は簡略化 — ネットワークケーブル断裂など物理的なものは根本原因が明確なため短くしてよい
過去事例の参照 — 類似の過去ポストモーテムを参考にすると、重要な視点を見落としにくくなる
定期的なテンプレート更新 — 組織の成長やシステムの変化に応じて、テンプレート自体も改善する

よくある失敗例と改善策

失敗例1: 犯人探しに終始してしまう

症状：「〇〇さんが設定を間違えた」「エンジニアのミス」という表現で終わってしまい、改善策がない。

改善策：ポストモーテム開始時に「今日の目的は問題を解決すること。責任追及ではありません」と明言し、プロセス改善に焦点を当てましょう。個人の過失ではなく「なぜそのような状況が生まれたのか」にアプローチすることが大切とされています。

失敗例2: 改善策が実行されない

症状：「マニュアルを整備する」「体制を強化する」と書かれるが、誰がいつまでに何をするのか不明確で、実行されないまま終わる。

改善策：改善策を「宿題リスト」として管理し、定期的（例：1週間後）に進捗をフォローアップしましょう。責任者・期限・成果物を具体的に定義することが重要とされています。できれば改善策の進捗を全員で共有する仕組みをつくるとよいでしょう。

失敗例3: 原因の掘り下げが浅い

症状：「メモリリークが発生した」で終わり、「なぜリークが検知されなかったのか」「運用監視体制は十分か」といった視点がない。

改善策：「5つのなぜ」を意識的に実施しましょう。技術的な原因だけでなく、組織・プロセス・人材育成の観点から掘り下げることで、より根本的な対策が見つかるとされています。

失敗例4: 関係者の見落とし

症状：インフラチームだけでポストモーテムを作成し、アプリケーション側からの視点や営業からのフィードバックが反映されていない。

改善策：障害の規模に応じて、複数チームでポストモーテムを実施しましょう。特に顧客影響がある場合は、営業やカスタマーサポートの意見も含めることで、より実務的な改善策が生まれるとされています。

チーム全体で活かすコツ

ポストモーテム後の行動

ポストモーテムを作成した後が最も重要とされています。以下のような施策で、組織全体が学習できる仕組みをつくりましょう：

全員への共有会議 — ポストモーテムの内容を全チームで共有し、他チームのエンジニアからも質問を受ける
wiki・ナレッジベースへの記録 — ポストモーテムを検索可能な形で保存しておくと、後の類似障害対応が速くなる
トレーニング資料への反映 — 新入社員教育やオンボーディング時にポストモーテム事例を紹介する
改善策の進捗可視化 — 対応状況を定期的に報告し、「組織が本気で改善している」というメッセージを発信する

心理的安全性の確保

ポストモーテムが真の学習ツールになるには、チーム内の「心理的安全性」が不可欠とされています。以下の点に注意しましょう：

マネージャーは責任追及の姿勢を見せない
失敗を「学習の機会」と捉える文化を育てる
他チームのポストモーテムに建設的なコメントを寄せる
改善策が実行されたときに成果を認める

メンバーが「正直に問題を報告しても責められない」と感じられる環境があって初めて、ポストモーテムの本来の価値が発揮されるとされています。

まとめ

ポストモーテムは、組織の信頼性と学習能力を高めるための重要なツールです。効果的に活用するには、以下のポイントが大切とされています：

1. 事実に基づく中立的な記述で、責任追及ではなく改善に焦点を当てることが基本です。2. 正確なタイムラインと図解により、複雑な障害も他者が理解しやすくなります。3. 「5つのなぜ」で根本原因を掘り下げることで、表面的な対症療法ではなく本質的な改善策が見つかるとされています。4. 具体的で実行可能な改善策を、責任者と期限を明記して定義することで、実際の改善につながります。

テンプレートを活用しつつ、個別の障害に合わせて柔軟に調整することが大切とされています。そして何より、チーム全体で学習できる環境づくり、つまり心理的安全性の確保が、ポストモーテムの価値を最大限に引き出すための鍵となるでしょう。

障害は必ず起きます。しかしそこから何を学び、どう改善するかで、組織の成熟度が大きく変わります。効果的なポストモーテムの習慣が定着することで、段階的に運用の質が向上していくとされています。

免責事項

本記事の情報は執筆時点のものです。ポストモーテムのベストプラクティスは組織の文化やシステム規模により異なります。記事に掲載されたテンプレートや手法は参考例であり、実装時は貴社の状況に合わせてカスタマイズしてください。その他、セキュリティ設定や具体的な運用変更については、必ず公式ドキュメントおよび関連部門の責任者とご確認ください。

【編集・制作ポリシー】
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら