本番障害が収束した後に「英語でポストモーテムを書いて」と言われ、何から書けばいいか迷うエンジニアは多い。障害のタイムライン・根本原因・影響範囲・再発防止策を英語で構造化したポストモーテムは、チームが障害から学び、同じ問題を繰り返さないための基盤となる。
この記事では、ITプロジェクトで実際に使える英語ポストモーテムの書き方を解説する。フレーズ20選・日英Wordテンプレートもセットで用意した。コピペしてすぐに使える。
英語ポストモーテムを整備すると、「また同じ障害が起きた」「あのとき何をしたか分からない」という状況を防ぎ、障害対応の知識をチーム全体の資産にできる。さっそく構成と書き方を確認しよう。
英語ポストモーテムとは何か・なぜ必要か
ポストモーテム（Post-Mortem）とは、本番障害・重大インシデントの発生後に実施する振り返り文書だ。障害の概要・タイムライン・根本原因・影響範囲・対応内容・再発防止策・教訓を記録し、チームが同じ問題を再発させないための組織的な学習として機能する。
英語では “Post-Mortem” のほか “Incident Review” “Incident Post-Mortem” とも呼ばれる。SRE（サイトリライアビリティエンジニアリング）文化を取り入れているチームでは「Blameless Post-Mortem（犯人捜しをしないポストモーテム）」として定着している。
ポストモーテム・RCA・障害報告書の違い
RCA（Root Cause Analysis：根本原因分析）は障害の原因を深掘りする分析手法で、ポストモーテムの一セクションとして組み込まれることが多い。障害報告書はステークホルダーへの報告文書として体裁を整えたものだ。
ポストモーテムはチームの内部文書として再発防止を目的とする。障害報告書は管理職やクライアントへの説明文書として機能する。目的と読者が異なるため使い分けるのが適切だ。
英語ポストモーテムがないと何が起きるか
ポストモーテムなしで障害対応を終えると、「あのとき何をしたか・なぜ直ったか」が担当者の記憶にしか残らない。次に同じ障害が起きたとき、前回の対応を参照できずに同じ試行錯誤を繰り返す。
グローバルチームでは、時差・担当者の異動・言語の壁により、口頭での引き継ぎは機能しない。英語で構造化されたポストモーテムがあることで、どのメンバーが障害対応にあたっても同じ水準で過去の知見を活用できる。
障害対応の手順はRunbookと合わせて整備すると証跡管理が完結する。【テンプレあり】英語Runbookの書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
英語ポストモーテムの7つの必須セクション（日英対訳）
英語ポストモーテムは7つのセクションで構成するのが基本だ。
1. 障害概要（Incident Summary）
障害の概要・発生日時・検知日時・復旧日時・障害の重大度を記載するセクションだ。「いつ・何が起きた・いつ直った」を冒頭に示すことで、読者が詳細を読む前に全体像をつかめる。
2. タイムライン（Timeline）
障害発生から復旧完了までの時系列の出来事を記録するセクションだ。「いつ・誰が・何をしたか・何が分かったか」を時刻とともに記録する。タイムラインが正確であるほど、根本原因の特定と再発防止策の立案が精度を増す。
3. 根本原因分析（Root Cause Analysis）
なぜ障害が発生したのかを「5 Why」などの手法で掘り下げるセクションだ。「表面的な症状（サーバーが落ちた）」ではなく「その背景にあった構造的な原因（監視設定の不備・設計上の欠陥）」まで特定することが目的だ。
4. 影響範囲（Impact）
障害が影響したユーザー数・システム・ビジネスへの影響を定量的に記録するセクションだ。「推定〇〇人のユーザーが〇〇時間アクセスできなかった」など数値で表現することで、重大度の評価と再発時の判断基準になる。
5. 対応内容（Response and Resolution）
実際に行った対応手順・判断・エスカレーションの記録を記載するセクションだ。「正しかった対応」と「遅れた判断」の両方を正直に記録することで、次回の対応品質向上につながる。
6. 再発防止策（Action Items）
根本原因に対する具体的な改善アクションを担当者・期限付きで記録するセクションだ。「監視の強化」という曖昧な記述ではなく「〇〇のアラートしきい値を〇〇に変更する（担当：〇〇、期限：〇〇）」のように実行可能な形で定義する。
7. 教訓（Lessons Learned）
この障害を通じてチームが得た学びを記録するセクションだ。技術的な教訓だけでなく、コミュニケーション・エスカレーション・判断プロセスの改善点も含める。教訓を言語化することで、次の障害対応者が同じ過ちを繰り返さない文化が育つ。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。
📥 日本語テンプレートをダウンロード（Word（空白版））
📥 Download English Template (Word – Blank)
📥 日本語サンプルをダウンロード（ECサイト 決済障害）
📥 Download Sample in English (E-Commerce Payment Outage)
日本語版テンプレート（コピペOK）
以下をコピーして、プロジェクトのポストモーテムとしてそのまま使える。
# ポストモーテム（障害振り返り）
**インシデントID：** INC-〇〇〇
**タイトル：** 〇〇障害（〇〇機能が〇〇時間停止）
**作成者：** 〇〇
**作成日：** 2026年〇月〇日
**重大度：** Critical / High / Medium
---
## 障害概要
〇〇機能において、〇月〇日〇:00から〇:00の〇時間、〇〇が発生した。推定〇〇人のユーザーに影響が生じた。
| 項目 | 日時 |
|------|------|
| 障害発生 | 〇月〇日 〇:00 |
| 検知 | 〇月〇日 〇:00（発生から〇分後） |
| エスカレーション | 〇月〇日 〇:00 |
| 復旧完了 | 〇月〇日 〇:00 |
| 総対応時間 | 〇時間〇分 |
---
## タイムライン
| 時刻 | 出来事・対応 | 担当者 |
|------|------------|--------|
| 〇:00 | 〇〇アラートが発報 | 監視システム |
| 〇:05 | オンコール担当が検知・調査開始 | 〇〇 |
| 〇:20 | 根本原因の仮説を特定 | 〇〇 |
| 〇:30 | チームリードにエスカレーション | 〇〇 |
| 〇:45 | 修正対応を実施 | 〇〇 |
| 〇:55 | サービス復旧を確認 | 〇〇 |
---
## 根本原因分析
- 直接原因：〇〇
- 根本原因：〇〇
- なぜ1：〇〇が発生したのはなぜか？ → 〇〇
- なぜ2：〇〇になったのはなぜか？ → 〇〇
- なぜ3：〇〇だったのはなぜか？ → 〇〇
---
## 影響範囲
- 影響ユーザー：〇〇（推定〇〇人）
- 影響機能：〇〇
- ビジネス影響：〇〇
---
## 対応内容
1. 〇〇を確認し、〇〇であることを特定した
2. 〇〇を実施した（〇:〇〇）
3. サービス復旧を確認した（〇:〇〇）
---
## 再発防止策
| No. | アクション | 担当者 | 期限 | ステータス |
|-----|-----------|--------|------|-----------|
| 1 | 〇〇の監視アラートを追加する | 〇〇 | 〇月〇日 | 未着手 |
| 2 | 〇〇の設計を見直す | 〇〇 | 〇月〇日 | 未着手 |
| 3 | 〇〇のRunbookを作成する | 〇〇 | 〇月〇日 | 未着手 |
---
## 教訓
- 〇〇の監視が不十分だった。今後は〇〇を追加する
- エスカレーションの判断が〇〇分遅れた。基準を明文化する
- 〇〇の対応手順が属人化していた。Runbookを整備する英語版テンプレート（コピペOK）
以下をコピーして、グローバルチームのポストモーテムとしてすぐに使える。
# Post-Mortem
**ID:** PM-[Number]
**Title:** [Service / Feature] – Outage for [X] hours on [Date]
**Author:** [Name]
**Date:** [Date]
**Severity:** Critical / High / Medium
---
## Overview
On 2026/06/07, [service] was unavailable from [start time] to [end time] (total: [X] hours).
Approximately [number] users were affected.
| Item | Date and Time |
|------|--------------|
| Outage Start | [Date] [Time] |
| First Alert | [Date] [Time] |
| Escalation | [Date] [Time] |
| Resolved | [Date] [Time] |
| Total Duration | [X] hours [X] min |
---
## Timeline
| Time | Event | Owner |
|------|-------|-------|
| [Time] | Alert fired | [Name] |
| [Time] | On-call engineer began investigation | [Name] |
| [Time] | Probable cause identified | [Name] |
| [Time] | Handed off to team lead | [Name] |
| [Time] | Fix applied | [Name] |
| [Time] | Service restored | [Name] |
---
## Cause Analysis
- Direct Cause: [What directly caused the outage]
- Underlying Cause: [Process or design issue]
- Why 1: Why did [problem] happen? → [Answer]
- Why 2: Why did [condition] exist? → [Answer]
- Why 3: Why was this not caught earlier? → [Answer]
---
## Impact
- Affected Users: [Description] (Estimated: [number] users)
- Affected Features: [Feature name]
- Business Effect: [Description]
---
## Response Summary
1. Confirmed [finding] and identified the cause
2. Applied [fix] at [time]
3. Confirmed full service restoration at [time]
---
## Action Items
| No. | Action | Owner | Due Date | Status |
|-----|--------|-------|----------|--------|
| 1 | Add alert for [condition] | [Name] | [Date] | Not started |
| 2 | Review design of [component] | [Name] | [Date] | Not started |
| 3 | Create Runbook for [scenario] | [Name] | [Date] | Not started |
---
## Lessons Learned
- Alerting for [condition] was not in place. We will add [alert] going forward
- Handoff to the team lead took longer than expected. We will set clear handoff criteria
- The response steps for [scenario] were not written down. We will create a Runbook英語ポストモーテムで使えるフレーズ20選
ポストモーテムを書くとき・障害振り返り会議で発言するときに使える表現を場面別にまとめた。
障害の概要を説明するとき
| 日本語 | 英語フレーズ |
|---|---|
| 〇〇機能が〇月〇日〇:00から〇時間停止した | [Feature] was unavailable from [time] on 2026/06/07 for a total of [X] hours |
| 推定〇〇人のユーザーが影響を受けた | An estimated [number] users were affected by this incident |
| 重大度はCriticalと判断する | This incident is classified as Critical severity |
| 障害は〇分後に検知され、〇:〇〇に復旧した | The issue was detected [X] minutes after it began and resolved at [time] |
| 同様の障害は過去〇ヶ月間で〇回発生している | A similar outage has occurred [X] times over the past [X] months |
タイムライン・対応内容を記述するとき
| 日本語 | 英語フレーズ |
|---|---|
| 〇:〇〇に監視アラートが発報した | A monitoring alert was triggered at [time] |
| 〇:〇〇にオンコール担当が調査を開始した | The on-call engineer began investigation at [time] |
| 〇:〇〇にチームリードにエスカレーションした | The issue was escalated to the team lead at [time] |
| 〇の対応を実施したことでサービスが復旧した | Applying [fix] restored the service to normal operation |
| 本障害の総対応時間は〇時間〇分だった | The total outage duration was [X] hours and [X] minutes |
根本原因を分析するとき
| 日本語 | 英語フレーズ |
|---|---|
| 直接原因は〇〇だった | The immediate cause of this outage was [cause] |
| 根本原因は〇〇の設計上の欠陥だった | The root cause was a design gap in [component] |
| 5 Why分析の結果、〇〇が特定された | The 5 Why analysis identified [cause] as the underlying issue |
| この問題は〇〇の監視が不十分だったために検知が遅れた | Detection was delayed due to insufficient alerting on [condition] |
| 〇〇の変更が本障害のトリガーになった | A recent change to [component] triggered this outage |
再発防止策を提案するとき
| 日本語 | 英語フレーズ |
|---|---|
| 〇〇の監視アラートを追加することを提案する | We propose adding an alert for [condition] to improve early detection |
| 〇〇のRunbookを作成し、対応手順を標準化する | We will create a Runbook for [scenario] to standardize the response process |
| 〇〇のしきい値を引き下げて早期検知を強化する | We will lower the threshold for [metric] to strengthen early detection |
| エスカレーション基準を明文化し、判断の遅れを防ぐ | We will document clear escalation criteria to prevent delayed decisions |
| 本アクションアイテムは〇月〇日までに完了させる | This action item will be completed by 2026/06/07 |
障害の不具合報告はバグレポートとセットで記録すると証跡管理が完結する。【テンプレあり】英語バグレポートの書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
英語ポストモーテムを書くときの3つのコツ
① Blameless（犯人捜しをしない）で書く
「〇〇さんが設定を間違えた」という書き方は、次回からポストモーテムに正直に書く文化を壊す。「〇〇の設定手順が明文化されておらず、誤設定が起きやすい構造だった」のようにシステム・プロセスの問題として記述する。Blamelessの原則が、ポストモーテムを再発防止の有効な文書にする前提条件だ。
② タイムラインは正確な時刻と担当者をセットで書く
「しばらくして復旧した」では次の障害対応に使えない。「〇:〇〇にアラート発報→〇:〇〇に調査開始→〇:〇〇にエスカレーション→〇:〇〇に復旧」のように時刻と担当者をセットで記録する。タイムラインの精度が根本原因の特定精度を直接左右する。
③ アクションアイテムは担当者・期限を必ず設定する
「監視を強化する」という曖昧なアクションは次のスプリントで消える。「〇〇のアラートしきい値を〇〇に変更する（担当：〇〇、期限：〇月〇日）」のように、具体的な変更内容・担当者・期限をセットで定義する。次回のポストモーテムで「前回のアクションが完了したか」を確認することで改善が継続する。
スプリントレトロと合わせてポストモーテムを整備することで、障害とプロセス改善の両方が継続して進む。【テンプレあり】英語スプリントレトロの書き方｜KPT形式の日英フォーマット付きも参考にしてほしい。
プロジェクト全体の教訓は完了報告書にまとめることで組織の知識資産になる。【テンプレあり】英語プロジェクト完了報告書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
まとめ：英語ポストモーテムで障害を組織の学びに変える
英語ポストモーテムの要点は3つだ。
- 7セクションで構成：障害概要・タイムライン・根本原因分析・影響範囲・対応内容・再発防止策・教訓
- Blamelessで書く：個人ではなくシステム・プロセスの問題として記述することで次回の正直な振り返りが生まれる
- アクションアイテムは担当者・期限つきで定義する：曖昧なアクションは実行されず再発防止につながらない
ポストモーテムをプロジェクト標準として整備することで、障害のたびにチームの対応力と設計品質が向上する。Wordテンプレートを活用して、今すぐ自チームのポストモーテム文化をつくってみてほしい。
コメント