ポストモーテムとは？障害振り返りの意味と書き方

ポストモーテム（障害振り返り）とは

ポストモーテムとは、システム障害などのインシデントが収束したあとに、何が起きたのか、なぜ起きたのか、どうすれば防げるのかを整理し、文書として残す取り組みのことです。

平たく言えば「障害の振り返り会と、その記録」です。英語の postmortem は本来「事後の検証」を意味する言葉で、IT運用の分野では、障害を個人の失敗としてではなく、仕組みを改善するための材料として扱う文化とセットで語られます。日本の現場では「障害報告書」「事後レビュー」と呼ばれることもありますが、ポストモーテムという場合は、特に責任追及をしない（ブレームレス）姿勢を重視するのが特徴です。

ポストモーテムに書く項目

ポストモーテムの文書には、おおむね次の項目を含めます。

特に重要なのが「時系列」と「再発防止策」です。時系列は記憶が新しいうちにまとめないと、判断の根拠があいまいになります。再発防止策は、担当者と期限を決めて追いかけなければ、文書を作っただけで終わってしまいます。

原因を掘り下げる

原因の欄は「担当者が設定を間違えた」で止めないことが大切です。なぜ間違えられる状態だったのか、なぜレビューで気づけなかったのか、なぜ検知が遅れたのか、と問いを重ねて、仕組みの側にある原因までたどります。「注意する」「気をつける」は再発防止策になりません。手順の自動化、チェックの追加、権限の見直しなど、人が注意しなくても防げる対策を考えます。

実務での使い方・具体例

進め方の例

1. 障害の収束後、できれば数日以内に振り返りの場を設定する
2. 対応にあたった人が時系列の下書きを作る
3. 関係者で集まり、事実の確認と原因の掘り下げを行う
4. 再発防止策を洗い出し、優先度・担当・期限を決める
5. 文書を共有し、対策の進み具合を定例会などで確認する

架空の例：メール配信の誤送信

あるオンラインスクール（架空）で、特定の受講者だけに送るはずの案内メールが、全会員に送られてしまいました。振り返りの場では、担当者を責めるのではなく、配信対象を選ぶ画面で絞り込み条件が外れていても警告が出ない仕組みであったこと、送信前の確認が一人だけで完結していたことを原因として整理しました。再発防止策として、送信対象の件数を確認画面に大きく表示する改修と、一定件数以上の配信には別の担当者の承認を必須にする運用を決めました。

小さな組織での続け方

専任の運用チームがない会社では、大がかりな文書を毎回作るのは負担です。最初は「何が起きたか・影響・原因・対策」の4項目だけの簡易版から始め、影響の大きい障害のときだけ詳しく書く、と使い分けると続けやすくなります。書いた文書は共有フォルダやナレッジ管理の仕組みに一か所にまとめ、障害の種類で検索できるようにしておくと、似た障害が起きたときの初動が早くなります。新しく入ったメンバーにとっても、過去の障害と対策を知るよい教材になります。

よくある誤解と注意点

• 犯人探しの場にしない：個人が責められる場になると、次から事実が報告されなくなります。仕組みの問題として扱う前提を最初に共有しましょう。
• 書いて終わりにしない：再発防止策の実施状況を追いかけなければ、同じ障害が繰り返されます。
• 大きな障害だけが対象ではない：利用者への影響がなかった「ヒヤリハット」も、振り返る価値があります。
• 外部の開発会社とも共有する：委託先が関わる障害では、発注側と受注側が同じ場で振り返ると、責任の押し付け合いを避けやすくなります。

関連用語

• インシデント管理：障害の発生から収束までを管理する仕組み。ポストモーテムはその後工程
• SRE（サイトリライアビリティエンジニアリング）：ブレームレスなポストモーテムを重視する運用の考え方
• KPT：良かったこと・問題・次に試すことで振り返るフレームワーク
• 監視（システムモニタリング）：振り返りで見つかった検知の遅れを改善する対象
• ランブック：振り返りをもとに整備する復旧手順書

障害時の体制づくりはシステム障害時の対応フローもあわせてご覧ください。

Otsumuに相談できること

ポストモーテムは、障害を次の改善につなげるための仕組みです。Otsumuでは、振り返りの進め方やテンプレートづくり、見つかった課題の改修、監視や手順書の整備までを支援しています。運用中のシステムの改善は保守・運用のページをご覧ください。

同じような障害が繰り返されている場合は、30分の無料相談で状況をお聞かせください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01