コードレビューを導入したのに、「中身を見ずにLGTM（Looks Good To Me）で通ってしまう」「特定のベテランしかレビューできず、その人がボトルネックになる」「指摘が個人攻撃のように受け取られて雰囲気が悪くなる」——こうしてレビューが形骸化する現場は珍しくありません。

これは、レビューを「入れたかどうか」ではなく、社内でどう運用するかの設計が抜けているために起きます。この記事では、社内のコードレビューが機能し続ける運用体制の作り方を、観点の明文化から負荷分散までの手順で解説します。なお、外部の専門家に設計・技術レビューへ入ってもらう話は自社プロダクトの設計レビューに外部の専門家を入れるで扱っており、本記事は社内でレビューを回す運用に絞ります。ドキュメント面の整備は開発ドキュメントの整備の進め方もあわせてご覧ください。

なお筆者・馬込は、複数のプロダクト開発でコードレビューを担い、レビュー基準の整備やチームメンバーへのレビュー指導を行ってきました。本記事はその実務目線でまとめています。

結論：レビューは「観点」と「負荷分散」を設計すると形骸化しない

レビューが形骸化するのは、何を見るか（観点）が曖昧で、特定の人に集中しているからです。逆に言えば、観点を明文化し、レビューできる人を増やし、指摘の作法を揃える——この3点を設計すれば機能します。順に見ていきます。

手順1：レビューの「観点」を明文化する

まず、レビューで何を見るかを言語化します。観点が共有されていないと、人によって見る場所がバラバラで、重要な問題が見逃されます。

観点 見るポイントの例
正しさ 仕様どおりか、エッジケース、テストの有無
設計 責務の分割、既存構造との整合、拡張性
可読性 命名、複雑さ、後から読んで分かるか
安全性 入力検証、権限、機密情報の扱い

すべてを毎回完璧に見る必要はありません。「最低限ここは見る」という観点リストがあるだけで、LGTMだけの素通りは大きく減ります。

手順2：レビューできる人を増やし、負荷を分散する

特定のベテランにレビューが集中すると、その人がボトルネックになり、レビュー待ちで開発が止まります。レビューできる人を計画的に増やします。

  • 観点リストを共有し、若手も観点に沿ってレビューに参加する
  • ベテランのレビューコメントを教材にして、レビューの目を育てる
  • レビュアーを固定せず、ローテーションやペアレビューで分散する

レビューは「品質を守る作業」であると同時に「知見が伝わる場」です。参加者を広げることは、負荷分散だけでなく属人化の解消にもつながります。

手順3：指摘の作法と粒度を揃える

同じ指摘でも、伝え方次第でチームの雰囲気は変わります。レビューが個人攻撃に見えると、萎縮して率直な議論ができなくなります。

  • 指摘は「コードに対して」行い、人格に向けない
  • 「must（直す）／nits（好みの提案）」のように、指摘の強さを区別する
  • 大きな設計の齟齬は、プルリクエストの前に相談する（レビューで初めて発覚させない）

作法を揃えると、レビューが「詰める場」ではなく「良くする場」になります。心理的な安全があってはじめて、レビューは継続します。

手順4：レビューが機能しているかを確認する

観点を決め、レビュアーを増やし、作法を揃えた——それで終わりではありません。レビューが実際に機能しているかは、意識して見ないと分からないからです。形骸化は、ある日突然ではなく、じわじわ進みます。

見るべきは、次のような兆候です。

兆候 何を意味するか 打ち手
指摘がほぼ出ない 観点が共有されていない／素通り 観点リストを見直す
レビュー待ちが長い レビュアーが偏っている レビュアーを増やす・PRを小さく
同じ指摘が繰り返される 個別指摘で終わり、規約に還元されていない 頻出指摘を規約・自動チェックへ

3つ目は見落とされがちですが重要です。同じ指摘を毎回人が手で書いているなら、それは規約に書くか、自動チェックに任せるべきサインです。人のレビューは、機械にできない設計判断にこそ使います。

もう一つの確認は、レビューが「良くする場」として機能しているかという空気の面です。指摘が減っているのが、質が上がったからなのか、それとも「言っても仕方ない」と諦められているからなのか——この2つは数字だけでは見分けられません。ときどきチームに直接聞いてみることが、いちばん確実です。

よくある落とし穴

  • 観点がなくLGTMで素通り：何を見るかが曖昧だと形骸化します。最低限の観点リストを作ります。
  • 特定の人に集中する：ボトルネックになり、レビュー待ちで止まります。レビュアーを増やし分散します。
  • 指摘が人格に向く：萎縮して率直な議論が消えます。コードに対して、強さを区別して指摘します。
  • 大きな設計をレビューで初めて指摘する：手戻りが大きくなります。設計は着手前に相談します。
  • 同じ指摘を毎回人が書く：規約や自動チェックに任せられる部分です。人のレビューは、機械にできない設計判断に使います。

よくある質問

Q. 少人数チームでもコードレビューは必要ですか？ A. 必要です。少人数ほど属人化しやすく、レビューは知見を共有する数少ない機会になります。人数が少ない場合は、全項目を厳密に見るより、観点を絞って「最低限ここは見る」を回すほうが継続します。

Q. レビューに時間がかかりすぎて開発が遅れます。どうすればいいですか？ A. 多くは、プルリクエストが大きすぎることが原因です。変更を小さく分割すると、レビューが速く正確になります。あわせて観点リストで見る場所を絞り、レビュアーを分散すると、待ち時間が短くなります。

Q. レビュー基準は誰が決めるべきですか？ A. 開発責任者やリード級が叩き台を作り、チームで合意する形が現実的です。トップダウンで押し付けるより、チームが納得した基準のほうが守られます。運用しながら、実態に合わせて更新していきます。最初から完璧な基準を作ろうとせず、「まずこの3点だけ見る」程度で始めて、実際のレビューで繰り返し出た指摘を足していくほうが、現場に馴染みます。

コードレビューは、①観点の明文化 ②レビュアーを増やして負荷分散 ③指摘の作法を揃える、という運用設計があれば形骸化しません。レビューを「入れる」ことより「回す仕組み」を作ることが、品質とチームの成長の両方につながります。

社内の開発体制づくりやレビュー運用の相談は、開発支援について相談するからお問い合わせください。