今日のコードレビュー、また8人も呼ばれてる…。話してるのって結局2人だけなのに、なんで人数こんなに多いんだろう？
IT業界30余年、フリーランスのシルバーエンジニア。おにぎりです。
「レビュー」
システムを開発していくうえで、避けてはとおれない重要なタスクの一つですが、
レビューが形骸化している現場では、「とりあえず多く呼んでおけば安心」という空気が生まれがちです。でも、レビュアーが多すぎることがかえって品質を下げているケースは非常に多い。
この記事でその構造的な問題と、現場で今すぐ使える解決策をお伝えします。
結論：レビューは「人数」ではなく「設計」で決まる
コードレビューの人数が多いことは「安心感」ではなく「責任の分散」を生む。
レビューで本当に必要なのは、目的に合った2〜3人の適切なレビュアーと、明確な観点の設計だ。
この3つが揃えば、人数を絞っても品質は上がる。
コードレビューの人数が多すぎると何が起きるか
正直、8人いるのに発言するのって毎回同じ2〜3人なんですよね。他の人は何のためにいるんだろうって思って…
それ、典型的な「人数が多すぎるレビュー」の症状だよ。問題は発言しない人がいることじゃなくて、そもそもなぜ8人呼んだのかが設計されていないことなんだ。
問題①：傍観者効果が起きる
心理学の「傍観者効果」はレビューでも発生します。参加者が多いほど、「誰かが指摘するだろう」という意識が働き、一人ひとりの責任感が薄れます。結果として、本来なら発見されるべきバグや設計上の問題が素通りしてしまうのです。
特にコードレビューでは、「ベテランが見てるから大丈夫」「自分より詳しい人がOKしたなら問題ないはず」という認知が働きやすく、8人いても実質ゼロ確認に近い状態になることがあります。
問題②：指摘が発散してまとまらない
参加者が多いと、それぞれが異なる観点から指摘を出し始めます。ある人はコーディングスタイルを指摘し、別の人は要件との整合性を問い、さらに別の人は命名規則に引っかかる。
観点が統一されていないため、指摘が発散してレビュー対象者が何を直せばいいのか分からなくなります。1時間かけたのに「TODO:後で検討」がたくさんついて終わり、という現場を何度も見てきました。
問題③：発言しにくい空気になる
会議でもレビューでも、参加人数が多いほど発言のハードルは上がります。特に若手エンジニアや経験の浅いメンバーは、「こんな指摘をして怒られないか」「的外れじゃないか」という不安から発言を控えます。
本来ならフレッシュな視点で気づけた問題も、この「空気」によって埋もれてしまう。結果として、ベテランが同じことを何度も言うだけのレビューになります。
問題④：時間コストが膨大になる
8人×1時間のレビュー = 8人時。月に4回あれば32人時のコストです。これは新機能開発に充てられたはずの工数でもあります。
人数が多いほどスケジュール調整も難しくなり、「レビューが詰まって開発が止まる」という本末転倒な状態が生まれます。
そもそも「レビュー」の種類と目的を整理する
一言でレビューと言っても、実は種類があって目的がバラバラなんだよ。まずここを整理しないと、誰を呼ぶかも決まらない。
コードレビューやシステムレビューには複数の種類があり、それぞれ目的とタイミングが異なります。
| 種類 | 目的 | 適正人数 | タイミング |
|---|---|---|---|
| ウォークスルー | 内容の共有・軽い確認 | 3〜5人 | 作成直後 |
| インスペクション | 品質担保・仕様検証 | 2〜4人 | 設計・実装完了時 |
| コードレビュー | コーディングルール確認 | 1〜3人 | 実装中または直後 |
| ピアレビュー | 相互チェック・ナレッジ共有 | 2〜3人 | 各工程の節目 |
コードレビューに限れば、最適な人数は 1〜3人 です。「関係しそうな人を全員呼ぶ」のは目的ではなくリスクヘッジの感情から来ていることがほとんどです。
レビュアーの適正人数はどう決めるか
じゃあ、誰を呼ぶかはどうやって決めればいいんですか？
「レビューの目的」から逆算するのが基本だよ。目的が決まれば、自然に必要な人材も見えてくる。
目的別・呼ぶべきメンバーの選び方
| レビューの目的 | 呼ぶべきメンバー | 人数の目安 |
|---|---|---|
| 仕様・要件の確認 | 業務エキスパート、PM | 1〜2人 |
| 技術的な妥当性 | ベテランSE、アーキテクト | 1〜2人 |
| コーディングスタイル確認 | 同じチームの開発者 | 1〜2人 |
| セキュリティ・パフォーマンス | 専門担当者 | 1人 |
目的が複数ある場合は、レビューを分けるのが正解です。1回のレビューで「仕様確認もコーディングも設計も全部やる」は無理があります。
「情報共有」と「レビュー」は分ける
よくある失敗が、情報共有目的の人をレビュアーとして呼んでしまうこと。「あとでQAチームも見るから念のため」「PMも把握してほしいから」という理由で人数が膨らみます。
情報共有は、レビュー後に議事録やレビュー記録表を展開することで代替できます。リアルタイムで同席する必要はありません。
レビュー効率を上げるための事前準備
人数を絞るのはわかりました。でも、準備って何をすればいいんですか？
実はレビューイ（レビューされる側）の準備が一番大事なんだよ。レビュアー任せにしているうちはいつまで経っても改善しない。
準備①：レビューの目的を書面で明示する
「このレビューで何を確認してほしいか」を事前にテキストで共有します。口頭だけで伝えると、レビュアーが当日まで何を見ればいいか分からない状態になります。
例：レビュー依頼時に明示する内容
- 今回確認してほしい観点（例：DB設計の冗長性、異常系の考慮漏れ）
- 確認不要な観点（例：命名規則は社内ツールで自動チェック済み）
- 特に迷っている点（例：テーブル分割の粒度に自信がない）
準備②：観点をチェックリスト化する
「何を確認するか」がレビュアーによってバラバラだと、指摘の質にムラが出ます。観点をチェックリストにテンプレート化しておくことで、誰でも一定水準の確認ができます。
設計書レビューの観点例
- 要件との整合性が取れているか
- 異常系・例外処理が考慮されているか
- 他システムとの整合性に問題はないか
- 拡張性・保守性の観点で問題はないか
- セキュリティ上のリスクはないか
準備③：「見てほしくない箇所」も伝える
意外と重要なのが「今回はここは見なくていい」という情報です。観点が絞られていないと、レビュアーは全体を均等に確認しようとして時間が足りなくなります。集中してほしいポイントを明示することで、レビューの密度が上がります。
レビュー当日に意識すること
事前準備ができたら、当日の進め方も変わってくるよ。特に開始直後の5分が大事。
冒頭で「目的」と「観点」を全員で確認する
レビューが始まったら最初に「今日は何を確認するか」を全員で共有します。これがないと、それぞれが勝手に気になったところを指摘し始め、議論が発散します。
冒頭の確認事項（例）
- 今日のレビューの目的（例：テーブル設計の妥当性確認）
- 確認する観点（チェックリストを画面共有）
- 終了条件（例：チェックリスト全項目にコメント済み）
指摘は「問題の種類」を明示してもらう
レビュアーには指摘の種類を明示してもらうよう依頼します。「バグ」「設計上の懸念」「提案」「疑問」など、カテゴリが明確だと修正の優先度がつけやすくなります。
「ここどうかと思う」という曖昧な指摘より、「パフォーマンス懸念：N+1クエリが発生する可能性あり（要確認）」の方が修正者にとってはるかに価値があります。
おにぎりの現場経験：レビュー人数を減らして品質が上がった話
あるプロジェクトで、毎回10人以上呼んでいた設計レビューを3人に絞ったことがあります。最初は「本当に大丈夫か」という声もありましたが、結果は逆でした。
3人全員が観点を持って真剣に確認するようになり、指摘の密度と質が格段に上がりました。「誰かが見てくれている」という空気がなくなったことで、各自が責任感を持って臨むようになったのです。
情報共有が必要な関係者には、レビュー後にレビュー記録表と議事録をSlackで展開するルールにしました。これで「把握しておきたい」という要望も満たせるようになり、全員が満足する形に落ち着きました。
レビューは「多く集めれば安心」ではありません。目的に合った人数で、集中して確認する時間にしてこそ価値が生まれます。
まとめ：コードレビューの人数問題を解決する5つのアクション
コードレビューの人数が多すぎると、傍観者効果・指摘の発散・時間コストの増大という三重の問題が起きる。解決策は「設計」にある。
明日からできるアクション
- 次回のレビュー依頼メールに「今回の確認観点」を3行追加する
- レビュー参加者リストを見直し、情報共有だけなら外す
- 社内用レビューチェックリストのテンプレートを1枚作る
人数を減らすのが目的じゃなくて、「誰が何を確認するか」を設計することが大事なんですね。次のレビューから意識してみます！
この記事を読んで、レビューについて「こういうケースはどうする？」という疑問があればぜひコメントで教えてください。現場経験をもとにお答えします。
コメント