ポストモーテムとは｜非難しない振り返りの進め方とテンプレート

障害が収まったあと「振り返りをしよう」と決めても、犯人探しの空気になったり、対策を書いたまま誰もやらなかったりして、同じ障害がまた起きることがあります。この記事では障害の振り返りの方法として広く使われているポストモーテムについて、非難しない進め方、書く項目、会議の回し方を説明します。専任の SRE がいない 2〜5 人のチームでも始められるよう、テンプレートと記入例も載せています。

ポストモーテムとは

ポストモーテム (postmortem) は、障害のあとに、何が起きたか、どんな影響があったか、どう対処したか、なぜ起きたか、今後どう防ぐかを文書にまとめ、チームで学ぶための振り返りです。英語の post-mortem はもともと「死後の検死」を意味する言葉で、IT の分野では「障害の事後分析」の意味で使われます。

この言葉が広まったきっかけの 1 つは、Google が公開している『Site Reliability Engineering』(SRE 本) です。同書はポストモーテムを、障害とその影響、緩和や解決のための対応、根本原因、再発を防ぐためのフォローアップを記録した文書と説明しています。目的は障害を記録し、原因を理解し、効果のある再発防止策を実行することです。

ポストモーテムの特徴は次の 2 つです。

• 個人を責めず、仕組みと手順の問題を探す (非難しない、ブレームレス)
• 文書を書いて終わりにせず、対策 (アクション) を最後まで実行する

障害報告書との違い

日本の会社では「障害報告書」という言葉の方がなじみがあるかもしれません。2 つは重なる部分が多いものの、目的と読み手が違います。

小さな会社では、ポストモーテムを書いてから、そこをもとに顧客向けの障害報告書を作ると無理がありません。社内のポストモーテムには判断の迷いや「運がよかったこと」まで正直に書き、顧客向けにはそのうち確定した事実と対策を選んで書きます。顧客向けの報告書の書き方は 障害報告書の書き方とテンプレート で説明しています。

どんなときにポストモーテムを書くか

すべての障害でポストモーテムを書くと、書くこと自体が負担になって続きません。書く基準を先に決めておきます。SRE 本はよくある基準として次のようなものを挙げています。

• ユーザーから見える停止や劣化が、決めた水準を超えた
• データが失われた (程度を問わない)
• 当番の人が手で対応した (リリースの切り戻し、通信の切り替えなど)
• 解決までの時間が決めた水準を超えた
• 監視が働かなかった (人が手で障害を見つけた)

PagerDuty が公開している障害対応のドキュメントでは、重大度が SEV1 と SEV2 の障害でポストモーテムを必須にしています。

小さなチームなら、次のくらいから始めると続けやすくなります。

• 顧客に告知した障害は必ず書く
• データが失われた、または誤ったデータが顧客に見えた障害は、必ず書く
• 監視ではなく顧客や社内の人の連絡で気づいた障害は、短くてもよいので書く
• それ以外は誰かが「書きたい」と言ったら書く

最後の基準は大事です。顧客への影響がなかった「ヒヤリハット」にも、次の大きな障害の手がかりが含まれていることがあります。

非難しない (ブレームレス) とはどういうことか

SRE 本は非難しないポストモーテムの条件を、個人やチームを責めずに、障害の原因になった要因を明らかにすることだとしています。同書には「人は直せないが、システムと手順は直せる」という趣旨の一文もあります。

非難しないのは、優しくするためではありません。責められると分かっている場では、人は自分に不利な事実を話さなくなります。「実は手順書を読まずに作業した」「アラートが来ていたが、いつもの誤報だと思って見なかった」という話が出てこないと、本当の原因にたどり着けません。

「人為ミス」は結論ではなく出発点

ポストモーテムで「原因: 担当者の操作ミス」と書いたら、そこで止まらずに次を問います。

• その操作はなぜ間違えやすかったのか (画面、コマンド、手順書の書き方)
• 間違えたとき、なぜ止まらなかったのか (確認の手順、権限、ステージング環境)
• なぜすぐに気づけなかったのか (監視、アラート)
• 同じ状況で、別の人なら間違えなかったと言えるか

最後の問いに「たぶん自分もやっていた」と答えられるなら、直すべきは人ではなく状況です。

問いかけの言い換え

会議や文書で使う言葉を少し変えるだけで、場の空気が変わります。

右の問いに共通するのは、「その時点で、その人に何が見えていたか」を聞いていることです。あとから見れば答えは明らかでも、障害の最中には情報が足りず、時間に追われています。あとから分かった事実で当時の判断を裁かないようにします。

なぜなぜ分析の落とし穴

原因を掘り下げる方法として「なぜ」を 5 回繰り返すなぜなぜ分析がよく使われます。便利な方法ですが、次の 2 点に注意します。

