필사 모드: コードレビュー 完全ガイド: レビューをプロセスとして設計する

• はじめに
• 1. レビューが実際に存在する4つの理由
• 2. 承認基準を文書化する
  • 2-1. 基準がなければレビュアーの好みが基準になる
  • 2-2. 何が根拠になるか
  • 2-3. チーム文書に入れる最小項目
• 3. 変更サイズがほとんどすべてを決める
  • 3-1. サイズは他のあらゆる指標の上流にある
  • 3-2. サイズを縮める具体的な方法
  • 3-3. サイズ規則を運用する方法
• 4. レイテンシ — 1営業日規則とその根拠
  • 4-1. 規則
  • 4-2. なぜ速度がそれほど重要か
  • 4-3. 集中時間との衝突
• 5. 何を人が見て、何を自動化に押し出すか
• 6. 所有権と承認規則
  • 6-1. 誰が承認できるか
  • 6-2. 論争: 承認はいくつ必要か
  • 6-3. 論争: レビューはマージを止めるべきか
• 7. コメントの等級 — 妨げるものと妨げないもの
  • 7-1. 等級がなければすべてのコメントが遮断として読まれる
  • 7-2. 論争: コメントを付けたまま承認するのは健全か
• 8. 合意できないときのエスカレーション
• 9. レビュープロセスを測る指標とその誤用
  • 9-1. 見る値打ちのある指標
  • 9-2. 個人の指標にした瞬間に壊れる
• クイズ: 理解度を確認しましょう
• おわりに
• 参考資料
• 関連記事

はじめに

このブログにはコードレビューを扱った記事がすでにあります。コードレビューの対話術と教えるコードレビュー、傷つけるコードレビューは、どちらも言葉がどう伝わりどう届くかを扱っています。良い記事ですが、その2本が扱っていない層が1つあります。

本記事はレビューを会話ではなくシステムとして見ます。スループットがあり、レイテンシがあり、待ち行列があり、所有権があるプロセスです。同じチームで同じ人が同じように丁寧に話しても、変更が800行で最初の応答まで3日かかればレビューは失敗します。逆にプロセスがうまく設計されていれば、平凡なコメントでも役目を果たします。レビュー品質の問題のかなりの部分は、口調ではなく配置の問題です。

基準にはGoogleのエンジニアリング慣行の文書2本を使います。公開されている資料の中で承認基準と応答速度をもっとも具体的に規定した資料であり、本記事の引用はすべてその原文から取っています。

1. レビューが実際に存在する4つの理由

レビューはバグを捕まえるためのもの、という前提でプロセスを組むとたいてい失敗します。欠陥の発見は4つの目的の1つにすぎず、しかももっとも確実なものでもありません。

• 欠陥の発見: 人が読んで捕まえられる欠陥は主に意図と実装の食い違いです。nullチェックの漏れや書式の問題は道具のほうがはるかにうまく捕まえます。人がうまく捕まえるのは、この関数が「やる」と言っていることと実際にやっていることが違う、という種類です。
• 設計圧力: 誰かが読むという事実だけで作成者の基準線が上がります。レビューが実際に開く前にすでに半分の効果が出ています。
• 知識の伝播: コードベースのどの部分を誰が知っているかを広げます。バス係数を下げるもっとも安い手段であり、長期的には欠陥の発見より値打ちがあります。
• 集団所有と記録: この決定はなぜこうなったのか、という根拠がレビューのスレッドに残ります。半年後、この記録はコミットメッセージよりも頻繁に読まれます。

目的が違えばプロセスも変わります。欠陥の発見が目的ならドメインを知る1人が深く見るほうがよく、知識の伝播が目的ならよく知らない人が一緒に見るほうがよいのです。2つの目的を1つのレビューに同時に載せると、どちらも中途半端になります。チームがどの目的を買っているかを明示しなければ、レビュアーごとに違う基準で見ることになり、そのばらつきは作成者には「人によって言うことが違う」と体感されます。

2. 承認基準を文書化する

2-1. 基準がなければレビュアーの好みが基準になる

レビューがもっとも大きく崩れるのは、承認基準が暗黙のときです。あるレビュアーは完璧を求め、別のレビュアーは適当に通すなら、作成者はレビュアーの割り当て結果によって通過が決まる経験をします。これは公平性の問題である前に予測可能性の問題であり、予測できないプロセスは迂回されます。

