【ITニュース解説】How many lines should a pull request be? We traced the 400-line rule to its source

ソフトウェア開発において、自分の書いたコードを他の開発者に確認してもらう「プルリクエスト（PR）」は、品質を保ち、バグを減らすために非常に重要な工程だ。このPRの際、「一体どれくらいの行数の変更が適切なのか？」という疑問は多くの開発者が抱える共通のテーマであり、特に「400行以下に保つべき」という通説をよく耳にするだろう。この通説は、まるで揺るぎない事実のように語られることが多いが、その根拠と真意を深掘りしてみよう。

「400行ルール」という通説の源流は、2006年にSmartBear社とCiscoのあるチームが共同で行った研究にまで遡る。この研究は、約10ヶ月間にわたり、50人の開発者が行った2,500件ものレビュー、合計320万行のコードを対象に、様々な指標を収集したものだ。その中で最も注目すべき発見は、コードレビューの対象となる行数が約200行を超えると、欠陥の発見率が急激に低下するというものだった。SmartBear社はこの結果を受けて、「一度にレビューするコードは200行から400行に留めるべきで、400行を超えると欠陥を発見する能力が落ちる」というアドバイスを出した。これは実際のデータに基づいた研究であり、この数字が広まるきっかけとなったのは確かだ。

しかし、この研究の測定内容と限界を理解しておくことは非常に重要だ。この研究が測った「欠陥密度」とは、レビューしたコード量あたりに発見された欠陥の数を意味する。つまり、「200行を超えると欠陥密度が低下する」という結果は、「レビュー担当者が注意力を失い、欠陥を見逃しやすくなる」と解釈できる。この解釈は妥当である。しかし、この研究は「実際にコードに含まれるバグの数が少なかったのか」や、「その変更がシステムにとってどれくらいリスクが高いものだったのか」といったことまでは測っていない。あくまで「人がコードをどれだけ注意深く読めるか」を測定したものであり、「変更そのもののリスク」を評価したものではないのだ。

さらに、いくつかの重要な背景も考慮する必要がある。この研究は2006年という、今からずいぶん前の時代に行われたものだ。対象はCiscoの一つのチーム、一つの製品、そしてコミットする前に専用ツールを使ってレビューするという環境だった。現代のGitHubのようなプラットフォームで、継続的インテグレーション（CI）ツールによる自動テストが走り、活発な議論が交わされるプルリクエストとは、状況が大きく異なる。研究の詳細な統計的手法や実験の制御に関する情報が一般に公開されていない点、そしてこの数字を広めたSmartBear社自身がコードレビューツールを販売している企業であることも、頭の片隅に置いておくべきだろう。これらは「400行ルール」が間違っているわけではないが、それを絶対的な法則ではなく、あくまで出発点として捉えるべきであることを示唆する。

近年、この「400行ルール」とは異なる視点から、プルリクエストのサイズに関するデータが発表されている。例えば、LinearB社は2026年のベンチマークとして、4,813チームからの800万件以上のプルリクエストを分析した結果を公開している。彼らはPRサイズを上位25%の数値（75パーセンタイル）で評価し、100行未満を「エリート」、100〜155行を「良好」と位置づけている。AIによって書かれたコードのPRでは、サイズが大きくなる傾向があることも指摘している。一方、Graphite社は2023年の報告で、理想的なPRの行数の中央値は50行であり、25〜100行の範囲を推奨している。彼らの調査では、50行の変更は250行の変更に比べて、約40%も早くレビューされてマージされることがわかった。また、1000万件のPRのサンプルから作成されたリバート（一度マージされたコードが問題を起こし、元の状態に戻されること）に関するグラフでは、25〜50行のPRが最もリバートされにくいという結果も出ている。

一見すると両社のデータは矛盾するように見えるが、LinearBが上位25%の数値を、Graphiteが中央値を報告しており、異なる視点であるため両立しうる。これらは同じデータ群を異なる視点から見たものだ。両社もPRサイズやレビュー速度を測定するツールを販売しており、これらのデータがその指標への注目を促す立場にあることは念頭に置くべきだ。

これらの研究やデータが示さない最も重要な点は、「400行を超えるPRが、より多くのバグを含んだ状態でリリースされる可能性が高い」という直接的な証拠がないことだ。Ciscoの研究はレビューの質に焦点を当て、最近のベンダーデータはレビュー速度やリバート率に関することであり、どちらもマージ後のバグ発生までは追跡していない。

また、PRの「行数」だけでは、その変更の「レビュー労力」を正確に測ることはできない。例えば、ディレクトリを丸ごと移動するだけの2,000行のPRは、支払い処理のロジックをわずか60行変更するPRよりも、はるかにレビューが簡単である場合が多い。生成されたファイル（自動生成コード）、ロックファイル（依存関係管理ファイル）、マイグレーションファイル（データベース変更履歴）などは、実際にレビューが必要なコードの量を増やさずに、PRの行数だけを大幅に膨らませてしまうことがある。Graphite社のリバートに関するデータでは、10,000行を超える非常に大きなPRが、なぜかリバート率がわずかに低いという興味深い傾向も示されている。これは、非常に大きな変更が、コードの構造を大きく改善する「リファクタリング」のようなものである場合が多く、品質が保たれているためだと推測されている。

それでは、これらの情報にどう向き合えば良いのだろうか。まず、「200〜400行」という数字は、あくまで「一回のレビューで集中してコードを読める妥当な上限」として捉えるべきであり、絶対的な「ルール」ではない。これはコードが出荷された後のバグの数ではなく、「レビュー担当者の読解力」に関する目安だからだ。次に、最も重要なのは、自分たちのチームが通常どれくらいのサイズのPRを出しているのか、その中央値や上位25%の値を測定し、把握することだ。ベンダーが報告する数字はあくまで一般的な傾向であり、自分たちのチームの状況を最もよく表すのは、自分たちのデータだからである。そして、ロックファイルや生成ファイル、純粋なファイルの移動など、レビューの労力に直結しない行は、カウントから除外して考えるべきだ。もし、どうしても変更が大規模になってしまう場合は、PRの説明文に「ここから読んでください」といった短いメモを添えるなど、レビュー担当者がどこに注目すべきかを明確に伝える工夫が非常に有効だ。何よりも大切なのは、単純な「行数」だけでなく、その行にどのような「変更内容」が含まれているかを重視することだ。例えば、テストがない状態で複雑な分岐ロジックを追加するわずか60行のPRは、ほとんどが削除コードであるような長いPRよりも、はるかに大きな問題を引き起こす可能性がある。

結局のところ、プルリクエストの「最適な行数」は、絶対的な唯一の数字として存在するわけではない。それは、チームの文化、プロジェクトの性質、コードの複雑さ、レビューの目的によって変わる。あなたにとって、あるいはあなたのチームにとって、何行のPRが最もレビューしやすく、品質を保ちやすいと感じるだろうか。