1 つは、一本の鎖だけをたどると、ほかの要因を見落とすことです。障害は「バグがあった」「テストが通った」「監視がなかった」「夜間で気づくのが遅れた」のように、いくつもの条件が重なって大きくなります。なぜなぜを 1 本だけ書くより、被害を大きくした条件を並べて、それぞれに手を打てるかを考える方が、対策の選択肢が増えます。

もう 1 つは、「なぜ」を繰り返すと最後に人の注意力や意識に行き着きやすいことです。「担当者の意識が低かった」で終わったら、1 つ前の「なぜ」に戻り、仕組みで防げる答えを探します。

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

SRE 本に載っているポストモーテムの例は、概要、影響、根本原因、きっかけ、解決、検知、アクション、学び、時系列といった項目で構成されています。小さなチームで使いやすいように整理すると、次のようになります。

「運がよかったこと」は、SRE 本の例にも入っている項目です。「詳しい人がたまたま起きていた」「障害が月末の締めの前日でなかった」のように、運で被害が小さく済んだ点は、次に運が悪かったときにそのまま穴になります。

小さなチームでの進め方

PagerDuty のドキュメントでは、SEV1 なら 3 日以内、SEV2 なら 5 営業日以内に振り返りの会議を設定するとしています。記憶が新しいうちに行うのが大切なので、小さなチームでも次のような日程で回します。

役割

担当者 (書く人) は、障害の対応に深く関わった人が向いています。ただし、ミスをした本人に書かせることが罰のように見えないよう、交代で担当すると決めておきます。

進行役は、会議で「責める問い」が出たら言い換える役です。障害の対応に関わっていない人が向いています。2〜3 人のチームでは担当者と兼ねても構いません。

会議の議題

会議は、下書きを全員が読んできた前提で、次の順に進めます。PagerDuty のドキュメントにある議題 (時系列の確認、重要な点、どうすれば早く見つけられたか、顧客への影響、アクションの確認) をもとにしています。

1. 進行役が「誰かを責める場ではなく、仕組みを直す場です」と最初に言う (1 分)
2. 担当者が時系列を説明し、抜けや誤りを全員で直す (10 分)
3. 被害を大きくした条件を出し合う (15 分)
4. どうすればもっと早く気づけたか、早く戻せたかを話す (10 分)
5. アクションを決める。担当と期限を、その場で決める (10 分)
6. 学び (うまくいったこと、運がよかったこと) を確かめる (5 分)

最初の宣言は形だけに見えますが、毎回言うことで、参加者が不利な事実を話しやすくなります。

アクションを最後まで実行する

ポストモーテムが形だけになる一番の理由は、アクションが実行されないことです。次の 3 点で防ぎます。

• アクションは文書の中だけでなく、ふだんの課題管理ツール (Jira、GitHub Issues、Backlog など) に登録する
• 期限と担当のないアクションは書かない。数を絞り、実行できるものだけを残す
• 次のポストモーテムの会議や週の定例の冒頭で、前回のアクションの状態を確かめる

半年に 1 回ほど、ポストモーテムのアクションの完了率を数えてみると、仕組みが回っているかが分かります。

SRE 本には、レビューされないポストモーテムは書かれなかったのと同じ、という趣旨の一文があります。書いた文書は、少なくとも 1 人が読んでコメントをつけるところまでを決まりにします。

ポストモーテムのテンプレート

コピーして社内の Wiki やリポジトリに置いて使ってください。

# ポストモーテム: (障害の名前) (YYYY-MM-DD)

- 担当: / 進行役:
- 状態: 下書き / レビュー中 / 確定
- 重大度:

## 概要
(3〜5 行。何が起き、どれだけ影響し、なぜ起き、どう直したか)

## 影響
- 時間: 発生 HH:MM / 検知 HH:MM / 復旧 HH:MM (JST)
- 件数・ユーザー数・金額:
- データへの影響:

## 時系列
| 時刻 | 出来事・判断 | 備考 |
| --- | --- | --- |
|  |  | (後で判明) など |

## きっかけ

## 被害を大きくした条件
- 障害を起こした条件:
- 気づくのが遅れた条件:
- 戻すのが遅れた条件:

## 検知
- どうやって気づいたか:
- 監視で気づけたか。気づけなかったなら、何があれば気づけたか:

## 解決

## 学び
- うまくいったこと:
- うまくいかなかったこと:
- 運がよかったこと:

## アクション
| 対策 | 種類 (予防/検知/復旧/手順) | 担当 | 期限 | チケット | 状態 |
| --- | --- | --- | --- | --- | --- |

記入例: 夜間バッチが朝まで終わらなかった障害

テンプレートの使い方の例として、データベースが関わる障害を 1 つ書いてみます。

# ポストモーテム: 夜間の売上集計バッチの遅延 (2026-10-21)

## 概要
10/21 の夜間の売上集計バッチが、通常 4:00 に終わるところ 9:40 まで終わらず、
朝の営業会議で前日の売上を確認できなかった。
アプリの不具合で、トランザクションを開いたまま放置された接続が orders テーブルの行ロックを持ち続け、
集計バッチの UPDATE がロック待ちになっていた。9:30 にその接続を切断して解消した。

