「PRが増えた＝開発生産性が上がった」ではない AI時代のDevExを測る“3つの観点”：Datadog社内の実践に学ぶ（2/2 ページ）

[＠IT]

AI時代の「ツール品質」　ビルドやテストが新たなボトルネックに

　「ツール品質」では、ビルドやテスト、リリースに使う仕組みが開発のボトルネックになっていないかどうかを測る。例えば、CI（継続的インテグレーション）の実行やテスト結果を待つ時間、テストが安定して成功するかどうかなどを追跡する。Datadogは以下の指標を推奨している。

• ビルドとテストの所要時間：開発者がCIのフィードバックを待つ時間
• CIキュー時間：ジョブが実行前にランナー（実行マシン）の割り当てを待つ時間
• 不安定なテストの割合：テストが非決定的に失敗する頻度
• コードカバレッジ：自動テストがカバーするコードの割合

　AIがコード生成を高速化するほど、変更を生む速さとビルドのフィードバックが返る速さの差がボトルネックになる。同じコードでも実行するたびに成功したり失敗したりする「不安定なテスト（フレイキーテスト）」が多いと、テスト結果そのものを信頼しにくくなる。特にAIが生成したコードでは、テストの失敗が既知の不安定さによるものなのか、新たな変更によって不具合が生じたのかを判断しづらくなるという。

認知負荷の主因は「複数のAIエージェントのオーケストレーション」

　認知負荷とフロー状態は直接測れないため代理指標を使う。AI活用が広がる中で新たな負荷となっているのが、複数のAIエージェントを使い分け、連携させる作業だ。開発者はエディタのAIアシスタント、CLIエージェント、CIレビューエージェント、ドメイン特化型エージェントなどを協調させる必要があり、役割の決定や出力の検証、競合の解消が負荷の中心になっている。

　ドキュメントの鮮度やサービス所有者情報の網羅性が低いと、インシデントのたびに手順書や担当者を探すことになり、認知負荷が高まる。ローカル環境とクラウド環境の設定の食い違いを調整する時間も、見過ごされがちな負荷要因だ。計画的な作業と突発対応の比率も重要で、Datadogの最新調査では、インシデント関連の労力が開発者センチメント（心理）全体と最も強く相関していたという。

アンケートが指標に「なぜ」を与える

　システムから取得できる指標だけでは、開発者が実際に感じている負担までは分からない。そこでDatadogは、定期的なアンケートを通じて、開発者の満足度やツールに対する評価、安全にリリースするためにどれだけ手間がかかっているかなどを把握している。例えば、リリース頻度が高くても、ビルドに強い不満を抱えているチームでは、開発者の負担が大きくなっている可能性がある。こうした問題は、DORA指標だけでは見つけにくいという。

　アンケートでは、選択式などの定型的な設問だけでなく、自由記述も組み合わせる。Datadogの直近の調査では2400件を超える自由記述が集まり、システムの指標だけでは把握できなかったボトルネックの発見につながったという。

　結果を全社平均だけで判断しないことも重要だ。チームやリポジトリ、AIの利用頻度ごとに分析すると、全体の数値は安定しているにもかかわらず、レビュー時間が500％以上増加しているチームも見つかった。AIの利用状況についても自己申告だけに頼らず、過去90日間の実際の利用状況を基に開発者を分類し、利用頻度による違いを比較している。

　Datadogは、こうした開発者へのアンケートと、システムや開発ワークフローから取得した指標を組み合わせることで、生産性を妨げている要因を特定し、どこを優先的に改善すべきか判断できるとしている。