第3章: コードレビューとIssueの英語術 — エンジニアのための英語

基本原則: コードレビューはコードを批判するのであって、人を批判しない。英語ネイティブは「あなた」を主語にせず、「コード」や「we」を主語にすることで自然にこれを実現する。

主語の選び方でトーンが変わる

同じ意図でも主語を変えると印象が大きく変わる

評価	英語表現	問題点 / 理由
❌ Bad	You should use a constant here.	「あなた」を主語にすると責める感じになる
❌ Bad	You forgot to handle the error.	失敗を個人に帰着させてしまう
❌ Bad	Why did you write it like this?	尋問調になりやすい
✅ Good	This could be a constant.	コードに焦点。「〜できそう」の提案トーン
✅ Good	The error case isn't handled here.	事実の指摘。個人への帰責なし
✅ Good	Could you help me understand the reasoning here?	疑問を「理解したい」という形で表現。非攻撃的

ソフトな表現を使う

could / might / consider を使うことで命令でなく提案のトーンになる

命令的（Bad）

Rename this variable.
Add error handling.
Fix the type.
Use async/await here.

命令形のみでは強すぎる印象になりやすい

提案的（Good）

Could you rename this for clarity?
It might be worth adding error handling here.
Consider using async/await for readability.
This could be simplified with optional chaining.

could / might / consider でソフトな提案に

コメントの重大度スケール — 低い順に

Nit

細かい・任意

Suggestion

提案・任意

Question

疑問・確認

Required

修正必須

Blocker

マージ不可

コメントの冒頭にラベルを付けることで、レビュイーがどの程度の対応が必要かを即座に判断できる。Google・Shopify など大手企業で定着している文化。

Nit

細かい指摘 — 任意対応 マージを阻害しない細かい点。レビュイーは対応してもしなくてもOK。"nitpick" の略。

Nit: could rename this to `userEmail` for clarity.

Nit: missing trailing newline.

Nit: s/recieve/receive

Suggestion

改善提案 — 任意対応 より良い実装方法の提案。強制ではないが採用を推奨。

Consider using `Array.from()` instead of the spread operator here.

What about extracting this into a separate function?

You could simplify this with optional chaining: `user?.profile?.avatar`

Question

疑問 — 変更を求めない場合も 学ぶため・確認のために聞く。必ずしも変更を要求していない。

Why did you choose Redis over Memcached here?

What happens if `items` is an empty array?

Is this intentional — or a potential edge case we should handle?

Required

修正必須 — マージ前に対応 品質・安全性・仕様に関わる必須修正。明確に要求する。

This needs to handle the null case.

Please add input validation here — this is user-facing.

The test coverage for this path is missing.

Blocker

マージ絶対不可 — 重大な問題 セキュリティ脆弱性・本番破壊・API破壊的変更など。即座の対応が必要。

This would break the production deployment — we must fix this before merging.

This introduces a SQL injection vulnerability. Blocking.

This changes the public API without a version bump — we need to address this.

レビュープロセスのフロー

コードが良い時は積極的に褒めるのが英語圏のエンジニア文化。黙ってLGTMだけより、具体的に何が良いかを伝えると関係も良くなる。

シンプルな称賛表現

コードレビューで使える肯定コメント

Great approach!

素晴らしいアプローチです！

Clever solution!

賢い解決策です！

This is much cleaner than the previous implementation.

前の実装よりはるかにきれいです。

Nice, I didn't know you could do this!

これできるの知らなかった！

This is really elegant.

本当にエレガントですね。

Love this abstraction.

この抽象化が好きです。

I like how you handled the edge case here.

エッジケースの処理の仕方が好きです。

Well done — this was a tricky problem.

お疲れ様です — 難しい問題でした。

褒めながら改善提案する技術

「問題ないが、さらに良くできる」という場合のパターン

This works perfectly. One thing we could also do is batch these calls to reduce the number of DB round trips.

完璧に動いています。さらに、これらの呼び出しをバッチ化してDBラウンドトリップ数を減らすこともできます。

This is a solid solution! We could also consider memoizing the result since this function is called frequently.

しっかりした解決策です！この関数は頻繁に呼ばれるので、結果をメモ化することも検討できます。

Great implementation — and if we ever need to scale this, switching to a queue-based approach would be straightforward from here.

素晴らしい実装です。スケールが必要になった場合は、ここからキューベースのアプローチへの移行も簡単です。

