目次
全体要約：この本が目指すもの
コードレビューにおいて、多くのチームが「ただの承認作業（ハンコ押し）」か「人格否定を含む殺伐とした議論」のどちらかに陥りがちです。
本書は、「建設的（Constructive）」であることを最優先し、技術的な品質（Code Quality）と心理的安全性（Psychological Safety）を両立させるための具体的なフレームワークを提供しています。
Part 1: コードレビューの基礎 (Foundations)
なぜレビューをするのか？
バグを見つけることだけが目的ではありません。本書では以下の価値を定義しています。
- 知識の共有 (Knowledge Transfer): 特定の人しか触れないコード（サイロ化）を防ぐ。
- チームの基準の維持: 「私たちのチームではこう書く」という文化の醸成。
- メンターシップ: ベテランから若手へ、またはその逆の学びの場。
👥 役割の再定義：Author（書く人）と Reviewer（見る人）
1. 🧑💻 Author（コード作成者）の責任と禁止事項
Authorの最大の責務は、「Reviewerの認知負荷（Cognitive Load）を下げること」です。Reviewerがコードを読み解くための「謎解き」をさせないように準備する必要があります。
| カテゴリ | 責任 (Responsibilities) – やるべきこと | やってはいけないこと (Anti-patterns) |
| コンテキスト (背景共有) | 「なぜ (Why)」と「何を (What)」を説明する PRの冒頭に、関連するチケットのリンク、変更の目的、検証方法（スクリーンショットや動画）を明記する。「コードを読めばわかる」は通用しないと心得る。 | 壁の向こうに丸投げ (Throwing over the wall) 説明文が空欄、または「Fix bug」だけのPR。Reviewerに「これ何のための変更？」と推測させること。 |
| PRのサイズ (粒度) | 小さく、一つのことに集中させる (Atomic PRs) 「リファクタリング」と「新機能追加」を混ぜない。Reviewerが一度に理解できる量（目安は200〜400行以内）に抑える。 | 巨大なPR爆弾 ( The PR Bomb) 100ファイル以上の変更を一度に送る。これを見るReviewerは疲弊し、結局中身を見ずに「LGTM」を押すか、放置することになる。 |
| 事前準備 (Self-Review) | 自分のPRを最初にレビューする Reviewerに投げる前に、自分でdiffを確認し、誤字、不要なログ、コメントアウトされたコードを削除する。Lintやテストが通っていることを確認する。 | 未完成品をレビューさせる 「とりあえず見て」と、ビルドすら通らないコードや、ケアレスミスだらけのコードを投げる。Reviewerの時間をデバッグに使わせるのは失礼にあたる。 |
| マインドセット (態度) | フィードバックを歓迎し、感謝する 指摘は「自分の人格」への攻撃ではなく、「コード」への改善案だと切り分ける。修正したら「Done」「Fixed」と明確に反応する。 | 防御的になる (Getting Defensive) 指摘に対して言い訳を並べたり、不機嫌になったりする。「でも動くからいいじゃん」と開き直る。 |
2. 🕵️♀️ Reviewer（レビュアー）の責任と禁止事項
Reviewerの最大の責務は、バグを見つけること以上に「チームの健全性と開発速度のバランスを取ること」です。
| カテゴリ | 責任 (Responsibilities) – やるべきこと | やってはいけないこと (Anti-patterns) |
| トーン＆マナー (伝え方) | 質問形式で、コードについて話す 「なぜこの実装を選んだのですか？」と意図を尋ねる。主語を「You（あなた）」ではなく「We（私たち）」や「This code（このコード）」にする。 (例: “You broke the API” ではなく “This change breaks the API”) | 命令形や皮肉を使う 「これを直せ」「なんでこんなことしたの？」「ありえない」といった言葉。これらはAuthorを萎縮させ、心理的安全性を破壊する。 |
| 優先順位付け (トリアージ) | 「必須 (Blocker)」と「任意 (Nitpick)」を分ける バグやセキュリティ問題はマージを阻止するが、好みの問題（変数名など）は「Nit」ラベルをつけ、Authorに判断を委ねる（またはマージ承認後に直してもらう）。 | すべてを重大問題として扱う 個人の好み（「自分ならこう書く」）を理由に、機能的に正しいコードのマージをブロックする。 |
| 範囲の限定 (Scope) | PRの変更範囲内だけを見る 今回の変更に関連する部分に集中してレビューを行う。 | スコープ・クリープ (Scope Creep) 「ついでにこっちのコードも直しておいて」「ここもリファクタリングして」と、今回のPRの目的とは無関係な修正を追加で要求する。 |
| スピード (Velocity) | ブロックを最小限にする 完璧を求めすぎていつまでも承認しないのではなく、「十分に良い (Good Enough)」段階で承認する。チームで決めたSLA（例: 24時間以内）を守る。 | ゴースティング (Ghosting) レビュー依頼を無視し続ける、あるいは途中で反応しなくなる。Authorは催促していいのかわからず、開発が完全にストップする。 |
🤝 Part 2: プロセスと合意形成 (Elevated Code Review Essentials)
本書の核となる部分です。「暗黙の了解」を排除し、明文化することを強く推奨しています。
1. チーム・ワーキング・アグリーメント (The Team Working Agreement)
「良いレビュー」の定義はチームごとに異なります。以下の項目について明示的な合意（ドキュメント化）を作ることを推奨しています。
- SLA (Service Level Agreement): 「PRが出されてから何時間以内にレビューを開始するか？」（例：24時間以内）
- 「完了」の定義: 何をもってマージ可能とするか？（全テストパス？承認人数は？QAは？）
- 緊急時の対応: 本番障害時のホットフィックスは、誰の承認でマージしてよいか？
⚖️ トレードオフ: 厳格さ vs 柔軟性
- ルールをガチガチに固めるとスピードが落ちますが、ルールがないと無法地帯になります。
- 解決策: 「原則としてのルール」を作りつつ、後述する「緊急時プレイブック」で例外を認める構造にします。
2. コメントの作法 (Effective Comments)
「何を言うか」より「どう言うか」が重要です。著者はConventional Comments（ラベル付きコメント）の導入を推奨しています。
| ラベル | 意味 | アクション |
| [BLOCKER] | 致命的な問題（バグ、セキュリティ）。 | 修正必須。これがある限りマージ不可。 |
| [NIT] | 些細な指摘 (Nitpick)。変数名や好みの問題。 | 修正は任意。議論で時間を浪費しない。 |
| [QUESTION] | 純粋な疑問。 | 意図を説明すればOK。 |
| [SUGGESTION] | 改善提案。 | 「今回はいいけど、次はこうすると良いかも」 |
💡 ポイント: このラベル付けにより、レビュアーは「細かい指摘もしたいが、進行を止めたくない」というジレンマ（トレードオフ）から解放されます。
3. 自動化の活用 (Automation)
人間がやるべきことと、機械にやらせることを分けます。
- 機械: インデント、スペース、未使用変数、型チェック (Lint/Format)。
- 人間: アーキテクチャの妥当性、ビジネスロジックの正しさ、可読性、保守性。
🚧 Part 3: ジレンマとトラブルシューティング (Dealing with Dilemmas)
現実の現場で起こる「泥臭い問題」への対処法です。
1. 「レビュー待ち」で開発が止まる問題
- 原因: レビュアーが忙しすぎる、またはPRが巨大すぎる。
- 対策:
- PRを小さく分割する: 「1つのPR、1つの関心事」を徹底する。
- 同期的なレビュー時間: 毎日特定の時間を「レビュータイム」としてブロックする。
2. 意見の対立 (Conflict)
- シチュエーション: 実装方針について、AuthorとReviewerが譲らない場合。
- 解決策:
- 「多数決」ではなく「タイブレーカー（決定者）」を決めておく: テックリードやアーキテクトが最終決定を行う。
- 同期コミュニケーションに切り替える: テキスト（GitHub上のコメント）での議論が3往復以上続いたら、Zoomや対面で話す。テキストは感情が伝わりにくいトレードオフがあるため。
3. 緊急時プレイブック (The Emergency Playbook)
「本番環境が落ちているのに、コードレビューの承認待ちで修正が出せない」という事態を防ぐための特例ルールです。
- 事後レビュー（Post-merge review）を許可する条件を明確にする。
- ただし、必ず「後でレビューする」タスクをチケット化し、うやむやにしない。
🚀 Part 4: 最新のプラクティス (Pairing with other practices)
従来の非同期レビュー以外の選択肢についても言及しています。
1. ペアプログラミング / モブプログラミング
- 考え方: 「書きながらレビューする」究極の形。
- トレードオフ:
- メリット: レビュー待ち時間ゼロ。知識共有が最速。
- デメリット: 全員の拘束時間が長い。内向的なエンジニアには疲労が大きい。
- 結論: 常に行うのではなく、「複雑な機能の実装」や「新人のオンボーディング」など、コンテキスト共有が重要な場面で選択的に導入する。
2. AIによるレビュー (AI Reviewers)
- 考え方: GitHub Copilotやその他AIツールを「最初のレビュアー」として使う。
- 注意点: AIは「文法」は指摘できるが、「ビジネスの意図」は理解できない。AIの「LGTM」を鵜呑みにせず、あくまで「人間の負荷を下げる補助ツール（linterの延長）」として扱うべき。
📝 まとめ：アクションプラン
- PRテンプレートの改善:
- 「変更の背景」「検証手順」を書く欄を設ける。
- Conventional Commentsの導入:
- チーム内で「[NIT] や [SUGGESTION] を使い分けよう」と提案してみる。
- 「マイルール」ではなく「合意」を作る:
- 「Goのこの書き方は好きじゃない」ではなく、「GoogleのGo Style Guideに合わせよう」と、外部の権威やドキュメントを基準に議論する。
コメント