Googleのレビュアー基準の文書はこの点に一文を示します。"In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect."

この一文の核心は2つです。判定の対象が変更自体の完成度ではなくシステム全体のコード健全性の方向であること、そして完璧でなくても承認することです。基準が完璧なら承認はレビュアーの忍耐力に依存し、基準が方向なら判定は再現可能になります。

2-2. 何が根拠になるか

同じ文書は意見の衝突を解く順序も定めます。技術的事実とデータが意見や個人の好みに勝ちます。スタイルの問題はスタイルガイドが権威であり、ガイドになければ個人の好みではなく既存コードとの一貫性に従います。この順序が明示されていれば、私の好みではという形のコメントは自然に減ります。

2-3. チーム文書に入れる最小項目

承認基準（1枚）

承認する        システムのコード健全性が明らかに良くなる方向なら
                完璧でなくても承認する
承認しない      正しさの欠陥 / セキュリティ問題 / 戻しにくいインターフェース決定 /
                ロールバック経路がない / テストなしで振る舞いが変わる
根拠の優先順位  技術的事実・データ > スタイルガイド > 既存コードとの一貫性 > 個人の好み
妨げないコメント  Nit: の接頭辞を付け、作成者が飛ばしてよい

この1枚があれば、レビューの論争のかなりが文書を指すことで終わります。なければ毎回ゼロから交渉し直すことになります。

3. 変更サイズがほとんどすべてを決める

3-1. サイズは他のあらゆる指標の上流にある

レビュープロセスで動かせる変数のうち、もっとも効果が大きいのはレビュアーの真面目さではなく変更サイズです。サイズが大きくなると、次のことが同時に悪化します。

• 着手の遅れ: 800行のものは「今は時間がない」の対象になります。待ち行列にもっとも長く留まる項目は、たいていもっとも大きい項目です。
• 検討密度の低下: 人が一度に保てる文脈には限界があります。一定のサイズを超えると読む速度は保たれても発見率が落ちます。大型の変更にLGTMだけが付く現象は、誠意の不足ではなく容量超過の症状です。
• やり直しコストの急増: 800行を書き終えてから設計方向が誤っていると指摘されると、戻すものが多すぎます。だからレビュアーが指摘を飲み込み、結果としてレビューが形式になります。
• 衝突とリベース: 大きな変更は長く開いたままになり、長く開いていれば衝突が増え、衝突を解くうちにまた大きくなります。

3-2. サイズを縮める具体的な方法

• 振る舞いの変更と構造の変更を分ける: リファクタリングと機能追加を1つの変更に混ぜると、レビュアーが本当の変化を見つけられません。純粋な移動や改名は別の変更として先に送ります。
• インターフェースと実装を分ける: インターフェースと契約を先に合意すれば実装のレビューははるかに速くなります。戻しにくい決定を前倒しする効果もあります。
• フラグの裏で細切れに入れる: 完成まで無効の状態でマージすれば各片が小さく保たれます。フィーチャーフラグとプログレッシブデリバリーの方式がそのまま適用できます。
• 生成コードと大量移動は別枠に: 自動生成物や書式の一括適用はレビュー対象ではない別の変更として送り、コミットメッセージに再現コマンドを残します。

3-3. サイズ規則を運用する方法

絶対的な行数の上限を規則にすると迂回が生まれます。代わりにサイズに応じて手順を変える方式がよく働きます。一定規模を超えたらレビュー依頼の前に設計合意を求めるか、分割計画を本文に書かせる、といった形です。作成者に「なぜこれほど大きくなったか」を一行で説明させるだけでも、かなりの割合が自ら分かれます。

4. レイテンシ — 1営業日規則とその根拠

4-1. 規則

Googleのレビュー速度の文書は上限を明示します。"One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning)." そして "If you are not in the middle of a focused task, you should do a code review shortly after it comes in" と付け加えます。

注意すべきは、この規則が応答時間についてのものであって承認時間についてのものではない点です。同じ文書は、個々の応答の遅れが全体の所要時間より重要だと説明します。レビューが何度往復しても各往復が速ければ全体の体験は良く、往復1回に3日かかれば2回で1週間が消えます。

