DXは先日、400以上のエンジニアリング組織を対象とした16か月にわたる縦断研究の結果を公開した。AIツールの利用は65%増加した一方で、PRスループットの中央値は8%弱の上昇にとどまった。多くの組織は5〜15%の範囲に収まっている。有意義な数字ではあるが、一部のベンダーがうたう3倍や10倍には遠く及ばない。

Microsoftで開発者生産性の研究を率いるBrian Houck氏は、その理由についてこう説明している。コーディングが開発者の1週間の業務時間の約14%を占めるにすぎないというのだ。コーディング部分で大きな効率化が得られたとしても、取り戻せる時間には限りがある。

残りの86%――レビューや計画、デバッグ、コンテキストスイッチ、ステークホルダーとのやり取り、理解が不十分なまま作ってしまって発生する手戻りなど――は、コードを書くスピードが上がったからといって速くはならない。

これはコーディングツールを否定する話ではない。私自身、毎日使っている。ただ「コーディングツールを導入する」だけでは戦略とは呼べない。私は最近、Mintelで新たな領域にフォーカスしている。エンジニアリングチームによるAIツールの導入を最適化することだ。チームがより速く動けるようにすることが私の仕事だとすれば、どのツールがどのチームの役に立っているのか、本当のボトルネックはどこにあるのか、チームが実際に抱える課題に対して投資をどう振り向けるべきかを知る必要がある。それはツールの問題である前に、計測の問題なのだ。

DORAは「何が起きたか」は教えてくれるが、「なぜ」は教えてくれない

多くのチームは、すでに何かを物語ってくれるデータを手にしている。DORAメトリクス（デプロイ頻度、変更のリードタイム、変更失敗率、復旧までの時間）は妥当な指標だが、メトリクスを持っていることと、その意味を理解することは別問題だ。

2年前、私はGitLab APIを使ってリポジトリのアクティビティからデプロイ頻度とリードタイムを取得する社内ダッシュボードを作った。エンジニアリングマネージャーたちが使っており、Jiraのサイクルタイムだけを見るよりも地に足のついた議論ができるようになった。だが、その限界もすぐに明らかになった。リードタイムが遅くなったことは教えてくれても、なぜそうなったかはわからないのだ。メトリクスを手作業でスプレッドシートにエクスポートしてパターンを探しているEMとも話したことがある。データはあるのにインサイトがないことの明確なサインだ。

計測がなければ勘に頼ることになる。計測はあってもコンテキストがなければ、チャートを眺めているだけだ。

より地に足のついたレトロスペクティブへ

そのギャップを埋めるため、私はメトリクスをレトロの議論に持ち込むためのエージェントを作ってきた。定量的なデータと定性的なデータを組み合わせて「なぜ」を理解するためのものだ。JiraとGitLabからスプリントのメトリクス（当該スプリントと直前2回分）を取得してLLMに渡し、個別のチケットやマージリクエストを参照するツールも持たせている。出力されるのは、チームのスプリントレトロスペクティブで使うための仮説と論点のセットだ。データが示唆するパターン、問うべき問い、深掘りすべき論点である。

これはレトロスペクティブを自動化するものではない。レトロスペクティブとは、チームが自らの経験を振り返る場であり、そのプロセスは人間が行うからこそ価値がある。共通理解を築き、メトリクスには現れないことを浮かび上がらせ、率直な対話を可能にする心理的安全性を生み出す。アルゴリズムがそれに取って代わることはできない。

エージェントにできるのは、問いを起点に糸を手繰り寄せていくことだ。実際のスプリントからいくつか例を挙げる。

• サイクルタイムが急増した。 エージェントはサイクルタイムが長くなったチケットがワークフローをどう移動したかをたどり、その多くが「blocked」を行き来していたことを浮かび上がらせる。「サイクルタイムが上がっています」ではなく、「サイクルタイムが上がっており、多くのチケットが繰り返しblockedに滞留していました――計画時に考慮できていなかった外部依存があったのでは？」という問いになる。
• 1つのチケットが3週間も引っ張られた。 エージェントは紐づくMRをたどり、作業が3つのサービスにまたがっていたことを見つける。「遅いチケットでした」ではなく、「このチケットは3つのサービスにまたがっていました――変更の境界は適切でしょうか、それとも今後も付きまとう結合のコストを払い続けているのでは？」となる。
• あるMRが1週間レビューで止まっていた。 エージェントは差分を確認し、40ファイル以上が変更されていたことを見つける。「レビューが遅い」ではなく、「このMRは適切にレビューするには大きすぎたのでは――本来分割すべき変更がまとめられてしまうパターンがあるのでは？」という問いになる。

これらはあくまで仮説だ。チームがそれらを評価し、反論し、どれが腑に落ちるかを判断する必要がある。目指すのは、人間が主導する対話の冒頭で、データに裏打ちされたより良い問いを提示することだ。全体像を把握しているエンジニアが、本当に何が起きているのかを振り返れるようにするために。

コード生成の先にあるエージェント

エンジニアリングにおけるAIの話題は、ほとんどがコードを書くことに収束する。DXのデータが示すように、生産性の向上は確かにあるが限定的だ。もし残り86%の業務に大半の時間が費やされているのだとすれば、生産性向上の余地があるのはまさにそこだ。

レトロスペクティブ用のエージェントはコードを書かない。チームが自分たちの時間をどこに使っているかを見えるようにし、それについてより良い問いを立てられるようにするものだ。もしこれがうまくいけば、最も面白いエージェントの使い方は、コーディングエージェントとはまったく違うものになる可能性を示す一つの事例になる。

これは連載の第1回だ。次回では、エージェントがどのように動いているのか――データソース、プロンプトの設計、そして難しいポイントについて扱う。その次は、どのように展開したのか、そして実際の利用から何を学んだかについてだ。