7.2 AI支援のソフトウェア開発の測定

概要と動機

トピック7.1は、AI支援の開発の下で、なぜいくつかの既存の指標がもはや以前測定していたことを信頼できる形で測定しないかを確立しました。本トピックは、代わりに何を測定すべきかについてです。印象やベンダーのマーケティングではなく本物の証拠で、AIのコーディング支援があなたの組織に実際に役立っているかどうか、そしてどれだけ役立っているかをどう知るかです。これは本物に重要な、実際の予算への結果を伴う問いです。AIのツールのライセンスは本物の継続的なコストを表し、トピック5.4の単位経済性の規律が直接適用されます。それに証拠をもって答えられない組織は、役に立っていないツールに過剰に支払っているか、本物に役立っているツールに過小投資しているかのどちらかです。

本トピックのアプローチは、トピック1.3の産出より成果の原則に直接基づいており、今やAIのツール評価に特に適用されます。素朴で最も一般的なアプローチは、AI支援の開発をアウトプットの量、生成されたコードの行数、受け入れられた提案、開発者が自己報告したタスクあたりの節約された時間によって測定します。これはまさにトピック7.1がこの変化に最も露出していると警告した指標です。本トピックが推奨するより厳密なアプローチは成果を測定します。AI支援は品質を劣化させることなく本物にサイクルタイムを減らしたでしょうか、本物に低価値の反復的な仕事に費やされる時間を減らし、より高い価値の仕事のための容量を解放したでしょうか、そして第5部のビジネスと製品の成果に測定可能な影響を与えたでしょうか。

大規模なチームにとって、この測定を正しく行うことは、AIのツールへの投資の決定が証拠に基づいてなされるか、ベンダーの主張と組織的な勢いに基づいてなされるかを決定します。大規模なAIツールの契約を交渉する企業組織は、その支出を正当化し、競合するツールを公平に比較するために本物の価値の証拠を必要とします。しばしば技術支出について特に精査される政府組織は、大規模なAIツールの採用に公的資金をコミットする前に厳密で擁護可能な評価方法論を必要とします。

重要な原則

アウトプットの量やベンダーが報告する利用統計ではなく、成果によってAI支援を測定してください。 トピック1.3の規律がここで全力で適用されます。
可能な限り本物の比較グループを使ってください。 業界全体で上昇するベースラインによって交絡されうる単なる前後比較ではありません。
自己報告された時間の節約はそれ単独では弱いシグナルである。 それを客観的なサイクルタイムと品質のデータと組み合わせてください。
レビューと修正の時間を含む完全なコストを測定してください。 生成の速度だけではありません。
異なるタスクと異なるエンジニアは、AI支援の価値について非常に異なる経験をするかもしれない。 この変動を隠す単一の混合された組織全体の数字を避けてください。

推奨事項

単なる前後のスナップショットではなく、本物の比較を構築する

可能な場合、あなた自身の組織の前後の数字だけを比較するのではなく、同じ期間にわたって、AI支援を使うグループと、それを使わない比較可能なグループの間で成果を比較してください。前後の比較だけでは、AI支援の効果を他の同時進行の変化から区別できません(トピック1.6の交絡変数への注意が直接適用されます)。真の比較グループが非現実的な場合、少なくとも、平均への回帰や無関係な同時進行の変化に脆弱な単一の前後のスナップショットではなく、より長い過去のベースライン(トピック1.6に従った管理図)と比較してください。

サイクルタイムと品質を一緒に測定し、AI支援の速度の主張だけを決して測定しない

トピック2.6とトピック2.10の規律を直接適用してください。AI支援の仕事がサイクルタイムの段階をより速く進むかどうかを追跡し、同時にその仕事について変更失敗率あるいはエスケープした欠陥率(トピック5.1)が間違った方向に動くかどうかを追跡してください。本物の生産性の利益は、安定したあるいは改善された品質とともに速いサイクルタイムを示します。偽の利益は、劣化する品質とともに速いサイクルタイムを示します。これはまさにトピック7.1が警告したトレードオフであり、ここでは本書が一貫して適用する同じ対になった指標の規律を通じて発見されます。

レビューと修正の時間を完全なコスト会計に含める

