価値のある進捗を測る

指標より先に成果を定める

AIツールはコードを素早く生成できます。有用な成果とは、必要な品質水準で利用者の要求を満たす変更です。この二つは異なる測定対象です。

生成行数、採用した提案数、エージェントの実行回数は活動を表します。ツールの使われ方を理解する助けにはなります。しかし、サービスが改善した証拠や、チームが有用な成果を早く届けた証拠にはなりません。

まず問いを一つ設定します。例えば「このワークフローで、小さな保守タスクを完了するための総工数は減るか」です。結果を集める前に完了条件を定めます。必要なテスト、レビュー、ドキュメントを含めてください。

レポートのフィルターを変更する架空の例を考えます。AIを使わない場合、実装は60分、レビューは10分です。AIを使うと、実装は30分、レビューは45分になります。

実装は速くなります。一方、この二つの工程で測定した工数は70分から75分へ増えます。どちらにも、準備、後の修正、リリース後の不具合は含まれていません。この限界を明示してください。

これらの数値は計算の例です。研究結果でも、チームの将来予測でもありません。レビューが増えた原因は、差分の拡大、不慣れなコード、要件の欠落かもしれません。ツールの利用方針を変える前に、原因を調べます。

工数は、人が作業に費やす時間を測ります。経過時間には待ち時間も含まれます。開発者が別のタスクをしている間、エージェントは確認を実行できます。同じ人の時間を二重に数えないでください。レビューや環境を待つ時間も記録します。

ワークフローによって工数が減っても、提供までの時間は減らない場合があります。承認待ちの列が完了日を決めている場合などです。節約した工数に価値があっても、その使い方は組織が別途判断する必要があります。

そのワークフローが、システムの理解や集中の維持に役立つかを開発者に尋ねます。回答は利用体験のデータとして扱います。速く感じるという感想を、検証済みの改善率に変えてはいけません。

METRは、経験豊富なオープンソース開発者を対象とした2025年初めの特定の研究で、作業の遅れを報告しました。すべての開発者やタスクへの効果を示した研究ではありません。2026年2月の更新では、後続の実験における選択の影響と測定上の問題を説明しています。

ここで学ぶべきことは、測定の方法です。ツールのバージョン、タスクの選び方、品質要件、参加者の行動で結果は変わり得ます。過去の一つの割合を、AI開発に永続的に当てはまるルールにしないでください。

DORAの2025年の研究も、ツールを取り巻く組織に注目しています。ツールの能力を有用な提供成果に変えるには、有効な開発の実践が必要です。

実際の仕事を代表するタスクを使い、完了基準をそろえます。モデルとツールのバージョンを記録してください。失敗した試行とレビュー工数も含めます。最もよいデモだけを選ばず、複数のタスクを比較します。

結果の幅と主な限界を報告します。工数が減っても不具合が増えた場合は、利用を広げる前に調べます。結果が混在する場合は、有用な証拠があるタスクの種類に推奨を限定します。

よい測定は、次の具体的な判断に役立ちます。AIが常によい、または常に悪いと証明する必要はありません。