4-2. なぜ速度がそれほど重要か

同じ文書は2つの根拠を示します。1つは "Most complaints about the code review process are actually resolved by making the process faster" です。レビュープロセスへの不満の大半が、実際には速度の問題だということです。もう1つは波及効果です。"Slow reviews also discourage code cleanups, refactorings, and further improvements to existing CLs."

2つ目のほうが重要です。レビューが遅いと、コストの大きい変更だけが残ります。整理やリファクタリングは急ぎではないので待ち行列で後回しになり、後回しになると知っている人は最初から始めません。そうしてコード健全性がじわじわ悪化します。レビューの遅れはレビュー品質の問題ではなく、技術的負債が積み上がる経路です。負債が積み上がる経済構造はリファクタリングの経済学に整理されています。

4-3. 集中時間との衝突

同じ文書は、集中作業の最中はレビューのために流れを断つなとも述べます。この2つを同時に満たすには、レビューを割り込みではなく予定として扱う必要があります。

• 1日2回のような固定のレビュー枠を取ります。ランダムに処理すると流れが切れ、枠がなければ1日の終わりまで先送りされます。
• 待機中のレビューをチーム単位で見えるようにします。個人の通知箱にだけあると、古い項目が静かに埋もれます。
• 閾値の時間を超えた依頼は自動で昇格させ、別のレビュアーに回します。特定の人待ちで放置されるのがもっとも多い遅延要因です。
• 時間帯の異なるチームなら、上限をそのチーム基準で書き直します。1営業日規則は勤務時間が重なるという前提の上にあります。

5. 何を人が見て、何を自動化に押し出すか

人のレビュー予算は有限です。機械のほうが得意なことを人が見ていれば、人にしか見えないものを見る時間が消えます。

原則は1つです。一度でもレビューで繰り返された指摘は自動化の候補です。同じコメントを3回書いたなら、それは人の仕事ではなく規則の仕事です。自動化に移せないなら、せめて文書に移して毎回交渉しないようにします。

AIレビュー道具もこの表の左の列を広げる方向で見ます。ただし自動の提案は承認ではなくコメントとして扱うほうが安全です。判定の責任が人に残っていなければ、誰も読まない承認が積み上がります。

6. 所有権と承認規則

6-1. 誰が承認できるか

所有権の規則がなければ、2つの失敗が交互に現れます。誰でも承認できればドメインを知らない人が通してしまい、特定の人しか承認できなければその人がボトルネックになり、休暇のときにチームが止まります。

実務でよく働く構成は、経路ごとの所有者リストをリポジトリに置き、所有者グループを最低3人以上に保つことです。所有者が1人の経路が残っているなら、それはレビュー規則の問題ではなくバス係数の問題です。

6-2. 論争: 承認はいくつ必要か

ここはチームごとに答えが分かれます。

• 1人承認側: 2つ目の承認の限界効用は低いという主張です。2人必要なら2人の予定が重ならねばならず遅延が増え、責任が分散してかえって各自が念入りに見なくなります。
• 2人承認側: 決済や権限のように失敗コストが非対称に大きい領域では、2つ目の目が値打ちを果たします。規制要件として必須の組織もあります。
• 実際の分岐軸: 戻すコスト、規制要件、チームの規模とドメイン知識の分布、そして現在のレイテンシの余裕。

折衷案として経路ごとの差別化が広く使われます。大半の経路は1人、認証・決済・マイグレーションのような高リスク経路だけ2人という方式です。規則がリポジトリにあれば例外交渉が減ります。

6-3. 論争: レビューはマージを止めるべきか

より根本的な論争もあります。トランクベース開発やペアプログラミングを行うチームには、レビューはマージを止めるべきでないと見る側があります。ペアで書けばすでに2人が見ており、マージ後のレビューのほうがバッチサイズを小さく保って統合頻度を上げる、という主張です。

• 止めるべき側: マージ後のレビューは実質的にレビューが消える経路になります。戻すコストが大きく、指摘が出ても後続作業が優先順位で押し出されます。
• 止めるべきでない側: マージの遮断は待ち行列を作り、待ち行列はバッチを大きくします。安全はレビューではなくテスト・フラグ・カナリア・素早いロールバックで確保するほうがよいという立場です。
• 実際の分岐軸: ロールバックがどれだけ安いか、ペアリングの比率がどれだけ高いか、規制が承認記録を要求するか、そしてチームの経験分布がどれだけ均一か。

