2.6 サイクルタイムとその構成要素

概要と動機

サイクルタイムは、ある変更のフロータイム(トピック2.4)を、その構成するエンジニアリング段階へと内部的に分解したものです。コーディング時間、レビュー時間、テスト時間、デプロイ時間、時にはさらに、着手待ち時間(ある変更が誰かに取り組まれ始めるまでどれだけ待つか)とアクティブな時間(誰かが実際に取り組んでからどれだけかかるか)に分けられます。フロータイムが、バリューストリーム全体を通じてある変更がエンドツーエンドでどれだけかかるかについての単一の数字を与えるのに対し、サイクルタイムは、それがエンジニアリングに届いた後、その時間が実際どこへ行くのかを教えてくれます。これは、トピック2.4が自らの要約の数字の下に存在すると約束した診断の層です。

この区別が重要なのは、「リードタイムが長すぎる」だけでは行動につながらないからです。コーディング時間に支配されているリードタイムを持つチームは、3日間のレビューキューに支配されているリードタイムを持つチームとは異なる介入を必要とし、それはまた、不安定で遅いテストスイートにほとんどの時間を失っているチームとは異なる介入を必要とします。サイクルタイムの分解なしでは、チームはボトルネックを推測しがちであり、その推測は、間違った段階を修正することが本物の努力を無駄にし、実際の制約が手つかずのままになるほど頻繁に外れます。

大規模なチームにとって、サイクルタイムの分解は、組織全体のリードタイムの悪化を、謎から具体的で対処可能な問題へと変えるものです。数十のチームが共通のインフラストラクチャを共有しているとき、共有されたレビューのボトルネックや共有された遅いCIパイプラインは、すべてのチームのリードタイムを同じように引きずり下げている可能性があり、それぞれのチームが独立して自分自身の局所的な説明を推測するのではなく、チームを横断したサイクルタイムの比較だけが、その共有された根本原因を明らかにします。

重要な原則

サイクルタイムはリードタイムを説明するものであり、それを置き換えるものではない。 サイクルタイムを診断として、リードタイムを要約として、両方を一緒に報告してください。
待ち時間は通常アクティブな時間を支配する。 ソフトウェア提供におけるほとんどの遅延は、アクティブな努力からではなく、キューの中で手つかずのまま座っている仕事から来ます(トピック2.5がフロー効率を通じてこれを直接扱います)。
修正を提案する前に段階ごとに分解する。 間違った段階に狙いを定めた修正は努力を無駄にし、本当のボトルネックが他の場所にあったときに「もっと速く働け」と言われたチームの士気をくじくことがあります。
多くのチームにわたる共有されたボトルネックは、プラットフォーム投資の機会である。 個々のチームの問題の連続ではありません。
サイクルタイムのデータは、フロータイムと同じ操作のリスクにさらされている(トピック2.4)。数字をより良く見せるために静かにずれる段階の境界に注意してください。

推奨事項

すべての段階の境界を明示的に計装する

ある変更の旅を、明確で計装可能な境界を持つ名前のついた段階に分解してください。コーディング(最初のコミットからプルリクエストが開かれるまで)、着手待ち(プルリクエストが開かれてから最初のレビューまで)、レビュー(最初のレビューから承認まで)、そしてデプロイ(承認から本番まで)です。自己申告の段階追跡からではなく、バージョン管理とCI/CDのイベントから自動的にすべての遷移のタイムスタンプを捉えてください。これはトピック1.5の自己申告より計測基盤を優先する原則を適用したものです。

各段階の内側で待ち時間をアクティブな時間から切り分ける

たとえばレビューの中で、レビュー担当者が始めるのを待って手つかずのままプルリクエストが座っている時間(待ち時間)と、アクティブなレビューの会話が始まってからかかる時間(アクティブな時間)を区別してください。この区別は、通常、支配的なコストが努力ではなくキューイングであることを明らかにし、これはレビューの会話そのものを速くすることを目指した修正とはまったく異なる修正(より多くのレビュー担当者の容量、より良い通知、レビューするプルリクエストを小さくすること)を示唆します。

チームごとに診断する前に共有されたボトルネックを探す

