提供システム全体を測る

必要な判断から始める

チームは、AIがソフトウェアの提供を改善するか知りたいと考えています。生成行数を数えても、別の問いに答えることになります。指標を選ぶ前に、有用な成果と品質条件を定めます。

架空のエクスポートサービスでは、受け入れた変更を、少ない総工数で確実に提供することが目標です。準備、実装、レビュー、修正、待機を記録します。失敗した変更や、中止した変更も含めます。

境界が明確な一つのサービスを使います。実験用サイトと重要な決済サービスをまとめると、どちらも説明しない数値になることがあります。期間やチームを比較する前に、背景を記述してください。

現在の定義を使う

DORAの現在の提供モデルには、五つの指標があります。対象はソフトウェアの提供実績であり、各機能の価値や個人の貢献ではありません。DORAの指標定義を参照してください。

ダッシュボードが別の定義を使う場合もあります。結果を解釈する前に読んでください。Taigaの現在のデプロイドキュメントは、提供者のデプロイ記録から算出する四つの報告指標を説明しています。復旧の指標には、その後の成功したデプロイを使います。本番インシデント全件の完全な記録ではありません。Taigaの定義を参照してください。

架空の変更の流れを調べる

あるサービスが一か月に十二回デプロイしたとします。八回は計画した変更、四回は以前のリリースの問題の修正です。合計は十二回ですが、内訳が重要です。

翌月は十回で、計画した変更が九回、修正が一回です。デプロイ数が減っても、有用な作業は増える場合があります。これらは解釈の例であり、実績のベンチマークではありません。

分布も調べます。平均の中では、一件の長いレビュー待ちが見えなくなることがあります。一回の失敗から得た復旧指標は、将来の信頼性を示す証拠としては弱いものです。観察数と重要な例外を報告してください。

流れと影響を一緒に見る

提供プロセスの変更が利用者に影響するかを、サービスのシグナルで確認します。パイプラインが速くなっても、エクスポートの失敗が増えるなら不十分です。適切なSLOや、明確に定義した別の成果指標を使います。SLOのガイドを参照してください。

レビュー工数と手戻りは、結果を説明する助けになります。AIで実装時間が短くなっても、大きな差分を生成すればレビューが制約になり得ます。環境を用意するのに数日かかるなら、コーディングが速くなっても、提供までの経過時間にはほとんど影響しないかもしれません。

観察した制約に対応する改善を一つ選びます。例えば、サポートされたテスト環境を用意する、変更を小さくする、といった方法です。品質を併せて監視する指標を定め、確認を弱めたために見かけ上速くなった場合を検出できるようにします。

役立つ測定を保つ

PR数や生成コード量で個人を順位付けしないでください。これらの指標は、作業を不自然に細分化する、難しい保守を避ける、レビュー工数を同僚に押し付ける行動を有利にする可能性があります。

サービス全体の責任を持つ人たちと、結果をレビューします。ツール、作業の内訳、チーム、環境で何が変わったかを記録します。前後の比較は、限界のある証拠として扱います。自動的に因果関係を証明するものではありません。

目的は、次の判断をよくすることです。検証された改善につながる、小さく信頼できる測定のほうが、意味について合意のない大きなダッシュボードより役立ちます。

十件の変更で練習する

この別の架空データセットは、計画した十件の変更を記録しています。すべての時刻は、表示された日付のUTCです。修正欄が空の場合、このデータセットには修正が記録されていないことを意味します。

コード完成からレビュー開始までと、受け入れからリリースまでの時間を比較します。確認できる最長の待ち時間を特定します。避けられた待ち時間だと判断する前に、原因を調べてください。これらの時刻からは、実作業の工数やインシデント開始時刻は分かりません。修正リリースだけでは、デプロイ失敗からの復旧時間は確認できません。

架空のデータセットをダウンロード（CSV）