シナリオ
あなたはECサイトのデータエンジニアです。昨日、本番の商品レコメンデーション用データパイプラインが3時間停止するインシデントが発生しました。原因調査が完了し、今日の午後にポストモーテム（障害振り返り）レポートを英語でチームに共有します。
あなた
Data Engineer
今日の学習者ロール
宛先
Engineering team
US/JP混成チーム · 技術者向け
文化的コンテキスト
結論ファースト（BLUF原則）
英語の技術文書は最初にインパクトと原因を簡潔に述べ、詳細を後に続ける
英語の技術文書は最初にインパクトと原因を簡潔に述べ、詳細を後に続ける
目的
インシデントの事実・原因・再発防止策を明確に伝える
インシデントの事実・原因・再発防止策を明確に伝える
タスク
以下の情報をもとに、Post-Incident Summary（障害サマリー）ドキュメントを英語で書いてください。
インシデント情報
- 発生日時: April 16, 2026 14:30 JST
- 復旧日時: April 16, 2026 17:45 JST（停止時間: 約3時間15分）
- 影響範囲: Product recommendation pipeline — レコメンド機能がダウン → 推定 CTR 低下 18%
- 原因: BigQueryのスキーマ変更（新カラム追加）に伴い、dbtモデルがNULLエラーで失敗
- 対応: dbtモデルのNULLハンドリングを修正し、パイプラインを手動再実行
- 再発防止1: スキーマ変更時のdbtモデル影響チェックをCI/CDに組み込む
- 再発防止2: パイプライン失敗時のSlackアラートのレイテンシを現在の30分→5分に短縮
必要な構成
- Incident Summary (2〜3行): 何が起きたか・影響を端的に
- Root Cause (2〜3行): 技術的な原因を説明
- Timeline (箇条書き): 発生→検知→対応→復旧の時系列
- Action Items (箇条書き): 再発防止策と担当者・期限
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
〜が停止した
クリックで英語を表示 →
... went down / ... was unavailable
💡 "went down" はカジュアル、"was unavailable" はフォーマル
約〜時間
クリックで英語を表示 →
approximately X hours / ~X hours
💡 レポートでは "approximately" の方が正確な印象
原因は〜
クリックで英語を表示 →
The root cause was ... / This was caused by ...
💡 "root cause" は技術文書の必須表現
影響を与えた
クリックで英語を表示 →
impacted / affected
💡 "impacted" は結果に重点、"affected" は対象に重点
再発防止
クリックで英語を表示 →
to prevent recurrence / to prevent this from happening again
💡 短くするなら "to prevent recurrence"
〜に組み込む
クリックで英語を表示 →
integrate ... into / incorporate ... into
💡 CI/CDに組み込む → integrate checks into CI/CD
アクションアイテム
クリックで英語を表示 →
action items / follow-up actions
💡 技術チームでは "action items" が一般的
ヒント（段階的開示）
ヒント 1 — 構成・方向性
冒頭の "Incident Summary" はこのレポートで最も重要。「何が・いつ・どのくらい影響したか」を1〜2文でまとめる。読み手がここだけ読んでも全体像が分かるように。
ヒント 2 — キーフレーズ・表現
Root Cause の例:
A schema change in BigQuery introduced a new column, which caused dbt models to fail with a NULL error.
Action Items では Owner: [名前], Due: [日付] の形式が実務標準
ヒント 3 — 骨格テンプレート
ドキュメントの骨格：
## Incident Summary
[2-3 sentences: what happened, duration, business impact]
## Root Cause
[2-3 sentences: technical explanation]
## Timeline
- 14:30 JST: [event]
- 15:00 JST: [event]
...
## Action Items
- [ ] [Action] | Owner: [Name] | Due: [Date]
[2-3 sentences: what happened, duration, business impact]
## Root Cause
[2-3 sentences: technical explanation]
## Timeline
- 14:30 JST: [event]
- 15:00 JST: [event]
...
## Action Items
- [ ] [Action] | Owner: [Name] | Due: [Date]
モデル解答（B1〜B2相当）
### Incident Summary
On April 16, 2026, the product recommendation pipeline was unavailable for approximately 3 hours and 15 minutes (14:30–17:45 JST). This outage impacted the recommendation feature on the site, resulting in an estimated 18% drop in click-through rate during the affected period.
### Root Cause
A schema change in BigQuery — specifically, the addition of a new column — caused downstream dbt models to fail with NULL errors. The pipeline was not designed to handle unexpected NULL values in this column, and no automated validation caught the issue before it reached production.
### Timeline
- **14:30 JST**: Pipeline failure detected via Datadog alert (30-minute delay from actual failure at ~14:00)
- **14:45 JST**: Engineer began investigation; identified dbt model NULL error
- **15:30 JST**: Root cause confirmed — BigQuery schema change from earlier that day
- **16:00 JST**: Fix applied to dbt model (added COALESCE handling for NULL values)
- **17:45 JST**: Pipeline manually re-run and confirmed healthy; recommendation feature restored
### Action Items
- [ ] Integrate dbt model impact checks into CI/CD for all BigQuery schema changes | Owner: Team | Due: May 1, 2026
- [ ] Reduce pipeline failure alert latency from 30 minutes to 5 minutes in Datadog | Owner: Daishi | Due: April 24, 2026
解説
構成分析
1
Incident Summary: "was unavailable for approximately 3h15m" → 停止時間を正確に記載。"resulting in an estimated 18% drop" → ビジネスインパクトを数値で。
2
Root Cause: "A schema change ... caused ... to fail with NULL errors" → 原因→結果の構造。"no automated validation caught the issue" → 防げたはずの問題という自己批判も含める（post-mortem文化）。
3
Timeline: 過去形の時刻 + 動詞の組み合わせ。技術文書では箇条書きが読みやすい。
4
Action Items:
[ ] チェックボックスで「まだ未完了」を示す。Owner と Due が必須。
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
was unavailable | "broke" より技術文書向き |
downstream | BIエンジニア文脈で「下流の（依存している）」モデルのこと |
COALESCE | SQLの関数名。技術文書では略さず書く |
confirmed healthy | システムが正常であることを確認した、の定番表現 |
文化的ポイント
blame-free（責任を問わない）
「誰がミスしたか」ではなく「システムや仕組みに何が足りなかったか」にフォーカスする。"no automated validation caught the issue" はこのアプローチの典型表現。
「誰がミスしたか」ではなく「システムや仕組みに何が足りなかったか」にフォーカスする。"no automated validation caught the issue" はこのアプローチの典型表現。
よくある日本人のミス
❌ タイムラインを全部文章で書く
箇条書きに慣れていない
→
✅ 時刻 + 短い説明の箇条書きが英語技術文書の標準
❌ "Action Items" がない、または "We should..." で終わる
抽象的な対策
→
✅ 担当者・期限を必ず入れる
❌ "I'm sorry for the trouble." を冒頭に書く
日本語の謝罪文化
→
✅ 英語のインシデントレポートは事実記述が中心。謝罪より再発防止を強調
ワンランク上の表現（Phase 2 以降）
Basic
"The root cause was a schema change."
↓ インシデント文脈では
B2
"The failure was traced back to a schema migration."（trace back to = 原因を特定する）
↓ さらに上のレベルでは
C1
"mitigated at 17:45 JST"（"fixed" より "mitigated" がよりプロフェッショナル）
"This is a known failure mode"
（既知の問題であることを示す表現。責任回避ではなく現実的な文脈確認）
次のステップ
- 発展: より複雑なマルチチームインシデント（原因が複数・関係者が多い）の対応レポートを書く
- 次回（Day 005）: 1on1/会話 × Engineering — コードレビューのフィードバックを伝える
自己評価（解いた後に記入）
理解度
自分の回答
Post-Incident Summary