## 影響
- 時間: 発生 2:10 / 検知 8:50 (営業からの問い合わせ) / 復旧 9:40
- 社内の売上レポートが 5 時間 40 分遅れた。顧客への影響はなし
- データへの影響: なし (集計結果を前日分と照合して確認)

## 時系列
| 時刻 | 出来事・判断 | 備考 |
| --- | --- | --- |
| 1:55 | 管理画面の一括更新でエラー。例外処理でトランザクションが閉じられなかった | 後で判明 |
| 2:10 | 集計バッチが開始。orders の UPDATE がロック待ちになる | 後で判明 |
| 8:50 | 営業から「売上レポートが出ていない」と連絡 | |
| 9:05 | pg_stat_activity で idle in transaction の接続を見つける | |
| 9:30 | 管理画面のプロセスの接続と確認し、切断すると判断して実行 | |
| 9:40 | 集計バッチが完了 | |

## きっかけ
管理画面の一括更新で、例外が出たときにトランザクションをロールバックしない不具合。

## 被害を大きくした条件
- 障害を起こした条件: 例外時の処理にテストがなかった
- 気づくのが遅れた条件: バッチが終わったかどうかを監視していなかった。
  遅延に気づいたのは、レポートを見た営業だった
- 戻すのが遅れた条件: ロック待ちを調べる手順がなく、どの接続を切ってよいかの判断に時間がかかった

## 学び
- うまくいったこと: 接続を切る前に、どのプロセスの接続かを確かめた
- うまくいかなかったこと: 6 時間以上、誰も気づかなかった
- 運がよかったこと: 月末の締めの日ではなかった

## アクション
| 対策 | 種類 | 担当 | 期限 | 状態 |
| --- | --- | --- | --- | --- |
| 一括更新の例外時にロールバックする修正とテスト | 予防 | 佐藤 | 10/24 | 完了 |
| idle_in_transaction_session_timeout を 10 分に設定 | 予防 | 山田 | 10/31 | 完了 |
| 集計バッチが 5:00 までに終わらなければ通知する | 検知 | 鈴木 | 10/31 | 対応中 |
| ロック待ちの調べ方と、接続を切る判断基準を手順書に書く | 復旧 | 山田 | 11/7 | 未着手 |

idle_in_transaction_session_timeout は、トランザクションを開いたまま何もしていない接続を、指定した時間で切断する PostgreSQL の設定です。既定値は 0 (無効) です。アプリの作りによっては正常な処理まで切れることがあるので、値は自社の処理に合わせて決めてください。ロック待ちの調べ方は ロック待ちの原因と対処 で説明しています。

この例では原因を「不具合を入れた人」ではなく、テストのない例外処理、終わったかを見ていないバッチ、手順のないロック調査という 3 つの条件に分けています。どれか 1 つでも手当てされていれば、被害はもっと小さく済んでいました。

ポストモーテムを文化にするには

最初の数回は、書くのも会議も時間がかかります。続けるうちに、次のような工夫でチームに根づかせていきます。

• 過去の障害を題材に、1 本目を練習として書く (本番の障害を待たない)
• よく書けたポストモーテムを、月に 1 本、全社のチャットで紹介する (SRE 本は Google での「今月のポストモーテム」という取り組みを紹介しています)
• 新しく入った人に、過去のポストモーテムを読んでもらう。システムの弱いところを知る近道になります
• ポストモーテムを書いた人、障害の対応をうまく回した人に、チームの場でお礼を言う

経営者やリーダーが、障害を起こした人を責めない姿勢を言葉と行動で示すことも欠かせません。上の人が一度でも犯人探しをすると、次から誰も本当のことを書かなくなります。

気づくのが遅れた条件を減らすには

ポストモーテムを何本か書くと、「気づくのが遅れた条件」に同じ答えが並ぶことがよくあります。記入例の「バッチが終わったかを見ていなかった」のように、監視していなかった数字が後から見つかるパターンです。対策としては、バッチの完了時刻や注文数を数える SQL を cron で回し、ふだんと違えば通知する、監視ツールにアラートを足す、といった方法があります。アラートの考え方は アラートの閾値の決め方 で説明しています。

この部分を AI に任せる方法もあります。Scandock は、データベースの接続文字列を登録すると、AI がテーブルの構成と実データを読み、注文数や決済の成否、バッチ・ジョブの滞留のような数字の監視項目を決めます。異常と判断すると、読み取り専用のクエリで関連するデータを調べ、原因・影響・根拠・対処案をつけて通知します。実行したクエリと結果が残るので、ポストモーテムの時系列を書くときの材料にもなります。

参考

• Postmortem Culture: Learning from Failure (Site Reliability Engineering, Google)
• Example Postmortem (Site Reliability Engineering, Google)
• Postmortem Process (PagerDuty Incident Response Documentation)
• PostgreSQL: Client Connection Defaults (idle_in_transaction_session_timeout)