Rui Softwareコードレビューは指摘ではなく共有：出す側と受ける側の作法【第5回】
レビューで10件の指摘が返ってきて心が折れた。あるいは、あなたがレビューする側になって「何を見ればいいのか分からない」と固まった。この記事を読み終えると、レビューを人格の審査ではなく意図の受け渡しとして捉え、出す側・受ける側・指摘する側のそれぞれで何を守ればすれ違わないかを説明できるようになります。ジュニアエンジニア向け開発フロー入門シリーズ（全8回）の第5回です。
🎯 テーマの主役：「コードレビュー」——非同期の会話
今回の主役はコードレビューです。一言で言えば、コードレビューとは「変更を渡す前に、意図が正しく伝わるかを他人の目で確かめる会話」です。
日常の例えで言うなら、引っ越し前の荷造りを友人に確認してもらうようなものです。あなたは「この箱は食器だから大事に運んで」と伝えたつもりでも、箱に何も書いていなければ、運ぶ人は分かりません。友人が「この箱、割れ物？」と聞いてくるのは、あなたの荷造りが下手だという指摘ではなく、伝達の穴の指摘です。レビューも同じで、指摘の多くはコードの欠陥ではなく、意図が伝わっていない箇所を指しています。
もう1つの例えは校正と校閲です。校正は誤字・脱字・表記の揺れを見ます。校閲は「この記述は事実として正しいか」「話の流れは通っているか」を見ます。コードレビューにもこの2層があり、表層（書き方・命名）と深層（正しさ・設計）では、見るべきものが違います。そして重要なのは、表層の多くは機械で確認できる（自動整形・静的解析）という点です。人間のレビューは、機械にできない深層に集中するのが合理的です。
第4回で、レビューに出せる形（小さなコミットとPR）を作りました。今回の第5回は関門5の「レビュー」そのものを掘ります。第1回の出口条件は「少なくとも1人が、変更の意図を自分の言葉で説明できる」でした。この条件を満たすには、出す側と受ける側の両方に作法が要ります。
この関門を通せるようになると、次の4つができるようになります。第一に、レビューで何を優先して見るかを決められること（全部を見ようとして固まらない）。第二に、指摘を、相手が動きやすい形で書けること。第三に、指摘を受けたとき、感情と技術を切り離して対応できること。第四に、「LGTM」だけのレビューを減らす仕組みを理解することです。
動機：レビューが「審査」に見えてしまう理由
ジュニアエンジニアがレビューで感じる負担は、方向の違う2種類あります。1つは受ける側の負担。「自分の書いたコードを否定される」「指摘の数が多いと、自分の実力が足りない気がする」。もう1つは出す側（指摘する側）の負担。「何を見ればいいか分からない」「指摘したら嫌われるのでは」「結局LGTMと書いてしまう」。
この2つは、実は同じ原因から来ています。それは、レビューが「審査」だと捉えられていることです。審査には合否があります。合格するために、受ける側は弱点を隠したくなり、指摘する側は責任を回避したくなります。この状態では、本当に見つけるべき問題が隠され、レビューは形骸化します。
実務では、レビューの目的は合否判定ではありません。変更の意図を共有し、間違いを早く見つけることです。第1回のコスト原則を思い出してください。レビューで見つけた問題の修正は、本番後の100分の1以下で済みます。レビューはチームの保険であり、受ける側のためではなく、全員のためにあります。
この記事の仮説はこうです。レビューの質は、指摘の数ではなく「重要度が伝わっているか」で決まる。もしこれが正しいなら、指摘する側はすべての指摘を同じ重さで書かないこと、受ける側は重要度に応じて対応を変えることが、すれ違いを減らす鍵になります。
🔍 検証①：レビューの目的は4つある——バグ発見だけではない
レビューの目的を「バグを見つけること」だけだと思うと、次のような失敗が起きます。バグがなかったときに「レビューする意味がなかった」と感じる。あるいは、バグ以外の指摘（読みやすさ・設計）を「細かい指摘」として軽視する。しかし実際の研究では、レビューの価値は複数の目的に分散しています。
マイクロソフトの研究者たちによる実証研究（Bacchelli & Bird, 2013）では、開発者がレビューから得ている効果として、欠陥の発見よりも「コードの理解」「チームの認識合わせ」「代替案の検討」が多いことが報告されています。また、グーグルの大規模な事例研究（Sadowski et al., 2018）では、コードレビューが知識共有・一貫性の維持・教育の場として機能していることが示されています。
| # | 目的 | 具体的に何が守られるか | 機械で代替できるか |
|---|---|---|---|
| 1 | 欠陥の発見 | バグ・例外処理漏れ・境界値の誤り | 一部可能（テスト・静的解析）。文脈依存の欠陥は人間の領域 |
| 2 | 設計の妥当性の確認 | 変えにくい構造になっていないか（第3回） | 難しい。意図と将来の変更の見通しが要る |
| 3 | 知識の共有 | 属人化の防止。休んだ人を誰かが代われる | 不可能。人から人への移動が本質 |
| 4 | 一貫性の維持 | 同じ問題への同じ解き方。読み方の統一 | 一部可能（規約の自動検査）。判断を伴う部分は人間 |
この4つを意識すると、レビューでの問いの形が変わります。「バグはないか」だけでなく「この変更を半年後に読んだ人は、なぜこうなっているか分かるか」「他の人が同じ問題に直面したとき、このコードを参考にできるか」と問うようになります。これが第1回の出口条件「意図を自分の言葉で説明できる」に直結します。
🔍 検証②：見る順番を決める——全部を同じ強さで見ない
レビューで固まる原因の多くは、全部を同じ強さで見ようとすることです。数百行の差分を前に、命名の好みから例外処理の妥当性まで同時に検討すると、集中力が尽きます。だから見る順番と優先順位を決めます。
推奨する順番は次のとおりです。①正しさ（要件を満たすか・壊れないか）→ ②設計（変えやすいか）→ ③読みやすさ（意図が読み取れるか）→ ④細部（命名・スタイル）。上位で問題が見つかったら、そこで一度止めてコメントします。下位の問題は、上位が解決してから見ても遅くありません。
| 優先度 | 観点 | 具体的に見るもの | 見つけたときの扱い |
|---|---|---|---|
| 1（最優先） | 正しさ | 受け入れ条件（第2回）を満たすか。失敗時の動作は決まっているか。既存の動作を壊していないか | 必ず指摘。マージを止める |
| 2 | 設計 | 境界は妥当か。同じ処理の重複はないか。変えにくい決定が記録されているか | 方針に関わるので早めに指摘 |
| 3 | 読みやすさ | 名前から意図が読めるか。関数の長さは適切か。コメントは「なぜ」を書いているか | 可能なら指摘。次回の改善でもよい |
| 4（最低） | 細部 | スタイル・整形・表記の揺れ | 自動化に寄せる。指摘するなら「どちらでもよい」と明示 |
特に重要なのが、優先度4を自動化に寄せるという判断です。インデント、改行、引用符の種類、行の長さ——こうした規則は、自動整形ツールや静的解析（リンタ）で機械的に検査・修正できます。人間がこれを指摘するのは、時間の使い方として最も効率が悪いだけでなく、指摘の山に重要な問題が埋もれる原因になります。第7回で扱うCIは、この自動化を仕組みとして組み込む話です。
🔍 検証③：指摘の書き方——コードについて話し、人格について話さない
指摘の書き方は、レビューの成否を分けます。原則は1つです。「コードについて話し、人について話さない」。そして実務的には重要度を明示することです。
まず、悪い例と良い例を比べます。悪い指摘の典型は「なぜこうした？」「これは普通やりません」「ダメです」です。これらは情報量がゼロか、判断を押し付けているかのどちらかです。受け取った側は、何を直せばよいか分からず、場合によっては人格を否定されたように感じます。
| 悪い指摘 | 何が問題か | 書き直した指摘 |
|---|---|---|
| 「なぜこうした？」 | 意図を問うだけ。相手は説明を強いられる | 「◯◯の理由で△△を想定していました。□□という懸念があるのですが、どうでしょうか」 |
| 「これはダメです」 | 根拠がない。どう直すかも不明 | 「このまま実行すると◯◯の場合に例外になります。△△の対応が必要では？」 |
| 「普通はこうしません」 | 慣習を根拠にした押し付け | 「チームの他の箇所では△△の形に統一されています。理由があればこのままでも構いません」 |
| 「細かいですが、空白が…」 | 自動化できる指摘。優先度も不明 | （自動整形に任せる。指摘するなら「好みの範囲です。次の機会で構いません」） |
| 「すごい！完璧です！」だけ | 何を確認したか不明。LGTMと同じ | 「要件の3条件を確認しました。特に◯◯の例外処理が妥当です。1点だけ△△を確認したいです」 |
次に、重要度の明示です。すべての指摘が同じ見た目だと、受ける側は全部に対応しようとして疲れます。近年のレビュー文化では、指摘にラベルや接頭辞を付けて重要度を伝えるのが標準的です。
| ラベル | 意味 | 受ける側の対応 |
|---|---|---|
| 必須（blocking / must） | 直さないとマージできない | 必ず対応する。対応しない場合は理由を返す |
| 提案（suggestion / should） | 直したほうがよいが、判断は任せる | 対応するか、判断の理由を返す |
| 質問（question / q） | 理解のために聞いている。変更は必須でない | 答える。伝わっていないなら説明を足す |
| 些細（nit / minor） | 好みの範囲。対応は任意 | 余裕があれば対応。議論しない |
| 称賛（praise） | 良い判断への言及 | そのまま。ただし「称賛だけのレビュー」は避ける |
このラベル運用には、副次的な効果があります。「これはブロッカーではない」と明示できることです。ジュニアエンジニアが指摘するとき、最も気を使うのは「これを言ったらマージが止まるのでは」という点です。ラベルがあれば、「提案だけど、今すぐでなくてよい」と伝えられます。逆に受ける側は、必須ラベルが付いていない指摘を、次回の改善として後回しにできます。
🔍 検証④：指摘を受けたときの3つの対応
指摘を受けたときの対応は、3つに分かれます。①修正する、②説明する、③相談する。この3つを無自覚に混ぜると、往復が増えて疲弊します。
① 修正するのが最も多い対応です。このとき大事なのは、修正の過程も履歴に残すことです（第4回）。追加のコミットで修正を積むと、「どこを直したか」がレビュアーに伝わります。履歴を書き換えて1つのコミットにまとめると、指摘との対応が消えます（ただし、マージ時にまとめる運用のチームもあります。チームの流儀に合わせてください）。
② 説明するのは、意図が伝わっていなかった場合です。このときの原則は、「説明で終わらせず、コードか記述を直す」ことです。「実は◯◯という理由でこうしています」と返すだけでは、次の読者も同じ疑問を持ちます。コメントを1行足す、名前を変える、PRの説明に理由を書く——疑問が再発しない形にします。
③ 相談するのは、合意できない場合です。ここで避けたいのは、レビューの場で長い議論を続けることです。文字だけのやり取りは、往復が増えるほど温度が上がり、論点がずれます。原則は「往復が3回を超えたら、対面（または通話）に切り替える」です。対面で決まったことを、レビューコメントに要約して残すのを忘れないようにします。
| 状況 | 対応 | 返信の例 | 避けたいこと |
|---|---|---|---|
| そのとおり、直すべき | 修正コミットを積む | 「修正しました（コミット△△）。境界値のテストも追加しました」 | 無言で直す（何を直したか伝わらない） |
| 意図が伝わっていない | 説明＋再発防止 | 「意図は◯◯でした。分かりにくかったので、コメントを追加しました」 | 説明だけで終わる（次の人が同じ疑問を持つ） |
| 合意できない | 対面に切り替える | 「論点が2つありそうです。10分お話しできますか」 | コメントで長い応酬を続ける |
| 次回でよい指摘 | 記録して先へ進む | 「今回は見送ります。チケット#△△に積みました」 | 無視する（指摘した人が損をする） |
| 感情的になりそう | いったん下書きで置く | （翌朝読み返してから投稿する） | 即レスで応酬する |
🔍 検証⑤：出す側の作法——レビューしやすさは「作る」もの
レビューの質は、出す側の準備で大きく変わります。第4回で扱った内容と重なりますが、レビューの観点から整理します。
第一に、セルフレビューです。PRを出す前に、自分の差分を最初から最後まで読みます。これだけで、次のものが見つかります。デバッグ用の出力が残っている、コメントアウトしたコードが残っている、意図しないファイルの変更が含まれている、誤字がある。小さいPRなら1〜2分で終わる作業です。逆にこれをしないと、レビュアーは「あなたが1分で見つけられた問題」に時間を使います。
第二に、「見てほしい点」の明示です（第4回のPR説明文）。特に、自分で迷っている箇所を書きます。「この部分は2案で迷っていて、A案にしましたが確信がありません」——こう書くと、レビュアーはそこに集中して見てくれます。逆に「全部見てください」と書かれたPRは、どこから見ればよいか分からず、浅く見られます。
第三に、レビューの待ち時間を短くする依頼の仕方です。レビュアーが忙しいことを前提に、「今日中にお願いできますか」「急ぎではありません、明日で構いません」と緊急度を伝えます。レビューで滞留すると、チーム全体のリードタイム（第1回のDORAの指標）が伸びます。
| 段階 | やること | 所要時間の目安 |
|---|---|---|
| 出す前 | 自分の差分を読み、ゴミを取り除く | 1〜5分 |
| 出す前 | 説明文に課題・理由・見てほしい点を書く | 3〜5分 |
| 依頼時 | 緊急度と期限を伝える | 1分 |
| レビュー中 | 指摘を待つ間、次のタスクに着手する（PRを短命に保つ） | — |
| 指摘後 | 対応し、何をしたかを返信する | 指摘の量による |
🔍 検証⑥：「LGTMだけ」を減らす仕組み
「LGTM（Looks Good To Me：良さそう）」とだけ書かれたレビューは、承認の印としては機能しますが、レビューとしては機能していません。なぜこれが起きるのか、仕組みの側から考えます。原因は主に3つです。PRが大きすぎる（読めない）、何を見るかが共有されていない（観点がない）、レビューが形式的な儀式になっている（意味がないと信じられている）。
対処も仕組みで行います。PRを小さくする（第4回）、観点のチェックリストを共有する（検証②の優先順位）、そしてレビューの記録を評価につなげる（「何を確認したか」を書く習慣）。特に3つ目は、「指摘の数」ではなく「確認した観点」を評価するという設計です。指摘の数を評価すると、些細な指摘が増えて重要度が下がります。逆に「確認した観点」を書く運用にすると、LGTMだけのレビューが自然に減ります。
| LGTMだけの原因 | 仕組みでの対処 |
|---|---|
| PRが大きすぎて読めない | PRを400行以下に分割する運用にする |
| 何を見るか分からない | レビューの観点リストを用意し、確認項目を書く |
| 急いでいて時間がない | レビュー時間を業務として確保する。当番制にする |
| 指摘すると嫌がられそう | 重要度ラベル（必須／提案／質問／些細）を導入する |
| 自分の理解が浅くて怖い | 「質問」ラベルを歓迎する文化にする。質問は恥ではない |
結果：レビュー1回の実務フロー
ここまでの内容を、レビュー1回の流れにまとめます。出す側と受ける側の往復として見ると、どこで時間が溶けるかが分かります。
| # | 段階 | 担当 | やること |
|---|---|---|---|
| 1 | 準備 | 出す側 | セルフレビュー。PRを小さく保つ。説明文を書く |
| 2 | 依頼 | 出す側 | 緊急度と見てほしい点を伝える |
| 3 | 読む | レビュアー | 優先順位に沿って読む（正しさ→設計→読みやすさ→細部） |
| 4 | 指摘 | レビュアー | 重要度ラベルを付け、コードについて書き、確認した観点を残す |
| 5 | 対応 | 出す側 | 修正・説明・相談の3分岐。修正コミットで対応 |
| 6 | 再確認 | レビュアー | 指摘箇所と影響範囲だけを確認する（全体を読み直さない） |
| 7 | マージ | 出す側 | テスト結果を確認してマージ。ブランチを削除 |
このフローで最も滞留しやすいのは2〜3（待ち）と4〜5（往復）です。待ち時間はPRの小ささと依頼の仕方で、往復はたすきの中身（説明文）と重要度ラベルで短くなります。
考察：レビューは技術ではなく、関係の設計である
ここからは、検証では扱いきれなかった解釈を述べます。レビューについて調べると、技術的なテクニック（何を見るか、どう書くか）に注目が集まります。しかし実際にレビューが機能するかどうかを決めているのは、指摘しやすい関係があるかだと私は考えます。
これは心理的安全性と呼ばれる概念と関係します。エイミー・エドモンドソンが1999年に提唱したこの概念は、「自分の発言が罰せられないという確信」を指します。医療チームの研究では、心理的安全性が高いチームほど、事故やエラーの報告が多いという一見逆の結果が報告されています。これは、報告が増えるのは事故が増えたからではなく、隠さなくなったからです。レビューも同じで、指摘が出ないチームは、問題がないのではなく、指摘が抑圧されている可能性があります。
そして、心理的安全性は個人の性格ではなく、仕組みと振る舞いで作られます。重要度ラベル（「これは些細です」と言える）、質問の歓迎、指摘の数を評価しない、対面への切り替え——これらはすべて、安心して指摘できる仕組みです。ジュニアエンジニアでも、「質問」ラベルの指摘を歓迎するという振る舞いから始められます。
AI時代の視点も加えます。静的解析やAIによる自動レビューが普及すると、表層の指摘は機械が担当します。すると人間のレビューは、設計の妥当性・文脈の理解・知識の共有に集中することになります。これは、本記事の優先順位（①正しさ、②設計、③読みやすさ、④細部）で言えば、④（と一部の③①）を機械に渡し、②③と文脈判断を人間が担うという分担です。逆に言えば、機械が見つけられる問題を人間が指摘しているチームは、機械化の余地が大きいということでもあります。
📌 注目ポイント
- レビューの目的は欠陥発見だけではない。設計の確認・知識共有・一貫性の維持も含む
- 見る順番は正しさ → 設計 → 読みやすさ → 細部。上位で問題を見つけたら一度止める
- 細部（整形・スタイル）は自動化に寄せる。人間は上位3つに時間を使う
- 指摘はコードについて書き、人について書かない。根拠と代案を添える
- 重要度ラベル（必須／提案／質問／些細）で、すべての指摘を同じ重さにしない
- 指摘への対応は修正・説明・相談の3分岐。説明はコードか記述に反映して再発を防ぐ
- 往復3回を超えたら対面に切り替える。決定はレビューに書き戻す
- 出す側はセルフレビューと「見てほしい点」の明示でレビューしやすさを作る
- LGTMだけは仕組みで防ぐ。「確認した観点」を評価する
💡 活用事例：副操縦士が機長のミスを止められるようにした訓練
「指摘しにくい」「指摘すると嫌われる」という問題は、実は人命を預かる現場で先に解決が迫られた問題です。その代表が、航空業界のCRM（Crew Resource Management：乗員資源管理）です。
きっかけの1つとされるのが、1978年のユナイテッド航空173便の事故です。着陸装置のトラブルに対応している最中に燃料が尽き、乗員と乗客に犠牲が出ました。事故調査では、副操縦士が燃料の残量に気づいていたにもかかわらず、機長に強く指摘できなかったことなど、乗員間のコミュニケーションの問題が指摘されました。当時の航空業界には、機長の判断に部下が異議を唱えにくいという文化（これを権威勾配と呼びます）がありました。
この事故などを教訓に、CRM訓練が導入されます。内容は、状況を共有する、役割を明確にする、異議を述べる、確認を求めるといったコミュニケーションの訓練です。「何かおかしいと思ったら、立場に関係なく言う」という規範を、訓練と手順で支えます。たとえば「機長、燃料の残量が少ないように見えます」と具体的に、役割を明示して伝える形が訓練されます。
効果は、航空の事故率の低下に表れています。CRMの導入は1970年代後半から1990年代にかけて業界標準になり、米国の定期航空輸送における事故率は長期的に大きく低下しました（事故率の低下には、機材の信頼性向上・気象予測の進歩・訓練の改善など複数の要因が寄与しているため、CRMだけに帰属させることはできません。ただし、乗員間のコミュニケーションが事故要因として繰り返し報告され、その改善が業界全体の課題だったことは確かです）。
この事例の教訓は、レビューにそのまま当てはまります。第一に、指摘できない関係は、事故を防げない。第二に、「言いやすい形式」を決めることが対策になる（CRMは「何かおかしい」ではなく、具体的な伝え方を訓練します。これは重要度ラベルや指摘の型と同じです）。第三に、仕組み（訓練・手順）として定着させないと、個人の性格に依存する。レビューが「気の強い人だけが指摘する場」になっているなら、それはCRM導入前の航空業界と同じ状態です。
✅ 要点まとめ
- レビューは審査ではなく、意図の受け渡し。指摘の多くは伝達の穴を指す
- 目的は4つ：欠陥発見・設計確認・知識共有・一貫性維持
- 見る順番は正しさ → 設計 → 読みやすさ → 細部。細部は自動化に寄せる
- 指摘は「コードについて、根拠と代案を添えて」書く。人格に触れない
- 重要度ラベルで、対応が必要な指摘だけを明確にする
- 受けた側は修正・説明・相談の3分岐。説明は再発防止まで含める
- 往復3回で対面に切り替え、決定をレビューに書き戻す
- 出す側はセルフレビュー・説明文・緊急度の3点を準備する
- 指摘できない関係は事故を防げない。仕組み（ラベル・質問の歓迎）で作る
🚀 取り込み方：明日から使う3段階
今日（5分でできること）：次にPRを出すとき、セルフレビューを1回だけ丁寧にやってみてください。自分の差分を上から下まで読み、デバッグ出力・コメントアウト・意図しない変更を探します。見つかった数を記録しておくと、レビュアーの時間を何件分節約したかが分かります。
今週（小さく試す）：次のレビューで、重要度を1つ書いてみてください。「これは必須です」または「これは提案です。今でなくて構いません」。相手の反応と、往復回数の変化を観察します。あわせて、レビューを出す側としては「見てほしい点」を1つ書きます（「この例外の扱いだけ見てほしい」）。
今月（定着させる）：チームのレビューに観点のチェックリストを1つ提案してみてください。たとえば「確認した観点：正しさ／設計／読みやすさ」をPRのテンプレートに加える、あるいはレビュー時に「何を確認したか」を書く運用です。指摘が0件でも「何を確認したか」を書くのがポイントです。あわせて、自分が受けたレビューで往復が3回を超えたものを1つ振り返り、対面に切り替えるべきだったかを確認してみてください。
🔥 ハマりポイント
その1：レビューはバグ探しだと思う
バグ探しだけが目的だと思うと、バグがなかったレビューは「無駄」に見えます。しかし実際の効果は知識共有・設計の確認・一貫性維持に大きく分散しています。この視点がないと、設計の議論を「細かい指摘」として切り捨て、後で大きな手戻りになります。
症状：レビューで設計の話が出ると「動いているので大丈夫です」と返す。原因：正しさだけで十分だと考えている。対処：優先度②（設計）の問いを1つ持つ。「半年後にこの構造で変更できますか」。
その2：LGTMと書いて終わる
忙しいとき、読み切れないPRに「LGTM」と書くのは、承認の押印であってレビューではありません。問題が本流に入ると、レビュアーも責任の一部を負います。「時間がない」なら、「今日はここまでしか見られません。この部分だけ確認しました」と正直に書くのが誠実です。分割して出し直すよう依頼するのも、正しい対応です。
症状：後から本流でバグが見つかり、「レビューしたはず」となる。原因：読めないPRを承認した。対処：見た範囲を明示する。分割を依頼する。
その3：指摘の数を評価する
「たくさん指摘する人ほど貢献している」という評価をすると、些細な指摘が増え、重要度が下がります。受ける側も疲弊し、レビュー全体が重い儀式になります。評価すべきは確認した観点と、早く見つけたことです（第1回のコスト原則）。
症状：些細な指摘が大量に返り、本質的な議論に時間が残らない。原因：指摘数が評価されている。対処：重要度ラベルを導入し、「些細」は対応任意と明示する。
その4：指摘を人格への評価として受け取る
指摘はコードの性質についての情報です。しかし連続して指摘を受けると、「自分はダメだ」という解釈に傾きます。この状態では、指摘を隠す・言い訳する・学習が止まるという悪循環に入ります。対処は、指摘を「教材」として扱うことです。「この指摘が繰り返し出るなら、次は書く前に確認しよう」とチェックリスト化します。第1回のコスト原則ではありませんが、指摘は最も安い学習機会です。
症状：レビュー後に落ち込み、次のPRを出すのが遅れる。原因：コードと自己評価が結びついている。対処：指摘をパターン化して記録する（自分用のレビューチェックリストを作る）。
🔄 代替技術との比較：レビューの形態
レビューには複数の形態があります。どれか1つではなく、組み合わせるのが現実的です。
| 形態 | 特徴 | 向いている場面 | 弱み |
|---|---|---|---|
| 非同期レビュー（PRコメント） | 時間を選ばない。記録が残る | 日常の変更。多くのチームの標準 | 往復が長引く。温度が上がりやすい |
| ペアレビュー（画面共有） | その場で意図を確認できる | 複雑な変更。新人の教育 | 時間を同時に確保する必要がある |
| 形式レビュー（会議） | 複数人で観点を分担できる | 重要な設計変更・規制対応 | コストが高い。頻繁にはできない |
| 自動レビュー（静的解析・AI） | 24時間動く。見落としがない | スタイル・型・脆弱性のパターン | 文脈・意図・設計の妥当性は判断できない |
補足として、自動レビューの位置づけが近年大きく変わりました。静的解析・型検査・依存関係の脆弱性検査は標準的な道具になり、AIによる差分の要約や指摘の提案も実用化しています。重要なのは、自動レビューは人間のレビューを置き換えるのではなく、人間が集中すべき領域を作るという関係です。第7回では、この自動化をCI（継続的インテグレーション）として仕組みに組み込みます。
また、レビューの対象にも選択肢があります。コードだけでなく、設計文書（第3回のADR）・インフラ設定・データベースのマイグレーション・ドキュメントもレビューの対象にできます。特にデータベースの変更は、後から戻すのが難しいため（第3回の「変えにくいもの」）、レビューを厚くする価値があります。
📅 今後の展望：AIレビューと人間レビューの分担
レビューを巡る変化を3つ挙げます。第一に、自動レビューの高度化です。第7回で扱うCIに組み込まれた静的解析・型検査・セキュリティ検査に加え、AIが差分の意図を要約し、過去の類似の指摘を提示する仕組みが普及しつつあります。これにより、人間のレビュアーは「正しさの確認」の一部を機械に渡し、設計と文脈に集中できるようになります。
第二に、レビューの計測です。PRの滞留時間、往復回数、レビュー待ち時間といったデータが取得しやすくなり、チームのボトルネックを数字で特定できるようになりました。第1回で扱ったDORAの4指標（デプロイ頻度・変更リードタイム・変更失敗率・復旧時間）は、レビューの滞留とも直結します。
第三に、AIが生成したコードのレビューという新しい課題です。AIが生成した変更は、一見自然で、もっともらしく、動くことが多いため、レビュアーが「読めたつもり」になりやすいという危険があります。だからこそ、この記事で扱った原則——意図を確認する（なぜこの形か）・受け入れ条件との対応を見る・重要度を分けて指摘する——が、これまで以上に重要になります。AIの出力を承認する場合も、確認した観点を書くという習慣が、そのまま記録と説明責任になります（第4回で触れた規制の動きとも関係します）。
まとめ
この記事を読んだあなたは、次にレビューを受けたとき、指摘を「自分の評価」ではなく「伝達の穴の情報」として読めるようになります。そして、レビューする側になったとき、正しさから順に見て、重要度を明示して指摘するという手順を持てます。
レビューは、技術力の審査会ではありません。チームが早く失敗に気づき、知識を循環させるための装置です。だからこそ、うまく回すには形式（型）が要ります。指摘の型、返信の型、重要度の型。型があるから、内容に集中できます。型は、あなたの性格を変える必要がありません。
第6回では、関門6の「テスト」を掘ります。レビューが「人の目」なら、テストは「機械の目」です。何をテストし、何をテストしないのか。網はどう張るのか。テストは仕様書であり、網であるという視点で扱います。
参考文献
- Google, “Google’s Engineering Practices documentation”（レビューの標準と指摘の書き方） — https://google.github.io/eng-practices/
- Alberto Bacchelli, Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013（レビューの実際の効果に関する実証研究） — https://dl.acm.org/doi/10.5555/2486788.2486882
- Caitlin Sadowski et al., “Modern Code Review: A Case Study at Google”, ICSE-SEIP 2018（Googleのレビュー事例研究） — https://dl.acm.org/doi/10.1145/3183519.3183525
- Peter C. Rigby, Christian Bird, “Convergent Contemporary Software Peer Review Practices”, FSE 2013 — https://dl.acm.org/doi/10.1145/2491411.2491444
- Jason Cohen et al., “Best Kept Secrets of Peer Code Review”, SmartBear Software, 2006（レビューサイズと発見率） — https://smartbear.com/
- Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly, 1999（心理的安全性の原典） — https://journals.sagepub.com/doi/10.2307/2666999
- Robert L. Helmreich, Ashleigh C. Merritt, John A. Wilhelm, “The Evolution of Crew Resource Management Training in Commercial Aviation”, International Journal of Aviation Psychology, 1999（CRMの総説） — https://www.tandfonline.com/doi/abs/10.1207/s15327108ijap0901_2
- National Transportation Safety Board, “Aircraft Accident Report: United Airlines Flight 173”（1978年事故の調査報告） — https://www.ntsb.gov/
- Federal Aviation Administration, “Crew Resource Management Training” (AC 120-51E) — https://www.faa.gov/
- Kim, Gene, et al., “The DevOps Handbook” (2nd ed.), IT Revolution, 2021（レビューとデプロイの流れ） — https://itrevolution.com/
- Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”, IT Revolution Press, 2018（リードタイムの計測） — https://itrevolution.com/
- NIST, “Secure Software Development Framework (SSDF) SP 800-218”（レビューの統制としての位置づけ） — https://csrc.nist.gov/pubs/sp/800/218/final
- OWASP, “Code Review Guide”（セキュリティ観点のレビュー） — https://owasp.org/www-project-code-review-guide/
- Michael Fagan, “Design and Code Inspections to Reduce Errors in Program Development”, IBM Systems Journal, 1976（形式的レビューの原典） — https://ieeexplore.ieee.org/document/5388081
- DORA, “Accelerate State of DevOps Report” — https://dora.dev/
- 情報処理推進機構（IPA）, 「ソフトウェア開発データ白書」 — https://www.ipa.go.jp/