変更のリードタイムとは？

変更のリードタイムは DORA メトリクスの 1 つで、コードの変更がコミットされてからその変更が本番で動作するまでの経過時間を測ります。

変更のリードタイムは、デリバリシステムがどれだけ速く作業をユーザーへの価値に変えるかを捉えます。短いリードタイムはフィードバックループが緊密で本番への経路がよく整備されていることを意味し、長いものは通常、待ち時間、手動ステップ、または脆いプロセスを隠しています。

時計を定義する

変更のリードタイムはコードがコミットされたときに始まり、本番で正常に動作したときに止まります。何を作るかを設計・決定するのに費やした時間を意図的に除外し、代わりにデリバリパイプライン、つまりチームが最も直接的に設計できる部分に焦点を当てます。

時間がどこへ行くのか

リードタイムは多くの小さな待ち時間の合計です。コードレビュー、CI のビルドとテストの実行、runner のためのキュー待ち、承認、そしてデプロイそのものです。時間が実際にどこへ行くのかをマッピングすると、通常、経過時間の大半は作業ではなく待ち時間であることが明らかになります。

CI の速度が主要な要因

多くのチームにとって、パイプラインはリードタイムの中で最も制御可能な大きな部分です。遅いビルド、長いテストスイート、runner を待ってキューに並ぶ job がすべて積み重なります。より速く並列な CI とフレーキーな再実行の回避は、リードタイムを大幅に圧縮できます。キュー時間を削減し一時的な失敗から回復するマネージド runner プラットフォームは、このメトリクスを直接改善できます。

安全に短縮する

リードタイムを削る正しい方法は、安全ではなく無駄を取り除くことです。より小さな変更、自動化されたテスト、トランクベース開発、並列化されたパイプラインはすべて、品質を保つか向上させながら時計を短縮します。レビューやテストを省けばそれも短縮しますが、安定性のメトリクスを犠牲にします。

良い状態とはどのようなものか

エリートチームはリードタイムを数時間以下で測り、低パフォーマーは数週間または数か月で測ります。正確な目標値よりトレンドが重要です。着実に縮んでいくリードタイムは、より健全で反応の良いデリバリシステムを示します。

重要なポイント

変更のリードタイムはコミットから本番で動作するまでの経過時間です。
その大半は通常、レビュー、キュー、遅い CI での待ち時間です。
安全を省くのではなく、無駄を取り除きパイプラインを速めることで短縮しましょう。