2.4 フロータイムとフロー負荷

概要と動機

フロータイムは、あるフローアイテム(トピック2.2)がバリューストリームに入ってから届けられるまでの総経過時間であり、ビジネスのニーズが特定されてから顧客が価値を受け取るまでの全経路にわたる応答性を測定します。フロー負荷は、ある瞬間にバリューストリーム内で現在アクティブあるいは待機中のフローアイテムの総数であり、Flow Frameworkにおける、トピック2.5が仕掛かり作業と呼ぶものの呼び名です。この二つは一緒になって、待ち行列の数学に最も直接つながるFlow Frameworkの指標です。なぜなら、フロー負荷はフロータイムと単に相関するだけでなく、数学的にそれを決定するからです。

その関係はリトルの法則であり、待ち行列理論からの証明(トピック2.7が完全に扱います)であり、安定したシステムにおけるアイテムの平均数は、平均到着率に各アイテムがシステムに留まる平均時間を掛けたものに等しいと述べます。ここに適用すると、フロー負荷は到着率にフロータイムを掛けたものに等しくなります。これが本トピックにおける唯一最も有用な事実です。なぜなら、かつて定性的だった議論、「私たちは過負荷すぎて、物事に時間がかかりすぎている」を、ビジネスリーダーが簡単には退けられない、証明可能で定量的な議論に変えるからです。もし到着率が横ばいのままフロー負荷が上昇し続けるなら、フロータイムはおそらくではなく数学的に保証されて上昇します。

大規模なチームにとって、これはしばしばフレームワーク全体の中で唯一最も説得力のある数字です。あらゆる依頼が個々には正当に感じられるために新しい仕事に対してノーと言うという考えに抵抗するビジネスリーダーも、フロー負荷が追跡され、フロータイムとの関係が抽象的に論じられるのではなく直接示されたとき、バリューストリームを過負荷にすることがすでにその中にあるすべてのアイテムを証明可能に遅くするということを受け入れることがよくあります。多くの同時並行の戦略的取り組みをやりくりする企業組織と、数十の並行するワークストリームを運営する政府プログラムは、どちらも、一度に複数の仕事を始めることにノーと言うことを正当化するために、その背後にある直感だけでなくこの証明に依存しています。

重要な原則

フロー負荷はリトルの法則を通じて数学的にフロータイムを決定する。 これは相関ではなく、どんな安定したバリューストリームにも成り立つ証明です。
フロータイムはエンジニアリングだけでなくバリューストリーム全体にわたる。 それは、エンジニアリングが仕事を拾い上げたときではなく、ビジネスのニーズが特定されたときに始まり、トピック2.6のサイクルタイムがそれをさらに分解します。
上昇するフロー負荷は、上昇するフロータイムの最も早い警告の兆候である。 その関係は証明可能であるため、フロー負荷は、フロータイムがすでに悪化した後に発見されるだけでなく、先行指標として監視できます。
バリューストリームの入り口は固定され文書化されていなければならない。 フロータイムの時計がどこで始まるかは、本書の他のどんな指標の境界とも同じ操作のリスクにさらされた、定義上の選択です。
ビジネスリーダーはフロー負荷に直接働きかけることができる。 遅行測定であるフロータイムとは異なり、フロー負荷はレバーです。新しい仕事を始めることにノーと言うことは、今日利用できる行動です。

推奨事項

フロータイムを測定する前にバリューストリームの入り口を固定し文書化する

フロータイムが、ビジネスのニーズが最初に特定されたときに始まるのか、正式に承認されたときなのか、あるいはエンジニアリングが仕事を始めたときなのかを明示的に決め、トピック1.4がどんな指標チャーターについても推奨するのと同じように、その選択を文書化してください。この一つの決定が、フロータイムが本物のエンドツーエンドの応答性を測定するのか、それともエンジニアリングが統制するより狭い部分だけを測定するのかを決定し、後になって開示なしに定義を変えることが、本トピックの中心的な操作のリスクです。

フロー負荷を定期的にではなく継続的に追跡する

フロー負荷は、リトルの法則を通じて、まだ来ていないフロータイムの先行指標であるため、定期的な一時点ではなく、生きた、継続的に更新される数字として追跡してください。誰かがそれを確認する頃にはすでに何週間も上昇し続けてきたフロー負荷は、その指標が追いつく前に、見えないまま同じだけの期間、静かにフロータイムを引き延ばし続けてきたのです。

