「そのコード、読めますか？」現場で役立つコードレビュー10のチェックポイント

1. はじめに

コードレビューは、単なるバグ検出作業ではありません。
それはチームの品質を支え、スキルを共有し、未来のメンテナたちへのラブレターを書く行為です。

では、どんな視点でコードを読めばいいのか？
この記事では、現場で「実際に使える」コードレビューのチェックポイントを10項目に絞って紹介します。

2. コードレビューの主な目的

品質の担保：バグ、脆弱性、設計ミスの早期発見
可読性の向上：第三者が理解しやすいコードへ
知識の共有：レビュアーと開発者間の相互理解
ベストプラクティスの浸透：チームの開発文化の統一

3. チェックポイント一覧（10選）

1. このコード、読める？理解できる？

変数名、関数名が曖昧ではないか
読み手が意図を想像しなくても済むか
コメントが説明になっていないか（＝コードの読解が難しい証拠）

目安：「他の人が初見で10秒以内に理解できるか？」

2. 責務が明確か？

1つの関数・クラスに複数の役割が詰まっていないか
SRP（単一責任の原則）に沿っているか

3. 変数・関数名が具体的か？

data, info, temp のような曖昧な名前になっていないか
get_data() よりも fetch_user_profile() のように意味が具体化されているか

4. 冗長なコードや処理の繰り返しがないか？

同じ処理が複数箇所に書かれていないか
ユーティリティ関数に切り出せないか

5. スコープ・可視性が適切か？

グローバルに出す必要があるか？
クラス内変数がprivateで良いのにpublicになっていないか？

6. エラーハンドリングは十分か？

例外処理はされているか
try / except の中でログや通知が残されているか

7. テスト可能な設計か？

DI（依存性注入）やインターフェースの活用でテストが容易か？
グローバル依存や静的メソッドに縛られていないか？

8. パフォーマンスに影響するポイントはないか？

重いループ処理・N+1問題・無駄なDBアクセス
キャッシュが使える場面で活用しているか

9. セキュリティリスクはないか？

入力値のバリデーションが適切か？
SQLインジェクション・XSSへの対策はされているか？

10. そのコード、本当に必要？（YAGNI）

「将来必要かも」で入れた機能や処理はないか
今の要件で必要なものだけに絞って書かれているか

4. 実際のコメント例（良いレビュー）

関数名が "do_task" だと処理の意図が読みにくいため、何をする関数なのか明示してください。
例: `process_user_registration()`

この if 文のネストが深く、読みづらいです。ガード節を使って早期 return すると読みやすくなります。

似たような処理が3か所にありますね。1つのユーティリティ関数にまとめてみませんか？

NG例（ありがちな悪いレビュー）

・これはダメ  
・これ、前と違うから戻して  
・意味わからん（説明なし）

5. まとめ：良いコードレビューとは？

良いレビューは「攻撃」ではなく、「会話」です。

良いレビューの態度	説明
具体的である	「こう変えると改善できそう」まで言える
思いやりがある	相手の意図を理解しようとする
目的志向	「仕様を満たし、品質を担保する」ことがゴール
知識の共有	「なぜこうすべきか？」を説明することでチームの知見に

6. おすすめツール・文化

GitHub Pull Request + Code Owners
GitLab Merge Request + Approvers
Reviewdog + CIでLint自動化
ペアレビューやモブレビューの導入も効果的

7. 参考リンク

おわりに

コードレビューは単なるチェック作業ではありません。
「チームの開発文化を育てるコミュニケーション」です。

この記事で紹介したポイントを意識することで、
読む人にも、書いた人にも、そして未来の自分にも優しいコードが生まれていくはずです。

参考書籍

リンク

TechCraft – エンジニアのためのスキルアップメモ

エンジニアのスキルアップを少しでも加速する技術ブログ

コードレビュー 10のチェックポイント