サイクルタイムとは？リードタイムとの違いと、短縮の理屈（リトルの法則）

サイクルタイムとは、開発の作業に着手してから、その作業が完了するまでの経過時間です。 リードタイムと並んで開発フローの速さを測る代表的な指標ですが、この2つは測り始める「起点」が違います。 しかも呼び名の揺れが大きく、ツールや組織によって指す範囲が異なるため、定義を確認しないまま数字を比較すると誤った結論を導きます。 この記事では、リードタイムとの違い、測り方、そしてサイクルタイムが縮む理屈（リトルの法則）を整理します。

リードタイムとの違いは「起点」

一般的な使い分けでは、リードタイムは依頼が発生してから届くまで、サイクルタイムは作業に着手してから完了するまでを指します。

リードタイムには、着手される前の「順番待ち」の時間が含まれます。 チケットが起票されてから2週間バックログに眠り、着手から2日で完了した場合、リードタイムは16日、サイクルタイムは2日です。 顧客が体感するのは16日です。 サイクルタイムの2日は着手後の流れを、残りの14日は優先順位や投入能力を診断する材料になります。 改善する場所を切り分けるために、2つの指標を分けて持ちます。

ただし、この使い分けは慣習であって、業界で統一された定義はありません。 たとえばDORAの「変更のリードタイム」は、コミットから本番デプロイまでを測る指標です。 起点が作業開始の側にあるので、上の分類ではむしろサイクルタイムに近い測り方をしています。 ツールによっては、最初のコミットからマージまでをサイクルタイムと呼ぶものもあります。 したがって、社内で数字を扱うときは、名前ではなく起点と終点で会話してください。 「サイクルタイムが3日」ではなく「着手からマージまでが3日」と言えば、定義の行き違いは起きません。 （この呼び名の揺れについては変更のリードタイムの解説でも触れています）

測り方

• 起点：チケットを「進行中」に動かした時刻を使うのが最も簡単です。コミットベースで測るなら最初のコミット時刻を使います
• 終点：完了の定義を先に固定します。 マージなのか、本番反映なのか、検証完了なのかを決め、計測中に揺らさないようにします
• 代表値：日々の予測には中央値とパーセンタイルを使います。 サイクルタイムの分布は数時間から数週間まで長い裾を持ち、平均は少数の長期滞留に引っ張られるためです。 一方、リトルの法則を使うときは長期平均を使い、目的によって代表値を分けます

カンバンでは、過去の実績から「85%の作業は◯日以内に完了した」というサービスレベル期待値（Service Level Expectation、SLE）を置く例があります。 平均値だけでは完了確率を示せませんが、パーセンタイルなら期間と確率を組み合わせた予測として使えます。 ただし、85パーセンタイルは納期の保証ではなく、同じ条件が続いた場合にも約15%は超過し得るという見積もりです。 作業の種類や開発フローが変わったら、直近の実績で更新します。

なぜ縮むのか：リトルの法則

サイクルタイムには、待ち行列理論で使われるリトルの法則が成り立ちます。 長期平均を取り、対象とするシステムが安定していることが前提です。

平均サイクルタイム ＝ 平均仕掛かり数（WIP） ÷ 平均スループット

仕掛かり数（WIP：Work in Progress）は同時に進行中の作業の数、スループットは単位時間あたりの完了数です。 この式が示すのは同じ完了ペースで同時に抱える作業が増えるほど、1つの作業が終わるまでの時間は比例して延びるという関係です。 10件を並行で進めるチームと3件に絞るチームでは、完了能力が同じでも、1件あたりの滞留時間は3倍以上違います。

ただし、この式だけから「WIPを減らせば必ず速くなる」とは言えません。 WIPを減らしすぎて担当者や設備が仕事を待つ状態になれば、スループットも下がるからです。 需要が処理能力を上回り、同時並行が増えすぎているチームが対象です。 この場合はスループットを落とさない範囲でWIPを減らすことがサイクルタイム短縮の有力な打ち手になります。

• WIP制限を設ける：1人あたり同時2件まで、チームで同時5件まで、のような上限を決め、上限に達したら新しい作業に着手せず、進行中の作業を終わらせることを優先します
• 滞留を毎日見る：「進行中なのに数日動いていない作業」を朝会で確認します。レビュー待ちなのか、確認待ちなのか、詰まりの理由ごと解消します
• 作業を分割する：大きな作業はサイクルタイムのばらつきを生みます。 最終的に届ける成果は変えず、独立してレビューや検証ができる単位に分けてから着手します

「新しく始めるのをやめて、終わらせることを始める」というカンバンの標語は、この式の実務的な言い換えです。

注意点

サイクルタイムだけを縮めても、リードタイムが縮むとは限りません。 着手前の待ち行列が長いままなら、顧客の体感は変わらないからです。 待ち行列の側を短くするのは、優先順位づけと「そもそも着手しないものを決める」判断の仕事で、これはサイクルタイム改善とは別の投資です。

また、サイクルタイムを目標や評価にすると、作業を細かく割って数字を作る動機が生まれます。 分割そのものは良い実践ですが、指標のための分割は何も改善しません。 評価には使わず、診断の道具にとどめる原則は、開発生産性の指標全般と同じです。

関連して読める記事

サイクルタイムは、デリバリの速さを測る指標群の1つです。 隣接する指標との関係から押さえたい方は、リードタイムの解説からどうぞ。

変更のリードタイムとは？コミットから本番までを測るDORA指標と短縮の順序

変更のリードタイムとは、コミットから本番デプロイまでの時間を測るDORAのFour Keys指標です。なぜ起点が企画ではなくコミットなのか、レビュー待ちとデプロイ待ちに分解する見方、中央値で測る理由、短縮に取り組む順序までを実務目線で整理します。

2026年7月28日

開発生産性とは？測り方の全体像と、指標選びで失敗しない考え方

開発生産性とは、開発組織が投入した人と時間に対して、どれだけ速く確実に価値のあるソフトウェアを届けられているかを表す概念です。行数計測が失敗する理由、Four Keys、SPACE、DevExの使い分け、測り始める5つの手順、指標を個人評価に使ってはいけない理由までを総論として整理します。

2026年7月28日

デプロイ頻度とは？DORAが定義する測り方と、頻度が高いほど安全になる理由

デプロイ頻度とは、開発チームが本番環境へどれくらいの頻度でリリースしているかを測るDORAのFour Keys指標です。定義と測り方、頻度が高いほどデプロイが安全になる理由、ランク分け廃止後の正しい比較のしかた、目標化してはいけない理由までを整理します。

2026年7月28日

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日