エンジニアの皆さん、こんにちは。現場で戦うための「技術の武器」を磨く準備はいいですか？
GitHubのPull Request（PR）。毎日触れるこの画面、ただ「コードを投げてマージボタンを押す場所」だと思っていませんか？ もしそうなら、あなたはまだ、本来得られるはずの「開発速度」と「チームの信頼」という果実を半分も手にできていません。
今回は、PRを単なる作業報告書から、「チームを最強にするコミュニケーションツール」へと昇華させるための極意を伝授します。
—
1. PRは「ラブレター」だ：質の高いテンプレートを作る
コードをレビューする人の脳内メモリを節約してください。質の低いPRは、レビューアに「まず何がしたいの？」「どこを見ればいいの？」という無駄な推測を強います。
GitHubには `pull_request_template.md` という魔法の機能があります。リポジトリの `.github/` ディレクトリにこのファイルを置くだけで、PR作成時に自動でテンプレートが挿入されます。
おすすめのテンプレート例:
どんな変更ですか？
- [ ] 〇〇のバグ修正
- [ ] 〇〇機能の追加
なぜその変更が必要ですか？
- 課題の背景と、なぜこのアプローチを選択したのかを簡潔に書く。
どうやって動作確認しましたか？
- [ ] ユニットテストを追加（`npm test`で確認済み）
- [ ] 実際にローカル環境で画面遷移を確認
- [ ] エッジケース（null値など）への対応
レビューで特に見てほしい箇所
- 特にロジックの複雑な `utils/validator.ts` 周りを見てほしい。
ポイント: テンプレートの目的は「自分を縛るため」ではなく、「レビューアが考えるべきことを最小限にするため」です。
—
2. レビュー依頼の「作法」：読み手への敬意をコードに宿す
レビュー依頼を出すとき、以下の「3つの禁句」を自分に課してください。
- 「とりあえず投げました」：レビューアはあなたの作業の進捗確認係ではありません。
- 「説明なしでコードだけ送る」：コードは「何をしたか」は語れますが、「なぜそうしたか」は語りません。
- 「巨大すぎるPR」：人間が一度に集中してレビューできるのは、せいぜい300行までです。
極意: PRは「小さく、目的を一つに絞る」こと。もし機能追加とリファクタリングが混ざっているなら、別々のPRに分けるべきです。小さいPRは、レビューの速度を劇的に高めます。
—
3. レビューをもらった後の「修正フロー」：感情を切り離す
コードレビューは、あなたの人格への攻撃ではなく、「コードという成果物を磨くための共同作業」です。
- 素直に感謝する: 「修正してくれてありがとう」の一言で、チームの空気は劇的に変わります。
- 「議論」と「修正」を分ける: 理解できない指摘があれば、感情的にならずに「意図を教えてください」と質問しましょう。
- 修正はコミットを汚さない: レビュー指摘を受けての修正は、`git commit –amend` や `git rebase -i` を使って履歴をきれいに保つのがプロの嗜みです。
—
4. 承認への最短ルート：コミュニケーションのハック
最後は人間関係のハックです。承認をもらうまでの時間を短縮するためのテクニックを紹介します。
- セルフレビューを最初に行う: 自分が投稿したPRを、一度自分の目で客観的に読み返してください。「あ、ここ変数名変だな」と気づくだけで、レビューアの手間が一つ減ります。
- WIP (Work In Progress) を活用する: まだ途中だけど方針を確認したいときは、タイトルに `[WIP]` をつけましょう。完成してから指摘をもらうより、方向性をすり合わせたほうが手戻りは最小限です。
- LGTM (Looks Good To Me) を待つだけでなく、自ら動く: もしレビューが止まっているなら、「お忙しいところすみません、これマージしたいのでレビューをお願いできますか？」とチャットで声をかける勇気を持ちましょう。
—
最後に：これが「できるエンジニア」の背中
優秀なエンジニアは、コードを書くのと同じくらい、あるいはそれ以上に「他人のコードを読むこと」と「自分の意図を伝えること」に情熱を注ぎます。
PRは、あなたの考えを形にする場所です。今回紹介したテンプレートや作法を一つ取り入れるだけで、あなたのチームのレビュー文化は確実に変わります。
明日からのGitHubライフ、少しだけ意識を変えてみませんか？
「誰かのために」書くPRは、巡り巡って、必ずあなたの生産性を最大化してくれますよ。
それでは、素晴らしいコードライフを！