WIP制限や容量増加を主張するときにリトルの法則を明示的に使う

同時並行の仕事を減らす、あるいは容量を追加する主張をするとき、推奨事項だけでなく実際の式を提示してください。フロー負荷は到着率にフロータイムを掛けたものに等しく、したがって到着率がおおよそ固定されているなら、フロー負荷を減らすことは数学的にフロータイムを減らすことを保証します。これは、懐疑的な利害関係者に対して、「私たちは忙しすぎる」という定量化されていない主張よりも、はるかに強い議論です。なぜなら、それは主張されたものではなく証明可能だからです。

修正を提案する前に、フロータイムをフロー負荷の根底にある原因から切り分ける

フロー負荷が高いとき、どのフローアイテムの種類(トピック2.2)が実際にそれを駆動しているかを調査してください。一度に始められすぎた並行機能、未対応の欠陥のバックログ、あるいは共有承認を待って止まっているリスクの仕事などです。それぞれの原因は異なる修正を示唆しており、「フロー負荷が高い」を単一の未分化な問題として扱うことは、一般的で効果のない対応を生み出す傾向があります。

遅延が実際どこで起きているかを切り分けるために、フロータイムをサイクルタイムと照らし合わせる

フロータイムはバリューストリーム全体にわたり、サイクルタイム(トピック2.6)はそのエンジニアリング部分だけをカバーするため、両者を直接比較してください。フロータイムとサイクルタイムの間に大きな隔たりがあるということは、エンジニアリングがその仕事を目にする前の、承認の列、優先順位づけのバックログ、あるいはチーム間の引き継ぎで、ほとんどの遅延が起きていることを意味し、これはエンジニアリングそのものの内側に集中した隔たりとはまったく異なる修正を示唆します。

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

アプローチ	長所	短所
エンジニアリングの拾い上げからのみフロータイムを測定する	単純で、既存のサイクルタイムの計測基盤と一致する	エンジニアリング以前の遅延を見逃し、本物の応答性を過小評価する
本物のビジネスニーズの特定からフロータイムを測定する	本物のエンドツーエンドの応答性を捉える	エンジニアリングの直接統制の外にある段階を計装する必要がある
定期的なフロー負荷の一時点	時折計算するのが安く済む	先行指標としての価値を失う。上昇する負荷が長すぎる間気づかれない
継続的なフロー負荷の追跡	生きた、行動可能な先行指標	時折の報告だけでなく継続的なツール統合が必要

中心にある緊張関係は範囲と計測基盤の届く範囲です。エンジニアリングの拾い上げからだけフロータイムを測定することは計装がはるかに容易です。なぜなら、トピック2.6がすでに収集しているサイクルタイムのデータを再利用するからですが、エンジニアリングが仕事を目にする前に起きるすべてを無視することで、本物の応答性を静かに過小評価します。この緊張を解消するには、今日計装できるのがそれだけなら、より狭いエンジニアリングに限定された測定から始めてください。ただし、フロータイムの開始点を上流へ、ビジネスニーズの特定と優先順位づけへと広げることを、恒久的な限界としてではなく近い将来の優先事項として扱ってください。

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

私たちのフロータイムの時計は実際今日どこから始まり、組織全体がそれが正しい開始点であると同意しているでしょうか。 利害関係者が時計が始まると想定している場所と、実際に始まる場所との不一致は、その指標への不信のよくある静かな原因です。文書化された定義が共有された理解と一致しているか確認してください。
私たちは、測定されたフロー負荷、到着率、フロータイムが実際にリトルの法則を満たしているかを確認したことがあるでしょうか。 もしそれらがおおよそ釣り合っていないなら、三つの数字のどれか一つが一貫性なく測定されています。その確認が通ると仮定するのではなく、実際の数字を一緒にたどってみてください。
フロー負荷は継続的に追跡されているでしょうか。それとも、着実な上昇は誰かが確認するまで何週間も気づかれないままになるでしょうか。 先行指標は、それが実際にほぼリアルタイムで監視されている場合にのみあなたを守ります。四半期報告で見直されるだけでは不十分です。
フロー負荷が上昇したとき、どのフローアイテムの種類が実際にそれを駆動しているかを私たちは言えるでしょうか。それとも単一の未分化な数字として読まれるでしょうか。一般的な「私たちは過負荷だ」という診断は、一般的で、しばしば効果のない対応を生み出します。現在の計測基盤が実際に上昇する負荷を特定の原因に帰属させられるかを確認してください。
私たちのフロータイムとサイクルタイムの間の隔たりはどれだけ大きく、その隔たりは、ほとんどの遅延がエンジニアリングが仕事を目にする前に起きているのか後に起きているのかについて何を示唆しているでしょうか。この比較は、しばしば、改善のための最大の機会が完全にエンジニアリング自身の統制の外にあることを明らかにします。
誰かが、その変更が文書化あるいは開示されることなく、数字をより良く見せるために私たちのフロータイムの開始点を静かに狭めたことがあるでしょうか。これが本トピックの中心的な操作のリスクを直接述べたものです。あなたの定義がこのようにずれたことがあるかを正直に問うてください。

