7.1 生成AIのパラダイムシフト

概要と動機

ソフトウェアエンジニアリングの歴史のほとんどにおいて、コードを書くことは十分に遅く労力を要するものであり、生のアウトプットの量、書かれた行数、行われたコミット、出荷された機能は、少なくとも緩く本物の努力と相関し、不完全ながら本物の価値と相関していました。その相関は決して完璧ではありませんでした。トピック3.4は、AI以前の世界でさえ活動の指標がなぜ誤解を招くかについてトピックを一つ丸ごと割きました。しかし、それは多くの組織が、より多くのコードが生み出されることは一般により多くの仕事がなされたことを意味するという暗黙の仮定の上に指標プログラムを構築するのに十分なほど強いものでした。生成AIのコーディングアシスタントはその仮定を決定的に打ち砕きました。ツールは今や、以前のコストのごく一部で、数秒で大量のもっともらしく見えるコードを生み出すことができ、その量だけでは、結果として得られたコードが機能するか、保守可能か、あるいは何か本物の目的に奉仕するかについてほとんど何も教えてくれません。

本トピックの中心的な主張は、これが段階的なツールの変化ではなく、パラダイムシフトであるということです。パラダイムシフトは、既存の計器が報告する値だけでなく、それが実際に測定するものを変えます。速度計は、車のエンジンを変えた後も速度を測定し続けますが、本書のいくつかの指標はこの移行をそれほどきれいには生き延びません。デプロイ頻度(トピック2.10)は、AIが本物に価値のある仕事を加速させたために上昇することもあれば、AIが多くの小さな低価値の変更を生み出すことを些細なほど容易にしたために上昇することもあります。数字だけでは、以前は適切な注意を払えばほとんど可能だった方法で、もはや二つを区別できません。同じ論理は、生のコミット件数、コード行数、プルリクエストの量にさらに強い力で適用されます。これらはすべてトピック3.4がすでに個々の指標として警告していたものであり、今やチームおよび組織レベルでも関連するリスクへと増幅されています。

大規模なチームにとって、この変化はほとんどの組織の測定の実践が適応できたよりも速くやってきました。そして採用の速度と測定の適応の間のギャップこそが、この部の本物のリスクが存在する場所です。調整なしにAI以前の時代の活動指標を報告し続ける企業組織は、静かに価値と相関しなくなった指標を祝うリスクを冒します。AIのツールへの投資を評価する政府組織は、調達や政策の決定を古い測定の仮定の上に構築されたものにコミットする前に、正確にどの指標が信頼できるままで、どれがもはやそうでないかについての明確な理解を必要とします。

重要な原則

これは指標が測定するものにおけるパラダイムシフトであり、段階的な変化ではない。 いくつかの既存の指標は、静かに以前意味していたことを意味しなくなりました。
アウトプットの量は決して価値の信頼できる代理ではなかったが、今では積極的に信頼できなくなった。 トピック3.4の警告は常に正しかったのです。この変化はそれを無視することをはるかにコストのかかるものにします。
AIの採用の速度と測定の適応の速度の間のギャップこそが本物のリスクである。 組織は、指標を再検討するよりも速くツールを採用します。
本書のすべての指標が等しく影響を受けるわけではない。 成果の指標(第5部)は、活動と生のアウトプットの指標よりもこの変化に対してはるかに回復力があります。
この変化は業界全体にわたり継続的であり、一度限りの調整ではない。 ツールとその採用のパターンが進化し続けるにつれて、継続的な変化を予期してください。

推奨事項

既存の指標セットをAI時代の妥当性について明示的に監査する

あなたの現在のダッシュボードを見直し、各指標について直接問うてください。AI支援を大いに使っているが以前より多くの本物の価値を生み出していないチームは、この指標で改善された読み取り値を示すでしょうか。活動の件数、コミットの頻度、そして(対になった安定性のガードレールなしの)生のデプロイ頻度(トピック2.10)は最も露出しています。第5部の成果の指標、エスケープした欠陥率、機能の採用、ビジネスの成果は、比較的回復力があります。それらは、それを生み出した活動の量ではなく実際の結果を測定するからです。

デプロイ頻度とリードタイムを特に、高まったガードレールの注意を持って再検討する

トピック2.10はすでに代替のゲーミング、件数を膨らませるために意味のある仕事を些細なデプロイに分割することについて警告していました。生成AIは、意図的でなくても、AI支援の些細な変更が今やほぼ無料で生成できるため、この特定のゲーミングのパターンを劇的に安く容易に生み出せるようにします。チームがどれだけAI支援の開発を採用しているかに特に比例して、あなたの変更失敗率のガードレール(トピック2.10)を引き締め、以前よりもさらに注意深くデプロイのサイズのトレンドを見守ってください。