生成はより速いがレビューはより遅い、あるいは最初の生成の後により多くの修正と手直しを必要とするAI生成のコードは、たとえ最初のコード生成のステップが個々のエンジニアにとって劇的に速く感じられたとしても、完全なパイプラインが測定されると正味のサイクルタイムの改善を示さないかもしれません。完全なサイクルタイムの連鎖(トピック2.6)を測定してください。コーディングの段階だけではありません。感じられたが不完全な速度の感覚に基づいてAI支援を評価するのではなく、これを正直に捕捉するためです。

自己報告された時間の節約を結論ではなく出発点の仮説として扱う

開発者の自己報告「これは1時間節約した」は、初期のシグナルとして、そして定性的な文脈として有用ですが(トピック5.3の定量的と定性的を組み合わせたアプローチがここでも適用されます)、トピック1.5がどんな自己報告データについても警告する同じ想起と望ましさのバイアスにさらされており、下流のレビューや修正のコストについては何も語りません。自己報告を使ってAI支援が最も役立っている場所についての仮説を生成し、堅固な結論を出す前にそれらの仮説を客観的なサイクルタイムと品質のデータに対して検証してください。

タスクの種類別に測定をセグメント化し、単一の混合された数字を避ける

AIのコーディング支援は、おそらく定型的でよく理解されたタスクに対しては、本物に新規で複雑な問題解決に対してとは非常に異なる価値を提供します。単一の混合された組織全体の平均ではなく、タスクのカテゴリー別に測定し報告してください。混合された数字は、ある支援があるカテゴリーで強い価値を提供している一方で、別のカテゴリーではほとんどあるいはマイナスの価値さえ提供しているという事実を隠すことがあります。これは混合された数字が完全に曖昧にする情報です。

トレードオフ:長所と短所

アプローチ	長所	短所
自己報告された時間の節約だけ	速く、収集しやすい	弱いシグナル。バイアスにさらされる。下流のレビューコストを無視する
前後比較だけ	設定が単純	他のどんな同時進行の変化や業界全体のトレンドによっても交絡される
本物の比較グループ	最も強力で最も擁護可能な証拠	手配がより難しい。完全な採用の展開では実現不可能かもしれない
タスクをセグメント化した成果の測定	価値が本物に集中する場所を明らかにする	より詳細な追跡と分類の努力が必要

中心にある緊張関係は測定の厳密さと実用的な実現可能性です。本物の統制された比較グループは最も強力な証拠ですが、ツールが保持された統制グループなしに組織全体に展開された後ではしばしば非現実的です。自己報告された印象は速く簡単ですがそれだけでは弱いです。この緊張を、あなたの実際の展開が許す最も強力な比較設計を使うことで解消してください。可能なら早期の試験段階での本物の統制グループ、できないなら過去のベースラインの管理図です。そしてどの比較設計を最終的に使うことになっても、自己報告を最終的な言葉ではなく仮説生成のツールとして扱ってください。

チームで話し合うべき問い

私たちは、AIのツールの採用を評価するための本物の比較グループを持っていたでしょうか、あるいは今でも構築できるでしょうか、それとも完全に前後比較に頼っているでしょうか。真の比較グループが一度も確立されなかったなら、過去のベースラインの管理図が依然として合理的に厳密な代替手段を提供できるかを話し合ってください。
私たちはAI支援の仕事についてサイクルタイムと品質を一緒に測定したでしょうか、それとも対応する品質の確認のない速度の主張だけを持っているでしょうか。存在するどんなデータでも取り出し、この特定の組み合わせを確認してください。存在しないなら、そのギャップが本トピックの単一の最優先の修正です。
私たちのAI支援の仕事についてのサイクルタイムの測定は、レビューと修正の時間を含んでいるでしょうか、それとも最初の生成のステップだけでしょうか。下流のレビューコストを無視した生成時間だけに基づく速度の主張は、本トピックが直接警告する不完全な会計の罠のリスクを冒します。
私たちはどのような自己報告された時間節約の主張を収集し、それらのどれかを客観的なデータに対して検証したでしょうか。 特定のよく繰り返される主張を一つ選び、客観的なデータが実際にそれを裏付けているかを確認してください。
私たちの現在の測定はすべてのタスクの種類を一つの数字に混合しているでしょうか、それとも私たちは、どの特定の仕事のカテゴリーが最も強いAI支援の価値を示すかを知っているでしょうか。混合されているなら、タスクをセグメント化した内訳が現在の数字が隠しているものを何明らかにするかを話し合ってください。
もし今日、印象ではなく証拠を使って、懐疑的な財務のステークホルダーに私たちのAIツールへの投資を擁護しなければならないとしたら、私たちは実際に彼らに何を示すことができるでしょうか。この具体的なテストは、あなたの組織が現在AI支援の価値について信じていることと、それが実際に証拠で実証できることの間のギャップを表面化させます。

