もしかしたら、すべてのコードレビューをやめるべきではないか

もしかしたら、すべてのコードレビューをやめるべきではないか レイチェル・レイコック 私はThoughtworksのCTO、レイチェル・レイコックです。テクノロジーがソフトウェアの構築方法、チームのリード方法、ビジネスの運営方法を変えていることに、絶えず好奇心を抱いています。ここでは、アイデアが完全に形成される前にキャプチャし、自身の思考に挑戦し、時折興味深い脱線に迷い込むことがあります。 2026年9月2日 TL;DR あるいは、問題はAIがコードレビューを壊したのではなく、私たちがコードレビューを間違った問題解決に使ってきたのかもしれません。 最近、Moderneが主催するCode Remixで、DXのBrian Houck氏と共にパネルに参加しました。これは私が参加した中でも特に興味深いパネルの一つでした。なぜなら、私たちは意見が異なっていたからです。私の同僚であるMartin Fowler氏が言うように、パネルは人々が意見を異にし、両者が良い議論を持っている場合に、より興味深いものです。Brianと私は間違いなくそうでした。Brianはその後、What are code reviews even for?という思慮深い記事を書いています。彼は明らかに自身の立場に情熱を持っており、私も私の立場に十分情熱があるので、この応答を書いています。 はっきりさせておくと、私たちはほとんど同じことを望んでいると思います。ただ、それらを得るための最良の方法がコードレビューだとは思っていません。 ちなみにBrianは素晴らしい人物で、私にこの記事を書くよう促してくれました。しかし、最後には私が正しいと思わせたいという気持ちがないと言ったら嘘になります :)。 では、何について意見が異なっていたのでしょうか？ AIは、人間が現実的にレビューできる量を超えるコードを生成しています。Brianは、Metaでは、人間が承認した差分あたりのコード行数が1年間で106％増加したという非常に印象的な数字を引用しており、DX自身のデータでは、プルリクエストの中央値サイズが64％増加していることを示しています。彼の懸念は、私も共有していますが、コードレビューを単に自動化してしまうと、私たちがそれを利用してきた他のすべてのものを失うリスクがあるということです。コードレビューはバグを見つけるだけではありません。それは、チームが知識を共有し、ジュニアエンジニアを教育し、共同所有権を構築し、アーキテクチャの理解を広める方法です。 私の質問は、なぜ私たちはそれらすべてのことをコードレビューまで待っているのでしょうか？ 私は、ソフトウェア開発プロセスの中心としてプルリクエストを特に好んだことはありません。エンジニアが互いのコードを見るべきではないからではなく、何かを構築し、それを完成させ、パッケージ化し、誰かに渡し、そして私たちが正しいものを正しい方法で構築したかどうかについての重要な会話をするという考え方に、私は常に苦労してきました。そして、マージコンフリクトについては言うまでもありません。私は人生の多くの時間を無駄にしてきました。 判断を左にシフトする Thoughtworksで非常に早い段階に学んだ原則の一つは、フィードバックループを短縮することです。フィードバックが価値があるなら、それを取り除かないでください。それが影響を与える決定に近づけてください。 コードレビューが私たちに与えてくれると言うものを取り上げてみましょう。代替ソリューションを探求したいのであれば、それを実装する前に検討したいです。知識移転を望むなら、ペアを組みましょう。誰かが問題を解決するのを横で、物理的または仮想的に見ていることは、完成したソリューションを後で読むよりもはるかに多くのことを教えてくれます。ジュニアエンジニアに経験豊富なエンジニアの考え方を学ばせたいなら、彼らが考えている間に経験豊富なエンジニアと一緒に働かせましょう。ここでもペアプログラミングが思い浮かびますが、チームは（エージェントに書かせるか、自身で）何も書く前に、ホワイトボードを使って共同で設計セッションを行うこともできます。 共同所有権を望むなら、人々がプルリクエストに頼って誰かがすでに構築したものを知るのではなく、実際にソフトウェアを共同で構築し運用できるようにチームを組織しましょう。これにも、ペアプログラミング、モブプログラミング、またはホワイトボード周りのチーム設計セッションを使用します。 アーキテクチャの整合性を望むなら、一緒に設計し（ペアプログラミングとチーム設計セッションについては繰り返しません、ああ、待って…）、その後、重要な制約をフィットネス関数としてエンコードします。 そして、フォーマット、リンティング、既知のセキュリティ問題、または決定論的にテストできるものについてコードをレビューしているのであれば、それらを自動化しましょう。2026年になっても、まだ空白文字について議論しているべきではありません。 ペアプログラミング、トランクベース開発、自動テスト、静的解析、フィットネス関数、セキュリティスキャンはすべて、フィードバックを早期に移動させます。ますます、エージェントもこれらのループに参加できるようになり、設計に疑問を投げかけ、仮説をテストし、構築されているものを継続的に検証しますが、真の思考は経験豊富な人間から来ています。そして、その経験がチーム全体に利益をもたらすことを望むなら、コードレビューよりもはるかに早い段階で行動しなければなりません。 例外によるレビュー これらすべてが、誰もコードレビューをしないという意味ではありません。経験豊富な人間が確認することを望む変更は絶対にあります。例えば、根本的なアーキテクチャの変更です。チーム全体で設計セッションを行ったと仮定すると、チームとしてコードをレビューするか、正しく実装されたことに同意するか、何か変更したいことがあるか議論したいかもしれません。他の例としては、機密性の高いセキュリティ境界を越えるもの、広範囲に影響を及ぼす変更、重要なシステムの馴染みのない部分、あるいは単にチームが「これについては自信がない」と言うようなものがあります。 これらはまさに人間の判断が価値を発揮する場所ですが、それは人間がすべての変更を検査することを要求することとは全く異なります。なぜなら、それは私たちが歴史的に信頼を築くために使用してきた儀式だからです。そして、この道を継続することが実行可能ではないことを私たちはすでに知っています。だからこそ、コードレビューは問題またはブロッカーとして常に浮上してくるのです。 エージェントが人間の10倍のコードを生成できたとしても、すべての行がシニアエンジニアの検査を待つキューに入るとしたら、私たちは10倍のエンジニアリング組織を作り出したのではなく、大きなバックログと新しいボトルネックを作り出したことになります。そして、答えは、人間レビュアーを装ったAIエージェントが、より高速で全く同じプロセスを維持できるようにすることだとは思いません。それは、儀式の存在理由を問い直すのではなく、儀式を自動化しているのです。 しかし、Brianの議論で心配していることが一つあります。彼は、チームが認知的および意図的な負債を蓄積していると話しています。ソフトウェアは成長する一方で、それに対して責任を持つ人間は、それがどのように機能しているのかをますます理解しなくなっています。私はそれが非常に現実的な問題だと思います。ただ、必須のプルリクエストがそれに対する特に強力な防御策だとは思いません。 エージェントが実装の大部分を生成するようになるなら、共同設計、ペアプログラミング、適切な境界、実行可能なアーキテクチャ、共有された運用責任、そしておそらくまだ発明されていないいくつかのプラクティスを通じて、人間の理解を維持するために、より意図的に取り組む必要があります。エンジニアは、差分ではなく、システムを理解する必要があります。おそらく、AIが露呈しているのはそれです。 私たちは何年もかけて、謙虚なコードレビューに信じられないほどの数の責任を負わせてきました。品質ゲート、セキュリティチェック、アーキテクチャレビュー、メンタリングメカニズム、知識共有システム、所有権モデルです。人間がコードを生成できる速度が遅かった間は、それは、まあ、機能していました。その制約は消えつつあります。 したがって、問題は、コードレビューをより速く行う方法ではなく、そもそもなぜすべての重要な会話をコードレビューまで待っているのか、ということかもしれません。 最新投稿（9月2日）：もしかしたら、すべてのコードレビューをやめるべきではないか 前回の投稿：市民が構築し、エージェントが実行し、専門家が統治する すべての投稿