業種別の視点

スタートアップ。 フロー負荷は、単純に多くの仕事を同時に始めるのに十分な人数がいないという理由で通常は低いものですが、創業者やリードエンジニアが多くの同時並行の取り組みにとって個人的なボトルネックになった瞬間、同じ数学的な関係が適用されます。専用のツールがなくても非公式にフロー負荷を追跡してください。リトルの法則は規模にかかわらず成り立つからです。

中小企業。 現在アクティブなすべてのものの単純で共有された一覧は、専用のバリューストリーム管理ソフトウェアなしにフロー負荷を計算するのに通常十分です。役立つ習慣は、フロータイムがすでに目に見えて悪化してから発見するのではなく、上昇する数字が早期に捉えられるほど十分な頻度でそれを確認することです。

企業。 ここでこそリトルの法則は、単なる指標としてだけでなく議論として価値を発揮します。数十の同時並行の戦略的取り組みをやりくりする大規模な組織は、フロー負荷とフロータイムの間の証明可能な関係を使って、仕事を順序づける証拠に基づく議論を行うことができます。これは、純粋に定性的な「私たちは忙しすぎる」という議論が、断固とした利害関係者の圧力に対してはめったに達成できないものです。

政府。 複数年にわたるプログラムは、それぞれ個々には正当化されるものの、総計についての組織全体の可視性がないまま、多くのワークストリームにわたって大きな暗黙のフロー負荷を日常的に蓄積します。リトルの法則を直接提示すること、つまりプログラム自身のフロータイムの成長が、プログラム自身の上昇するフロー負荷によって数学的に説明されることを示すことは、しばしば、すべてのワークストリームを無期限に並行して実行するのではなく、順序づけるための入手可能な最も明確で最も説得力のある証拠です。

事例

企業。 あるメディア技術企業のプラットフォーム組織は、おおよそ12件分の容量しかないのに22件の同時並行の戦略的取り組みを実行しており、この不一致は、新しいエンジニアリング担当副社長がフロー負荷を直接要求するまで誰も定量化していませんでした。中央値の取り組みのフロータイムは前年に40%成長していましたが、この傾向を指導層は「仕事が難しくなっている」せいだと考えていました。実際のフロー負荷と到着率の数字と一緒にリトルの法則を提示することで、その成長が、根底にある仕事の難しさの変化を一切必要とせず、上昇するフロー負荷だけで完全に説明されることが示されました。この組織は取り組みを持続可能なフロー負荷まで順序づけ、中央値のフロータイムは2四半期以内にほぼ3分の1減少しました。

政府。 ある連邦補助金管理機関の近代化プログラムは、単一の追跡された合計もないまま、数十の並行するワークストリームにわたってフロー負荷を蓄積していました。それぞれのワークストリームのスポンサーは、自分自身の取り組みが単独で適切に資源配分されていると信じていました。リトルの法則を使ったプログラム事務局の分析は、プログラムの集計フロータイム、つまりあるワークストリームの承認からその提供までの時間が、その集計フロー負荷だけからほぼ正確に予測できることを示しました。この発見は、1年以上優先度引き下げの議論に抵抗してきたスポンサーたちを納得させました。このプログラムは明示的なフロー負荷の上限を採用し、新しいワークストリームは現在の負荷にかかわらず即座に始まるのではなく、今では列に並んで待機します。

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

フロー負荷とフロータイムを一緒に追跡することからの見返りは、すべてを並行して実行するのではなく仕事を順序づけるための、単に説得力があるだけでなく証明可能な議論です。上記のメディア技術の例、フロータイムの悪化全体をフロー負荷だけで説明したことは、この組み合わせが確実に生み出すパターンです。具体的で定量的な議論が、より多くの仕事を始めるという実際の組織的圧力に対して、「忙しすぎる」という定性的な訴えが以前は失敗していたところで成功するのです。