業種別の視点

スタートアップ。 正式な比較グループの研究は、小規模では通常非現実的ですが、仕事がどれだけ速く感じられるかに純粋に頼るのではなく、サイクルタイムと欠陥率についての単純で正直な前後の見方でさえ、印象だけよりも意味のある形で信頼できるシグナルを与えます。

中小企業。 AI支援の価値が最も明確で測定可能である可能性が最も高い、あなたの最も価値の高い最も反復的なタスクのカテゴリーにまず測定の努力を集中させてください。あなたの小さなチームが行うあらゆる種類の仕事にわたる包括的な評価を試みるのではなくです。

企業。 完全な組織全体の展開の前の、早期の試験段階における本物の統制された比較は、ここではしばしば達成可能であり、それを手配するための意図的な努力に値します。それは、成功した試験の後に通常続く大規模なツールへの投資決定のためにはるかに擁護可能な証拠を生み出すからです。

政府。 AIツールの調達を含む公共の技術支出の決定は、しばしば特別な精査に直面し、正式な費用便益の正当化(トピック5.5)を必要とするかもしれません。本トピックが推奨する測定の規律を最初からどんな試験段階にも組み込んでください。厳密で文書化された評価方法論は、最終的な資金提供や調達の事例をかなり強化するからです。

事例

企業。 あるソフトウェア会社は、意図的な試験として、エンジニアリングチームの半分にAIのコーディングアシスタントを展開し、完全な展開の前の1四半期は残りの半分を比較グループとして保持しました。試験グループは、明確に定義された定型的なタスクについて本物の統計的に意味のあるサイクルタイムの改善を示しましたが、複雑で新規のアーキテクチャの仕事については測定可能な改善を示さず、わずかに高まったレビューの反復回数(トピック2.9)を示しました。本物の比較設計とタスクカテゴリーの内訳のおかげでのみ見えたこのタスクをセグメント化した発見は、会社がAI支援を一律のすべての仕事にわたる生産性の向上として提示するのではなく、それが実証的に役立ったタスクのカテゴリーに特にAI支援の展開メッセージと訓練を的を絞って向けることにつながりました。

政府。 ある連邦機関は、近代化プログラムのチームの一部についてAIのコーディング支援を試験的に実施し、当初は自己報告の時間節約の調査に頼っていました。それは熱狂的で一様に肯定的な回答を示していました。試験チームと類似のシステムコンポーネントで作業する比較可能な非試験のコホートの間でサイクルタイムとエスケープした欠陥率を比較するフォローアップの客観的な分析は、客観的なサイクルタイムの改善は本物だが、自己報告の見積もりが示唆していたよりも著しく小さいことを発見し、生成速度の利益の一部を相殺していた穏やかだが本物のレビュー時間の増加を特定しました。これは自己報告データだけでは完全に見逃していた発見です。このより正確で証拠に基づいた全体像は、そのツールの継続的な拡大された調達のためのより控えめでより擁護可能なビジネスケースに直接情報を与えました。

ビジネスケース:動機、ROI、総所有コスト

AI支援の開発を厳密に測定することからの見返りは、自信に満ちた証拠に基づいた投資決定です。AI支援が本物に役立つ場所を正確に知っている組織は、そこで拡大するために投資でき、ほとんど価値を提供しないタスクのカテゴリーでライセンスに過剰に支払うことを避けられます。これはまさに上記のソフトウェア会社の例が示すタスクセグメンテーションの洞察です。これはトピック5.4の単位経済性とトピック5.5のROIの規律に直接つながります。AIのツールのコストは、しばしば席あたりでライセンスされ、本書が他のどんな主要なエンジニアリング投資にも適用する同じ厳密な費用便益の扱いを必要とするからです。

