サイクルタイム対リードタイム：定義と計算式

サイクルタイムとリードタイムの違いは、リーン、アジャイル、業務改善の現場で最もよく混同されるポイントの1つです。両者は関連していますが、測定している時計が異なります。この2つを混同すると、プロセスのどこを改善すべきかについて誤った判断につながります。

リードタイムとは何か

リードタイムとは、顧客のリクエストが届いてから、そのリクエストが提供されるまでの総時間です。時計は発注書、サポートチケット、ユーザーストーリーなど需要が発生した瞬間に始まり、顧客が完成したアウトプットを手にして初めて止まります。

リードタイムには、キューでの待機時間、承認待ちのブロック時間、実際の作業時間、輸送時間など、すべてが含まれます。チームがまったく手を付けていない時間帯が多くを占めていたとしても、これは顧客が実際に経験する数字です。

例。 ある顧客が月曜の朝にソフトウェア機能のリクエストを提出します。チームは水曜日にそれを取り上げ、木曜と金曜にコーディングし、翌週の月曜にテストし、火曜日にデプロイします。顧客の機能は、リクエストが届いてから9営業日後にリリースされます。リードタイム＝9日。

重要なポイント：サイクルタイムとリードタイム

• オペレーションズリサーチャーのJohn D. C. Littleが1961年に初めて証明したリトルの法則によれば、平均リードタイムは平均仕掛品（WIP）を平均スループットで割ったものに等しくなります。これは製造業、ソフトウェア、サポートなど、あらゆる安定したシステムに適用されます。
• Lean Enterprise Instituteによるバリューストリームマッピングの研究では、ほとんどのプロセスにおいてリードタイムの80%以上がキューと待機時間であり、実作業時間ではないことが一貫して示されています。リードタイムを削減することは、ほぼ常に「待機を削る」ことであり、「作業を速める」ことではありません。
• Accelerate（Forsgren、Humble、Kim著、2018年）によれば、卓越したソフトウェアデリバリーチームは、変更に対する中央値リードタイムを1時間未満に抑えています。ほとんどの組織は数日から数週間からスタートします。

サイクルタイムとは何か

サイクルタイムとは、チームが実際に着手してから1単位の作業を完了するまでにかかる時間です。時計は実作業が始まった瞬間に始まり、その単位が完了して次の工程（または納品）に進む準備が整った時点で止まります。サイクルタイムには、バックログに滞留している時間や、誰かが着手するのを待っている時間は含まれません。

製造業では、サイクルタイムは単位ごとに測定されることが多く、「1つの品目がワークステーションを通過するのにどれくらいかかるか」を測ります。ソフトウェアやカンバンでは、通常「進行中」から「完了」までの時間です。

例。 同じ機能リクエストを使うと、チームは水曜日に作業に着手し、金曜日までコーディングし、月曜日にテストし、火曜日にデプロイします。実作業時間＝5営業日。サイクルタイム＝5日。リードタイム＝9日。4日のギャップは、作業開始前のキュー時間でした。

サイクルタイムは社内指標です。チームがコントロールできます。リードタイムは、サイクルタイムと作業開始前の待機時間の両方に左右される、顧客に見える指標です。

サイクルタイム対リードタイム：主な違い

以下は両指標の並列比較です。

両者の数字の差は、キュー時間、つまりリクエストが誰にも触れられずに待機している時間です。大きなギャップは通常、スピードの問題ではなくバックログの問題を示しています。リードタイムが10日でサイクルタイムが2日であれば、プロセスは作業ではなく待機に8日を費やしていることになります。

サイクルタイムとリードタイムの計算方法

どちらの計算式もシンプルです。難しいのは、自分のプロセスにおいて各時計がいつ始まり、いつ止まるかを正確に合意することです。

リードタイムの計算式

リードタイム = 納品日時 − リクエスト日時

バッチや平均値の場合は、完了した項目群のリードタイムを合計し、項目数で割ります。

サイクルタイムの計算式

サイクルタイム = 完了日時 − 実作業開始日時

期間ごとのチーム平均であれば、総アウトプットを稼働期間数で割ります。

リトルの法則

リトルの法則は、両指標を結びつける最も有用な公式です。

リードタイム＝仕掛品（WIP）／スループット

ここで、

• **仕掛品（WIP）**とは、現在処理中の（開始されたがまだ完了していない）アイテム数です
• スループットとは、単位時間あたりに完了するアイテム数です

チームが週に5件のチケットを完了させ、常に20件の仕掛品を抱えているなら、リトルの法則は平均リードタイムを4週間と予測します。リードタイムを半分にするには、スループットを倍にする（難しい）か、WIPを半分にする（多くの場合より簡単で速い）かのいずれかです。これが、カンバンやリーンシステムにおいてWIP上限が中心的な実践となっている理由です。

リトルの法則は、コールセンター、ソフトウェアのスプリント、倉庫のピッキングステーションなど、フローレートがおおむね安定していれば、あらゆる安定したプロセスで成り立ちます。

サイクルタイムとリードタイムを短縮する方法

両指標を短縮するには、まずどちらが実際の問題なのかを見極めることから始まります。

ステップ1：両方を個別に測定する

すべての単位について、リクエストの到着時刻、作業開始時刻、完了時刻を記録する仕組みを整えます。ほとんどのプロジェクトツールやカンバンボードは、最小限の設定でこれを行えます。見えないものは改善できません。