ロールバックが数分で終わりカナリアのあるチームと、リリースが月1回で戻しにくいチームの答えが同じになるはずがありません。どちらを選ぶにせよ、その選択がどんな前提の上にあるかを書き残すほうがよいでしょう。

7. コメントの等級 — 妨げるものと妨げないもの

7-1. 等級がなければすべてのコメントが遮断として読まれる

作成者にとってもっとも消耗する状況は、どのコメントを必ず反映すべきか分からないことです。10個のコメントが同じ重さに見えれば、全部反映するか全部無視するかになります。

Googleの文書はここに簡単な慣行を示します。必ずしも反映しなくてよい仕上げの提案には Nit: の接頭辞を付け、作成者が飛ばせるようにすることです。この慣行を少し広げて等級を明示すると、往復が目に見えて減ります。

Blocking:  反映しなければ承認しない（正しさ・セキュリティ・戻しにくい決定）
Nit:       仕上げの提案、作成者が飛ばしてよい
Question:  理解のための質問、答えるだけでよい
FYI:       今回の変更と無関係の情報共有
Later:     別課題として残す後続作業（ここでは扱わない）

接頭辞5つを導入するコストはほぼゼロで、効果は即座に出ます。とりわけLaterの等級があると、ついでにという理由で変更が膨らむ現象が減ります。

7-2. 論争: コメントを付けたまま承認するのは健全か

これもチームによって分かれます。

• 健全だとする側: 些細な指摘のために丸一日待たせるのは無駄です。作成者を信頼して反映を任せれば往復が消えます。
• 健全でないとする側: 実際にはかなりの割合が反映されずに過ぎます。承認が出たあとは確認する人がいないので、コメントは記録としてだけ残ります。
• 実際の分岐軸: チームの後続反映の実施率、コメント等級の体系の有無、そしてその変更が戻しやすいか。

等級の体系があり実施率が高ければコメント付き承認はうまく働き、等級もなく実施の有無を誰も見ていないなら、それは事実上の無条件承認です。制度を導入する前に実施率を先に測るほうが賢明です。

8. 合意できないときのエスカレーション

レビュープロセスでもっとも頻繁に抜け落ちるのがこの部分です。多くのチームは合意できる場合だけを想定して規則を作ります。

Googleの文書は原則を短く示します。"Don't let a CL sit around because the author and the reviewer can't come to an agreement." 膠着そのものがコストだということです。

実務の手順に移すとこうなります。

段階1  往復2回で解決しなければ非同期のコメントを打ち切る
       （テキストで3回以上やり取りする論争はほとんど収束しない）

段階2  15分の通話か対面に移し、結論をレビューのスレッドに要約して残す
       （チャネルは変えても記録はレビューに残す）

段階3  それでも駄目なら判定の根拠を明示する
       技術的事実・データ > スタイルガイド > 既存コードとの一貫性

段階4  判定者が必要ならあらかじめ決めた役割が決める
       （当該領域の所有者 → テックリードの順を文書に書いておく）

段階5  決定を文書に反映する
       同じ論争が2回起きたなら、それはガイドがないということ

核心は段階3と段階5です。根拠の優先順位があらかじめ決まっていれば論争が好みの対決に流れず、結論を文書に戻せば同じ論争が繰り返されません。段階5がなければチームは四半期ごとに同じ論争をやり直します。レビューで主張を説得力をもって書く方法は文章で説得するに整理されています。

9. レビュープロセスを測る指標とその誤用

9-1. 見る値打ちのある指標

• 最初の応答までの時間: 1営業日規則に直接対応します。平均ではなく上位パーセンタイルで見ます。平均4時間でも上位10%が3日なら、その3日がチームの体感を支配します。
• 変更サイズの分布: 中央値と上位パーセンタイルを併せて見ます。上位の裾が長ければ3章の措置が必要です。
• 往復回数: 3回を超える変更が増えたら、承認基準かコメント等級が不明瞭だという合図です。
• 待ち行列の年齢: 開いてから長い項目の数です。この値が上がったら個人ではなくバッチ規則を見ます。
• 変更リードタイムと変更失敗率: DORAは変更リードタイムを "The amount of time it takes for a change to go from committed to version control to deployed in production" と、変更失敗率を "The ratio of deployments that require immediate intervention following a deployment" と定義します。レビュープロセスを変えたときにこの2つがどう動くかが最終的な判定です。