複数のチームが同じ段階を支配的な遅延として示しているとき、遅い共有CIパイプライン、過負荷の共有レビュープール、頻度の低い共有リリーストレインなど、その共有された原因はプラットフォームレベルの投資の機会であり、無関係な局所的問題の連続ではありません。それぞれのチームのボトルネックがそのチームに固有だと仮定する前に、このパターンを特に探すために、チームを横断してサイクルタイムのデータを集計してください。

サイクルタイムを使って現実的で段階固有の改善目標を設定する

チームにどこに焦点を当てるべきかの指針を何も与えない単一の「リードタイムを20%削減する」という目標の代わりに、サイクルタイムの分解を使って段階固有の目標を設定してください。「レビューの待ち時間の中央値を2日から4時間に減らす」のようにです。具体的で段階を狙った目標は、チームが行動を起こしやすいだけでなく、それが実際に無関係な他の場所でのシフトではなく本物のプロセス変更を通じて達成されたことを検証しやすくなります。

段階の境界の操作に注意する

フロータイムの開始点と終了点がずれうる(トピック2.4)のと同じように、個々のサイクルタイムの段階の境界は、本物の改善なしに特定の段階の数字をより良く見せる方向にずれることがあります。たとえば、レビュー担当者が実際に変更を読み始めたときではなく割り当てられた瞬間に、レビューが「開始された」とマークすることです。段階の境界の計測基盤を、文書化された定義と照らし合わせて定期的に監査してください。

トレードオフ:長所と短所

アプローチ	長所	短所
粗い粒度のサイクルタイム(二つか三つの段階)	計装と説明が簡単	実際のボトルネックを行動できるほど正確には特定できないことがある
細かい粒度のサイクルタイム(多くの段階、待ちとアクティブの分割)	正確な診断、行動可能な段階固有の目標	より多くの計装の労力。維持し説明すべきより多くの数字
チームごとのサイクルタイムのレビュー	各チームの実際のワークフローに合わせられる	似たような局所的な数字の背後に隠れた共有のチーム横断的ボトルネックを見逃すことがある
チームを横断した集計サイクルタイムのレビュー	共有されたプラットフォームレベルのボトルネックを明らかにする	意味のあるものにするにはチームを横断した標準化された段階の定義が必要

中心にある緊張関係は診断の精度と計装のコストです。より細かい粒度のサイクルタイムの追跡は、より行動可能な診断を与えますが、構築と維持により多くの費用がかかり、チームが理解し信頼しなければならない数字がさらに増えます。この緊張を解消するには、粗く始め(コーディング、レビュー、デプロイ)、ある段階が本物の繰り返されるボトルネックであり、追加の計装投資に値すると確認された後にのみ、より細かい分割(特定の段階内での待ちとアクティブの対比)を追加してください。

チームで話し合うべき問い

もし今日リードタイムが悪化したら、私たちは推測ではなくデータを使って、1時間以内にどの具体的な段階が原因だったかを言えるでしょうか。 これは、私たちのサイクルタイムの計測基盤が実際にその診断の目的を果たしているかどうかの核心的なテストです。正直な答えがノーなら、次の悪化が起きる前にその隙間を埋める価値があります。
私たちの支配的なボトルネックの段階の中で、遅延のうちどれだけが待ち時間で、どれだけがアクティブな時間でしょうか。 ほとんどのチームは、確認する前にアクティブな努力が制約であると想定しますが、キューイングの方がたいてい大きなコストです。最も遅い段階について実際の内訳を持ち出し、その想定が成り立つかを確認してください。
複数のチームが同じ支配的なボトルネックの段階を共有しており、チームレベルではなくプラットフォームレベルの修正を示唆しているでしょうか。チームを横断してサイクルタイムのデータを集計し、すべてのチームの遅さが局所的に引き起こされていると仮定する前に、明示的にこのパターンを探してください。
私たちは段階固有の改善目標を設定したでしょうか。それとも、どこに焦点を当てるべきかの指針が何もない単一の全体的なリードタイムの目標だけでしょうか。曖昧な目標は、チームにどこに努力を投資すべきか推測させたままにします。段階固有の目標はそうしません。あなたの現在の目標をこの区別と照らし合わせて確認してください。
私たちの計測基盤における段階の境界が、時間とともにその文書化された定義からずれたことがあるでしょうか。 段階の境界は、フロータイムそのもの(トピック2.4)と同じ定義のずれのリスクにさらされています。最近の段階遷移イベントのサンプルを、書かれた定義と照らし合わせて監査してください。
レビューに重きを置く文化と信頼に重きを置く文化は、私たちのサイクルタイムのデータにどう違って現れるでしょうか。 非常に徹底した複数ラウンドのレビューを行うチームは、単一承認のマージを信頼するチームよりも長いレビュー段階の時間を示します。あなたの現在のバランスが意図的な選択を反映しているのか、検証されていない既定なのかを話し合ってください。

