AIはボトルネックをコーディングからコードレビューに移していない
多くの人はAIがボトルネックをコーディングからコードレビューに移したと考えているが、実際のボトルネックはデプロイメントバッチ（変更の溜まり）にある。研究によると、90%以上のチームがバッチで出荷しており、AIによってコードレビューを高速化しても、下流のボトルネックが悪化するだけである。
多くの人がAIによってソフトウェア開発のボトルネックがコーディングからコードレビューに移ったと考えていますが、これは正確ではありません。実際には、コーディングはもともとボトルネックではなく、今のコードレビューもそうではありません。真のボトルネックはデプロイメントバッチ、つまりレビューを通過した変更が本番環境にデプロイされる前に溜まっている状態です。
簡単なテストがあります。あなたのアプリケーションやサービスでは、コードレビューは通ったものの、まだデプロイされてユーザーが使えるようになっていない変更がいくつありますか？答えが0または1なら、あなたのケースでは私が間違っています。しかし、ほとんどの場合、その数は複数であり、それだけでボトルネックが別の場所にあることがわかります。
私たちが現在実施している独自調査によると、チームの半数が2～10の変更をバッチに溜めており、4分の1が11～50の変更を溜めています。全体として、90%以上のチームが変更を一度に1つずつではなくバッチで出荷しています。
「コーディングはもともとボトルネックではなく、今のコードレビューもそうではない。」この数字は業界全体の可視性のギャップを明らかにしています。人々はClaude Code、Cursor、GitHub Copilotがボトルネックをコーディングからコードレビューに移したと信じていますが、レビュー後に起こるすべてを無視しています。これは個人の失敗ではなく、業界全体の誤解です。
私たちはバッチで作業することに慣れすぎて、それが当然のように見えています。それは苔むしていて、周囲の丘と見分けがつきません。ソフトウェアデリバリーを高速化する方法を探しても、それが問題に見えないため、見つけることができません。
AIがバッチに氾濫するとどうなるでしょうか？コードを書くことは、機会から始まりユーザーが必要な価値を得るところで終わる長い価値ストリームの小さな部分です。この価値ストリーム全体への影響は不均一です。AIはある領域では他の領域よりも役立ちますが、エンドツーエンドのメリットは、作業が蓄積される領域に気づくかどうかに依存します。
GitLabの2026年AIアカウンタビリティレポートでは、回答者の85%がAIによってボトルネックがコードの作成からレビューに移ったことに同意しています。しかし、デプロイメントバッチを見ると、これらの人々の92%はおそらく間違っています。レビュー後に蓄積があるなら、コードレビューはボトルネックではありません。レビューを高速化しても、本当のボトルネックが悪化するだけです。
これは、コーディング速度の向上がコードレビューに圧力をかけないと言っているのではありません。Faros AIの1万人の開発者を対象とした調査では、AI導入率の高いチームはプルリクエストのマージ数が98%増加する一方、レビュー時間は91%増加し、平均プルリクエストサイズは154%増加しています。Cursor自身の研究でも、同社のコーディングエージェントがデフォルトになると、企業はプルリクエストのマージ数が39%増加することがわかりました。
しかし、変更をより速く承認しても、その変更がスムーズに本番環境に流れ込む場合にのみ効果があります。ほとんどの場合、変更はテストやデプロイなどのさらなる処理を待つキューに移動するだけです。レビュー段階を通過する変更の割合とサイズを増やすと、圧力は本当のボトルネックに転嫁されます。
「レビュー段階を通過する変更の割合とサイズを増やすと、圧力は本当のボトルネックに転嫁されます。」
コードレビューが制約に見えるのは、目に見えるキューがあるからにすぎません。下流のキューは業界で広く受け入れられているために隠されています。パイプラインの仕事は、変更を本番環境に届けて使用可能にすることであり、「デプロイ待ち」キューに集めることではありません。
そして、それらの未リリースの変更が蓄積するにつれて、リスクも増大します。
バッチは道標です。バッチサイズの問題を尋ねれば、本当に価値ストリームを制約しているものが見つかります：手動検証ステップ、面倒な変更承認やリリーストレインのプロセス、または変更をデプロイする簡単な方法がないこと。コーディングではありません。コードレビューでもありません。
AIイニシアチブを開始する前から、おそらくバッチで作業していました。AIの導入はバッチサイズを増加させ、問題を引き起こす可能性があります。コードレビューのスループットを上げても問題は解決しません。単に変更をより速くボトルネックに移動させるだけです。
真の制約を使って価値ストリーム全体のペースを設定することで、正しい問題の解決に投資できるようになります。レトロスペクティブが目に見える改善を生み出せない場合、おそらくバッチ問題を見逃しています。これが、一部のAIイニシアチブが成功し、他が失敗する理由です。
研究もそれを見逃しています。AIの影響に関する研究は有用ですが、このトピックに関する多くの研究と同様に、コードがマージされた時点で止まっています。オープンなプルリクエスト、マージされたプルリクエスト、レビューに費やした時間を調べます。レビュー後に変更がどれだけ待機しているか、または誰かが本番環境で見る前にいくつの変更が束ねられているかを尋ねるものはありません。その数字がなければ、真の制約を見つけることはできません。
AIに投資してコーディングを高速化した後、次にコードレビューを修正しようとしたり、コードレビューを完全に放棄しようとしたりするかもしれません。バッチで出荷している場合、どちらもリスクを迅速に除去したり、ソフトウェアを使用する人々に価値を届けたりするのにほとんど違いをもたらしません。
組織がバッチ問題の修正に抵抗する理由こそ、あなたが解決すべき本当の問題です。