シナリオ
あなたはグローバルECプラットフォーム「ShopWave」の SRE（日本拠点）。昨日の Operations Review ミーティング（Day 044）では月次実績を口頭で報告したが、今日はその内容を 書面レポート（英語） にまとめて社内Wikiに投稿する必要がある。
対象読者はエンジニアリングマネージャー・VP of Operations・他拠点のSREチーム。読み手が多忙であるため、「何が起きたか」「どう対応したか」「次に何をするか」を3分以内で把握させることが求められる。
あなた
ShopWave SRE（日本拠点）
月次運用サマリレポートの起票担当 · 英語 B1
読者 1
David Cohen
VP of Operations（US本社）· 数字と再発防止を重視
読者 2
Priya Sharma
Regional Ops Lead（India）· 結論と「次の一手」を求める
文化的コンテキスト
BLUF原則
Bottom Line Up Front — 英語の技術ドキュメントは結論を先頭に。エグゼクティブサマリーだけ読めば全体がわかる構造にする
Bottom Line Up Front — 英語の技術ドキュメントは結論を先頭に。エグゼクティブサマリーだけ読めば全体がわかる構造にする
Blameless 文化
英語のインシデントレポートは「誰が悪いか」ではなく「何が起きたか・なぜか・次に何をするか」にフォーカスする
英語のインシデントレポートは「誰が悪いか」ではなく「何が起きたか・なぜか・次に何をするか」にフォーカスする
数字は文脈とセット
"99.4%" 単体ではなく「目標 99.5% に対して」と並べることで良し悪しが即座に伝わる
"99.4%" 単体ではなく「目標 99.5% に対して」と並べることで良し悪しが即座に伝わる
Action Items に Owner + Due Date
「誰がいつまでに何をするか」が不明なAction Itemsは対応されない。必ず担当者と期限を明記
「誰がいつまでに何をするか」が不明なAction Itemsは対応されない。必ず担当者と期限を明記
タスク
May 2026 Operations Summary
📌 Executive Summary
[ここに2〜3文のサマリを書く]
📊 Key Metrics
| Metric | Target | Actual | Status |
|---|---|---|---|
| Uptime | 99.5% | ? | ? |
| Major Incidents | 0 | ? | ? |
| MTTR | <30 min | ? | ? |
🔥 Incident Summary
[発生日時・根本原因・対応・影響範囲・復旧時間を記載]
✅ Action Items
[Owner + Due Date 付きで記載]
🎯 Next Month Goals
[来月の目標を記載]
上記ドキュメントの空白セクションをすべて英語で埋めなさい
以下のデータを使用すること:
- 対象期間: May 2026
- 稼働率: 99.4%（目標 99.5%）
- メジャーインシデント: 1件（決済API 20分障害・5月2日発生）
- MTTR（平均復旧時間）: 20分
- 根本原因: キャッシュ設定のミスコンフィグレーション
- 対応済み: ✅（設定修正・自動アラート強化）
- 再発防止策: configレビューのCI/CDパイプライン組み込み・監視アラートのしきい値見直し
- 次月目標: 99.5%以上の稼働率維持・同種インシデントゼロ
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
全体的に〇〇な月でした
クリックで英語を表示 →
Overall, May was a broadly stable month.
💡 "broadly stable" は「全体的に安定していた」。"good" より客観的で技術文書向き
目標をわずかに下回った
クリックで英語を表示 →
coming in just shy of our 99.5% target
💡 "missed" より柔らかく正直。"fell short of" でも可
影響範囲は〜のみ
クリックで英語を表示 →
Blast radius: payment API only
💡 "Blast radius" はインシデント管理の標準用語。影響が限定的であることを強調できる
完全に復旧した
クリックで英語を表示 →
Fully resolved within 20 minutes
💡 "within" で復旧の速さを示す。過去完了 "has been resolved" でも安心感を伝えられる
根本原因は〜でした
クリックで英語を表示 →
Root cause: misconfigured cache settings
💡 "Root cause:" ラベルで始める記法はPostmortemの標準。RCA（Root Cause Analysis）の略も使われる
〜をCI/CDに組み込む
クリックで英語を表示 →
Integrate X into the CI/CD pipeline
💡 再発防止策でよく使う技術的表現。"add X to" より明確
担当者・期限の記法
クリックで英語を表示 →
Owner: [Name] · Due: [Date]
💡 Action Itemsの国際標準フォーマット。Jiraチケット番号を添えることも多い
SLA内で対応した
クリックで英語を表示 →
Within SLA
💡 SLA = Service Level Agreement。ステークホルダーへの安心感を与える表現
ヒント（段階的開示）
ヒント 1 — 構成・方向性
英語の運用レポートは 「エグゼクティブサマリー（2〜3文）→ Key Metrics 表 → Incident Summary（事実ベース）→ Action Items（Owner + Due付き）→ Next Month Goals」 の流れが基本。エグゼクティブサマリーだけで90%の情報が得られる構造にすることが重要。謝罪よりも事実・対策・次のアクションを優先する。
ヒント 2 — キーフレーズ・表現
- Executive Summary 書き出し:
"May 2026 was a broadly stable month for ShopWave operations." - 目標比の正直な記述:
"We maintained 99.4% uptime, coming in just shy of our 99.5% target." - インシデントと対応:
"We experienced one major incident — a 20-minute outage on the payment API. Root cause has been fully addressed." - Action Items:
"[ ] Integrate config validation into CI/CD pipeline · Owner: Daichi · Due: Jun 6"
ヒント 3 — 骨格テンプレート
Executive Summary
May 2026 was [全体評価]. We maintained [稼働率] uptime, coming in just shy of our [目標] target. We experienced one major incident: [概要] — [対応状況].
Key Metrics
| Metric | Target | Actual | Status |
| Uptime | 99.5% | ? | ⚠️ / ✅ |
| Major Incidents | 0 | ? | ❌ / ✅ |
| MTTR | <30 min | ? | ✅ Within SLA |
Incident Summary
- Date: May 2, 2026 · Duration: 20 min
- Blast radius: payment API only
- Root cause: [原因]
- Resolution: [対応内容]
Action Items
- [ ] [対応] · Owner: [Name] · Due: [Date]
May 2026 was [全体評価]. We maintained [稼働率] uptime, coming in just shy of our [目標] target. We experienced one major incident: [概要] — [対応状況].
Key Metrics
| Metric | Target | Actual | Status |
| Uptime | 99.5% | ? | ⚠️ / ✅ |
| Major Incidents | 0 | ? | ❌ / ✅ |
| MTTR | <30 min | ? | ✅ Within SLA |
Incident Summary
- Date: May 2, 2026 · Duration: 20 min
- Blast radius: payment API only
- Root cause: [原因]
- Resolution: [対応内容]
Action Items
- [ ] [対応] · Owner: [Name] · Due: [Date]
モデル解答（B2〜C1相当）
完成版 — May 2026 Operations Summary
May 2026 Operations Summary
Period: May 1–31, 2026 · Prepared by: Daichi Kainuma (SRE, Japan)
📌 Executive Summary
May 2026 was a broadly stable month for ShopWave infrastructure. We maintained 99.4% uptime, coming in just shy of our 99.5% target due to one major incident early in the month. The incident has been fully resolved, root cause identified, and additional safeguards have been implemented to prevent recurrence.
📊 Key Metrics
| Metric | Target | Actual | Status |
|---|---|---|---|
| Uptime | 99.5% | 99.4% | ⚠️ Slightly below target |
| Major Incidents | 0 | 1 | ❌ |
| MTTR | < 30 min | 20 min | ✅ Within SLA |
🔥 Incident Summary: Payment API Outage
Date: May 2, 2026 · Duration: 20 minutes
Blast radius: Payment API only — order-service and other APIs unaffected
Root cause: Misconfigured cache settings introduced in the May 1st deployment
Detection: Automated alert triggered at T+2 min; on-call engineer paged immediately
Resolution: Cache configuration corrected; service fully restored within 20 minutes
✅ Action Items
[ ] Integrate config validation into the CI/CD pipeline · Owner: Daichi · Due: Jun 6
[ ] Lower alerting threshold on payment API error rate (5% → 1%) · Owner: Liam Nguyen · Due: Jun 13
[ ] Add "cache config changes" to the deployment checklist · Owner: Team · Due: Jun 6
🎯 Next Month Goals
• Maintain ≥ 99.5% uptime in June
• Zero repeat incidents of config-related outages
• Complete all action items from this report
解説
構成分析
1
Executive Summary（2〜3文）: BLUF原則の核。全セクションを読まなくてもここだけで「良かった点・悪かった点・対応済み」が把握できる。多忙なVP・マネージャーはこのセクションだけ読む想定で設計する。
2
Key Metrics 表: 数字は必ず目標値とセットで並べる。Status 列の ✅ / ⚠️ / ❌ で視覚的に良し悪しを即座に伝える。表形式は文章より速く読める。
3
Incident Summary: 事実を時系列・箇条書きで記載。Blameless（誰が悪いかではなく何が起きたか）の原則に従い、"Root cause:" ラベルで原因を明示する。Blast radius（影響範囲）を明記することで「最小限の被害だった」という安心感を与える。
4
Action Items: Owner（担当者）+ Due Date（期限）を必ず付ける。チェックボックス
[ ] で進捗を視覚化。「誰がいつまでに何をするか」が明確でないAction Itemsは実行されない。
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
broadly stable | 「全体的に安定していた」。客観的な評価語で技術文書向き |
just shy of our target | 目標未達を柔らかく・正直に言う。"missed" より穏やか |
Blast radius | インシデントの影響範囲。影響が限定的だと示す標準用語 |
Root cause: | Postmortemの標準ラベル記法。RCA（Root Cause Analysis）の核 |
fully restored within 20 minutes | 復旧の速さを "within" で強調。SLA達成を示す |
Owner: X · Due: Y | Action Itemsの国際標準フォーマット。実行責任を明確化 |
文化的ポイント
Blameless Postmortem文化
英語圏の技術組織では「誰が悪いか」を追求せず「何が起きたか・なぜか・再発防止は何か」にフォーカスする。日本の障害報告書と根本的に異なる
英語圏の技術組織では「誰が悪いか」を追求せず「何が起きたか・なぜか・再発防止は何か」にフォーカスする。日本の障害報告書と根本的に異なる
BLUF（Bottom Line Up Front）
結論を最初に書く。エグゼクティブサマリーで全体把握できる構造が英語圏の標準。日本語の「まず背景説明→最後に結論」とは逆の順序
結論を最初に書く。エグゼクティブサマリーで全体把握できる構造が英語圏の標準。日本語の「まず背景説明→最後に結論」とは逆の順序
謝罪より事実と対策
「多大なご迷惑をおかけしました」ではなく「Root cause identified, safeguards in place」が英語運用文書の基本。謝罪より次のアクションを優先する
「多大なご迷惑をおかけしました」ではなく「Root cause identified, safeguards in place」が英語運用文書の基本。謝罪より次のアクションを優先する
よくある日本人のミス
❌ "We are very sorry for the inconvenience caused by the outage."
謝罪が前面に出ると対応より責任問題にフォーカスが移る
→
✅ "Root cause has been fully addressed. Safeguards are in place."
❌ Action Itemsに期限・担当者なし: "- Fix the alert configuration"
誰がいつやるか不明なので実行されない
→
✅ "[ ] Lower alert threshold · Owner: Liam · Due: Jun 13"
❌ "The uptime was 99.4%."
目標値がないと良いのか悪いのか読み手が判断できない
→
✅ "We maintained 99.4% uptime — just shy of our 99.5% target."
❌ "There was a problem with the payment system."
曖昧で深刻さも対応状況も伝わらない
→
✅ "Root cause: misconfigured cache settings · Duration: 20 min · Blast radius: payment API only"
❌ 全文を散文（paragraph）だけで書く
読むのに時間がかかる。多忙な読者が途中で止める
→
✅ 表・箇条書き・ラベル記法（"Root cause:" / "Blast radius:"）を活用して構造化する
ワンランク上の表現（Phase 2 以降）
Basic
"May report. Uptime was 99.4%. There was an outage. We fixed it."
↓ BLUF + 構造化ドキュメントにすると
B2
"May was broadly stable: 99.4% uptime, just shy of target. One P1 incident (20-min payment outage) — resolved, safeguards in place. Action items with owners and due dates attached."
↓ Postmortem / SRE 標準の書き方では
C1
"## TL;DR — May 2026 was within normal operating range. One P1 incident (payment API, 20-min blast radius limited to checkout flow) — contributing factor: config drift introduced in the May 1 deploy. Remediation: config validation gating added to CI; error-budget impact: 8.6% of monthly budget consumed."
"TL;DR" (Too Long; Didn't Read)
（インシデントレポートの冒頭に置く1〜2文のサマリ。エグゼクティブへの配慮を示す最上級のBLUF表現）
"config drift introduced in the May 1 deploy"
（config drift = 設定の意図せぬ変化。SRE/インフラの専門用語で、"misconfiguration" より根本的な原因を示す）
"error-budget impact: 8.6% of monthly budget consumed"
（error budget = SLOに基づく許容エラー量。SRE組織での標準的なインシデント影響評価指標。"99.4% uptime" をエラーバジェット消費量で表現する）
"config validation gating added to CI"
（gating = CI/CDパイプラインでチェックを通過しないと次に進めないようにする仕組み。"Integrate into CI/CD" より具体的なC1表現）
次のステップ
- 発展: このレポートをもとに David から「このインシデントは他のAPIでも起きる可能性があるか？」と質問が来た場合のメール返信（Email × Operations）を書く
- 次回（Day 046）: Conversation × Legal — 次のweek（week_index 7）へ進み、法務・コンプライアンス分野での1on1会話を練習
自己評価（解いた後に記入）
理解度
自分の回答
自分が書いた月次運用サマリレポート（全文）