コードレビューの容量を新しい重要なボトルネックとして扱う

AI支援がレビューのために提案されるコードの量を劇的に増やす場合、すでに提供パイプラインにおける最大の待ち時間の要因であることが多いレビューの段階(トピック2.9)は、さらに鋭い制約になります。以前と同じペースでAI生成のコードのはるかに多い量を評価するよう求められたレビュアーは、必然的にパイプラインを減速させるか、レビューの深さを減らすかのどちらかになります。これはまさにトピック2.9がすでに警告していたゴム印のリスクであり、今やかなり大きなプレッシャーの下にあります。AI生成のコードの量が上昇するにつれて、高まった注意でレビューの深さと品質のガードレールを監視してください。

AI生成のコードが人間が書いたコードと同じ欠陥プロファイルを持つと仮定しない

初期の証拠と実践者の経験は、AI生成のコードが人間が書いたコードとは異なる欠陥プロファイルを持つ可能性を示唆しています。もっともらしく見えるが微妙に間違ったロジック、自信を持って生成されたが不正確なエッジケースの処理、あるいは、慣用的で合理的に見えるために表面的なレビューを通過するが、システムの特定の文脈への本物の理解を持って実際には推論されていないコードです。これを、あなたの組織の品質実践が構築された歴史的な欠陥率の関係が依然として変わらず成り立っていると仮定するのではなく、あなた自身のエスケープした欠陥データ(トピック5.1)に対して積極的にテストする価値のある仮説として扱い、由来のコードが実質的にAI生成であったかどうかで欠陥にタグをつけてください。

この変化のために指標憲章とガバナンスのプロセスを明示的に更新する

トピック1.4のガバナンスの規律に従い、この変化があなたの指標プログラムに受動的に起きるままにしないでください。あなたの指標憲章を明示的に見直し、どの指標が新しいガードレールを必要とし、どれが廃止を必要とし、どれが信頼できるままであるかに、検討されない漂流ではなく意図的なガバナンスの決定として名前をつけてください。その理由を文書化してください。これはまさに、トピック1.4がそうでなければ静かに起きてずっと後になって初めて発見されうると警告する種類の定義的で文脈的な変化だからです。

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

アプローチ	長所	短所
AI以前の指標を変更せずに報告し続ける	混乱がなく、馴染みのある報告	静かに価値と相関しなくなった指標を祝うリスクを冒す
完全な指標セットの監査と意図的な改訂	信頼できる測定を回復する	本物の分析の努力と組織的な変更管理が必要
活動とアウトプットの指標を完全に放棄する	最も露出したリスクを直接取り除く	いくらかの正当に有用な文脈的シグナルを失う(トピック3.4の注意事項)
完全な監査なしにガードレールを引き締める	実装がより速い	最も明確なケースほど明白でない指標の露出を見逃す可能性がある

中心にある緊張関係は測定の継続性と測定の妥当性です。組織は理解できる理由から馴染みのある指標を馴染みのある方法で報告し続けることを好みます。指標プログラムを変更することには本物の組織的なコストと混乱があるからです。しかし、以前測定していたことを静かに測定しなくなった指標を報告し続けることは、混乱よりも悪いことです。それは積極的な誤誘導です。この緊張を、短期的には混乱を招くが組織の指標を正直に保つために必要な、トピック1.4が説明するまさにその種の意図的で文書化されたガバナンスの変化として扱うことで解消してください。

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

