コードレビューを120%活かす技術

レビュアーも実装者も成長できる。コードレビューの本質的な目的と実践的なテクニックを解説

コードレビューの本当の目的

多くのチームでコードレビューが「バグを見つける作業」として認識されています。しかし本来の目的は 3 層あります。

目的	内容
品質保証	バグ・セキュリティ問題の早期発見
知識共有	コードベースの理解とチームの底上げ
設計の議論	実装方針の確認と改善提案

「バグ探し」にしかなっていないレビューは、3 つのうち 1 つしか実現していません。

レビュアーの技術

コメントの分類を明示する

[MUST]  変更必須（バグ・セキュリティ・仕様違反）
[WANT]  できれば対応してほしい（設計・可読性）
[NIT]   細かい好みの話（命名・スタイル）
[IDEA]  提案・アイデア（対応は自由）
[Q]     質問・理解を深めたい

これがないと「このコメントは直さなきゃいけないの？」という無駄なコミュニケーションが発生します。

良いコメントの書き方

# NG：指摘だけで理由がない
「ここは変数名を変えてください」

# OK：理由と改善案がある
[NIT] `d` という変数名だと意図が読み取りにくいです。
`durationMs` など用途が伝わる名前にすると、
3ヶ月後に自分が読んだときも助かります。

批判はコードに向ける。人格への批判は絶対にしない。

レビューの優先順位

時間は有限です。レビュアーは以下の順で見ます。

仕様・要件の充足 — そもそも正しい実装か
セキュリティ — SQL インジェクション・認可漏れ等
エラーハンドリング — 異常系の考慮
パフォーマンス — N+1 クエリ・ループ内の重い処理
可読性・命名 — 後から読む人のために
テスト — カバレッジより有意なケースか

スタイルの統一は Linter/Formatter に任せ、人間はレベル 1〜4 に集中しましょう。

実装者の技術

PR を小さく保つ

大きな PR はレビュアーを消耗させ、見落としを増やします。

目安：1 PR ≤ 400 行の差分
例外：リファクタリングで機械的に変更が多い場合は
      「ロジック変更なし、〇〇の一斉リネーム」と明記

PR 説明文のテンプレート

## 変更の背景
注文画面でクーポン適用後の金額が正しく表示されない問題（Issue #234）

## 変更内容
- `calculateTotal()` のクーポン計算ロジックを修正
- ゼロ円クーポンのエッジケースを追加

## 確認方法
1. `npm run dev` で起動
2. テストユーザー（test@example.com）でログイン
3. カート → クーポン「FREE2024」を適用 → 合計0円になることを確認

## スクリーンショット
[変更前の画面] [変更後の画面]

## テスト
- [ ] ユニットテスト追加済み
- [ ] 既存テストがパスすることを確認

これだけで「この PR 何のためにあるの？」という質問が 8 割減ります。

事前セルフレビュー

PR を出す前に自分でレビュアー視点で読み返す習慣が最も費用対効果が高い。

git diff main...HEAD  # 自分の変更を通しで確認

チェックリスト：

TODOコメントが残っていないか
console.log / デバッグコードが残っていないか
エラーハンドリングが適切か
変数・関数名が意図を伝えているか

レビューのアンチパターン

レビュアー側

アンチパターン	問題
「なんかイケてない」	理由なき否定は議論にならない
数週間放置	チームのリズムが崩れる。24h 以内を目標に
承認しつつ大量コメント	「Approve したのに直さなきゃいけないの？」

実装者側

アンチパターン	問題
コメントへの返信なし	レビュアーが対応済みか判断できない
NIT コメントへの防衛	「自分はそう思わない」は議論を消耗させる
巨大 PR	1000 行越えは誰もまともにレビューしない

まとめ

コードレビューはバグ発見装置ではなく、チームで品質を作る共同作業です。

コメントは [MUST/WANT/NIT] で分類する
PR は小さく、説明文を丁寧に書く
指摘はコードに向け、人格批判はしない
24 時間以内にレビューする文化を作る

これを実践するチームは、3 ヶ月後に「レビューが苦痛じゃなくなった」を体験します。