シナリオ
Meeting × Engineering とは
スプリントレトロスペクティブ・インシデントレビュー・テクニカルデザインレビューなど、エンジニアチームの会議で英語をファシリテートする場面。感情的な議論を建設的な方向に変換し、具体的なアクションを引き出す力が求められる。
今日のシナリオ
あなた（シニアエンジニア）はアジャイルチームのスプリントレトロスペクティブをファシリテートしている。今スプリントは本番バグが7件発生し、そのうち3件がユーザーに影響した。QAエンジニアのPriyaとフロントエンドエンジニアのLiamが「レビューが甘い」「テストが不十分」と互いに責め始めている。blame game（責任の押し付け合い）を止め、建設的な改善議論に戻す必要がある。
文化的コンテキスト
アジャイルチームでは "Everyone did the best job they could, given what they knew" が出発点。個人の失敗ではなく「プロセスのどこに問題があったか」を問うのが正しいフレーム
英語圏のファシリテーターは意見を押しつけず「問い」で議論を動かす。"What do you think?" "What does the data tell us?" のように問いで終わると場の主体性を保てる
欧米アジャイルチームでは、レトロで合意したアクションアイテムは必ずSlack・Jira・Confluenceに記録する。"I'll send this in Slack" は口約束を書面に変える重要な発言
タスク
以下の3つの会議場面それぞれに対して、自然なビジネス英語の発言（3〜5文）を書け。ファシリテーターとして中立を保ちながら、チームの議論を前向きな方向に導くこと。
"Liam's PRs always skip edge cases. If the code review was done properly, we wouldn't have had these bugs."
"That's not fair — QA approved those tickets. If you'd caught it in testing, it wouldn't have gone to production."
→ 両者の感情を認めつつ、blame game を止めてプロセス・システムの問題として議論を再定義せよ。
"I think the root cause is that our code review process is just too relaxed. We need stricter reviews."
→ 「コードレビューが甘い」という表面的な原因の一段下を掘り下げる発問をせよ。データを使い、構造的な問題特定に向けてチームを誘導すること。
"I like the idea of a PR checklist and more test coverage requirements. But someone needs to actually own it."
→ 合意に向けて「番号 + アクション + オーナー + 期限」の形式でアクションアイテムを3点提示し、書面化を宣言して会議をクローズせよ。
Meeting × Engineering 必須語彙
カードをクリックすると日本語訳と例文を表示します。
ヒント（段階的開示）
ヒント 1 — 構成・方向性
- 場面 A: 両者の感情を認める（共感）→ "I want to pause here" でファシリテーターとして介入 → "process issue, not a people issue" でフレーム転換 → 問いで終わり場の主体性を返す
- 場面 B: "code review is one factor" と一旦受け取る → "dig one level deeper" で根本に向かう → データ（7件・3件）で客観化 → "systemic issue" という言葉を使ってパターン特定の議論に誘導
- 場面 C: "Before we close, let's align" でクロージングを宣言 → 「番号 + アクション + オーナー + 期限」で3点列挙 → 同意確認 → "I'll send this in Slack" で書面化
ヒント 2 — キーフレーズ
"I want to pause here — let's take a step back and look at this as a process issue, not a people issue.""If we look at the seven bugs, is there a pattern in where they were introduced — rushed tickets, unclear acceptance criteria, or test coverage gaps?""Before we close, let's align on three concrete action items. One: [action, owner, date]. Two: ... Three: ... I'll post this in Slack by end of today."
ヒント 3 — 骨格
場面 A 骨格:
場面 B 骨格:
場面 C 骨格:
モデル解答
"Liam's PRs always skip edge cases. If the code review was done properly, we wouldn't have had these bugs."
"That's not fair — QA approved those tickets. If you'd caught it in testing, it wouldn't have gone to production."
"I hear the frustration on both sides — and honestly, it makes sense given the week we've had. I want to pause here: let's take a step back and frame this as a process issue, not a people issue. The question I'd like us to focus on isn't who dropped the ball, but rather what in our pipeline allowed seven bugs to reach production, three of which hit real users. Can we hold that question together for the next few minutes?"
"I think the root cause is that our code review process is just too relaxed. We need stricter reviews."
"Code review is definitely one factor — let's dig one level deeper. When we look at those seven bugs, is there a pattern in where they were introduced? For instance, were most of them in areas that had recent refactors, or in features that were rushed to meet the sprint deadline? If we can identify the systemic issue — whether it's review bandwidth, unclear acceptance criteria, or test coverage gaps — we'll get to a fix that prevents the next seven bugs, not just these ones. What does the data tell us?"
"I like the idea of a PR checklist and more test coverage requirements. But someone needs to actually own it."
"Totally agree — ownership is everything. This has been a really honest conversation, and I appreciate everyone's candor. Before we close, let's align on three concrete action items for next sprint.
-
1Priya drafts a PR checklist with minimum test coverage requirements — by Wednesday. Liam and I review it by EOD Thursday.
-
2We add a 15-minute 'bug pattern review' slot at the start of every sprint planning — the whole team owns this, starting next sprint.
-
3Any ticket touching the payment module requires two reviewers instead of one, starting next Monday.
Does anyone see any gaps, or want to adjust the owners? I'll post this in Slack by end of today — no surprises. Great sprint everyone — let's make the next one even cleaner."
解説
構成分析
"I hear the frustration on both sides" で両者を否定せず、防衛反応を下げる。"I want to pause here" はファシリテーターとしての権限を行使する宣言。核心は "process issue, not a people issue" — このリフレーミングが blame game をシステム思考に変える転換点。最後を問いで終えることでチームの主体性を保つ。
"Code review is definitely one factor" で相手の意見を一旦受け取り（否定しない）、"dig one level deeper" で5 Whys的な思考に誘導。パターン分析の問いかけ（「どの領域に集中しているか」）でデータドリブンな議論に転換。"systemic issue" という言葉でインシデントを個人の失敗から構造的問題に再定義する。
"This has been a really honest conversation" でレトロの価値を認めてチームモラルを上げる。アクションアイテムは「番号 + アクション + オーナー + 期限」の5点セット。"Does anyone see any gaps?" で最後に合意確認し、"I'll post this in Slack" で書面化を宣言して口約束を残さない。
重要表現
| 英語表現 | 日本語 | ポイント |
|---|---|---|
take a step back | 一歩引いてみる | 過熱した議論をリセットするファシリテーターの定番 |
process issue, not a people issue | 人でなくプロセスの問題 | blame game からの脱出フレーム。チームへの信頼を示す |
dig one level deeper | もう一段掘り下げる | 5 Whysの精神を会話で体現する |
systemic issue | 構造的問題 | 再発防止の議論に向かうキーワード |
align on three concrete action items | 具体的な3つのアクションに合意する | クロージングの定型フレーズ |
no surprises | 予期せぬことはない | 信頼構築の一言。英語ビジネスで頻用 |
文化的ポイント
アジャイルの世界では "Everyone did the best job they could, given what they knew" が出発点。"Who's fault is it?" ではなく "What allowed this to happen?" と問うのが正しいファシリテーター像
英語圏のファシリテーターは自分の意見を押しつけず「問い」で場を進める。"What does the data tell us?" "Does anyone see any gaps?" のように問いで終わるとチームの主体性が高まる
欧米アジャイルでは "we should do X" より "Priya owns X by Wednesday" が好まれる。責任が曖昧なアクションは実行されない。ファシリテーターの仕事はこれを引き出すこと
よくある日本人のミス
ワンランク上の表現（Phase 3 以降）
次のステップ
- 発展: レトロ後、今日合意した3つのアクションアイテムをSlackに150字以内で投稿する（Chat × Engineering）
- 次回（水曜）: Chat × Engineering — オンコール中のインシデント対応をSlackでコーディネートする