2.9 プルリクエストとコードレビューの指標

概要と動機

コードレビューは通常、トピック2.6のサイクルタイムの内訳の中で唯一最大の待ち時間の寄与者であり、共有プラットフォームのボトルネックや外部の依存関係とは異なり、チーム自身が改善するために最も直接的に統制できる段階でもあります。本トピックは、レビューの段階の内側に生きる具体的な指標、つまり最初のレビューまでの時間、プルリクエストのサイズ、レビューの反復回数、レビュー担当者の負荷分布を扱い、それらを使って、レビューが提供するはずの実際の品質上の利益を犠牲にすることなくレビュー速度を改善する方法を扱います。

本トピックが最も警戒しているリスクは、本書がまだ直接扱っていないものです。レビュー速度を最適化することは、不注意に追求すると静かにレビューの品質を蝕むことがあります。すべてをラバースタンプで(形だけ)承認することで最初のレビューまでの時間を半分にしたチームは、ある指標を改善しながら、その慣行の実際の価値を破壊したのです。本トピックのあらゆる推奨事項は、このトレードオフを視野に入れて書かれています。なぜなら、プルリクエストの指標は、ダッシュボード上では良く見えながら、根底にあるコードベースを測定可能に悪化させる形で操作することが、本書の中でも最も簡単なものの一つだからです。

大規模なチームにとって、レビューの指標は、そうでなければ見えない負荷分散の問題を明らかにします。少数の上級エンジニアがレビュー負荷の不均衡な割合を吸収していること、レビューが一貫して停滞する特定のチームやコードベースの領域、あるいはレビュー担当者の勤勉さにかかわらず徹底的なレビューを実質的に不可能にする過大なプルリクエストのパターンです。これらのパターンは、誰もが指標を必要とせずに不均衡を直接見られる小さなチームよりも、規模において、はるかに積み重なります。

重要な原則

最初のレビューまでの時間は、通常、レビューの徹底さそのものよりも大きなレバーである。 ほとんどの遅延は、レビューの会話が始まってから長くかかることからではなく、プルリクエストが見てもらえるのを待っていることから来ます。
より小さなプルリクエストは、より速くだけでなく、より徹底的にレビューされる。 サイズは、速度と品質の両方にとって同時にテコの効く点です。
レビューの速度と品質は自動的に緊張関係にあるわけではないが、不注意にトレードオフされうる。 その取引に明示的に注意してください。
レビュー担当者の負荷の不均衡はよくあることであり、通常、指標なしには見えない。 少数の人々がしばしば不均衡な割合を吸収します。
これらの指標はラバースタンプの操作のリスクにさらされている。 本物の精査のない速い承認は、レビューの目的全体を打ち負かします。

推奨事項

最初のレビューまでの時間を主要な速度指標として追跡する

プルリクエストが開かれてから、レビュー担当者の最初の実質的なコメントや承認までの間隔を測定し、あなたのバージョン管理プラットフォームから自動的に計装してください。これは通常、レビュー段階の中で支配的な待ち時間の寄与者であり(トピック2.5、トピック2.6)、それを改善すること、より明確なレビュー割り当ての規範、通知の慣行、あるいは専用のレビュー時間のブロックを通じて、典型的にはチームが利用できる、全体のサイクルタイムへの単一で最大の改善を生み出します。

プルリクエストのサイズを追跡し、積極的により小さな変更を奨励する

プルリクエストあたりの変更された行数や触られたファイルを測定し、持続的に大きな中央値のサイズを直接対処する価値のある信号として扱ってください。より小さなプルリクエストは、より速くレビューされ、より徹底的にレビューされ(レビュー担当者は実際に変更全体を頭の中に保持できます)、何かがうまくいかなかったときに元に戻しやすいものです。これは、トピック2.10のデプロイ頻度の背後にあるバッチサイズの原則に直接つながります。作業が許す限り、大きな変更を、独立してレビュー可能な小さなプルリクエストの連なりに分割することを奨励してください。

レビュー担当者の負荷分布を明示的に監視する