ステップ2：実際に時間がどこに使われているかを特定する

プロセスのシンプルなバリューストリームマップを描きます。どの工程が実作業で、どの工程が純粋な待機なのかをマークします。リードタイムが10日でサイクルタイムが2日であれば、まず8日の待機に焦点を当てます。

ステップ3：仕掛品を制限する

リトルの法則に従い、WIPを削減すれば直接リードタイムが削減されます。各工程に明確なWIP上限を設定します。ある工程が上限に達したら、枠が空いたときにだけ作業を引き込みます。これは一見遅くなるように感じますが、キュー時間を生む詰まりを止めるため、ほぼ常に全体のフローが速くなります。

ステップ4：ブロッカーが再発する前に取り除く

承認漏れ、他チームへの依存、要件の不明確さ、環境アクセスの待ちなど、アイテムが滞留する理由を追跡します。根本原因分析やなぜなぜ分析セッションを使って繰り返されるパターンを突き止め、個々のブロッカーを追いかけるのではなく、システムそのものを修正してください。

ステップ5：ワークステーションやチームのキャパシティを均等化する

不均一なキャパシティは、サイクルタイムとリードタイムの両方を膨らませるボトルネックを生み出します。制約理論は、システム全体を制約している1つの制約を見つけるためのフレームワークを与えてくれます。まずそこを直せば、残りのフローも速くなります。また、ポカヨケの手法を適用して、手戻りを生みサイクルタイムを延ばす不良を防ぐこともできます。

ステップ6：バッチサイズを縮小する

大きなバッチの作業は、個々のサイクルタイムが短くても、システム全体を通過するのに時間がかかります。2週間分の機能を日次でデプロイ可能な単位に分割すると、フィードバックが早く得られキュー時間が減るため、リードタイムが大幅に短縮されます。

サイクルタイムとリードタイムの実例

サポートと調達の例は、ジャストインタイムの考え方が狙いを定めるパターンを示しています。実作業は総経過時間のごく一部にすぎません。リードタイムの大半は、引き継ぎ、キュー、承認のオーバーヘッドです。

タクトタイム、サイクルタイム、リードタイム

この3つの用語はしばしば一緒に登場し、リーン業務においてそれぞれ異なる役割を果たします。

タクトタイムは、顧客需要に合わせて1単位を生産すべき目標ペースです。これはチームではなく市場によって決まります。顧客が8時間シフトで100単位を求めているなら、タクトタイムは1単位あたり4.8分です。タクトタイムは計画のためのツールです。

サイクルタイムは、プロセスが実際に1単位あたりにかかっている時間です。サイクルタイムがタクトタイムを下回っていれば余力があります。サイクルタイムがタクトタイムを上回っていれば需要に応えられません。タクトタイムが基準を設定し、サイクルタイムがそれにどれだけ近いかを示します。

リードタイムは、サイクルタイムに加えて実作業前後のすべての待機を含む、エンドツーエンドの顧客体験です。

この3つは連動して機能します。タクトタイムが目標ペースを示し、サイクルタイムが単位あたりの実際のペースを示し、リードタイムがリクエストから受領までに顧客が経験する総待機時間を明らかにします。

よくある質問

サイクルタイムとリードタイムの違いは何ですか。

リードタイムは、すべての待機期間を含む、顧客のリクエストから納品までの総時間です。サイクルタイムは、タスクや単位が開始されてからの実作業時間のみです。リードタイムは常にサイクルタイム以上になります。両者の差がキュー時間です。

リードタイムは常にサイクルタイムより長いのですか。

実務上はそうです。サイクルタイムはリードタイムの構成要素の1つなので、リードタイムはサイクルタイムに実作業前後の待機時間を加えたものに等しくなります。両者が等しくなるのは、リクエストが届いた瞬間に作業が始まり、完了した瞬間に納品されるという、実際の業務ではほぼ起こり得ないケースだけです。

リトルの法則とは何で、なぜ重要なのですか。

リトルの法則は、平均リードタイムが平均WIPを平均スループット（単位時間あたりの完了アイテム数）で割ったものに等しいとするものです。これが重要なのは、レバーを与えてくれるからです。速く働く（スループットを上げる）代わりに、WIPを直接減らしてリードタイムを削減できます。WIPが低いほど、各アイテムはリソースの奪い合いが少なくなり、システムをより速く通過します。

サイクルタイムが低くてもリードタイムが高いということはあり得ますか。

はい、よくあることです。チームが着手してからは速い一方で、リクエストが何日もバックログに滞留してから拾われる場合、サイクルタイムは短いままリードタイムは高止まりします。これはまさに、WIP上限とプル型システムが対処するために設計されているシナリオです。

カンバンボードはこれらの指標をどう追跡していますか。

Jira、Linear、Trelloなどのほとんどのカンバンツールは、カードが「進行中」列に移動したタイムスタンプと「完了」列に移動したタイムスタンプを記録します。サイクルタイムは、この2つのイベント間のギャップです。リードタイムは、カード作成（あるいは顧客リクエストの時点）から完了までを追跡します。多くのツールは、WIP、スループット、予測リードタイムをすべて1つのチャートで示す累積フロー図を生成します。

---

サイクルタイムとリードタイムを短縮することは、人に速く動くよう求めることではありません。実作業の合間を埋める待機を取り除くことです。フローをマッピングし、WIPに上限を設け、ボトルネックを修正すれば、数字は自然についてきます。