エンジニア英語は “曖昧を潰す”。
仕様・不具合・レビューで必要なのは、ネイティブっぽさではなく 再現可能性 と 合意形成。
このPathは「事実 → 影響 → 次の一手」を英語で出せるようにします。
基本フォーマット（最強）
Fact（事実） → Impact（影響） → Next（次）
This fails on Android 14. → Users can’t log in. → Next, I’ll add logs and share a repro video.
This fails on Android 14. → Users can’t log in. → Next, I’ll add logs and share a repro video.
Bug 報告テンプレ（そのまま使える）
Summary Issue: …
Steps Steps to reproduce: 1) … 2) … 3) …
Expected Expected: …
Actual Actual: …
Env Environment: OS / version / build
仕様確認：誤解を消す質問
Just to confirm, do we support …?
What’s the expected behavior when …?
Is this in scope for this release?
What’s the success criteria?
What’s the expected behavior when …?
Is this in scope for this release?
What’s the success criteria?
レビューコメント（丁寧に強い）
Nit:（軽微）
Suggestion:（提案）
Concern:（懸念）
Blocking:（ここは直してから）
Can we add a test for …?
This might cause a race condition.
Foundations 連動
毎日6分
- Fact を2文
- Impact を1文
- Next を1文
- 確認質問を2つ
今日の勝ち
“It’s broken.” から卒業。
Steps to reproduce が言えたら勝ち。
Steps to reproduce が言えたら勝ち。
次に読む
チェック
- Bug を “Steps / Expected / Actual” で説明できる
- “Just to confirm …” で仕様を固められる
- レビューで “Concern / Blocking” を使い分けられる