変更のリードタイム（Change lead time）とは、コードの変更がバージョン管理にコミットされてから、本番環境にデプロイされるまでの時間です。 DORA（Google Cloud の研究チーム）が提唱する開発生産性指標「Four Keys」の一つで、作ったものをどれだけ速く届けられるかを測ります。 「リードタイム」という語は文脈によって指す範囲が変わるため、どこからどこまでを測るのかの理解が最初の関門になります。 この記事では、定義の範囲、内訳の分解のしかた、短縮に取り組む順序を整理します。
どこからどこまでを測るのか
DORA の定義では、起点はコミット、終点は本番デプロイの完了です。 「企画を思いついてから」でも「チケットを起票してから」でもありません。
この線引きには理由があります。 DORA の研究の土台になった書籍 Accelerate は、リードタイムを「設計と検討」の区間と「デリバリ」の区間に分け、Four Keys の対象を後者に限定しました。 設計の区間は、いつ始まったのかの判定が難しく、案件ごとのばらつきも大きいため、継続的な測定に向きません。 一方、コミットとデプロイはどちらも機械的に時刻が記録されるため、安定して比較できます。 この指標が測るのは「思いついてから届くまで」ではなく「書き上がってから届くまで」です。
なお、ツールや組織によっては、最初のコミットからマージまでといった区間をサイクルタイムと呼び、リードタイムと使い分けます。 呼び名の揺れが大きい領域なので、社内で数字を扱うときは、名前ではなく起点と終点を明記して運用するのが安全です。
内訳を分解する
変更のリードタイムは単一の区間ではなく、複数の作業と待ち時間の合計です。 典型的な内訳は次のようになります。
コミット → プルリクエスト作成 → レビュー待ち → レビューと修正 → 承認 → マージ → デプロイ待ち → 本番反映
多くのチームで最も長いのは、コードを書いている時間ではなく、レビュー待ちとデプロイ待ちです。 実装が数時間で終わった変更がレビューを2日待ち、週1回のリリース日をさらに3日待つ、という構造は珍しくないはずです。 この構造のまま実装だけを速くしても、全体のリードタイムはほとんど動きません。 AIコーディング支援を導入したのに速くならない、という悩みの原因もたいていここにあります。 AIが縮めるのは最初の実装区間だけで、その下流の待ち時間には影響しないからです（この論点はFour Keys の2026年版の解説記事で詳しく扱っています）。
測り方
- 起点：コミット時刻。実務では最初のコミットを使うか最後のコミットを使うかで流儀が分かれる。プルリクエストの履歴から近似するツールが多い
- 終点：本番デプロイの完了時刻。デプロイイベントとコミットの紐づけが必要になる
- 代表値：平均ではなく中央値で見る。リードタイムの分布は数分から数週間まで長い裾を持ち、平均は少数の長期滞留に引っ張られるため
自動集計には、GitHub のプルリクエスト履歴とデプロイイベントを突合するタイプの計測ツール（Findy Team+ など）を使うのが定石です。 ただし、全体の数字を出すだけでは次の打ち手につながりません。 価値があるのは、前述の内訳を区間別に見られる状態にすることです。
短縮の順序
短縮は、区間を測ってから最長の区間だけに手を入れる、という順序で進めます。 どこがボトルネックかを知らずに施策を打つと、もともと短い区間をさらに速くすることに投資してしまうからです。
- レビュー待ちが長い場合：プルリクエストを小さくする。差分が小さいほどレビューの心理的な負荷が下がり、着手が速くなる。あわせて「レビュー依頼から1営業日以内に反応する」のような目安をチームで決める
- 承認が長い場合：承認者を増やすか、権限を委譲する。誰も中身を見ずに押しているだけの承認なら、その工程自体を疑う
- デプロイ待ちが長い場合：決まったリリース日にまとめて出す方式をやめ、マージのたびにデプロイする方式へ寄せる。リリース作業の自動化が前提になる
デプロイ待ちの解消はデプロイ頻度の改善と表裏一体です。 リードタイムとデプロイ頻度は同じスループット能力の2つの断面であり、片方だけが劇的に良くなることは通常ありません。
注意点
リードタイムを目標や評価指標にすると、レビューを素通しにして数字を作る動機が生まれます。 品質側の指標（変更障害率）と対で見て、速くなったぶん壊れやすくなっていないかを確認してください。
もう一つ、リードタイムが短いことは、正しいものを作っていることを保証しません。 測っているのはデリバリの速さだけで、その機能が使われたか、事業成果につながったかは別の指標の仕事です。
関連して読める記事
変更のリードタイムは、Four Keys の他の指標と組み合わせて初めて全体像になります。枠組みの現行定義から押さえたい方は、2026年版の解説からどうぞ。
Four Keys はもう「4つ」ではない — 2026年版 DORA メトリクスの現在地と、AI導入の効果を証明する唯一の方法
「Four Keys は4つ」という理解は2026年時点では古く、DORA公式の指標は5つに増え、Elite/High/Medium/Lowのランク分けも廃止されています。5つ目は広く誤解されている「信頼性」ではなくデプロイ手戻り率であること、Googleのfourkeys OSSがアーカイブ済みで主要ツールもいまだ4指標止まりであること、そして手戻り率だけはツールなしで今日から測れることを、DORA公式ドキュメントで裏を取りながら整理します。AI導入の効果を数字で証明するための使い方までまとめました。
2026年7月27日
開発生産性とは？測り方の全体像と、指標選びで失敗しない考え方
開発生産性とは、開発組織が投入した人と時間に対して、どれだけ速く確実に価値のあるソフトウェアを届けられているかを表す概念です。行数計測が失敗する理由、Four Keys、SPACE、DevExの使い分け、測り始める5つの手順、指標を個人評価に使ってはいけない理由までを総論として整理します。
2026年7月28日
デプロイ頻度とは？DORAが定義する測り方と、頻度が高いほど安全になる理由
デプロイ頻度とは、開発チームが本番環境へどれくらいの頻度でリリースしているかを測るDORAのFour Keys指標です。定義と測り方、頻度が高いほどデプロイが安全になる理由、ランク分け廃止後の正しい比較のしかた、目標化してはいけない理由までを整理します。
2026年7月28日
変更障害率とは？デプロイの失敗割合を測るDORA指標の定義と下げ方
変更障害率（変更失敗率）とは、本番デプロイのうち直後に障害や緊急対応を引き起こした割合を測るDORAのFour Keys指標です。定義と測り方、速さと品質がトレードオフにならない理由、デプロイ手戻り率との違い、ゼロを目指してはいけない理由までを整理します。
2026年7月28日
MTTRとは？定義の揺れ、DORA指標としての現在地、平均の罠
MTTRとは、障害発生から復旧までの平均時間を指す指標ですが、Rの解釈が複数あり、DORAは現在この名前を使っていません。定義の揺れ、失敗デプロイの復旧時間への置き換え、平均値が実態を表さない統計上の罠、復旧を速くする打ち手までを整理します。
2026年7月28日