シナリオ
あなたは日本のスタートアップ「Flowly」のバックエンドエンジニア。週次スプリントプランニングで、プロダクトマネージャーのSarah Chen（US拠点）が新機能の優先順位を説明しているところ。ユーザー通知機能とダッシュボードの改善の2つがバックログに入っているが、技術的な依存関係があるためどちらを先にやるべきか判断できず、スプリント計画が立てられない。
あなた
Backend Engineer, Flowly Japan
依存関係を根拠に優先順位の合意を取りにいく
相手
Sarah Chen
Product Manager（US拠点）· ネイティブ英語話者 · スピード重視 · 技術的詳細は把握していない
文化的コンテキスト
目的
技術的な依存関係を会議でPMに明確に伝え、スプリントに入れる優先アイテムについて合意を取る
技術的な依存関係を会議でPMに明確に伝え、スプリントに入れる優先アイテムについて合意を取る
結論から話す（BLUF）
英語の会議では前置きなしに事実・主張から入るのが基本。「実はちょっと確認したいのですが…」はNG
英語の会議では前置きなしに事実・主張から入るのが基本。「実はちょっと確認したいのですが…」はNG
依存関係は根拠とセットで
「難しい」ではなく「AはBに依存しているため並行するとブロックされる」と具体的に伝える
「難しい」ではなく「AはBに依存しているため並行するとブロックされる」と具体的に伝える
提案→同意確認のワンセット
"I'd suggest X — does that work for you?" の形で会議を前進させる。意見を述べた後は必ず相手に返す
"I'd suggest X — does that work for you?" の形で会議を前進させる。意見を述べた後は必ず相手に返す
タスク
状況 A — Sarahの発言に対して返す
Sarah Chen (PM)
"Alright, let's get both the notification feature and the dashboard redesign into this sprint. We need to move fast on both."
この発言を受けて、技術的な依存関係を伝えながら優先順位の合意を取る発言を英語で2〜3文で作成してください:
- 技術的な依存関係を簡潔に説明する（通知機能はダッシュボードのAPIに依存している）
- 並行して進めた場合のリスクを伝える
- 具体的な優先順位の提案と同意確認を行う
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
ちょっと一言いいですか
クリックで英語を表示 →
Quick heads-up —
💡 会議中に自然に割り込む定番フレーズ
〜に依存しています
クリックで英語を表示 →
X relies on Y / There's a dependency between X and Y
💡 depends on の言い換え。reliesはやや技術的文脈で自然
スプリント中にブロックされる
クリックで英語を表示 →
get blocked mid-sprint
💡 開発現場で使われるそのままの表現
〜を提案します
クリックで英語を表示 →
I'd suggest we...
💡 "I suggest" より丁寧。PMへの提案に最適
それで大丈夫ですか？
クリックで英語を表示 →
Does that work for you?
💡 提案の後に必ず添える確認フレーズ
並行して進めるとリスクがある
クリックで英語を表示 →
Running them in parallel introduces sequencing risk.
💡 C1レベルの表現。エンジニアらしい明確な言い方
ヒント（段階的開示）
ヒント 1 — 構成・方向性
3ステップの構成が有効です: (1) 依存関係の事実を述べる → (2) 並行した場合のリスクを示す → (3) 具体的な優先順位を提案して確認を取る。感情や謝罪は不要。事実と提案だけで会議を前進させましょう。
ヒント 2 — キーフレーズ・表現
"Quick heads-up — there's a dependency here."で自然に割り込む"The notification feature relies on the dashboard API..."で依存関係を明示"...so running both in parallel could get us blocked."でリスクを伝える"I'd suggest prioritizing the dashboard this sprint — does that work for you?"で提案+確認
ヒント 3 — 骨格テンプレート
[割り込み] Quick heads-up — there's a dependency here.
[依存+リスク] The notification feature relies on the dashboard API, so if we run both in parallel, notifications will get blocked mid-sprint.
[提案+確認] I'd suggest we focus on the dashboard this sprint and pick up notifications next — does that work for you, Sarah?
[依存+リスク] The notification feature relies on the dashboard API, so if we run both in parallel, notifications will get blocked mid-sprint.
[提案+確認] I'd suggest we focus on the dashboard this sprint and pick up notifications next — does that work for you, Sarah?
モデル解答（B2〜C1相当）
状況 A — モデル解答
Sarah Chen (PM)
"Alright, let's get both the notification feature and the dashboard redesign into this sprint. We need to move fast on both."
あなた（モデル解答）
"Quick heads-up, Sarah — there's a dependency between these two items. The notification feature relies on the dashboard API, so if we start both in parallel, the notification work will likely get blocked mid-sprint. I'd suggest we focus on the dashboard redesign this sprint and move the notification feature to next — does that work for you?"
解説
構成分析
1
割り込みの前置き（"Quick heads-up, Sarah"）: 会議の流れを止めて注意を引く、礼儀正しくかつ直接的なフレーズ
2
依存関係の事実提示（"The notification feature relies on the dashboard API"）: 技術的な根拠を簡潔に、PMが理解できる言葉で伝える
3
リスクの明示（"will likely get blocked mid-sprint"）: 「何が困るのか」を具体的に伝えてPMの意思決定を促す
4
提案＋確認（"I'd suggest... does that work for you?"）: 一方的に押しつけず、PMに最終判断を委ねる形で締める
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
Quick heads-up | 「ちょっと一言」。会議中に自然に割り込むときの定番。"Excuse me" より使いやすい |
there's a dependency between X and Y | 「XとYの間に依存関係があります」。PMへの報告で使いやすい中立的な表現 |
relies on | depends on の言い換え。技術文脈でよく使われる |
get blocked mid-sprint | 「スプリント中にブロックされる」。アジャイル文脈でそのまま通じる表現 |
Does that work for you? | 「それで大丈夫ですか？」。提案の後に添える確認フレーズ |
文化的ポイント
BLUFで話す
「実は少し確認したいことがあって…」ではなく「依存関係があります（事実）」から入る。欧米の会議では結論ファーストが基本
「実は少し確認したいことがあって…」ではなく「依存関係があります（事実）」から入る。欧米の会議では結論ファーストが基本
技術的根拠をPM言語で伝える
「APIの実装が先」という技術的な理由を「並行するとブロックされる」というリスクとして伝えると、PMが意思決定しやすい
「APIの実装が先」という技術的な理由を「並行するとブロックされる」というリスクとして伝えると、PMが意思決定しやすい
提案は必ず確認とセット
"I'd suggest X — does that work for you?" の形にすることで、エンジニアがPMの意思決定を尊重している姿勢が伝わる
"I'd suggest X — does that work for you?" の形にすることで、エンジニアがPMの意思決定を尊重している姿勢が伝わる
よくある日本人のミス
❌ "I have a question about the priority..."
前置きが長く、結論が遅れる
→
✅ "Quick heads-up — there's a dependency here."
❌ "The notification feature is depend on the dashboard."
depend の動詞活用ミス（is + 動詞の原形は不可）
→
✅ "The notification feature depends on the dashboard." または "relies on"
❌ "Is it possible to do dashboard first?"
可能性の質問で意図が曖昧。消極的に聞こえる
→
✅ "I'd suggest we prioritize the dashboard — does that work for you?"
❌ "Both tasks are difficult to do in same sprint."
冠詞の欠落（the same sprint）、語順が不自然
→
✅ "It'll be difficult to run both in the same sprint."
ワンランク上の表現（Phase 2 以降）
Basic
"I think we should do the dashboard first because the notification feature uses its API."
↓ 依存関係の説明を追加すると
B2
"Quick heads-up — there's a dependency. The notification feature relies on the dashboard API, so running both in parallel could get us blocked. I'd suggest focusing on the dashboard this sprint."
↓ さらにリスク言語を使うと
C1
"Before we commit to both, I want to flag a blocker: the notification module is upstream-dependent on the dashboard API refactor. Running them in parallel introduces sequencing risk. My recommendation would be to timebox the dashboard work this sprint and gate the notification work on its completion — thoughts?"
"I want to flag a blocker before we commit."
（「コミットする前に、ブロッカーを共有したいです」。技術的な問題を事前に伝えるときに使えるC1表現）
"Gate the notification work on its completion."
（「通知機能の着手条件としてダッシュボードの完了を設定する」。依存を「ゲート（条件）」として表現する高度な言い方）
"Running them in parallel introduces sequencing risk."
（「並行すると順序リスクが生じます」。技術的リスクをPMにも伝わる言葉で表現したC1フレーズ）
次のステップ
- 発展: Sarahが「Can we do both in parallel with two separate teams?」と返してきたら、どう答えるか（Phase 2）
- 次回: Chat/Slack × Product — Slackで製品の仕様変更を開発チームに短く共有する問題
自己評価（解いた後に記入）
理解度
自分の回答
状況 A