エンジニアリング・ポストモーテム・テンプレート（ブレームレス・アクション指向）
ポストモーテムが責任追及の場に変わる理由
ポストモーテムは特定のパターンで失敗します。参加者全員が共通のタイムラインを持つ前に、原因の特定が始まってしまうのです。デプロイ時刻が確認される前に「デプロイが原因だ」と誰かが言い、そのシナリオに対してアラートが設定されていたかどうかも分からないまま「アラートが発火しなかった」と別の誰かが言う。実際に何が、どの順序で起きたのかを誰も確認しないまま、因果関係の議論が始まってしまいます。
解決策は構造的なものです。ルート原因を誰かが口にする前に、ポストモーテムの冒頭でインシデントのタイムラインを全員で一緒に構築することです。何がいつ変わり、誰がいつ何を見たか — この一連の出来事を全員が共有した後では、原因の議論はずっと進めやすくなり、責任追及に陥りにくくなります。これがほとんどのテンプレートが犯している「順序のミス」です。テンプレートの目的がルート原因の特定だからといって、ルート原因から始めてしまう。しかし、ルート原因の議論を誠実なものにするのはタイムラインなのです。
アジェンダ（コピー＆ペースト用）
所要時間： 単純なインシデントは60分、複数システムが絡む複雑な障害は90分
形式： ファシリテーター進行。対応した全員とオンコール・エンジニアが参加。事前に事前読み込みドキュメントを共有して非同期で準備
セクション1 — インシデント概要（5分）
- インシデントの発生日時と継続時間
- 重大度の分類と影響を受けたシステム
- 検知者と検知方法（顧客報告、アラート、エンジニア、モニタリング）
- このセクションは事実のみ。分析はまだ行わない
セクション2 — タイムライン（20分）
- タイムラインは画面上で全員で協力して構築する — 事前に作成したドキュメントではなく
- 順序：何が変化したか、何が観察されたか、誰が行動したか、何が決定されたか
- すべてのタイムスタンプは出典を明記する（ログの行、PagerDuty、Slackメッセージ）
- タイムラインが完成したら確認する：これが実際に起きたことだと全員が合意できるか？ 次に進む前に意見の相違を解消する
セクション3 — 影響サマリー（5分）
- 顧客への影響：誰が、どのくらいの時間、どのような形で影響を受けたか
- ビジネスへの影響：収益、SLA、レピュテーション
- 社内への影響：オンコール時間、チームへの支障
- 事実を淡々と述べる。意見を交えずに「どれほど深刻だったか」という問いに答える
セクション4 — ルート原因とコントリビューティング・ファクター（20分）
- ルート原因：インシデントを発生可能にした、最も直接的な変更や状態
- コントリビューティング・ファクター：インシデントを悪化させた、検知を困難にした、または復旧を遅らせた状態
- 有益なポストモーテムの多くは、ルート原因に加えて3〜5個のコントリビューティング・ファクターを特定する。ルート原因だけを修正しても、システム的な状態を見逃すことが多い
- 各ファクターについて問う：当時入手可能な情報のもとで合理的に見えた判断を下した個人やチームがいたか？ そうであれば、そのファクターは個人的なものではなくシステム的なものです
セクション5 — うまくいったこと（5分）
- 予想以上にうまく機能した検知や対応は何か？
- 被害範囲を限定した既存のプロセスやツールは何か？
- これらは正式化する価値のある実践です — ランブックで20分節約できたなら、ランブックがメンテナンスされ続けるようにその事実を記録しておく
セクション6 — アクションアイテム（15分）
- 各アクションアイテムはルート原因またはコントリビューティング・ファクターに対処するもの — 一般的な改善策ではない
- アイテムごとに1人のオーナー。緊急度に見合った納期を設定する
- カテゴリに分類する：より早く検知する / より速く復旧する / 再発を防ぐ
- チームが次のインシデントまでに現実的に完了できる範囲のアクションに絞る。包括的な信頼性ロードマップではない
ポストモーテム・テンプレートが失敗する原因
ルート原因から始める順序の問題が主要な構造的欠陥です — これは上述の通りです。次の問題は「アクションアイテム」を単一のカテゴリとして扱うことです。検知の改善、復旧の改善、再発防止の改善は、それぞれ異なるオーナーと異なるタイムラインを必要とします。混在させると6ヶ月・3チームにわたるリストができあがり、責任が分散して何も出荷されません。
3つ目の失敗パターンは、インシデント後に「うまくいったこと」を書くのは場違いな楽観主義に見えるからと省略してしまうことです。そうではありません — プレッシャー下で機能した実践を特定・正式化する唯一の系統的な方法です。問題を捉えたモニタリングがロードマップになかったものなら、それが重要だったと学ぶ価値があります。そうしなければ、インシデントの記憶が薄れた後に優先度が下がり、次回は見えない状態になります。
コントリビューティング・ファクターが放置され、うまく機能したランブックがメンテナンスされないことで積み重なるコストは速く膨らみます。ミーティングの税金では、定期的なミーティングのオーバーヘッドとインシデント・レビューの負債がどう相互作用するかを取り上げています。
ポストモーテムの記録が特に難しい理由
ポストモーテムの議論は、密度の高い非構造化コンテンツを急速に生み出します。タイムラインの再構築、解釈の競合、複数人へのアクションアイテムのアサイン、文脈なしでは意味をなさない技術的詳細 — こういったものが次々と出てきます。記憶や編集した音声から書かれたポストモーテムの要約は、ほぼ確実に不完全です。そして不完全なポストモーテムの記録は、インシデントをまたいだパターン認識に使えません。
Pavleurはポストモーテムの議論全体をキャプチャし、レポートを自動生成します — 再構築されたタイムライン、特定されたコントリビューティング・ファクター、ミーティング中に述べられたオーナーとカテゴリ付きのアクションアイテムをそのまま記録します。ログの抽出、モニタリンググラフ、発火しなかったアラート設定を画面共有して見せた場合、その視覚情報もレポートに含まれます。音声のみのツールではこれが完全に欠落します。グラフのないポストモーテムの記録は、証拠のない記録です。インシデント後に入社したエンジニアを含め、チームの誰もが誰かに再構築を依頼することなく、視覚的コンテキスト付きの完全な記録を読むことができます。他のツールとの直接比較についてはPavleur vs. 各種ツール比較をご覧ください。
ポストモーテムのタイミングについて
細部が新鮮なうちに、インシデント解決から48時間以内にポストモーテムを実施してください。待てば待つほど、タイムラインの再構築がログではなく記憶に頼るようになります。そしてストレス下では記憶は信頼できません。重大度の高いインシデントは24時間以内が望ましい。軽微なインシデントでは、非同期ポストモーテム — 構造化されたプロンプト付きの共有ドキュメントを同期的にレビュー — の方がフルミーティングより効率的なことがあります。インシデントが曖昧だった場合や、共通の解釈が重要なほど重大だった場合に、ミーティング形式が最も価値を発揮します。