Day 058 — 2026-06-11

システム障害のポストモーテム発表

Phase 2 — Functional 📊 Presentation ⚙️ Engineering ★★★☆☆

シナリオ

あなたはSaaS企業 Novalite のシニアエンジニアです。先週発生した本番インシデント（決済サービスの503エラー、約40分のダウンタイム）について、今日の週次エンジニアリングレビューで ポストモーテム（事後検証） を発表します。

📊 Weekly Engineering Review — Postmortem Presentation Live Presentation

P1 Incident — 2026-06-10

40 min
Downtime
~1,200
Affected Users
P1
Severity

Service: payment-service · Root Cause: Memory leak in v2.4.1 deploy

あなた
Senior Engineer（インシデントコマンダー）
ポストモーテムの発表者。今回の障害対応を主導した
Alex Kim
Engineering Manager
EM・技術的バックグラウンドあり。再発防止策に関心が高い
Sarah
Product Manager
非エンジニア。ビジネスインパクトと次のアクションを知りたい

重要なコンテキスト

🎯
Blameless Postmortem
「誰が悪いか」ではなく「システムをどう改善するか」にフォーカスする文化。責任追及のトーンを一切出さないこと
✅
結論先行（BLUF）
冒頭の1文で「何が起きたか・影響範囲・いつ解決したか」を述べる。背景説明から入らない
👥
混在する聴衆
技術者とSarahのような非エンジニアが混在。技術用語にはアナロジーを添えて平易な言葉で補足する

タスク

以下の情報をもとに、ポストモーテム発表の冒頭スピーチ（2〜3分、200〜300語） を英語で書いてください。

⏱️ 20分 📝 200〜300語 📊 Presentation
含める要素 1
Executive Summary（1文）
何が起きたか・影響範囲・いつ解決したかを1文で凝縮する。リスナーはこの1文で全体像を把握できる必要がある
含める要素 2
Timeline（3〜4点）
主要なタイムスタンプと各フェーズで何が起きたかを箇条書きで述べる。10:45 / 10:52 / 11:10 / 11:25 AM JST を使用すること
含める要素 3
Root Cause（2〜3文）
payment-service のメモリリークが原因。Sarah にも伝わるアナロジー を使って平易に説明すること。技術的詳細も省かない
含める要素 4
Key Takeaways（2点）
チームが学んだ最も重要な教訓を2点述べる。「誰が悪かったか」ではなく「システムと手順の何を改善するか」の観点で
含める要素 5
Next Actions（2〜3点）
再発防止のための具体的アクション。① メモリアラート閾値の変更 ② デプロイチェックリストへのロードテスト追加 ③ canary デプロイ導入 — 各アクションに担当者と期限を添えること

Presentation × Engineering 必須語彙

カードをクリックすると日本語訳と例文を表示します。

walk you through クリックで詳細を表示 →
順を追って説明する 💡 "Let me walk you through the timeline." — 発表の定番フレーズ。explain より口語的
root cause クリックで詳細を表示 →
根本原因（技術的な標準語） 💡 "The root cause was a memory leak..." — "cause of the problem" より専門的でプロらしい
blameless review クリックで詳細を表示 →
非難なしのレビュー（責任追及ではなくシステム改善が目的） 💡 Google・Netflix・Atlassian が採用する文化的規範。発表冒頭で述べることで心理的安全性を確保
action item クリックで詳細を表示 →
行動アイテム（担当者・期限付きタスク） 💡 "We have three action items coming out of this." — 必ず owner と deadline を添えること
coming out of this クリックで詳細を表示 →
これを経て・その結果として 💡 アクションアイテムを列挙する前の自然な導入句。"As a result" より会話的
blast radius クリックで詳細を表示 →
影響範囲（直訳: 爆発半径） 💡 "canary deploys reduce the blast radius" — エンジニアリング英語の慣用表現
to put it plainly クリックで詳細を表示 →
平たく言うと（非技術者向けの言い換え前置き） 💡 "To put it plainly for everyone: the service was..." — 技術用語をアナロジーで言い換えるときの自然な前置き
dig into the details クリックで詳細を表示 →
詳細を掘り下げる 💡 "Any questions before we dig into the details?" — 発表のサマリー後にQ&Aへ移る定番フレーズ

ヒント（段階的開示）

ヒント 1 — 構成・方向性
  • 構成は5段階: Executive Summary → Timeline → Root Cause → Key Takeaways → Next Actions の順。各セクションの移行時に "Let me walk you through..." や "Coming out of this..." を使うと自然に流れる
  • 冒頭の1文で地図を提供: 「いつ・何が・どの程度影響したか・いつ解決したか」を1文に凝縮する。リスナーは冒頭の1文で発表全体の地図を得る
  • 終わりはネガティブで終わらない: 最後は必ず「チームとして次に何をするか」でしめくくる。"This is a blameless review" のフレーズで心理的安全性を確保する
