記事

Googleに学ぶコードレビューの技術と心構え

Googleの「Code Review Developer Guide」をベースに、効果的なコードレビューの進め方・チェックポイント・よくある失敗パターンをまとめた実践ガイド。

PUBLISHED: 2026/05/31(日) UPDATED: 2026/05/31(日) TAGS: #development

はじめに

コードレビューはソフトウェア開発において品質を担保するための最も基本的なプラクティスのひとつである。Googleでは全てのコード変更がレビューを通過しなければマージされない。この記事では、Googleが公開している「Code Review Developer Guide」の考え方を軸に、レビュアーとCL（Changelist）作成者の双方が知っておくべき原則と実践方法を整理する。

コードレビューの目的

A code review is a process where someone other than the author(s) of a piece of code examines that code.

— Google Engineering Practices Documentation

コードレビューには複数の目的がある。単にバグを見つけるだけではない。

コードベースの健全性を維持する— 時間とともにコードベースが劣化するのを防ぐ
知識の共有— チーム内でコードの理解を広げ、バス係数を上げる
一貫性の確保— スタイル・設計パターンの統一を保つ
教育— ジュニアエンジニアが先輩のフィードバックから学ぶ機会を作る

NOTE

Googleでは「コードベースの健全性の向上」がレビューの最上位の目的とされている。個々のCLが完璧でなくても、コードベース全体を確実に良くしていくことが重要とされる。

レビューの全体フロー

レビューは以下のような流れで進行する。

MERMAID

flowchart TD
    A[CL作成者がコードを書く] --> B[セルフレビューを実施]
    B --> C[CLの説明文を記述]
    C --> D[レビュー依頼を送信]
    D --> E{レビュアーが確認}
    E -->|問題なし| F[LGTM — 承認]
    E -->|修正が必要| G[コメントでフィードバック]
    G --> H[CL作成者が修正]
    H --> I[修正をプッシュ]
    I --> E
    F --> J[マージ]

レビュアーの心得

すみやかに対応する

レビュー依頼を受けたら、1営業日以内に初回のフィードバックを返すことがGoogleでは推奨されている。レビューが遅れると開発のリズムが崩れ、CL作成者のコンテキストが失われてしまう。

WARNING

「忙しいから後で見る」を繰り返すと、CLが巨大化したまま放置される原因になる。小さなCLを迅速にレビューするサイクルを維持することが、チーム全体の生産性を左右する。

何を見るべきか

レビュアーが確認すべき観点は多岐にわたる。以下のチェックリストを参考にしてほしい。

カテゴリ	確認ポイント	重要度
設計	変更の設計は適切か。責務の分離は正しいか	高
機能性	意図した動作をするか。エッジケースは考慮されているか	高
複雑さ	不必要に複雑ではないか。将来の開発者が理解できるか	高
テスト	適切なテストが書かれているか。テストは正しいか	高
命名	変数名・関数名は意図を正確に伝えているか	中
コメント	なぜそのコードが存在するかを説明しているか	中
スタイル	プロジェクトのスタイルガイドに準拠しているか	低
ドキュメント	関連するドキュメントは更新されているか	低

NOTE

スタイルに関する指摘は自動フォーマッタに任せるのがベストプラクティスである。人間のレビュー時間はより本質的な設計やロジックの議論に使うべきだ。

建設的なフィードバックの書き方

レビューコメントは「何が問題か」だけでなく「なぜ問題か」「どうすればよいか」まで伝えることが重要である。

悪い例と良い例を比較してみよう。

typescript

// Bad: 何が悪いか分からないコメント
// 「これは良くない」

// Good: 理由と代替案を示すコメント
// 「この関数は引数が5つあり認知負荷が高い。
//  設定オブジェクトにまとめると呼び出し側の可読性が上がる。」

具体的には、関数のシグネチャを以下のようにリファクタリングすることを提案できる。

typescript

// Before: 引数が多く意図が読みにくい
function createUser(
  name: string,
  email: string,
  role: string,
  isActive: boolean,
  department: string,
) {
  // ...
}

// After: 設定オブジェクトでまとめる
interface CreateUserParams {
  name: string;
  email: string;
  role: string;
  isActive: boolean;
  department: string;
}