継続的な窓にわたって一人あたり完了したレビューの数を追跡し、特に少数の人々が不均衡な割合を吸収していないか注意してください。このパターンはよくあることで、しばしば最も上級の、あるいは最も信頼されたエンジニアにのしかかり、ボトルネック(彼らの可用性がチーム全体のレビュースループットの上限になる)と燃え尽きのリスク(トピック3.2が幸福感の指標をより深く扱います)の両方を生み出します。誰が最も速く応答するかを中心に既定で集中させるのではなく、意図的にレビューの責任をローテーションしてください。

ラバースタンプの操作のリスクに明示的に注意する

最初のレビューまでの時間を品質の信号と対にしてください。レビューコメントがゼロで承認された変更にたどれる欠陥やインシデントの率、あるいは最近レビューされたコードに必要なマージ後の修正の率です。本物の精査なしに承認することでレビュー速度を改善したチームは、このガードレールが悪化するのを見るはずです。これはまさに、トピック1.2の対化の原則をこの特定の指標の家系に適用したものです。この反対指標を視野に入れずにレビュー速度を追いかけることは決してしないでください。

レビューの反復回数を摩擦を見つけるために使い、個人を判断するためには使わない

あるプルリクエストがマージされるまでに経るレビューのラウンド数は、本物の摩擦、不明確な要件、アプローチについての意見の不一致、一貫性のないスタイルの期待を示すことがあり、プロセスレベルで調査する価値があります。この数字を個々の著者やレビュー担当者を直接判断するために使うことは避けてください。高い反復回数は、個人的な信号であるよりもしばしばシステムやコミュニケーションの信号であり、それを個人のスコアカードとして扱うことは、まさにトピック1.1が警告する評価的なずれを招きます。

トレードオフ:長所と短所

アプローチ	長所	短所
最初のレビューまでの時間だけを純粋に最適化する	速く、明確な信号、計装が簡単	守られていなければ表面的なラバースタンプレビューを促すことがある
プルリクエストのサイズ削減だけを純粋に最適化する	速度と徹底さの両方を同時に改善する	すべての仕事がきれいに小さな増分に分割できるわけではない
レビュー負荷を均等にローテーションする	ボトルネックと燃え尽きのリスクを減らす	特定の専門知識を必要とする専門的で、レビューの難しいコードについてはレビューを遅くすることがある
上級エンジニアにレビューを集中させる	深い領域の専門知識が一貫して適用される	時間とともにボトルネックと燃え尽きのリスクを生み出す

中心にある緊張関係は速度と精査の深さです。本トピックにある、より速い最初の応答、より小さなプルリクエスト、より分散されたレビュー担当者の負荷といった、レビューを速くするためのすべての技法は、本トピックが推奨する品質のガードレールなしに追求されると、本物の精査を取引してしまうリスクをいくらか伴います。この緊張を解消するには、あらゆる速度指標を、同じ期間にわたって追跡された品質の信号と対にし、チームが本物のプロセス改善を静かに蝕まれていくレビュー基準から見分けられるようにしてください。

チームで話し合うべき問い

私たちの実際の最初のレビューまでの時間はどれだけで、全体のサイクルタイムのうちどれだけをレビューの段階が消費しているでしょうか。 印象に頼るのではなく実際の数字を持ち出してください。レビューの待ち時間は、アクティブに働いている時間よりも待っている時間を過小評価しやすいために、しばしばチームが想定するよりも大きいものです。
私たちの中央値のプルリクエストのサイズはどれだけで、そのサイズが下がれば私たちのレビューの遅延のうちどれだけが縮小するでしょうか。 大きなプルリクエストは、レビュー担当者が全体を一度に頭の中に保持できないという単純な理由で、レビューに時間がかかり、表面的なレビューを受ける可能性が高くなります。中央値だけでなく実際のサイズ分布を見てください。
レビューの負荷は少数の人々に集中しているでしょうか。そして、そのうちの一人が2週間利用できなくなったら、私たちのレビュースループットに何が起きるでしょうか。この問いは、ボトルネックのリスクと燃え尽きのリスクの両方を同時に表面化させます。印象に頼るのではなく実際のレビュー担当者の負荷データを持ち出してください。
私たちは、振り返ってみると実際の精査を減らしてしまった形で、レビュー速度の指標を改善したことがあるでしょうか。 ここでは正直であってください。これはまさに本トピックが名指しするラバースタンプのリスクであり、それをそうすると意図的に決めることなく滑り込んでしまいやすいものです。
高いレビューの反復回数は、私たちのチームで通常何を示しているでしょうか。本物の意見の不一致、不明確な要件、それとも一貫性のないスタイルの期待でしょうか。異常に高い反復回数を持つプルリクエストのサンプルを見て、それが著者かレビュー担当者のどちらかを悪く反映していると仮定するのではなく、実際のパターンを診断してください。
私たちのレビュー速度の指標には品質のガードレールが対になっているでしょうか。それとも速度を単独で追跡しているでしょうか。 正直な答えがそのようなガードレールが存在しないというものなら、トピック1.2の対化の原則に従って、レビュー速度をさらに推し進める前に埋める価値のある隙間です。