LGTM = "Looks Good To Me" — 承認を意味するエンジニア定番の表現。温度感に応じて様々なバリエーションがある。

LGTMの温度感スペクトラム

場面に応じた LGTM バリエーション

Minimal

LGTM

最短の承認。コードが明らかに問題ない時。

Minimal

🚀 / ✅ / +1

絵文字・記号だけで承認するチームも多い。

Standard

Looks good to me!

少し丁寧な形。日常的なレビューに最適。

Standard

Looks great! Ship it!

Ship it = マージしていいよ、リリースしよう、のエンジニアスラング。

Warm

LGTM — nice work!

承認 + 一言称賛を添える。

Warm

LGTM, thanks for the quick turnaround.

素早い対応への感謝を添える。

Conditional

LGTM with minor comments above.

全体的にOKだが、小さいコメントに対応してほしい場合。

Conditional

Approve pending the fix for the null check in line 42.

特定の修正を条件に承認。修正箇所を明示する。

Request Changes を使う時の表現

複数の修正が必要な場合。番号付きリストで明確に伝える

A few things to address before this is ready: 1. The error handling is missing in the catch block 2. Tests for the edge case (empty input) are needed 3. The type definition in line 58 doesn't match the return value Happy to re-review once these are addressed!

マイナーな修正ならApprove しつつコメントで伝えるスタイルも多い。レビュイーに再レビュー待ちの時間を使わせないための配慮。

PRタイトルの書き方

命令形（動詞の原形）で始める。「このPRを適用すると何が起きるか」を一文で表す

❌ Bad Titles

Added user auth          ← 過去形NG
Fixing bug               ← 進行形NG
Changes                  ← 漠然としすぎ
Bug fix                  ← 具体性なし
更新                      ← 日本語NG

✅ Good Titles

Add user authentication
Fix null pointer exception in UserService
Remove deprecated API endpoints
Update payment gateway to v3
Refactor database connection pooling

タイトルのコツ: 50文字以内を目安に。Conventional CommitsのPrefixを使うチームも: feat: fix: chore: docs:

PR説明文テンプレート

What / Why / How / How to Test の4セクション構成が標準的

## What  - Added JWT-based authentication middleware - Integrated refresh token rotation - Added `/auth/login` and `/auth/logout` endpoints ## Why  Users were unable to stay logged in across sessions (#42). ## How  Used `jsonwebtoken` library for token signing. Refresh tokens are stored in Redis with a 7-day TTL. Chose short-lived access tokens (15 min). ## How to Test 1. Run `npm run dev` 2. POST `/auth/login` with `{ "email": "test@example.com", "password": "..." }` 3. Verify 200 response includes `accessToken` and `refreshToken` ## Checklist - [x] Unit tests added - [x] Documentation updated - [ ] Migration script prepared (not needed)

レビュー依頼の表現

Hey @alice, could you review this when you get a chance?

時間がある時にレビューしてもらえますか？

This is fairly large, so feel free to focus on the core logic in `service.ts`.

かなり大きいので、service.ts のコアロジックに集中してもらって大丈夫です。

Did a self-review — left a few inline comments where things might be unclear.

セルフレビューしました。不明な箇所にインラインコメントを残しています。

@team — this one needs two approvals before we can merge. Thanks!

マージ前に2人の承認が必要です。ありがとうございます！

バグレポートの構成

再現手順・期待値・実際の動作・環境情報を明確に記載する

## Bug Description Clicking "Submit" on the checkout page throws a 500 error when the cart contains more than 10 items. ## Steps to Reproduce 1. Add 11+ items to the cart 2. Proceed to checkout 3. Click "Submit Order" → Error: Internal Server Error (500) ## Expected Behavior Order should be submitted successfully. ## Actual Behavior 500 error is thrown. Server logs show: "Array index out of bounds at CartService.java:142" ## Environment - Browser: Chrome 120 - OS: macOS 14.2 - Version: v2.4.1

提案・意見を求めるIssue

I'd like to propose migrating from REST to GraphQL for the user API.

ユーザーAPIをREST→GraphQLに移行することを提案したいです。

I'm not sure this is the right approach — any thoughts?

これが正しいアプローチか確信が持てません。ご意見ありますか？

Opening this for discussion — would love to hear the team's perspective.

議論のためにオープンにします。チームの意見を聞かせてください。

What are the trade-offs between these two approaches?

この2つのアプローチのトレードオフは何ですか？