前回の連載はこちらから。
「足りないなら増やせ」と言われた後に現場で起きること
技術的負債の改善活動が進んで影響調査もしやすくなった！という現場感覚とは別に、営業は「この機能がないと次期契約が危ない」、マーケティングからは「新機能がないとプロモーションの材料がない」という要望は常日頃続きます。
リファクタリングや定期的なミドルウェアのバージョンアップといった保守運用をしながら、さらなる新規開発の割合を増やしていくにはエンジニアを追加する選択肢もありますが、現場によっては現有リソースでどうにかしてほしいというのが予算上あったりします。
採用に踏み出しても、面談から入社までに3カ月から半年、その後のオンボーディングにさらに数カ月かかるためリードタイムはかかります。
一方、急いで業務委託を入れてもミスマッチになるケースも多いでしょう。
そこで昨今ではAIエージェントを開発プロセスに組み込む方法が一般的になってきました。チームでコンテキストをマネジメントし、AIエージェントに渡すとコードが高速で出力されます。一方で、生成物を理解せずそのまま取り込めば「中身はわからないけど動いている」という認知的負債が膨らみます。一方、しっかり品質を見ようとすると実装は速いのにレビュー待ちで時間が溶けて、チームとしては遅く感じる。このねじれは、現場でよく聞こえてきます。
AIエージェントは従量課金が世界的トレンドにもなっており、1人あたりでも月額数万円から数十万円、1〜2週間で導入も始められます。こういった部分でも人を採用するより安く、開発期間が短くなる比較も目に入ります。流動性という意味では、予算もリードタイムも増減のしやすさもAIのほうが有利に見えます。そのため、足りない分をAIで埋めて人月の代わりにAI予算として積むという発想がここで生まれます。
人月もAIも、増やしているのは同じ側
人数を足しても、納期は線形に縮まない
これは、連載第1回でも触れたブルックスの法則です。フレデリック・ブルックスの『人月の神話』は、遅れているプロジェクトに人員を足しても納期が早まるとは限らず、むしろ遅れることがあると述べています。
加わったメンバーは仕様と設計とコードベースの説明を受ける時間が必要で、既存メンバーは教育とレビューに時間を取られます。人数が増えればコミュニケーションの経路も増え、作業の再分割と統合のやり直しも起きるため、順序に依存するタスクは人月を積んでも短くなりません。
「AIで速くなる」の数字は本当か
AIによって効果が出るのは「並列側」というのが本回の論点です。開発生産性の可視化サービスで知られるGitClearの2025年レポートは、2020年から2024年にかけての約2.11億行の変更を分析しています。
AI導入が進むなかで、書いてすぐ消される行（チャーン）はほぼ倍増し、重複コードのブロックは約10倍に増えたとされており、リファクタリングに相当する「移動された行」の割合は2021年の約25%から2024年には10%未満となり、コピー＆ペーストされた行が移動された行を上回ったのもデータ上初めてだと報告されています。
入口で書く量は増えても、再利用や整理は減り、下流の品質コストは切り離せないという特徴をもっていることが示唆されます。
天井を決めているのは、並列化できない判断の側
違う視点でAIを語るときに有用なのはジーン・アムダールが示した法則（アムダールの法則）です。ある仕事のうち、並列化できる部分をどれだけ速くしても並列化できない部分はそのまま残るため、全体の短縮には上限があるという法則で並列化できない部分が3割なら約3.3倍、5割なら2倍程度で止まります。
これを開発に当てはめると、並列化しやすいのは実装やテスト生成です。一方、課題の特定や設計判断、要件定義、レビュー、承認は並列化しにくい。直列が全体の30%なら残りを10倍速くしても全体は約2.7倍、50%なら約1.8倍にとどまります。
人を足すこともAIを足すことも、並列側の処理能力を増やす手段です。天井の高さを決めているのは直列側の割合なので、そこに触らないかぎり、投入量をどれだけ積んでも同じ壁に当たります。
ボトルネックは消えない。移動するだけ
Faros AIの分析（1,255チーム、1万名超）では、AIの採用度が高いチームでタスク完了数やマージされたプルリクエスト（PR）数は増えた一方、PRレビュー時間が91%増え、人間の承認が律速になっていました。
組織レベルでは、AIを採用するのとDORA（DevOps Research and Assessment）メトリクスの改善に有意な相関が見られなかったと報告されています。DORAの2025年版レポートはAIを増幅器と表現しています。流れが整った組織では実装の速さがレビューやリリースと噛み合う一方、レビュー待ちが大きい組織では生成量だけが先に増え、そこで起きるのが消える生産性です。
効率化で空いた時間が、次に何へ使うかが決まっていないと、待ち時間や細かい確認、惰性の作業に吸われて組織の成果には届きません。個人の書く速さは上がっても、チームの出口が動かないという感覚の正体のひとつでもあります。
開発生産性の誤解について、体系的に解説した書籍が発売中です！