ヒント 2 — キーフレーズ
  • "Last Tuesday, we had a P1 incident affecting checkout for approximately 40 minutes."
  • "Let me walk you through the timeline."
  • "The root cause was a memory leak in a newly deployed feature, which caused our payment-service pods to crash."
  • "To put it plainly for everyone: the service was slowly using more and more memory until it hit its limit and crashed."
  • "The key takeaway is: we caught this, we fixed it in 40 minutes, and we now have clear action items."
  • "Coming out of this, we have three action items."
  • "This is a blameless review. The system failed — we learn from it and make it better."
ヒント 3 — 骨格
[Executive Summary] Last [day], we had a P1 incident — [what happened]. Service was restored at [time], after approximately [X] minutes. [Timeline] Let me walk you through the timeline. - 10:45 AM: [what triggered it] - 10:52 AM: [incident declared] - 11:10 AM: [root cause identified] - 11:25 AM: [service restored via rollback] [Root Cause] The root cause was [technical explanation]. To put it plainly: [analogy for non-engineers]. [Key Takeaways] Two key takeaways: First, [lesson 1]. Second, [lesson 2]. [Next Actions] Coming out of this, we have [N] action items: 1. [Action] — owner: [name], by [date] 2. [Action] — owner: [name], by [date] 3. [Action] — owner: [name], by [date] This is a blameless review. Any questions before we dig into the details?

モデル解答

Executive Summary

Last Tuesday, we had a P1 outage affecting our checkout flow for approximately 40 minutes — from 10:45 to 11:25 AM JST. Roughly 1,200 users were unable to complete payments. Service was fully restored, and I want to walk you through what happened, why it happened, and what we're doing to make sure it doesn't happen again.

Timeline

Let me walk you through the timeline.

  • 10:45 AMOur payment-service pods began crashing in production. We started seeing 503 errors spike in Datadog.
  • 10:52 AMI declared a P1 incident and looped in Kevin from the backend team.
  • 11:10 AMKevin identified the root cause: a memory leak introduced in the v2.4.1 deploy from Monday.
  • 11:25 AMWe rolled back to v2.4.0 and restarted the pods. Service was fully restored.
Root Cause

The root cause was a memory leak in a new feature shipped in Monday's deploy. To put it plainly for everyone: the service was slowly using more and more memory until it hit its limit and crashed — like a program that forgets to clean up after itself. Our existing memory alerts didn't catch it because the threshold was set too high.

Key Takeaways

Two takeaways. First, our monitoring wasn't sensitive enough — we should have caught the memory spike before users were impacted. Second, we didn't have a load test as part of our deploy checklist, which would have surfaced this memory issue pre-production.

Next Actions

Coming out of this, we have three action items:

  • 1
    Lower the memory alert threshold from 85% to 70% — owner: Kevin, by this Friday.
  • 2
    Add load testing to the deploy checklist — owner: myself, by end of next week.
  • 3
    Introduce canary deployments to limit blast radius on future releases — owner: Alex and I will scope this together, targeting Q3.

This is a blameless review. The system failed — we learn from it and make it better. Any questions before we dig into the details?

キー表現ハイライト
"walk you through" — explain より自然な発表フレーズ
"looped in Kevin" — 対応チームに加えた、の英語エンジニア表現
"To put it plainly for everyone" — 非エンジニアへのアナロジー前置き
"Coming out of this, we have three action items." — アクション列挙の自然な導入
"This is a blameless review." — blameless postmortem 文化の宣言

解説

構成分析

1
Executive Summary（冒頭1文）で地図を提供する
"Last Tuesday, we had a P1 outage..." の1文に「いつ・何が・どの程度・いつ解決したか」を凝縮する。これがなければ聴衆はTimeline を聞きながら「で、最終的にどうなったの？」と不安を抱えながら聞くことになる。BLUF（Bottom Line Up Front）の実践。
2
Timeline は時刻 + 1〜2文の箇条書き
"Let me walk you through the timeline." という1文がセクション移行のシグナルになる。各エントリは「何が起きたか」だけを述べ、原因・対策はRoot Causeセクションで扱う。過去形（began / started / declared / identified / rolled back）を一貫して使う。
3
Root Cause はアナロジーで非エンジニアにも届ける
"like a program that forgets to clean up after itself" というアナロジーが Sarah のような非エンジニアへの橋渡しになる。技術用語（memory leak、pods、threshold）を使いながらも、アナロジーで補足するのが混在した聴衆への最善策。
4
Action Items は owner + deadline がセット
"We'll try to improve monitoring" では不十分。"owner: Kevin, by this Friday" のように担当者と期限を明示することで、フォローアップが可能なコミットメントになる。これがなければ action item として機能しない。