私たちのダッシュボードの各指標について、AI支援を大いに使っているが以前より多くの本物の価値を生み出していないチームは、改善された読み取り値を示すでしょうか。このテストであなたの指標を明示的にたどってください。これに失敗するものは、改訂されたガードレールあるいは廃止のための最優先候補です。
私たちのデプロイ頻度あるいはコミットの量は、AIのコーディング支援を採用して以来上昇したでしょうか、そして私たちは変更失敗率や欠陥率が対応して動いたかどうかを確認したでしょうか。肯定的あるいは否定的な成果のどちらかを仮定するのではなく、実際の対になったデータを取り出してください。
私たちのコードレビューの容量は、AI支援のコードの量の増加に追いついているでしょうか、それともレビューの深さが増大するプレッシャーの下で静かに侵食されているでしょうか。ゴム印のリスクが強まっている兆候について、レビュー段階の指標(トピック2.9)を特に確認してください。
私たちは由来のコードが実質的にAI生成であったかどうかで欠陥にタグをつけているでしょうか、そうであれば、そのデータはこれまでのところ何を示しているでしょうか。現在これにタグをつけていないなら、始めるために何が必要かを話し合ってください。このデータは、あなたの歴史的な品質の仮定が依然として成り立っているかどうかに直接関連するからです。
私たちはこの変化に照らして私たちの指標憲章(トピック1.4)を意図的に見直したでしょうか、それとも私たちの測定の実践は単に変わらず続いているでしょうか。正直な答えが後者であるなら、そのギャップはまさに本トピックが最初に埋めることを推奨するものです。
私たちの組織が、すでに考えていたことを意味しなくなった指標を祝いながら、この変化に不意を突かれるとしたらどうなるでしょうか。 この具体的で少し不快な思考実験は、そのシナリオが実際に起きた後ではなく前に、本トピックが推奨する監査を動機づけるのに役立ちます。

業種別の視点

スタートアップ。 速いAIツールの採用は一般的であり、しばしば本物の競争優位性ですが、採用を魅力的にする同じ速度が、検討されない指標の漂流をより起こりやすくします。AIの採用から報告する速度の改善を単独で報告するのではなく、報告する効率性の利益と並んで成果の指標(第5部)を確認する習慣を築いてください。

中小企業。 AIのコーディング支援は、小さなチームの容量を意味のある形で拡張できますが、品質のガードレールを確認せずに生のアウトプットの増加を明確な成功として報告する誘惑に抵抗してください。小さなチームは、より多くの冗長性を持つより大きな組織よりも、検出されない品質の問題を吸収する能力が少ないです。

企業。 このリスクの規模はここで著しく複合します。数十あるいは数百のチームにわたる同時のAIの採用は、単一のどのチームも局所的にそのパターンに気づく前に、組織全体で指標の妥当性を変える可能性があるからです。本トピックが推奨する指標セットの監査を、チームごとだけでなく組織レベルで実施し、ガバナンス(トピック1.4)を中央集権的かつ明示的に更新してください。

政府。 公共部門の組織はしばしばより慎重に新しい技術を採用しますが、政府の技術プログラムを評価するために使われる指標とベンチマークは、頻繁に、それ自体が同じプレッシャーの下で変化している民間部門の業界データから引き出されるか、それと比較されます。期待を設定したりパフォーマンスを評価したりするためにそれらを使う前に、あなたが比較する業界のベンチマークのどれがこの変化によって影響を受けたかを明示的に理解してください。

事例

企業。 あるフィンテック会社のエンジニアリングのリーダーシップは、広範なAIのコーディングアシスタントの採用後の2四半期でデプロイ頻度がほぼ40%上昇したことに気づき、当初はこれを取締役会のプレゼンテーションで単純な生産性の勝利として報告しました。品質が確認されたかどうかについての懐疑的な取締役会のメンバーの質問に促されたより注意深いフォローアップの分析は、変更失敗率がデプロイ頻度とほぼ歩調を合わせて上昇していたことを発見し、対になった安定性の指標が実際に調べられると、見かけ上の利益を完全に相殺していました。会社の改訂された報告は、今では、AI支援の生産性の主張がなされるときはいつでもデプロイ頻度と変更失敗率を明示的に一緒に提示し、以前のほぼ公になりかけた誤解を招く主張を避けています。

政府。 ある州政府のIT部門は、エンジニアリングチームの一部についてAIのコーディング支援を試験的に実施し、エンジニアあたりの生のコードのアウトプットが実質的に増加していたことを発見しました。この数字は当初、内部の試験的な見直しで好意的に引用されていました。本書の指針が部門の評価の枠組みに組み込まれたことに促されたより綿密な分析は、AI支援の仕事と非AI支援の仕事についてエスケープした欠陥率を特に調査し、AI支援のコホートにおいて、AIのツールが訓練中にさらされていなかった異常な市民の状況のエッジケース処理に集中した、わずかに高まった欠陥率を発見しました。この発見は試験的な実施を停止させませんでしたが、資格のエッジケースのロジックに触れるAI支援の変更についてレビューの厳密さの特定の的を絞った増加につながり、生のアウトプットの指標だけでは決して明らかにしなかったであろう実際のリスクに対処しました。

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

