ツール導入の前に計測から：エンジニアリングにおけるAI投資はどこに向けるべきか
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回です。次回はエージェントの仕組みについて、データソースやプロンプトの設計、そして難しいポイントを解説します。その後は、どのように展開したのか、実際の利用から何を学んだのかをお届けする予定です。