重要表現

英語表現日本語ポイント
walk you through順を追って説明する"explain" より発表文脈で自然。聴衆を「一緒に歩く」イメージ
looped in巻き込んだ・参加させたインシデント対応で誰かを呼び込む動作の慣用表現
to put it plainly平たく言うと技術説明の後にアナロジーへ移行するときの自然な前置き
coming out of thisこれを経て学びからアクションへの橋渡しフレーズ。"as a result" より会話的
blameless review非難なしのレビュー発表のトーンを設定する重要なフレーズ。冒頭か締めに使う
blast radius影響範囲デプロイ障害の影響範囲を指すエンジニアリング慣用表現

文化的ポイント

🎯
Blameless Postmortem の文化
Google SRE・Netflix・Atlassianが採用。「誰が間違いをしたか」ではなく「システムと手順の何が失敗を許したか」を問う。この文化がなければエンジニアは障害を隠すようになる。
📋
Action Items に owner と deadline は必須
英語圏のミーティングでは "We should..." で終わるアクションは行動アイテムとみなされない。必ず「誰が・いつまでに」を付ける文化がある。
💡
結論先行（BLUF）
アメリカのビジネス・技術文化では発表の冒頭でサマリーを述べる。日本の「背景 → 経緯 → 結論」の順番ではなく「結論 → 経緯 → アクション」が標準

よくある日本人のミス

❌ 謝罪から始める: "I'm sorry for the trouble this incident caused to our users and team..."
ポストモーテムは謝罪の場ではない。Executive Summary で状況を述べることから始める
→
✅ "Last Tuesday, we had a P1 outage affecting checkout for approximately 40 minutes."
❌ "The cause of the problem was a memory issue in the payment service..."
"root cause" が技術的な標準語。"cause of the problem" はカジュアルで専門性が低く見える
→
✅ "The root cause was a memory leak introduced in the v2.4.1 deploy."
❌ アクションアイテムを "We will try to improve our monitoring system in the near future."
"try to"・"near future" は曖昧。いつ・誰が・何をするかが不明で行動アイテムとして機能しない
→
✅ "Lower the memory alert threshold to 70% — owner: Kevin, by this Friday."
❌ タイムラインを長文段落で説明する: "At around 10:45, we started to see that there were some errors occurring in the payment service, and then..."
段落形式はスキャンできない。聴衆が追いにくく、スライドに映らない
→
✅ 時刻 + 1〜2文の箇条書き形式
❌ 発表を "That's all. Thank you." で締める
一方的に終わる。対話を促さず、聴衆が質問を持っても入り込む隙がない
→
✅ "Any questions before we dig into the details?" で対話を促す

ワンランク上の表現（Phase 3 以降）

Basic
"Last week we had a problem. The payment service stopped working because of a bug. We fixed it and will improve the monitoring."
↓ B2 レベルでは
B2
Last Tuesday, we had a P1 outage affecting checkout for ~40 minutes. Root cause: memory leak in v2.4.1. Key actions: lower alert threshold (Kevin/Friday), add load testing to deploy checklist (me/next week), introduce canary deploys (Q3). This is a blameless review — let's learn from it.
↓ C1 レベルでは（定量化 + 優先順位の根拠を加える）
C1
To quantify the impact: we estimate roughly $8,000 in lost GMV and affected approximately 1,200 checkout sessions over a 40-minute window. Of the three action items, I'd prioritize the memory alert threshold change — it's a 30-minute fix with the highest ROI in terms of preventing recurrence. The canary deployment initiative is higher effort and will require a separate scoping discussion, which Alex and I will kick off this week. Everything else here is a system failure, not a people failure — and that's the lens I want us to apply as we dig into the details.

※ C1表現のポイント: ① 影響を金額・件数で定量化 ② アクションの優先順位に根拠（ROI）を添える ③ "system failure, not a people failure" で blameless 文化を言語化する

次のステップ

  • 発展: ポストモーテム発表後のQ&Aセッションで技術的質問に英語で答える（Meeting × Engineering）
  • さらに発展: ポストモーテムドキュメントを英語で書いて GitHub に PR する（Report × Engineering）
  • 次回予告: Day 059 — Report × Engineering（Phase 2）

自己評価（解いた後に記入）

理解度

自分の回答

冒頭スピーチ全文（200〜300語）

気づき・メモ