コードレビューの作法｜レビュイー・レビュアー両方の視点で解説

きれいなコードの書き方入門も参考にしてください。

関連記事：Git・GitHub入門ガイド

コードレビューは、コードの品質を保つだけでなく、チームの技術力を底上げする重要なプロセスです。しかし、やり方を間違えると人間関係の悪化やボトルネックの原因にもなります。

コードレビューの目的

• バグの早期発見：本番環境に出る前に問題を見つける
• コード品質の維持：可読性や保守性の基準を揃える
• 知識の共有：チーム内で技術やドメイン知識を伝播させる
• 設計の妥当性確認：アーキテクチャレベルの判断を複数人で検証する

レビュイー（レビューを受ける側）の作法

良いプルリクエストの書き方

プルリクエストの説明テンプレート

## 概要
ユーザー登録フォームにバリデーションを追加

## 変更内容
- メールアドレスの形式チェックを追加
- パスワードの強度チェックを実装
- エラーメッセージの表示コンポーネントを作成

## 動作確認
1. /signup にアクセス
2. 不正なメールアドレスを入力 → エラー表示を確認
3. 8文字未満のパスワードを入力 → エラー表示を確認

## 関連Issue
#123

セルフレビューの習慣

プルリクエストを作成したら、まず自分で差分を確認します。

• デバッグ用のコードが残っていないか
• 不要なコメントアウトがないか
• テストが通っているか
• 変更に関係のないファイルが含まれていないか

レビュアー（レビューする側）の作法

コメントの書き方

# 悪い例
ここ違う

# 良い例
この条件分岐だと、userがnullの場合にエラーになる可能性があります。
Optional chainingを使うとより安全です：user?.name

レビューコメントのレベル分け

レビューの心構え

1. コードに対してコメントする（人格ではなく）
2. 提案型で書く：「こうすべき」ではなく「こうすると良いかも」
3. 良い点も伝える：ポジティブなフィードバックも重要
4. 迅速に対応する：24時間以内のレビュー開始を目指す
5. 完璧を求めすぎない：80点で十分。あとはイテレーションで改善

よくある問題と対処法

レビューが遅い

チームでSLA（例：24時間以内にレビュー開始）を決めるのが効果的です。小さなPRほど早くレビューできるため、PR の粒度を小さくする工夫も有効です。

指摘が多すぎて心が折れる

レビュアーはコメントのレベル分けを徹底しましょう。必須の修正と「あれば嬉しい」改善を明確に分けることで、レビュイーの負担が減ります。

設計レベルの手戻りが発生する

大きな変更は、実装前に設計ドキュメントやRFC（Request for Comments）で方向性を合意しておくと手戻りを防げます。

まとめ

コードレビューはチームの文化そのものです。技術的な正しさだけでなく、相互尊重のあるコミュニケーションを意識しましょう。良いレビュー文化があるチームは、個々のスキルも組織の生産性も自然と向上します。

あわせて読みたい

• Git・GitHub入門ガイド
• チーム開発でのGitブランチ戦略
• エンジニアの1on1面談の受け方
• CI/CD入門（GitHub Actions）