総所有コストは、その説得力に比べて低いものです。フロー負荷は、アクティブで待機中のアイテムの生きた件数だけを必要とし、フロータイムはバリューストリームの入り口を計装する仕事を必要とします。これは、組織が実際の容量が支えられる以上の同時並行の取り組みに手を出すことを初めて防いだときに、それ自体で元が取れます。

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

数字をより良く見せるためにフロータイムの開始点を静かに狭める。 本トピックの中心にある操作のベクトルです。時計の開始を本物のビジネスニーズの特定からより後の時点、エンジニアリングの拾い上げや正式な承認へと動かすことは、本物の応答性をまったく変えることなくフロータイムを縮小させ、どの単一の変更も意図的な操作には見えないほど徐々に起こりえます。ガードレールは、入り口を指標チャーター(トピック1.4)で明示的に文書化し、その文書化された定義と照らし合わせて定期的に監査することです。これは、本書が指標のあらゆる境界について求めるのと同じ規律です。
フロー負荷を定期的にしか測定しない。 先行指標としてのその価値を放棄します。着実な上昇が何週間も気づかれないままになることがあります。
フロー負荷を単一の未分化な数字として扱う。 どのフローアイテムの種類が実際に過負荷を駆動しているかを見逃し、的を絞ったものではなく一般的な対応を生み出します。
フロータイムとサイクルタイムの隔たりを無視する。 遅延がエンジニアリングの前か後に集中しているかを見逃し、これは非常に異なる修正を示唆します。
リトルの法則を明示的に提示することなく同時並行の仕事の削減を主張する。 定性的な訴えは、定量的で証明可能な関係よりも、利害関係者にとってはるかに退けやすいものです。
リトルの法則が大規模にしか当てはまらないと想定する。 それは、過負荷になった単一の個人を含め、規模にかかわらずどんな安定したシステムにも成り立ちます。

成熟度モデル

レベル1、開始: フロータイムもフロー負荷も追跡されておらず、遅延は裏づけるデータなしに逸話的に議論されます。
レベル2、発展: フロータイムはエンジニアリングの拾い上げからのみ追跡され、フロー負荷は継続的にではなく定期的に確認されます。
レベル3、標準化: フロータイムは文書化された組織全体のバリューストリームの入り口から測定され、フロー負荷は先行指標として継続的に追跡されます。
レベル4、管理: リトルの法則は容量と順序づけの決定を正当化するために明示的に使われ、上昇するフロー負荷は修正が提案される前に特定のフローアイテムの種類に帰属づけられます。
レベル5、最適化: 組織はそのバリューストリームにわたって明示的なフロー負荷の上限を設定し、リトルの法則に裏づけられ、フロータイムを測定可能に改善した特定の順序づけの決定を指し示すことができます。

議論のためのアイデア

私たちのフロータイムの時計は実際どこから始まり、その定義は文書化なしにずれたことがあるでしょうか。
私たちの測定されたフロー負荷、到着率、フロータイムはおおよそリトルの法則を満たしているでしょうか。
フロー負荷は、着実な上昇が数か月ではなく数日以内に捉えられるほど継続的に追跡されているでしょうか。
私たちのフロータイムとサイクルタイムの間の隔たりはどれだけで、その隔たりは遅延が実際どこで起きているかについて私たちに何を教えてくれるでしょうか。

主な要点

フロー負荷はリトルの法則を通じて数学的にフロータイムを決定します。 フロー負荷は到着率にフロータイムを掛けたものに等しく、どんな安定したバリューストリームにも成り立ちます。
フロータイムはバリューストリーム全体にわたります。 ビジネスニーズの特定から提供まで、サイクルタイムのエンジニアリングだけの範囲(トピック2.6)よりも広いものです。
本トピックの中心的な操作のベクトルはフロータイムの開始点を静かに狭めることです。ガードレールは文書化され監査された入り口の定義です。
フロー負荷を定期的にではなく継続的に追跡し、それが遅れた発見ではなく本物の先行指標として機能するようにしてください。
WIP制限、容量増加、あるいは同時並行の仕事の順序づけを主張するとき、リトルの法則を単なる直感としてではなく明示的に使ってください。

参考文献とさらなる読書

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018。
Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961。
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009。