11月4日、James Shoreが「Measuring AI's Impact on Delivery Speed」と題した記事を公開した。AIツールを使えば開発が速くなる、というのは多くのエンジニアが肌感覚で持っている認識だが、METRの研究によれば、エンジニアはAIによる速度向上を実際より約50%過大評価していた。この不都合な数字を出発点に、Shoreはより厳密な計測手法を提案している。
METRの研究が示す不都合な数字
高機能なエージェント型AIツールへの投資は桁違いの規模になりつつある。その投資が本当に回収できているのか、直感や「なんとなく速くなった感」だけで判断していいのか。Shoreはそこに問題意識を持つ。
なお、本記事中に登場する「月数万円のコスト」という表現は元記事に明示された数字ではなく、編集部がエージェント型AIツールの一般的な価格帯を参考に補足したものだ。※編集部の考察
「速くなった」をどう測るか——ありがちな罠
まず著者が強調するのは、「デリバリースピード ≠ 生産性」という点だ。速く動いていても、正しい方向に向かっていなければ意味がない。ここでは「チームが与えられた仕事を速く終わらせているか」という、より限定的な問いに絞って議論が進む。
問題は、ソフトウェア開発の速度には標準的な尺度が存在しないことだ。
- 行数・PR数：タスクの性質に依存しすぎる
- フィーチャー数・バグ数：大きさがバラバラ
- ストーリーポイント・ベロシティ：チームの恣意的な定義に依存
- 見積もり通りに終わったか：ソフトウェア見積もりは構造的に楽観的すぎる
「見積もりと実績の比率」を使う発想は悪くないが、それ自体にも複数の罠がある。
計測を難しくする4つの落とし穴
1. 見積もりのばらつき
実際のプロジェクトデータをプロットすると、見積もりに対する実績の比率はS字カーブを描く。個々のタスクは大きくばらつくため、改善の効果は集計レベルで曲線のシフトとして初めて見えてくる。
2. 人によって働き方が異なる
楽観的に見積もる人、悲観的に見積もる人、他者の教育に時間を使う人。チーム間の横比較はノイズが多い。同一人物との自己比較が基本になる。
3. AIを使うと分かった瞬間に見積もりが変わる
「AIを使う」と知ってから見積もると、人は無意識に小さめの数字を出す。対策は単純で、タスクを渡す前に見積もりを取り、その後でAI使用の有無をランダムに割り当てる。
4. AI以外の変化が混入する
AIの導入に合わせて、ワークフローの整理や開発者とビジネス担当者の連携強化を行うケースは多い。しかしそれらはAI抜きでも効果がある変化だ。AIの効果だけを取り出すには、「AIなし」の条件にも同じワークフロー改善を適用し、並行して実施する必要がある。
推奨される実験設計：ランダム化内被験者反復測定試験
著者が提案するのは、「ランダム化内被験者反復測定試験（randomized within-subject repeated-measures trial）」という実験設計だ。統計学の用語で難しく聞こえるが、実際にやることはシンプルだ。
- 「AIあり」と「AIなし」それぞれのアプローチを明確に定義し、両方に習熟させる
- 各メンバーに「AIあり50%・AIなし50%」の仮想バッグを渡す
- タスクが来たらまず見積もりを記録し、その後バッグからランダムにAIの使用有無を引く
- 見積もり時間・実績時間・タスク種別を記録する
なお、ステップ4における「AIコストの記録」が元記事で実験設計の必須ステップとして明示されているかは確認中であるため、ここでは元記事の記述に沿った項目のみ列挙している。※編集部の考察
集計は個人ごとに「AIあり」と「AIなし」を比較し、その後チーム全体で集約する。詳細な実験設計とデータ分析には統計家の協力が必要になる。
「コーディングが2倍速くなった」は本当に2倍か
著者が指摘する見落としやすいポイントがある。計測対象タスクが全業務に占める割合だ。
コーディング速度が2倍になったとしても、エンジニアが週の一定割合をコーディング以外の業務（会議・レビュー・調整等）に使っているなら、全体の速度向上はその分だけ小さくなる。「2倍速くなった」という報告をそのまま信じるのは危険だ。
なお、元記事中の具体的な数値例（業務配分の割合や速度向上の倍率）については元記事本文を直接参照されたい。紹介記事中の計算例が元記事の数値と乖離する場合は誤読のリスクがあるため、ここでは原文に忠実な形で概念のみ紹介する。※編集部の考察
この手法はコスト対効果があるか
著者は正直に認めている。PR数を数えるより、はるかに手間がかかる。
ただし、背景を考えれば話は変わる。エージェント型AIツールへの投資は桁違いの規模になりつつある。安価なオートコンプリートと高価なフル自律型エージェントのどちらに投資すべきかを、データなしに判断するのはリスクが高い。先述のMETRの研究が示すように、主観的な速度感は信頼できない。
チームが通常業務の中でデータを収集できる設計になっているため、追加の負荷は計測の仕組みを整える部分に集中する。最も難しいのは「AIをどう使うか」を明文化することだが、それ自体が開発プロセスの整理として意義を持つ。
詳細はMeasuring AI's Impact on Delivery Speedを参照していただきたい。