総所有コストは、本物の比較を構築し、レビューと修正を含む完全なサイクルタイムを測定し、タスクの種類別にセグメント化する分析の努力であり、これはベンダーが報告する利用統計や自己報告された印象を額面通り受け入れるよりも多くの作業です。その努力は、大規模な組織全体のAIツールのライセンスコストの規模と、データではなく印象に基づいた、証拠の乏しい高価な組織全体のコミットメントのリスクによって直接正当化されます。

アンチパターンと落とし穴

アウトプットの量やベンダーの利用統計だけでAI支援を測定する。 トピック7.1の中心的な警告を直接繰り返します。
完全に自己報告された時間の節約に頼る。 バイアスに脆弱で、下流のレビューと修正のコストに盲目な弱いシグナルです。
完全なサイクルタイムを無視して生成速度のステップだけを測定する。 実際の生産性効果の不完全で潜在的に誤解を招く会計を生み出します。
単一の混合された組織全体の数字を報告する。 異なるタスクのカテゴリーにわたる価値の実際の変動を隠します。
比較グループや過去のベースラインがない。 AI支援の実際の効果を他のどんな同時進行の変化からも区別できません。
熱狂的な自己報告の調査結果を大規模な投資決定のための十分な証拠として扱う。 上記の連邦機関の例がより厳密な比較を構築した後にのみ発見したまさにそのギャップのリスクを冒します。

成熟度モデル

レベル1、開始: AI支援の開発の価値は、評価されているとしても、自己報告された印象とベンダーの利用統計だけを通じて評価されています。
レベル2、発展: いくつかのサイクルタイムあるいは品質のデータが存在しますが、本物の比較グループや過去のベースラインはなく、タスクをセグメント化した分析もありません。
レベル3、標準化: 対になったサイクルタイムと品質の測定を伴う本物の比較設計(統制グループあるいは過去のベースライン)が、タスクの種類別にセグメント化されて一貫して適用されています。
レベル4、管理: レビューと修正の時間を含む完全なサイクルタイムの会計が追跡されています。自己報告された主張は体系的に客観的なデータに対して検証されています。
レベル5、最適化: 組織は、AI支援が本物に役立つ場所についての成熟した証拠に基づいた理解を持ち、実証され擁護可能なROIで的を絞った展開、訓練への投資、調達の決定に情報を与えています。

議論のためのアイデア

私たちの現在のAIツールの採用について、もしあるなら、私たちが持っている本物の比較は何でしょうか。
私たちはサイクルタイムと品質を一緒に測定したでしょうか、それとも速度の主張だけでしょうか。
どの自己報告されたAI支援の主張を私たちは客観的なデータに対して検証すべきでしょうか。
どの特定のタスクのカテゴリーが、私たちにとって本物のAI支援の価値の最も強い証拠を示すでしょうか。
私たちは現在、証拠を使って懐疑的な財務のステークホルダーに私たちのAIツールへの投資を擁護できるでしょうか。

主な要点

アウトプットの量やベンダーが報告する利用統計ではなく、成果でAI支援の開発を測定してください。
交絡因子に脆弱な単なる前後のスナップショットではなく、本物の比較グループあるいは過去のベースラインを使ってください。
完全なパイプライン、レビューと修正の時間を含めて、サイクルタイムと品質を一緒に測定してください。生成速度だけではありません。
自己報告された時間の節約を結論ではなく仮説として扱い、それを客観的なデータに対して検証してください。
タスクの種類別にセグメント化してください。 単一の混合された数字は、価値が本物に集中する場所とそうでない場所を隠します。

参考文献とさらなる読書

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
AIのペアプログラミングと開発者の生産性についてのGitHubの研究。
Forsgren, Nicole、Margaret-Anne Storey、Chandra Maddila、Thomas Zimmermann、Brian Houck、Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue(2021年)。
How to Measure Anything, Douglas W. Hubbard 著。