DORAは速度と安定性が相反しないと述べます。"DORA's research has repeatedly demonstrated that speed and stability are not tradeoffs." レビューを速くしたら変更失敗率が上がったのなら、それは折衷ではなく別の問題があるということです。

9-2. 個人の指標にした瞬間に壊れる

レビュー指標は個人評価に結び付いた瞬間、すべて歪みます。

• 書いたコメント数を測れば意味のないコメントが増えます。
• 承認の速さを測れば読まずに承認します。
• レビューした変更数を測れば小さいものだけ選んで見ます。
• 作成者別の指摘件数を測ればレビューが防御的になり、率直な指摘が消えます。

だから指標は人ではなくプロセスに付けます。最初の応答時間が悪いなら、それは特定の人の怠慢ではなく割り当て規則と枠の設計の問題として見ます。変更サイズの裾が長ければ作成者を指摘する代わりに分割の手順を作ります。

もう1つ重要なのは、欠陥の発見数をレビュー効果の代理指標に使わないことです。1章で見たとおり欠陥の発見はレビューの4つの目的の1つであり、知識の伝播や設計圧力はこの数字にまったく現れません。指摘が減ったという事実は、レビューが無力になったという意味かもしれず、上流が良くなったという意味かもしれません。数字だけでは区別できません。

クイズ: 理解度を確認しましょう

おわりに

コードレビューを改善しようとする試みは、たいてい口調に始まり口調に終わります。口調は重要ですが、同じ人が同じ文を書いても、変更が800行で応答が3日後に来ればそのレビューは失敗します。レビューは会話である前に待ち行列を持つプロセスです。

プロセスとして見れば手を入れる場所は明確です。承認基準を1枚に書いて判定を再現可能にし、変更サイズを縮めて上流を直し、最初の応答時間に上限を置き、機械が得意な仕事を人から取り除き、コメントに等級を付けて何が遮断かを明確にし、膠着にはあらかじめ決めた出口を用意します。

そして指標は人ではなくプロセスに付けます。レビューが遅いのは、たいてい誰かが怠けているからではなく配置がそうなっているからです。配置を直すほうが、人を急かすよりつねに効果が大きいのです。

参考資料

• The Standard of Code Review — Google Engineering Practices — 完璧でなくてもコード健全性が明らかに改善するなら承認せよという基準、技術的事実とデータが好みに優先するという順序、スタイルガイドと既存コードの一貫性の位置、仕上げの提案に付ける接頭辞の慣行、合意できないことを理由に変更を放置するなという一文を引用しました。2026-08-15確認。
• Speed of Code Reviews — Google Engineering Practices — 1営業日の応答上限、集中作業中でなければすぐレビューせよという推奨、不満の大半が速度で解決するという一文、遅いレビューが整理とリファクタリングを萎縮させるという指摘、個々の応答の遅れが全体の所要時間より重要だという説明を引用しました。2026-08-15確認。
• DORA — Four keys metrics — 変更リードタイムと変更失敗率の定義、速度と安定性が相反しないという研究結果を引用しました。2026-08-15確認。
• レビューの4つの目的の区別、コメント等級の5種類、5段階のエスカレーション手順、人と自動化の分担表は上記資料に出てくるものではなく、本記事で整理した手順です。

関連記事

• このブログの関連記事: コードレビューの対話術
• このブログの関連記事: 教えるコードレビュー、傷つけるコードレビュー
• このブログの関連記事: 文章で説得する — 設計文書とRFCが通る構造
• このブログの関連記事: リファクタリングの経済学、いつコストが回収されるか
• 関連ツール: 協業RPG

完全ガイドシリーズ

• 前の記事: テスト戦略 完全ガイド: ピラミッド論争ではなく判断基準
• 次の記事: デプロイ戦略 完全ガイド: 戻せるものと戻せないもの