function createUser(params: CreateUserParams) {
  // ...
}

CL作成者の心得

小さなCLを心がける

Googleのガイドラインで最も強調されている原則のひとつが「CLを小さく保つ」ことである。小さなCLには以下の利点がある。

レビュアーの負担が軽くなり、レビュー速度が上がる
バグの見落としが減少する
マージコンフリクトのリスクが低下する
リバートが必要な場合の影響範囲が小さい

目安として、変更行数は200行以内に収めるのが理想的とされている。

CLの説明文を丁寧に書く

CL（Pull Request）の説明文は、レビュアーが最初に読む情報である。以下の要素を含めるべきだ。

何を変更したか— 変更内容の要約
なぜ変更したか— 背景と動機
どうテストしたか— 検証方法

bash

# CLの説明文の例
git commit -m "$(cat <<'EOF'
ユーザー認証のタイムアウト処理を追加

セッションが30分以上アイドル状態の場合に自動ログアウトする処理を実装。
セキュリティ監査で指摘された項目への対応。

検証: 単体テスト追加済み。ステージング環境で30分放置後のログアウトを確認。
EOF
)"

WARNING

「修正」「更新」「対応」だけのコミットメッセージは避けること。数ヶ月後にgit logを追う開発者にとって、何の情報も提供しない。

よくあるアンチパターン

レビューを読まずに承認する

CAUTION

差分を確認せずにLGTMを出す行為は、レビュープロセスの形骸化を招く。本番障害の原因となるバグを見逃すだけでなく、チーム全体の品質意識を低下させる重大なリスクがある。

レビュー中のforce push

bash

# レビュー中に絶対にやってはいけないこと
git rebase -onto main feature-branch
git push --force origin feature-branch

CAUTION

レビュー中にforce pushすると、レビュアーが確認済みのコミットが消失し、どこが変わったか追跡できなくなる。修正は新しいコミットとして積み、マージ時にsquashするのが安全な運用である。

感情的なコメント

レビューはコードに対するフィードバックであり、人格への批判ではない。以下のような表現は避けるべきだ。

避けるべき表現	改善例
「なんでこんな書き方をしたの？」	「この部分、`Map`を使うとO(1)で検索できますがいかがですか？」
「これは間違い」	「この条件だと`null`の場合に例外が発生しそうです」
「前にも言ったけど」	「lint規則に追加して自動検出できるようにしましょうか？」

自動化で効率を上げる

人間がレビューに集中するために、機械的なチェックはCIに任せるべきである。

bash

# CI パイプラインでの自動チェック例
make format-check  # フォーマット検証
make lint          # 静的解析
make web-typecheck # 型チェック
make web-test      # テスト実行

これらが全てパスした状態でレビュー依頼を出すことで、レビュアーはスタイルやタイプミスではなく、設計とロジックに集中できる。

NOTE

CIで検出できる問題を人間がレビューで指摘するのは、双方にとって時間の無駄である。フォーマッタ・リンター・型チェッカーの導入はレビュー品質向上の第一歩だ。

レビューコメントの分類

レビューコメントには重要度のレベルがある。CL作成者がどのコメントに優先的に対応すべきか明確にするために、プレフィックスをつける運用が効果的である。

プレフィックス	意味	対応
`must:`	ブロッキング。修正しないとapproveしない	必須
`should:`	強い推奨。特別な理由がなければ修正すべき	ほぼ必須
`nit:`	些細な指摘。対応は任意	任意
`question:`	質問。理解を深めるための確認	回答
`thought:`	今後の改善アイデア。このCLでの対応は不要	記録のみ

まとめ

コードレビューは単なるゲートキーピングではなく、チームの技術力とコードベースの品質を継続的に高めるための投資である。レビュアーは敬意を持って迅速にフィードバックし、CL作成者は小さく明確な変更を心がける。機械に任せられることは自動化し、人間は設計と意図の議論に集中する。この循環が回り始めると、コードレビューは負担ではなく、チームの成長エンジンとなる。

Code review is not just about finding bugs. It’s about maintaining and improving the overall health of the codebase over time.

— Google Engineering Practices Documentation