「インシデントが起きたあと、英語でポストモーテムを書かなければいけない。どう構成すればいい？」グローバルチームで働くと、障害対応の振り返りを英語でまとめる機会が増える。
この記事では、ITプロジェクトで実際に使えるポストモーテム（Post-Mortem）の日英テンプレートをそのまま提供する。タイムライン・根本原因分析・アクションアイテムの書き方と、振り返りで使える英語表現もセットで解説する。
この記事を読めば、英語ポストモーテムの構成と書き方が身につき、コピーして即日使えるテンプレートが手に入る。
結論から言う。ポストモーテムに必要なのは8つのセクションだ。なかでも「根本原因分析（Root Cause Analysis）」と「アクションアイテム（Action Items）」の2つが、再発防止の実効性を左右する最重要パートになる。
英語ポストモーテムが日本語と異なる3つのポイント
英語スタイルのポストモーテムは、日本語の障害報告書とは求められる視点が異なる。違いを理解しないまま書くと、再発防止の説得力が弱まる。
① 「責任追及なし」の文化（Blameless）
英語圏のポストモーテムは「誰が悪かったか」ではなく「システムのどこに問題があったか」を問う。個人の失敗ではなくプロセス・設計の改善を目的とするため、報告書も中立的な言葉で書く。
② 5 Whysで根本原因まで掘り下げる
「〇〇が止まった」という表面的な原因だけでなく、なぜそれが起きたかを5段階で掘り下げる。根本原因（Root Cause）まで辿り着かないと、対症療法的なアクションしか生まれない。
③ アクションアイテムには必ず担当・期限・優先度を付ける
「〇〇を改善する」だけでは行動に移されない。担当者・期限・優先度の3点セットで記載することで、フォローアップが確実になる。
ポストモーテムの8つの必須セクション（日英対訳）
英語ポストモーテムを構成する8つのセクションを日英対訳で解説する。
① ヘッダー情報（Header）
インシデント名・発生日時・深刻度・報告者・ステータスを記載する。深刻度（Severity）はSEV1〜SEV3などのレベルで表記し、影響範囲を一目で把握できるようにする。
| 日本語 | English |
| インシデント名 | Incident Name |
| 深刻度 | Severity（SEV1 / SEV2 / SEV3） |
| 発生日時・停止時間 | Date & Duration |
| ステータス | Status（Draft / Under Review / Final） |
② エグゼクティブサマリー（Executive Summary）
3〜5文で全体の概要を記載する。発生した事象・影響・対処・根本原因・再発防止の方向性を端的にまとめることで、忙しいステークホルダーが全体像を素早く把握できる。
③ インシデントタイムライン（Timeline）
発生から復旧まで、時系列で出来事と対応者を記録する。タイムラインがあると、検知の遅れ・対応のボトルネック・次回改善すべきポイントが一目でわかる。
④ 根本原因分析（Root Cause Analysis）
直接原因・根本原因・5 Whys分析の3段階で記載する。表面的な原因だけでなく、なぜそれが起きたかをシステム・プロセス・設計の観点から掘り下げる。
⑤ 影響範囲（Impact）
影響ユーザー数・停止時間・影響システム・推定損失・SLA違反の有無を表形式で記載する。数字を明示することで、インシデントの深刻さと優先度が具体的に伝わる。
⑥ 対応措置（Response Actions）
暫定対処（Mitigation）と恒久対処（Resolution）に分けて記載する。時刻と実施内容を明記することで、同様のインシデントが発生したときの対応手順書として活用できる。
⑦ 再発防止策・アクションアイテム（Action Items）
担当者・期限・優先度・ステータスをセットで記載する。「Open / In Progress / Done」でステータスを管理し、定期的にフォローアップすることで実行率が高まる。
⑧ 振り返り（What Went Well / What Could Be Improved）
うまくいったことと改善できることの両方を記載する。ネガティブな点だけでなくポジティブな点も記録することで、チームの心理的安全性が保たれ、次回のインシデント対応力が高まる。
日本語版テンプレート（コピペOK）
以下をコピーして、プロジェクトのポストモーテムとしてそのまま使える。
# ポストモーテム（事後検証報告書）
**インシデント名：** 〇〇障害
**発生日時：** 2026年〇月〇日 〇時〇分 〜 〇時〇分
**深刻度：** SEV1 / SEV2 / SEV3
**報告者：** 〇〇（役割：〇〇）
**ステータス：** ドラフト / レビュー中 / 確定
---
## エグゼクティブサマリー
〇月〇日〇時〇分に〇〇が原因で〇〇システムに障害が発生し、〇時間〇分にわたってサービスが停止した。
影響を受けたユーザーは約〇〇名、推定損失は〇〇円だった。
根本原因は〇〇であり、再発防止策として〇〇を実施する。
---
## インシデントタイムライン
| 日時 | 出来事 | 対応者 |
|------|--------|--------|
| 〇時〇分 | 〇〇アラートが発報 | 監視システム |
| 〇時〇分 | オンコール担当者が検知・対応開始 | 〇〇 |
| 〇時〇分 | 暫定対処を実施 | 〇〇 |
| 〇時〇分 | 完全復旧を確認 | 〇〇 |
---
## 根本原因分析
**直接原因：** 〇〇の設定変更により〇〇が停止した
**根本原因：** 〇〇のレビュープロセスに〇〇チェックが含まれていなかった
**5 Whys分析：**
1. なぜ障害が発生したか？→ 〇〇が〇〇したため
2. なぜ〇〇が〇〇したか？→ 〇〇がなかったため
3. なぜ〇〇がなかったか？→ 〇〇プロセスで未定義だったため
4. なぜ未定義だったか？→ 〇〇を想定していなかったため
5. なぜ想定していなかったか？→ 〇〇のリスク評価が不十分だったため
---
## 影響範囲
| 観点 | 詳細 |
|------|------|
| 影響ユーザー数 | 約〇〇名 |
| 停止時間 | 〇時間〇分 |
| 影響システム | 〇〇システム |
| 推定損失 | 〇〇円 |
| SLA違反 | あり / なし |
---
## 対応措置
**暫定対処：** 〇時〇分に〇〇を実施し、仮復旧した
**恒久対処：** 〇時〇分に〇〇の修正を本番環境に適用した
---
## 再発防止策・アクションアイテム
| # | アクション | 担当者 | 期限 | 優先度 | ステータス |
|---|-----------|--------|------|--------|----------|
| 1 | 〇〇の監視アラートを追加する | 〇〇 | 〇月〇日 | 高 | 未着手 |
| 2 | 〇〇のチェックリストを更新する | 〇〇 | 〇月〇日 | 中 | 未着手 |
---
## 振り返り
**うまくいったこと：**
- 〇〇が迅速に検知し、初動対応が早かった
**改善できること：**
- 〇〇の検知に時間がかかった。アラート設定を見直す必要がある
---
作成者：〇〇 ｜ 作成日：〇月〇日英語版テンプレート（コピペOK）
英語ポストモーテムはそのままグローバルチームやステークホルダーに共有できる。
# Post-Mortem Report
**Incident Name:** [e.g., Payment API Outage]
**Date & Duration:** [Date], [Start Time] - [End Time] ([X] hours [X] minutes)
**Severity:** SEV1 (Critical) / SEV2 (Major) / SEV3 (Minor)
**Author:** [Name] ([Role])
**Status:** Draft / Under Review / Final
---
## Executive Summary
On 2026/05/09 at [time], [system] experienced an outage caused by [root cause],
resulting in [X] hours of service disruption. Approximately [X] users were
affected, with an estimated revenue impact of $[X]. Full recovery was confirmed
at [time]. The root cause was [brief description]. Preventive actions will be
implemented by 2026/05/09.
---
## Incident Timeline
| Time | Event | Responder |
|------|-------|-----------|
| [HH:MM] | Alert triggered by monitoring system | Monitoring |
| [HH:MM] | On-call engineer acknowledged and began investigation | [Name] |
| [HH:MM] | Mitigation applied | [Name] |
| [HH:MM] | Full service recovery confirmed | [Name] |
---
## Root Cause Analysis
**Immediate Cause:** [What directly caused the incident]
**Root Cause:** [The underlying systemic issue]
**5 Whys Analysis:**
1. Why did the incident occur? - [Answer]
2. Why did [X] happen? - [Answer]
3. Why was [Y] not in place? - [Answer]
4. Why was it not defined? - [Answer]
5. Why was it not anticipated? - [Answer]
---
## Impact
| Area | Details |
|------|---------|
| Users Affected | Approximately [X] users |
| Downtime | [X] hours [X] minutes |
| Systems Affected | [System/Feature names] |
| Estimated Revenue Impact | $[X] |
| SLA Violation | Yes / No |
---
## Response Actions
**Mitigation:** At [time], [action] was applied to partially restore service.
**Resolution:** At [time], [fix] was deployed and full recovery was confirmed.
---
## Action Items
| # | Action | Owner | Due Date | Priority | Status |
|---|--------|-------|----------|----------|--------|
| 1 | Add monitoring alert for [condition] | [Name] | [Date] | High | Open |
| 2 | Update review checklist to include [check] | [Name] | [Date] | Medium | Open |
---
## Retrospective
**What Went Well:**
- [e.g., Alert was detected quickly and initial response was fast]
**What Could Be Improved:**
- [e.g., Detection of [X] took too long - alert thresholds need review]
---
Prepared by: [Name] | Created: [Date] | Last updated: [Date]ポストモーテムで使える英語表現15選
ポストモーテムを書くときに頻出する表現を場面別にまとめた。
根本原因を説明するとき
① The root cause was identified as ～（根本原因は〜と特定された）
② This incident was triggered by ～（このインシデントは〜によって引き起こされた）
③ The immediate cause was ～, which led to ～（直接原因は〜であり、それが〜につながった）
④ A contributing factor was the lack of ～（一因は〜の欠如だった）
⑤ The system did not have a mechanism to detect ～（システムには〜を検知する仕組みがなかった）
影響範囲を伝えるとき
⑥ Approximately [X] users were affected during the outage.（停止中、約〇〇名のユーザーが影響を受けた）
⑦ The service was unavailable for [X] hours and [X] minutes.（サービスは〇時間〇分にわたって利用不能だった）
⑧ The estimated revenue impact is $[X].（推定の売上影響は〇〇ドルだ）
⑨ This incident resulted in an SLA violation of ～（このインシデントにより〜のSLA違反が発生した）
⑩ No customer data was compromised.（顧客データへの影響はなかった）
再発防止を提案するとき
⑪ To prevent recurrence, we will ～（再発防止のため、〜を実施する）
⑫ We will add an alert for ～ by 2026/05/09.（〇日までに〜のアラートを追加する）
⑬ The on-call runbook will be updated to include ～（オンコールRunbookに〜を追加して更新する）
⑭ A review of the [process] will be conducted by [team] within [X] weeks.（〇週間以内に〇チームが〇プロセスのレビューを実施する）
⑮ This action item has been assigned to [name] and is due by 2026/05/09.（このアクションアイテムは〇〇が担当し、期限は〇日だ）
ポストモーテム会議でのファシリテーションや英語フレーズは、【例文あり】エンジニアの英語ポストモーテム術｜振り返り・再発防止フレーズ30選も参考にしてほしい。
ポストモーテムを書くときの3つのコツ
① 報告書はインシデント終息後48時間以内に着手する
時間が経つと記憶が薄れ、タイムラインの詳細が失われる。対応中のSlackログやアラート履歴を48時間以内にまとめ、骨格を作るのが鉄則だ。
② 「誰が悪かった」を書かない（Blameless）
「〇〇さんのミスで」という表現は避ける。代わりに「レビュープロセスに〇〇が含まれていなかった」と、システムとプロセスの問題として記述することで、チームの心理的安全性が守られる。
③ アクションアイテムは次のスプリントに組み込む
「後で対応する」は実行されない。アクションアイテムをJiraやGitHub Issuesに起票し、次のスプリントに組み込むことで、再発防止が確実に動き出す。
インシデント発生中の英語対応フレーズは、【例文あり】エンジニアの英語インシデント対応術｜報告・対応・振り返りフレーズ30選も合わせて活用してほしい。
まとめ：8つのセクションと15表現で英語ポストモーテムが書ける
英語ポストモーテムの構成と書き方をまとめる。
- 8つの必須セクション：ヘッダー・エグゼクティブサマリー・タイムライン・根本原因分析・影響範囲・対応措置・アクションアイテム・振り返り
- 英語スタイルの3つの特徴：Blameless文化・5 Whysによる掘り下げ・担当/期限/優先度の明示
- 15の英語表現：根本原因説明・影響範囲・再発防止の場面ごとに使い分ける
- 3つのコツ：48時間以内に着手・Blameless記述・次スプリントへの組み込み
テンプレートは上記をコピーしてすぐ使える。チームの規模やインシデントの深刻度に合わせてセクションを調整してカスタマイズしてほしい。
コメント