業種別の視点

スタートアップ。 小さなチームであれば、レビューは既定で速いことが多く、時には速すぎることさえあります。誰もが誰もを信頼しているために、最小限の精査の単一承認者レビューです。チームが成長するにつれて注意すべきリスクは、レビューの品質がチームの規模とともにスケールしないことです。5人のエンジニアでうまくいった非公式な信頼は、50人では自動的にはうまくいかないからです。

中小企業。 ほとんどのバージョン管理プラットフォームは、すぐに使える形でマージまでの時間とレビュー件数の統計を報告します。カスタムの計装を構築するのではなくこれらを使ってください。採用する価値のある主な規律は、チームが成長するにつれてレビューの負荷が一人か二人に静かに集中していないかに単純に気づくことです。

企業。 レビュー担当者の負荷の不均衡と専門知識のボトルネックは、ここで特によくあります。重要なシステムにおける深い領域の専門知識は、チームの規模にかかわらず、レビューの責任を小さなグループに集中させることがあるからです。専門知識を広めるために、意図的な知識共有とレビューのローテーションに投資し、その専門知識があまりに少数の人々に生きていることによるボトルネックと、バス係数のリスクの両方を減らしてください。

政府。 ここでのレビュープロセスは、品質の目標と並んでコンプライアンスの重みを持つことが多く、これは設計上プルリクエストを大きく、レビューを遅くすることがあります。本物のコンプライアンス要件が徹底的なレビューを要求する場合、改善の努力をレビューの実際の深さを妥協することではなく、待ち時間を減らすこと(より速いレビューの割り当て、より明確なトリアージ)に集中させ、規制上の理由で精査が重いままでなければならない場合は、そのトレードオフを明示的に文書化してください。

事例

企業。 あるサイバーセキュリティ企業のエンジニアリング組織は、200人の組織全体にわたるすべてのコードレビューの40%以上を、一握りのプリンシパルエンジニアが完了していることを発見しました。この不均衡は、レビュー担当者の負荷のデータが持ち出されるまで、誰も直接測定していませんでした。この集中は、それらのエンジニアの可用性が組織全体のレビュースループットの上限になるためのボトルネックであると同時に、エンゲージメント調査(トピック3.2)によって別途旗が立てられた燃え尽きのリスクでもありました。この組織は、的を絞った知識共有セッションと対になった構造化されたレビューローテーションのプログラムを導入し、2四半期以内にレビューの負荷ははるかに広いグループに広がり、最初のレビューまでの時間は、ボトルネックが減ったことの直接的な副産物として改善しました。

政府。 ある税務当局のエンジニアリングチームは、提供速度を改善するプレッシャーのもとで、最初のレビューまでの時間を半分にするという目標を設定しました。1四半期以内に目標は達成されましたが、その後の品質監査は、単一の短いコメントで承認された変更に集中した、マージ後の欠陥修正プルリクエストの急激な上昇を発見しました。このチームの修正は、速度の目標を明示的な品質のガードレール、つまりレビューから2週間以内に必要なマージ後の修正の率と対にし、本物の実質的なレビューが実際に何を必要とするかについてチームを再訓練し、より良いレビューの割り当てとより小さなプルリクエストのサイズから来た速度の改善のほとんどを保ちながら、本物の精査を回復しました。

ビジネスケース:動機、ROI、総所有コスト

