シナリオ
あなたはグローバルECプラットフォーム「ShopWave」の SRE エンジニア（Daichi Kainuma）。先日の1on1でマネージャーの Marcus Webb にアラート改善プランを提案し、「水曜に提案書を見せてくれ」という承認を得た（Day 046の続き）。
提案書を提出したところ、Marcus からは「内容はいい。ただ本番への展開スコープについてインフラチームリードの Priya Nair と合意を取ってほしい」と言われた。
あなたの立場
全8サービスに同時展開
設定変更のみ・コード変更なし → blast radius は小さい
⟷
Priyaの立場
まず1サービスでパイロット（2週間）
安定性最優先 → system-wide incident を避けたい
あなた
Daichi Kainuma（SRE）
アラート改善の迅速な展開を目指す · Win-Win の妥協点を見つけたい · 英語 B1-B2
交渉相手
Priya Nair
インフラチームリード（Bangalore）· 安定性最優先 · 慎重派 · 否定ではなくリスクを減らしたいだけ
交渉のコンテキスト
Win-Win フレームワーク
英語圏の交渉では「どちらかが負ける」ではなく「両者にとって最善の結果」を目指すのが基本。強引に押し通すのではなく "middle ground" を提案する姿勢が重要
英語圏の交渉では「どちらかが負ける」ではなく「両者にとって最善の結果」を目指すのが基本。強引に押し通すのではなく "middle ground" を提案する姿勢が重要
データと条件で交渉する
感情や立場ではなく「なぜ安全か」をデータで示す。ロールバック基準（go/no-go criteria）を明示することで相手の懸念を具体的に解消できる
感情や立場ではなく「なぜ安全か」をデータで示す。ロールバック基準（go/no-go criteria）を明示することで相手の懸念を具体的に解消できる
相手の懸念を正当化する
"Totally fair" "I completely understand" で相手の懸念を否定せず受け入れることで対立を避ける。「あなたは間違っている」ではなく「共に解決策を見つけよう」という姿勢
"Totally fair" "I completely understand" で相手の懸念を否定せず受け入れることで対立を避ける。「あなたは間違っている」ではなく「共に解決策を見つけよう」という姿勢
具体的なコミットメントを示す
曖昧な合意より「条件付き合意」が信頼を生む。"if MTTA spikes, we roll back immediately" のように具体的な条件と行動を明示する
曖昧な合意より「条件付き合意」が信頼を生む。"if MTTA spikes, we roll back immediately" のように具体的な条件と行動を明示する
タスク
P
Priya Nair
"Thanks for sharing the proposal, Daichi. The plan looks solid. My concern is rolling this out to all eight services at once — if something goes wrong, we'd be dealing with a system-wide incident. What if we start with just one low-traffic service, monitor it for two weeks, and then expand from there?"
D
Daichi (あなた)
あなたの返答をここに書いてください。以下の4要素をすべて含めること:
1. Priyaの懸念への共感・理解を示す
2. 自分のオリジナル提案（全展開）の根拠を示す
3. 妥協案（3サービス ＋ ロールバック基準など）を提示する
4. 次のステップを提案して合意を求める
1. Priyaの懸念への共感・理解を示す
2. 自分のオリジナル提案（全展開）の根拠を示す
3. 妥協案（3サービス ＋ ロールバック基準など）を提示する
4. 次のステップを提案して合意を求める
上記4要素を盛り込んで英語で返答しなさい（Win-Win の妥協案を中心に）
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
懸念はよくわかります
クリックで英語を表示 →
I completely understand your concern.
💡 共感の第一声。"I hear you" や "Totally fair" でもよい。防御に入らず即座に受け入れることが重要
段階的展開
クリックで英語を表示 →
phased rollout
💡 インフラ・DevOpsの標準用語。"pilot deployment" や "canary release" も使える
ロールバック基準 / 中止基準
クリックで英語を表示 →
rollback criteria / abort threshold / go/no-go criteria
💡 問題発生時に戻す判断基準。明示することで「感覚で判断しない」安心感を与える
障害の影響範囲
クリックで英語を表示 →
blast radius
💡 DevOps/SRE標準用語。障害が広がりうる範囲を指す。"impact scope" より技術的で正確
中間的な妥協案として
クリックで英語を表示 →
How about this as a middle ground: …
💡 妥協案を提示する典型フレーズ。"compromise" より柔らかく、Win-Win を目指す姿勢が伝わる
設定変更のみ（コード変更なし）
クリックで英語を表示 →
config-level changes only — no code changes involved
💡 変更の範囲を限定して安全性を示す表現。"it's just a config change" より技術的に正確
適切なバランスが取れていますか？
クリックで英語を表示 →
Does that strike a reasonable balance between speed and caution?
💡 交渉のクロージングとして洗練された表現。"Do you agree?" より Win-Win の姿勢が伝わる
書面で明示することもできます
クリックで英語を表示 →
I'm happy to put the rollback criteria in writing before we kick off.
💡 書面化を申し出ることで信頼感と透明性を高める。"put X in writing" = 書面に残す
ヒント（段階的開示）
ヒント 1 — 構成・方向性
交渉の基本構造は「共感 → 自分の立場の説明 → 妥協案 → 合意確認」の4ステップ。Priyaを説得しようとするのではなく、一緒に「最善策を見つける」姿勢が重要。"I understand your concern, and here's what I propose" のように橋渡しをする。妥協案は具体的な数字（サービス数・期間・基準）を必ず含める。
ヒント 2 — キーフレーズ・表現
- 共感:
"Totally fair — a system-wide incident is the last thing either of us wants." - 自分の根拠:
"The changes are config-level only — no code changes involved. The blast radius is more limited than it might look." - 妥協案の前置き:
"I don't want to push through something you're not comfortable with." - 妥協案:
"How about this as a middle ground: we start with three services — including our two highest-traffic ones — and define explicit go/no-go criteria upfront." - 合意確認:
"Does that strike a reasonable balance between speed and caution?"
ヒント 3 — 骨格テンプレート
1. 共感（Acknowledge）
"Totally fair / I completely understand — [Priyaの懸念を言葉で受け止める]."
2. 根拠（Rationale）
"The reason I proposed all eight: config-level only / no code changes → blast radius limited."
3. 妥協案（Middle ground）
"That said, I don't want to push through something you're not comfortable with.
→ Start with 3 services (incl. highest-traffic ones)
→ Define go/no-go criteria upfront
→ If MTTA spikes / missed incidents → roll back immediately
→ After 7 days, proceed to remaining 5"
4. 合意確認（Close）
"Does that strike a reasonable balance? Happy to put the criteria in writing."
"Totally fair / I completely understand — [Priyaの懸念を言葉で受け止める]."
2. 根拠（Rationale）
"The reason I proposed all eight: config-level only / no code changes → blast radius limited."
3. 妥協案（Middle ground）
"That said, I don't want to push through something you're not comfortable with.
→ Start with 3 services (incl. highest-traffic ones)
→ Define go/no-go criteria upfront
→ If MTTA spikes / missed incidents → roll back immediately
→ After 7 days, proceed to remaining 5"
4. 合意確認（Close）
"Does that strike a reasonable balance? Happy to put the criteria in writing."
モデル解答（B2〜C1相当）
交渉返答 — Daichi → Priya
Win-Win の着地点
3サービス（高トラフィック2件含む）+ go/no-go基準 + 1週間モニタリング → 残り5サービスへ展開
P
Priya Nair
"Thanks for sharing the proposal, Daichi. The plan looks solid. My concern is rolling this out to all eight services at once — if something goes wrong, we'd be dealing with a system-wide incident. What if we start with just one low-traffic service, monitor it for two weeks, and then expand from there?"
D
Daichi (モデル解答)
"Totally fair, Priya — a system-wide incident is the last thing either of us wants. I completely understand the concern.
The reason I originally proposed all eight services is that these changes are config-level only — we're tuning thresholds and adding silencing rules, with no code changes involved. The blast radius is more limited than it might look. That said, I don't want to push through something you're not comfortable with.
How about this as a middle ground: we start with three services — I'd suggest including our two highest-traffic ones, since that's where the alert noise is worst and the value will be clearest. We define explicit go/no-go criteria upfront: if we see any increase in missed incidents or a spike in MTTA during the first week, we pause and roll back immediately. If the numbers look good after seven days, we proceed to the remaining five.
That way we're not going too slowly to lose momentum, but we also have a clear safety net. Does that strike a reasonable balance between speed and caution? I'm happy to put the rollback criteria in writing before we kick off."
解説
構成分析
1
共感（Acknowledge）: "Totally fair" で即座に相手の懸念を正当化。防御に入らず受け入れることで「対立ではなく協力」の空気を作る。続く "I completely understand" で二重の共感を示す
2
根拠（Rationale）: "config-level only" "no code changes" という技術的事実で「なぜ安全か」を示す。感情や主張ではなく事実ベースで話すことで信頼を維持する。"blast radius" はSRE/DevOps標準用語で専門性も示す
3
橋渡し（Bridge）: "I don't want to push through something you're not comfortable with" は相手を尊重しながら前に進む典型的な表現。強引さを解消して妥協案への導入をスムーズにする
4
妥協案（Middle ground）: "How about this as a middle ground" で提案。具体的な数字（3サービス・1週間・MTTA）と条件付き合意（go/no-go基準）を示す。「曖昧な妥協」ではなく「条件付きの具体的合意」が信頼を生む
5
合意確認（Close）: "Does that strike a reasonable balance?" で相手に決定権を渡す。押し付けでなく確認として使うことで Win-Win の姿勢を示す。書面化の申し出で最後に信頼感を高める
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
Totally fair | 相手の懸念を即座に正当化。"You're right" より口語的で柔らかい |
blast radius | 障害影響範囲。SRE/DevOps文脈の標準用語で専門性を示す |
middle ground | 妥協点・中間案。Win-Win 思考を示す交渉の核心フレーズ |
go/no-go criteria | 展開可否の判断基準。感覚でなく数字で判断することを示す |
roll back immediately | ロールバックのコミットメント。条件を明示することで安心感を与える |
strike a reasonable balance | 「適切なバランスを取る」。Win-Win 交渉の締めとして洗練された表現 |
put X in writing | 「書面化する」。書面化を申し出ることで透明性と信頼感を高める |
文化的ポイント
Win-Win フレームワーク
英語圏の交渉では「どちらかが負ける」ではなく「両者にとって最善の結果」を目指す。"middle ground" "balance" という言葉を使うことでその姿勢を示す
英語圏の交渉では「どちらかが負ける」ではなく「両者にとって最善の結果」を目指す。"middle ground" "balance" という言葉を使うことでその姿勢を示す
条件付き合意の力
曖昧な「やってみましょう」より「条件Xを満たせば進める」という具体的な条件付き合意が信頼を生む。"if X, then Y" の形式で明示する
曖昧な「やってみましょう」より「条件Xを満たせば進める」という具体的な条件付き合意が信頼を生む。"if X, then Y" の形式で明示する
相手の懸念の根本を理解する
Priya は「展開が嫌い」ではなく「リスクが心配」なだけ。「なぜ懸念しているか」を理解してそれを解消する提案をすることが Win-Win の鍵
Priya は「展開が嫌い」ではなく「リスクが心配」なだけ。「なぜ懸念しているか」を理解してそれを解消する提案をすることが Win-Win の鍵
よくある日本人のミス
❌ "I think maybe we can do 3 services."
遠慮が強く決断力がない印象。交渉では弱く見える
→
✅ "How about we start with three services?"
❌ "Your idea is good but my idea is better."
直接的な否定は対立を生む。Win-Win の姿勢を失う
→
✅ "I see where you're coming from. Here's a middle ground…"
❌ "Please agree with my proposal."
押し付け・命令調。相手に選択権を与えていない
→
✅ "Does that strike a reasonable balance between speed and caution?"
❌ "I will do rollback if something happens."
条件が曖昧すぎて安心感を与えられない
→
✅ "If MTTA spikes or we miss an incident, we roll back immediately."
❌ "I don't have problem with pilot."
同意の言い方が消極的。自分の主張がなくなる
→
✅ "That's a reasonable starting point — I'd just suggest expanding the pilot to three services."
ワンランク上の表現（Phase 3 以降）
Basic
"Your concern is OK. But I think all 8 is fine. Maybe we can do 3 services first?"
↓ 共感 + 根拠 + 具体的妥協案を組み合わせると
B2
"Totally fair — a system-wide incident is the last thing we want. The changes are config-level only, so blast radius is limited. Middle ground: start with 3 services, define go/no-go criteria, roll back if MTTA spikes, expand after 7 days. Does that work?"
↓ フレーミング + 技術的根拠 + 条件付き合意では
C1
"I appreciate you raising that, Priya — de-risking the rollout is absolutely the right instinct. Let me reframe slightly: rather than a single-service pilot, which could take weeks to yield statistically meaningful data, what if we ran a bounded three-service rollout with pre-agreed abort thresholds — say, any degradation in MTTA beyond 5% triggers an automatic pause? That gives us confidence in the approach while preserving enough signal to make a sound go/no-go call within a week."
"Let me reframe slightly"
（提案を再フレーミングする丁寧な前置き。相手の提案を否定せず別の視点を示す）
"pre-agreed abort thresholds"
（事前合意したロールバック基準。"rollback criteria" より技術的で正確）
"statistically meaningful data"
（統計的に意味のあるデータ。1サービスのパイロットが小さすぎる問題を論理的に指摘）
"bounded rollout"
（範囲を限定した展開。"limited scope" より技術的で意図的）
"de-risking the rollout"
（展開のリスクを低減すること。Priyaの懸念を "risk management" の観点で正当化する高度な受け答え）
次のステップ
- 発展: Priyaが「3サービスはまだ多い。どうしても1から始めたい」と再反論してきた場合の返答（さらに一歩引いた妥協か、根拠を強化して踏み込むか）
- 次回（Day 048）: Email × Legal — week_index が 7 に変わり、法務・コンプライアンス分野でのメール問題を練習
自己評価（解いた後に記入）
理解度
自分の回答
自分が書いたPriyaへの返答（全文）