連載第3回では、技術的負債と認知的負債という帳簿に乗りにくい負債を扱いました。その負債を抱えた現場に次に降ってくるのは開発量の要求です。「この機能に追加してほしい!」「足りないなら人を増やせ」といった声に、ここ数年はAIエージェントで開発量を確保すればいいという期待が加わりました。人月をAI人月に置き換えれば間に合うという読みも、DMM.comの現場で何度も出てきました。第4回では、この2つが同じ形の誤解であることを解きほぐします。
前回の連載はこちらから。
「足りないなら増やせ」と言われた後に現場で起きること
技術的負債の改善活動が進んで影響調査もしやすくなった!という現場感覚とは別に、営業は「この機能がないと次期契約が危ない」、マーケティングからは「新機能がないとプロモーションの材料がない」という要望は常日頃続きます。
リファクタリングや定期的なミドルウェアのバージョンアップといった保守運用をしながら、さらなる新規開発の割合を増やしていくにはエンジニアを追加する選択肢もありますが、現場によっては現有リソースでどうにかしてほしいというのが予算上あったりします。
採用に踏み出しても、面談から入社までに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を増幅器と表現しています。流れが整った組織では実装の速さがレビューやリリースと噛み合う一方、レビュー待ちが大きい組織では生成量だけが先に増え、そこで起きるのが消える生産性です。
効率化で空いた時間が、次に何へ使うかが決まっていないと、待ち時間や細かい確認、惰性の作業に吸われて組織の成果には届きません。個人の書く速さは上がっても、チームの出口が動かないという感覚の正体のひとつでもあります。
開発生産性の誤解について、体系的に解説した書籍が発売中です!
会員登録無料すると、続きをお読みいただけます
この記事は参考になりましたか?
- 誤解だらけの開発生産性 〜DMM.comで見てきた誤解〜連載記事一覧
-
- 評価の誤解 〜エンジニアだけが生産性を求められる構造〜
- 人月の誤解 〜「人が足りない」「AIで増やせる」の幻想〜
- 技術的負債の誤解 〜「測れないから説明できない」を越えることと認知的負債について〜
- この記事の著者
-
石垣 雅人(合同会社DMM.com)(イシガキ マサト)
DMM .comにエンジニア職で新卒入社し、翌年からプロジェクトマネージャーを務める。 いくつかのプロダクトマネージャーを経て2020年、DMM.comの入り口である総合トップなどを管轄する総合トップ開発部の立ち上げを行い、部長を従事。 現在はプラットフォーム事業本部 第1開発部 部長 / VPo...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア

