コードレビューは、ほとんどのチームで「やっている」のに、「うまくいっている」と言い切れるチームは意外と少ないものです。
指摘が細かすぎて疲れる、逆に LGTM だけが並んで何も改善しない、レビュー待ちで PR が数日止まる。
どれもレビュー自体の問題というより、レビューで何を守り、どこまでを許容するかという運用ルールが決まっていないことから起きます。
テックリードの仕事の一つは、このルールをチームの合意として形にすること。
筆者もテックリードを目指して学んでいる途中なので、Google が公開しているコードレビューのガイド（Google Engineering Practices）を一次情報にして、決めるべき項目を 4 つに整理しました。
レビューの目的を一文で言えるようにする
最初に決めるべきは、細かな作法ではなくレビューが何のためにあるのかという一文です。
Google のガイドは、コードレビューの第一の目的を「コードベース全体の健全性が時間とともに改善していくことを保証するため」と定めています。
この一文があるだけで、レビューの判断基準がはっきりしますね。
完璧でなくても、システム全体の健全性が確実に良くなる状態なら承認してよい——同じガイドはそう明言しています。
逆に言えば、「自分ならこう書く」という好みの差は、承認を止める理由にならないということです。
テックリードが最初にやるべきは、この目的をチームの言葉に置き換えて、README なり PR テンプレートなりの見える場所に書くことでしょう。
目的が共有されていない状態で細則だけ増やすと、ルールが「守らされるもの」になってしまいます。
「事実」と「好み」を分けるルール
レビューがこじれる原因の多くは、技術的な事実の話と個人の好みの話が同じ温度で交わされること。
Google のガイドには、技術的な事実とデータは意見や個人の好みに優先するという原則が置かれています。
そしてスタイルについては、スタイルガイドが絶対の権威であり、そこに書かれていない純粋なスタイルの論点は個人の好みに過ぎない、とも書かれているのです。
この整理をチームに持ち込むと、レビューコメントは自然に 3 種類に分かれます。
- 直さないと承認できないもの（バグ・設計上の問題・スタイルガイド違反）
- 直したほうがよいが承認は妨げないもの
- 個人の好み（コメントするなら「Nit:」を付けて、無視してよいと明示する）
「Nit:」の接頭辞は Google のガイドが勧めている書き方で、磨けばもっと良くなるという指摘を、ブロッカーと区別して伝えられるのが利点です。
テックリードが決めるのは、この 3 分類をチームの共通語にすることと、スタイルガイドをどれにするかを先に確定させること。
スタイルガイドが無いまま「好み」の議論を裁くのは、審判がルールブックを持たずに試合を見るようなもので、判断のたびに消耗します。
速さは品質の一部として扱う
レビューの運用で見落とされがちなのが、返答までの速さです。
Google のガイドは、コードレビューの依頼に応答するまでの最長時間を 1 営業日としています。
理由は個人の生産性ではなくチームの速度を優先しているからで、レビューが遅いと機能の完成が遅れ、開発者の不満がたまり、しまいには「早く通すために質を下げる」圧力まで生まれると説明されているのです。
レビュー待ちで PR が滞留するチームは、レビューの質を上げる前に、まず応答時間を測るほうが効きます。
同じガイドには、コメントを残したまま承認する「LGTM with comments」という運用も載っていました。
残した指摘を作者が適切に対処すると信頼できる場合や、指摘が任意の場合、些細な修正だけの場合は、承認と指摘を同時に出してよい、というものです。
時差のあるチームでは、この一手で丸一日の待ちが消えます。
テックリードが決めるのは、「何時間以内に最初の反応を返すか」という数字と、その数字を守れないときに誰へ振り替えるかという逃げ道の 2 つでしょう。
小さく出す文化はレビュー側が育てる
どれだけルールを整えても、1 つの PR に数千行の変更が乗ってくれば、レビューは形だけになります。
Google のガイドが著者側に求めているのも、変更を小さく分けることです。
ただ、これは著者の努力だけでは続きません。
大きな PR を「大変だけど頑張って読む」レビュアーがいる限り、小さく分ける動機が生まれないからです。
テックリードが決めるべきは、「この規模を超えたら分割を求める」という目安と、分割しやすいブランチ運用の型。
たとえば、リファクタリングと機能追加を同じ PR に混ぜない、というだけでも読みやすさは大きく変わります。
シニアエンジニアからテックリードになると「決める」と「そろえる」の仕事が増える、という話を以前の記事で整理しましたが、コードレビューの運用はまさにその両方が要る領域です。
技術・人・プロセスの 3 つの軸で言えば、レビュー文化はプロセスの軸に属しながら、人の軸にも深く関わります。
最後に
コードレビュー文化を作るとは、レビューを増やすことでも厳しくすることでもなく、目的・判断基準・応答時間・変更の大きさという 4 つの約束をチームで決めることでした。
Google のガイドは巨大な組織の運用を前提にしていますが、「健全性が良くなるなら承認する」「事実は好みに優先する」「1 営業日以内に反応する」の 3 原則は、数人のチームでもそのまま使えます。
筆者もまだ学んでいる途中ですが、まずは自分のレビューコメントに「Nit:」を付ける習慣から始めてみるつもりです。
参考: Code Review Developer Guide – Google Engineering Practices／The Standard of Code Review／Speed of Code Reviews
以上です。
コメントを残す