コードレビューの基本
なぜレビューするのか、何を見るのか、基本的な考え方を学ぼう
なぜコードレビューをするのか
コードレビューは単なる「間違い探し」ではありません。 チーム開発においてコードの品質を維持し、知識の共有を促進するための重要なプロセスです。
品質面のメリット
- • バグの早期発見（本番障害の防止）
- • セキュリティホールの検出
- • パフォーマンス問題の指摘
- • コーディング規約の徹底
チーム面のメリット
- • コードベースの共有知識が増える
- • ジュニアメンバーの教育機会になる
- • 属人化（バス因子）の防止
- • チーム内の信頼関係が強まる
統計データ
コードレビューを行うチームは、行わないチームに比べてバグの発生率が約60%低いという調査結果があります。 レビューは最もコスト効率の良い品質保証手法の一つです。
レビューの5つの観点
コードレビューでは、以下の5つの観点からコードを評価します。 すべてを一度に見る必要はなく、優先度をつけて確認しましょう。
正確性（Correctness）
コードが仕様通りに動作するか。エッジケースは考慮されているか。
// 悪い例: 0 で割る可能性がある
function average(nums: number[]): number {
const sum = nums.reduce((a, b) => a + b, 0);
return sum / nums.length; // nums が空配列だと NaN
}
// 良い例: エッジケースを考慮
function average(nums: number[]): number {
if (nums.length === 0) return 0;
const sum = nums.reduce((a, b) => a + b, 0);
return sum / nums.length;
}可読性（Readability）
変数名は適切か。ロジックは理解しやすいか。コメントは必要十分か。
パフォーマンス（Performance）
不要なループや再計算はないか。N+1クエリなどの問題はないか。
セキュリティ（Security）
ユーザー入力のバリデーションは十分か。機密情報が漏洩しないか。
保守性（Maintainability）
将来の変更が容易か。DRY原則に従っているか。テストは書かれているか。
レビューチェックリスト
レビュー時に確認すべきポイントをまとめたチェックリストです。 チームで共有して、レビューの質を均一化しましょう。
機能面
- ☐ 仕様通りに動作するか
- ☐ エッジケースは考慮されているか
- ☐ エラーハンドリングは適切か
- ☐ 既存の機能を壊していないか
コード品質
- ☐ 命名は分かりやすいか
- ☐ 関数やコンポーネントは適切な大きさか
- ☐ 重複コードはないか
- ☐ TypeScriptの型は適切か
セキュリティ
- ☐ ユーザー入力がサニタイズされているか
- ☐ 機密情報がハードコードされていないか
- ☐ 認証・認可のチェックがあるか
- ☐ SQLインジェクション等の脆弱性はないか
テスト・ドキュメント
- ☐ テストは追加・更新されているか
- ☐ CIが通っているか
- ☐ 必要なドキュメントが更新されているか
- ☐ 変更内容がPR説明文に記載されているか
Approve と Request Changes
GitHubでは、レビュー結果を3つのステータスで伝えることができます。 それぞれの使い分けを理解しましょう。
Approve（承認）
コードに問題がなく、マージして良い状態。軽微な修正提案がある場合でも、 ブロックする必要がなければApproveしてコメントで伝えるのがスムーズです。
Request Changes（変更要求）
マージ前に修正が必要な問題がある場合。バグ、セキュリティ問題、 設計上の大きな懸念がある場合に使います。修正後に再度レビューします。
Comment（コメント）
承認でも変更要求でもない、フィードバックのみ。質問や提案をしたいが、 判断は著者に任せたい場合に使います。
ポイント
Request Changesを使う場合は、具体的に何を修正すべきかを 明確に伝えましょう。「ここがダメ」ではなく「こう修正してください」と書くのがベストです。
健全なレビュー文化を作る
コードレビューは技術的なプロセスであると同時に、コミュニケーションです。 チーム全体で心がけるべきポイントを紹介します。
コードを批判し、人を批判しない
「このコードは...」と書き、「あなたは...」とは書かない
理由を説明する
「こうした方がいい」だけでなく「なぜなら...」を添える
良い点も褒める
指摘だけでなく、良いコードにはポジティブなコメントを残す
タイムリーにレビューする
レビュー待ちが長いとチームの生産性が下がる（目安: 24時間以内）
完璧を求めすぎない
「十分に良い」コードをマージして、改善は次のPRで行う
まとめ
- • コードレビューは品質向上と知識共有の両方に貢献する
- • レビューの観点は正確性・可読性・パフォーマンス・セキュリティ・保守性の5つ
- • チェックリストを使って、レビューの抜け漏れを防ぐ
- • Approve / Request Changes / Comment を適切に使い分ける
- • 健全なレビュー文化は、敬意あるコミュニケーションから始まる