この監査を積極的に実施することからの見返りは、精査の下で、何も本物のものを測定していなかったことが判明する指標を報告することからの公あるいは取締役会レベルの恥辱を避けることです。これはまさに上記のフィンテックの例がほぼ生み出していたシナリオです。この変化の先を行く組織は、そのステークホルダーとの信頼性を維持します。空虚な指標を報告しているのを見つかった組織は、本物の、そしてほぼ避けられる評判上のコストを払います。

総所有コストは、既存の指標セットを監査し、ガードレールを引き締め、ガバナンスの文書を更新する分析の努力です。それは、主張する通りのものを測定しなくなった指標を報告し続ける継続的なリスクと比較して、一度限りの穏やかな投資です。このコストはまた、より低いレベルで繰り返されます。この変化は一度限りのイベントではなく進行中のものであり、ツールと採用のパターンが進化し続けるにつれて定期的な再監査は、指標ガバナンスのペースへの合理的で永続的な追加だからです。

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

AI以前の時代の活動指標を変更せずに無批判に報告し続ける。 静かに本物の価値と相関しなくなった指標を祝うリスクを冒します。
対になった安定性のガードレールなしにデプロイ頻度やアウトプットの量の増加を報告する。 トピック2.10の警告を、AI支援の開発の下でかなり高い賭け金で繰り返します。
確認せずにAI生成のコードが人間が書いたコードと同じ欠陥プロファイルを持つと仮定する。 積極的に間違っている可能性のある未検証の仮定です。
増加するAI生成のコードの量の下でレビューの深さが静かに侵食されるままにする。 トピック2.9のゴム印のリスクが強まったものです。
この変化を一度限りの調整として扱い、進行中の懸念として扱わない。 ツールとその採用のパターンは進化し続け、測定の実践は追いつく必要があります。
それらのベンチマーク自体が同じプレッシャーの下で変化したかどうかを理解せずに業界のベンチマークと比較する。 相対的なパフォーマンスについての誤った感覚のリスクを冒します。

成熟度モデル

レベル1、開始: AI以前の時代の指標が変更されずに報告されており、AIの採用がその妥当性に影響を与えたかもしれないという認識はありません。
レベル2、発展: この変化についていくらかの認識は存在しますが、既存の指標セットの体系的な監査は実施されていません。
レベル3、標準化: 完全な指標セットの監査が実施され、ガードレールが引き締められ、指標が組織全体で影響を受けたか回復力があるかとして文書化されています。
レベル4、管理: 欠陥と品質の成果は、組織の歴史的な品質の関係が依然として成り立っているかどうかを仮定するのではなくテストするために、AI支援のレベルによって積極的にタグ付けされ追跡されています。
レベル5、最適化: 組織は、AIのツールと採用のパターンが進化し続けるにつれてその指標を再検討する成熟した進行中の実践を持ち、問題が表面化した後に反応的にではなく、この変化に対応して積極的になされた特定のガバナンスの決定を指し示すことができます。

議論のためのアイデア

私たちの現在の指標のどれが、AI支援を大いに使っているが以前より多くの本物の価値を生み出していないチームを最も良く見せるでしょうか。
AIの採用以来私たちのデプロイ頻度は上昇したでしょうか、そして変更失敗率はそれとともに動いたでしょうか。
私たちはAI支援のレベルによって品質の成果にタグをつけているでしょうか、そしてそのデータは何を示すでしょうか。
私たちのレビューの容量は、AI生成のコードの量のどんな増加にも追いついているでしょうか。
私たちが現在自分自身を比較している業界のベンチマークは何で、それ自体がこのプレッシャーの下で変化したでしょうか。

主な要点

生成AIは、ツールの段階的な変化ではなくいくつかの既存の指標が測定するもののパラダイムシフトです。 いくつかの指標は静かに以前意味していたことを意味しなくなりました。
活動と生のアウトプットの指標が最も露出しています。 成果の指標(第5部)は比較的回復力があります。
AI支援の開発の採用に比例してガードレール、特に変更失敗率を引き締めてください。
AI生成のコードが人間が書いたコードとは異なる欠陥プロファイルを持つかどうかを、タグ付けされたエスケープした欠陥データを使って、仮定するのではなくテストしてください。
これを一度限りではなく進行中のガバナンスの懸念として扱ってください(トピック1.4)。ツールとその採用のパターンは進化し続けるからです。

参考文献とさらなる読書

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
AIのペアプログラミングと開発者の生産性についてのGitHubの研究。
Google CloudのDevOps Research and Assessmentプログラム、dora.dev。
The Tyranny of Metrics, Jerry Z. Muller 著。