エンジニアリングリーダーたちが集まる部屋で、今年チームの開発速度が上がったかどうかを尋ねれば、大半はためらうことなく「イエス」と答えるだろう。しかし、前倒しされたリリース日、減少したバグ数、あるいは解決された顧客からの苦情を具体的に挙げるよう求めれば、その場はおそらく静まり返るはずだ。
確信と証拠の間のこのギャップこそが真の問題であり、AI導入を囃し立てる大半のヘッドラインよりも綿密に検証されるべきだと私は考えている。
スピードとアウトプットは別物である
AIの利用を生産性と結びつけたくなる衝動は理解できる。画面上にコードが数秒で現れるのを見るのは進歩のように感じられるし、キー入力という単一のレベルで見れば、確かにそうだ。しかし、ソフトウェアのデリバリーにおいて、タイピング速度がボトルネックになったことなど一度もない。
ボトルネックになっていたのは、問題を正確に理解すること、すでに動作しているものを壊さずに新しいロジックを統合すること、そしてバグが顧客に届く前にそれを発見することだった。
コード生成の高速化は、これら3つの制約を何一つ取り除いてはくれない。むしろ、それらにかかる負荷を増大させる。数秒で書かれた関数であっても、それを理解し、テストし、既存のシステムに適合させる必要があり、人間は今でもその3つの作業を以前と同じペースで行わなければならないのだ。
対照実験が明らかにした現実
AIコーディングツールに関する生産性の主張のほとんどは、ベンダーによる調査や自己申告の見積もりに基づいており、どちらも楽観バイアスがかかりやすい。その中で、METRが行った研究は数少ない例外だと私は考えている。それは、経験豊富なオープンソース開発者が、AIの支援あり、またはなしで実際のタスクを完了させるランダム化比較試験だった。
AIの支援を受けたグループは、事前に24%の効率向上を予測していたにもかかわらず、実際には完了までに19%余計に時間がかかった。
予測と結果の間のこのギャップは、速度低下そのものよりも重要だ。これは、開発者が作業中にAIによる自身の作業速度を正確に判断できないことを示唆している。つまり、多くの企業がいまだに依存している自己申告による生産性の指標は、事実ではなく「感覚」を測定しているということだ。
静かに蓄積される「技術的負債」
タスクレベルでの速度低下は問題の一つにすぎない。もう一つの、より気づきにくい問題は、AIが支援したコードがシステムの長期的な健全性に与える影響だ。Git Clearの分析によれば、コードを簡素化し統合する意図的な作業であるリファクタリングは、2億1100万行のコードを対象とした調査で、2021年から2024年の間に全変更に占める割合が25%から10%未満へと落ち込んだ。ちょうどAIコーディングツールが主流化した期間と一致する。
立ち止まって構築したコードを簡素化する開発者は減り、目の前の問題を解決する新しいコードを生成し、すぐに次のタスクへと移る開発者が増えている。
この変化は、スプリントのふりかえり（レトロスペクティブ）には現れない。それが表面化するのは18カ月後、もはや誰も周囲のコードを安全に触れなくなったために、日常的な機能追加の要求に通常の3倍の時間がかかるようになったときだ。
そのようにして構築されたソフトウェアは、価値ではなく「重荷」を蓄積し、耐用年数は延びるどころか縮んでいく。
真の恩恵が集中する場所
これらはすべて、AIの導入に反対するためのものではない。ガートナーの調査によると、エンジニアリングリーダーの90%が実質的な生産性の向上を報告しており、測定された平均向上率は19.3%だった。この数字とMETRの結果は、必ずしも矛盾するものではない。
これらは2つの異なる集団を説明している。すなわち、コード生成の規模拡大に伴ってレビュー能力やテストの規律も拡大させた組織と、コード生成だけが先行して進んでしまった組織である。
この違いは、ツール自体の問題ではなく、完全にガバナンスの問題だと私は考えている。ソフトウェア開発におけるAI活用に関する最近の統計によると、企業の60%がテストされていないコードを使い続けている。端的に言えば、多くの組織は自覚がないまま、すでに後者のグループへと転落しているのだ。
自社組織における状況を見極める方法
AIが実際にエンジニアリングのパフォーマンスを向上させているかどうかを知りたい場合は、以下のことを試してみてほしい。
・AI導入前後でのバグやインシデントの発生率を比較する。開発者の感覚に頼るのではなく、デリバリー指標を使用する。すでに証明されているように、体感速度と実際の速度は大きく乖離することがある。
・新規コードとリファクタリングされたコードの比率を経時的に追跡する。リファクタリングの割合の減少は、メンテナンス性の低下を示す初期の警告サインである。
・AIが生成したコードをマージする前に、明確に定義されたレビューとテストの関門を義務付ける。テストされていないコードが本番環境にデプロイされるのは、もはや例外的なケースではなく、データとして裏付けられた常態的なパターンである。
・コード生成速度とレビュー能力の間のギャップに対する明確な責任を、エンジニアリングの指導部に与える。リリースのサイクルが進むにつれて、一方が他方を置き去りにして加速するような事態を黙認してはならない。
・導入データではなくデリバリーデータを用いて、四半期ごとに生産性の問題を再検証する。ツールの使用率だけでは、ビジネスにおいて頑健なソフトウェアのリリースが迅速化されているかどうかは何も分からない。
AI単体では、開発者をより生産的にすることも、より忙しくすることもない。良くも悪くも、組織のエンジニアリングプロセスにすでに存在する規律を拡大するだけだ。AIがチームをどちらの方向に引っ張っているのか、そしてコードベースの長期的な健全性がどうなっているかを知る唯一の方法は、活動（アクティビティ）ではなく、成果（アウトカム）を測定することである。