よく管理されたレビュー指標からの見返りは、品質を犠牲にしない、より速い提供です。これはまれな組み合わせです。ほとんどの提供の改善は、どこかで速度をリスクと引き換えますが、レビュー段階の改善、より小さなプルリクエスト、より良い負荷分布、より速い最初の応答は、本トピックが推奨する品質のガードレールとともに追求されたとき、本当に両方を同時に改善します。上記のサイバーセキュリティの例は典型的です。ボトルネックを修正することは速度を改善し、一方で根底にあるレビューの品質は、専門知識がより広く広がるにつれて、どちらかといえば改善しました。

総所有コストは低いものです。これらの指標のほとんどは、最小限の追加計装で既存のバージョン管理プラットフォームのデータから直接得られ、それらが示唆するプロセスの変更、レビューのローテーション、より小さなプルリクエストの奨励は、ツールへの投資よりも主に規律の費用がかかります。

アンチパターンと落とし穴

対になる品質のガードレールなしに最初のレビューまでの時間を最適化する。 レビューの目的を打ち負かすラバースタンプ承認を招きます。
レビュー担当者の負荷の集中を無視する。 測定されるまで見えないままのボトルネックと燃え尽きのリスクの両方を生み出します。
レビューの反復回数を個人のスコアカードとして扱う。 個人的な信号であるよりもしばしばシステムやコミュニケーションの信号です。
持続的に大きなプルリクエストを避けられないものとして受け入れる。 ほとんどの大きな変更は、チームが最初に想定するよりもさらに分割できます。
変更のリスクにかかわらず均一なレビューの深さを適用する。 低リスクの変更に精査を無駄にする一方で、高リスクの変更の精査が不十分になる可能性があります。
レビュー速度を測定するが、本物の精査がそれと一緒に低下していないか一度も確認しない。 この指標の家系が意図せず操作される、唯一最も一般的な方法です。

成熟度モデル

レベル1、開始: レビューの指標は追跡されておらず、レビューの負荷分布とプルリクエストのサイズは見えません。
レベル2、発展: プラットフォームの既定値からいくらかのレビュー速度のデータが存在しますが、品質のガードレールはなく、レビュー担当者の負荷の能動的な管理もありません。
レベル3、標準化: 最初のレビューまでの時間、プルリクエストのサイズ、レビュー担当者の負荷が一貫して追跡されており、速度の改善に対して明示的な品質のガードレールが対になっています。
レベル4、管理: レビュー担当者の負荷はローテーションと知識共有を通じて能動的に再バランスされ、反復回数のパターンは個人レベルではなくプロセスレベルで調査されます。
レベル5、最適化: レビュー段階の指標がプロセスへの投資に直接情報を与え、組織は、持続的な期間にわたってレビュー速度とレビューに関連した品質の成果の両方における同時の改善を示すことができます。

議論のためのアイデア

私たちの現在の中央値の最初のレビューまでの時間はどれだけで、その時間は実際どこへ行っているでしょうか。
私たちのレビューの負荷は少数の人々に集中しているでしょうか。そして、そのうちの一人が利用できない場合のリスクは何でしょうか。
私たちは、意図せずであっても、本物の精査を犠牲にしてレビュー速度を改善したことがあるでしょうか。
私たちの中央値のプルリクエストのサイズはどれだけで、ほとんどの変更は現実的にどれだけ小さくできるでしょうか。
私たちは高いレビューの反復回数を、システムの信号として扱っているでしょうか、それとも個人の判断として扱っているでしょうか。

主な要点

最初のレビューまでの時間は、通常、レビューの会話の長さそのものよりも、レビュー段階の中で唯一最大のレバーです。
より小さなプルリクエストは、レビュー速度とレビューの徹底さの両方を同時に改善します。
レビュー担当者の負荷の不均衡はよくあることであり、通常、直接の測定なしには見えません。それはボトルネックと燃え尽きのリスクの両方を生み出します。
この指標の家系が特に陥りやすいラバースタンプの操作のリスクを捉えるために、あらゆるレビュー速度の指標を明示的な品質のガードレールと対にしてください。
レビューの反復回数を、個々の著者やレビュー担当者を判断するためにではなく、システムレベルの摩擦を診断するために使ってください。

参考文献とさらなる読書

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
Alberto Bacchelli と Christian Bird による Modern Code Review の研究。
Peer Reviews in Software: A Practical Guide, Karl E. Wiegers 著。
The Principles of Product Development Flow, Donald G. Reinertsen 著。