業種別の視点

スタートアップ。 サイクルタイムは、単純にプロセスが最小限であるため、通常レビューやデプロイの段階ではなくコーディング時間に支配されています。チームが一握りのエンジニアを超えて成長するにつれて、特にレビューの待ち時間に注意を払い始めてください。なぜなら、より多くの人々の仕事がより少ない利用可能なレビュー担当者を通過する必要があるにつれて、それが通常最初に遅くなる段階だからです。

中小企業。 基本的なバージョン管理プラットフォームの分析は、通常、カスタムの計装なしに十分な段階レベルのタイミング(最初のレビューまでの時間、マージまでの時間)を明らかにします。まずレビューの段階に焦点を当ててください。それが最もよくある早期のボトルネックであり、レビュー担当者のローテーションのような小さなプロセス変更で最も簡単に修正できるからです。

企業。 数十のチームにわたる共有されたボトルネックはよくあることで、見つけるのに高いレバレッジがあります。単一の過負荷の共有CIキューや必須の中央集権的なレビューの段階は、組織全体にわたって静かにリードタイムに課税していることがあります。それぞれのチームに独立して診断させるのではなく、これらの共有された制約を表面化させるために、チームを横断したサイクルタイムの集計に特に投資してください。

政府。 サイクルタイムのデータは、懐疑的な利害関係者に対してプロセスの近代化を正当化するための強力で具体的な道具です。なぜなら、「レビューの待ち時間は、単一のボトルネックとなった承認の役割のために平均で4日かかる」は、抽象的な「私たちのプロセスは遅い」という主張よりも、はるかに説得力のある具体的な投資の事例だからです。

事例

企業。 あるクラウドインフラストラクチャ企業のエンジニアリング指導層は、ほぼすべてのチームにわたって同時にリードタイムが忍び寄るように増えていることに気づきました。チームを横断したサイクルタイムの集計は、アクティブなレビュー時間ではなくレビューの待ち時間が、支配的で共有された原因であることを明らかにしました。小さな中央集権化されたセキュリティレビューチームが、彼らの承認を必要とするチームの数がチーム自身の成長よりも速く増えたために、ボトルネックになっていたのです。個々のチームにどうにかしてもっと速くコーディングやテストをするよう求めるのではなく、より広いセキュリティ認定を受けたレビュー担当者のプールを拡大し訓練することで、共有されたボトルネックは解消され、1四半期以内に全体にわたってリードタイムが元に戻りました。

政府。 ある州政府のデジタルサービスチームはリードタイムを削減するプレッシャーのもとにあり、最初はエンジニアにもっと速く働くよう求めることで対応しました。これは自然な、しかし最終的には役に立たない本能でした。サイクルタイムの分解は、アクティブなコーディング時間が前年比でほとんど変わっていないことを示しました。悪化のほぼすべては、18か月前にコンプライアンス対策として導入された必須のアーキテクチャレビューの段階での増え続けるキューから来ていました。このチームは、そのレビューを低リスクの変更のためのより軽い、リスク段階別のプロセスに再設計し、本当に高リスクの変更に対する完全なレビューの厳格さを保ちながら、レビューの待ち時間を大幅に削減しました。

ビジネスケース:動機、ROI、総所有コスト

サイクルタイムの分解からの見返りは、的を絞った効果的な投資です。どの段階がボトルネックかを正確に知っている組織は、何かが役立つことを期待してプロセス全体に薄く努力を広げるのではなく、その特定の段階を修正できます。上記のセキュリティレビューの例は典型的です。精密に的を絞った修正、つまり一つの特定のボトルネックとなった資源を拡大することが、広範で焦点の定まらない「提供を速くする」という取り組みよりもはるかに安く、組織全体の問題を解決したのです。

