フレームワーク活用ガイドひとことで言うと#
他の開発者が書いたコードを体系的にチェックし、フィードバックを返すプラクティス。バグの早期発見だけでなく、知識共有やコードの一貫性維持にも効果がある。PR（プルリクエスト）ベースのレビューが現在の主流。
押さえておきたい用語#
- プルリクエスト（Pull Request / PR）
- 変更したコードをメインブランチに取り込んでもらうためのレビュー依頼の単位のこと。変更内容・目的・影響範囲を記載し、レビュアーにフィードバックを求める。
- LGTM（Looks Good To Me）
- レビュアーが「問題なし」と判断したことを示す承認の合図のこと。チームによってはApproveボタンのクリックと同義で使われる。
- Nit（Nitpick）
- 「重箱の隅をつつく」程度の軽微な指摘のこと。修正しなくてもマージ可能だが、改善すると品質が少し上がるコメント。
- バス因子（Bus Factor）
- 特定のメンバーが不在になった場合にプロジェクトが停止する属人化のリスク度合いのこと。コードレビューはバス因子を改善する有効な手段。
コードレビューの全体像#
こんな悩みに効く#
- 特定の人しか理解できないコードが増え、バス因子が1になっている
- 本番リリース後にバグが見つかることが多い
- コーディング規約はあるが、実際に守られていない
基本の使い方#
何を見るかを事前に明確にする。
- 正確性: ロジックにバグはないか？エッジケースは考慮されているか？
- 可読性: 変数名は適切か？コメントは必要十分か？
- 設計: 責務の分割は適切か？SOLID原則に沿っているか？
- テスト: テストは書かれているか？テストケースは十分か？
ポイント: すべての観点を毎回見るのではなく、チームで優先順位を決める。
指摘は具体的かつ建設的に、提案を添えて書く。
- 「ダメ」ではなく「こうするともっと良くなる」の形式で
- 「なぜ」を説明する（教育効果がある）
- 重要度を明示する（Must / Should / Nit）
- 良いコードにはポジティブなコメントも
ポイント: レビューは「人」ではなく「コード」に対して行う。
レビューしやすいサイズのPRを作る文化を作る。
- 理想は200〜400行の変更
- 大きな変更はタスクを分割して複数のPRにする
- PRの説明文に「何を・なぜ・どうやって」を書く
ポイント: 1000行超えのPRは、レビュアーの集中力が持たず、品質が下がる。
PRが長時間放置されない仕組みを作る。
- レビュー依頼から24時間以内に初回レビューを返す
- Slackやメールの通知を設定する
- レビュアーのアサインを自動化する（CODEOWNERS等）
ポイント: レビュー待ちが長いと、開発者がコンテキストスイッチを強いられ生産性が落ちる。
具体例#
PRの概要: JWTを使ったログイン機能の追加。300行の変更。
レビューコメント例:
- [Must]
tokenの有効期限が3600秒にハードコードされています。環境変数JWT_EXPIRY_SECから設定できるようにしてください。→ セキュリティポリシー変更時にコード修正が不要になります。 - [Should]
validateToken()の中でDB接続エラーをcatchしていますが、エラーログが未出力です。logger.error()を追加すると障害調査が平均30分短縮できます。 - [Nit] 58行目の変数名
dはdecodedTokenの方がわかりやすいです。 - [Good] リフレッシュトークンのローテーション実装、セキュリティの観点でとても良いですね。
結果: レビュイーは「Must 1件を必ず修正、Should 1件を対応、Nit 1件は次回以降」と優先順位が即座に判断できた。
Before: レビュー依頼から初回レスポンスまで平均48時間。PR滞留数は常時15件以上。開発者は「レビュー待ち」でコンテキストスイッチを月に40回以上強いられていた。
改善策:
- CODEOWNERSファイルを設定し、ディレクトリごとに自動でレビュアーをアサイン
- Slackに
#pr-reviewチャンネルを作成し、新規PR通知を自動投稿 - 毎日15時にレビュー未対応PRをリマインド通知
After: 初回レスポンスが平均48時間→6時間に短縮。PR滞留数が15件→3件に減少。月のコンテキストスイッチ回数が40回→12回に改善。
状況: チームに入社3ヶ月の新メンバーがいる。コードの品質にばらつきがあり、チームの設計方針を理解していない箇所がある。
レビューの工夫:
- 新メンバーのPRにはシニアエンジニアがメインレビュアーとして必ずアサイン
- 指摘だけでなく「なぜそうするか」を参考リンク付きで説明
- 良い実装には**[Good]コメント**を積極的に付けてモチベーションを維持
3ヶ月後の効果: 新メンバーのPRに対する[Must]指摘が月12件→2件に減少。チームの設計パターンに沿ったコードが自然に書けるようになった。レビューが最強のOJTツールになった。
やりがちな失敗パターン#
- 細かいスタイルの指摘ばかりする — インデントや括弧の位置の指摘に時間を費やす。スタイルはリンターに任せ、人間はロジックと設計をレビューする
- レビューが承認のスタンプラリーになる — 中身を見ずにApproveする文化になっている。レビュー1件あたり最低1つはコメントを残すルールにする
- レビューが攻撃的になる — 「なんでこんな書き方するの？」のような表現は心理的安全性を壊す。「〜するとさらに良くなります」の提案型で書く
- PRが大きすぎてレビューが形骸化する — 1,000行を超えるPRは細部を見落とす。PRテンプレートにサイズガイドラインを明記し、300行以内を推奨する
よくある質問#
Q: PRの理想的なサイズはどのくらいですか？ A: 1PRあたり200〜400行が目安です。これ以上になるとレビュアーの集中力が落ち、重要なバグを見落とすリスクが高まります。大きな機能追加は「設計PR（インターフェース・型定義のみ）→ 実装PR（複数に分割）」と段階的に出すことを検討してください。
Q: Must / Should / Nit はどう使い分けますか？ A: Mustはバグ・セキュリティ問題・契約違反など修正必須の指摘、Shouldは品質改善として強く推奨する提案、Nitはスタイルや好みの軽微なコメントです。レビュアーはラベルを明示することでレビュイーが優先順位を付けやすくなります。Mustがなければ他のコメントが残っていてもApproveして問題ありません。
Q: レビューの返答にはどのくらいの時間で対応すべきですか？ A: 一般的なガイドラインは24時間以内です。レビュー依頼を受けたら翌営業日中に返答するのを基準にすると、PRが滞留しません。レビュアーが複数いる場合は担当者を明確にしておくことが重要です。
Q: コードのスタイルに関するコメントはすべきですか？ A: インデントや括弧位置などのスタイルはリンター（ESLint、Prettierなど）に任せ、CIで自動チェックするのが理想です。人間のレビューはロジックの正確性・設計の妥当性・テストカバレッジに集中させましょう。スタイルのコメントが多いとレビューの本質的な価値が薄れます。
まとめ#
コードレビューはバグ発見だけでなく、チームの知識共有と文化づくりの手段。適切なPRサイズ、建設的なフィードバック、迅速なレスポンスの3つが揃えば、チーム全体のコード品質が底上げされる。まずは 「Must/Should/Nit」 のラベル付けから始めてみよう。