総所有コストは、段階レベルのタイムスタンプを確実に捉える計装の労力と、ずれについて段階の境界を定期的に監査する継続的な規律です。そのコストは価値があります。なぜなら、代替案、つまりボトルネックを推測し間違った段階を修正することは、計装そのものよりも時間とともにはるかに多くのエンジニアリングの努力を無駄にするからです。

アンチパターンと落とし穴

サイクルタイムの診断なしにリードタイムの悪化に反応する。 しばしば間違った段階を修正することにつながります。
待ち時間ではなくアクティブな努力が支配的なコストだと想定する。 たいてい間違っています。ほとんどの実際の提供パイプラインではキューイングが支配的です(トピック2.5)。
チームごとにのみサイクルタイムをレビューして、共有されたチーム横断的なボトルネックを見逃す。 高いレバレッジを持つプラットフォームの修正を未発見のままにします。
段階固有の指針のない曖昧な全体的なリードタイムの目標を設定する。 チームにどこに焦点を当てるべきか推測させたままにします。
段階境界の定義のずれ。 本物の改善なしに特定の段階の数字をより良く見せます。
どれかが本物のボトルネックであると確認する前に、考えられるすべての細かい段階を計装する。 まだ決定に情報を与えない詳細に計装の労力を無駄にします。

成熟度モデル

レベル1、開始: サイクルタイムはまったく分解されておらず、リードタイムが悪化するとチームはボトルネックを推測します。
レベル2、発展: 一部のチームは非公式に粗い粒度の段階のタイミングを追跡していますが、一貫した計測基盤やチームを横断した比較はありません。
レベル3、標準化: 段階の境界は組織全体で一貫して計装されており、支配的なボトルネックの段階では待ち時間がアクティブな時間から分離されています。
レベル4、管理: チームを横断したサイクルタイムの集計が共有されたボトルネックを能動的に表面化させ、段階固有の改善目標が曖昧な全体的なリードタイムの目標に置き換わります。
レベル5、最適化: サイクルタイムのデータがプラットフォーム投資の優先順位づけを直接駆動し、組織は、拡大されたレビュープールやより速い共有パイプラインのような、多くのチームにわたって一度に測定可能にリードタイムを改善した具体的で的を絞った修正を指し示すことができます。

議論のためのアイデア

私たちの現在の支配的なボトルネックの段階は何で、その答えにどれだけ自信があるでしょうか。
そのボトルネックの段階の時間のうち、どれだけが待ち時間で、どれだけがアクティブな時間でしょうか。
私たちのチームのどれかが同じボトルネックを共有しており、プラットフォームレベルの修正を示唆しているでしょうか。
私たちが最後に、全体的ではなく段階固有の提供改善目標を設定したのはいつでしょうか。
私たちのツールにおける段階境界の定義が、文書化なしに変わったことがあるでしょうか。

主な要点

サイクルタイムはフロータイムをエンジニアリングの段階に分解します。 コーディング、レビュー、テスト、デプロイであり、その要約の数字の下にある診断の層です。
各段階の内側で待ち時間をアクティブな時間から切り分けてください。 キューイングは通常アクティブな努力を支配します(トピック2.5)。
遅れがチーム固有だと仮定する前にチームを横断した共有されたボトルネックを探してください。共有された原因はしばしばプラットフォーム投資の機会です。
曖昧な全体的な目標ではなく段階固有の改善目標を設定し、チームが正確にどこに焦点を当てるべきかを知るようにしてください。
段階の境界は、フロータイムそのものと同じ定義のずれのリスクにさらされています。定期的に監査してください。
トピック2.7は、仕掛かり作業とサイクルタイムがなぜ一緒に動くのかについての根底にある数学、リトルの法則を与えます。

参考文献とさらなる読書

The Principles of Product Development Flow, Donald G. Reinertsen 著。
Actionable Agile Metrics for Predictability, Daniel S. Vacanti 著。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
The Goal, Eliyahu M. Goldratt 著。