2.5 フロー効率と仕掛かり作業

概要と動機

フロー効率は、ある仕事についての、アクティブな時間と総時間の比率です。もしある変更が、コーディング、レビュー、テストに実際に10時間費やされる一方で、その旅全体を通じて合計90時間キューの中で手つかずのまま座っているなら、フロー効率は10%です。ほとんどのソフトウェア提供パイプラインは、正直に測定すると、10%から25%の間のどこかのフロー効率に落ち着きます。これは、努力が支配的だと予想する人々を驚かせます。ほとんどの提供システムにおける支配的なコストは、仕事を行うのにどれだけ時間がかかるかではなく、仕事が始められるのをどれだけ待つかです。

仕掛かり作業(WIP)は、ある瞬間に、チームやシステムを横断して実際に取り組まれているアイテムの数であり、トピック2.4が「フロー負荷」と呼ぶのと同じ量です。本トピックの背後にある直感に反する発見は、オペレーションズマネジメントにおける数十年の研究によって裏づけられ、カンバンと待ち行列理論を通じてソフトウェア提供のために形式化されたものですが、WIPを制限することは、スループットを減らすのではなく増やす傾向があるということです。なぜなら、一度に進行中の仕事が少ないほど、コンテキストスイッチが減り、キューが短くなり、アイテムごとの完了が速くなるからです。これは、同時に行う仕事を減らすことが全体としてより少ない産出を生むはずだと感じられるにもかかわらずです。

大規模なチームにとって、フロー効率を理解することは、ほとんどあらゆる提供の問題を、「人々はもっと速く働く必要がある」から「仕事はもっと待たされる必要がない」へと再構成します。この再構成が重要なのは、最初の枠組みが個人へのプレッシャーを招く、まさにトピック2.6が警告する罠だからです。一方、二つ目の枠組みは、待ち行列の構造、レビュー能力、そしてどれだけの仕事が同時に始められているかについての調査を招き、そこにこそ本物の持続可能な改善が通常宿ります。共有チームを横断して多くの同時並行の取り組みをやりくりする企業組織は、特に高いWIPと低いフロー効率に陥りやすいものです。なぜなら、新しい仕事を始めることは、それがすでに進行中のすべてを静かに遅くしているときでさえ、常に進歩のように感じられるからです。

重要な原則

ほとんどの提供パイプラインでは、アクティブな努力ではなく待ち時間が支配的である。 25%未満のフロー効率は典型的であり、壊れたチームの兆候ではありません。
仕掛かり作業を制限することは、コンテキストスイッチを減らしキューを短くすることで、スループットを減らすのではなく増やす傾向がある。
新しい仕事を始めることは進歩のように感じられるが、仕事を終わらせることこそが実際に価値を届ける。 これらは同じものではなく、組織は日常的にこれらを混同します。
高いWIPは測定されるまで見えないことが多い。 あるチームは、誰も個人的には気づかないほど多くの同時並行の仕事をやりくりしていることがあります。
これはシステムレベルの指標であり、個人レベルのものではない。 WIP制限を個人を罰するために適用することは、この技法の要点全体を読み違えています。

推奨事項

努力がボトルネックだと想定する前にフロー効率を測定する

トピック2.6のサイクルタイムの段階データを使って、最近の変更の代表的なサンプルについて、アクティブな時間と総経過時間の比率を計算してください。これを初めて測定するほとんどのチームは、その数字がいかに低いかに驚かされ、その驚きそれ自体が価値のあるものです。それは注意を「もっと一生懸命働く」から「待ち行列を減らす」へと向け直します。これはほとんど常により生産的なレバーです。

明示的な仕掛かり作業の制限を設定し、目に見える形で守る

チームや個人が一度に実際に進行中に持てるアイテムの数に上限を設け、共有されたボード上で見えるようにしてください(物理的あるいはデジタルのカンバンボードが古典的な実装です)。制限に達したとき、チームの次の行動は何か新しいものを始めることではなく、すでに進行中のものを終わらせるのを助けることです。この単一の慣行は、リーン製造業から借用され、カンバンの中で形式化されたもので、ソフトウェアチームが利用できる最も一貫して効果的なフローの改善の一つであり、実装するのにほとんど何も費用がかかりません。

WIP制限を個人の割り当てではなくシステムの制約として扱う

WIP制限は、システム(チーム、共有のレビューキュー、共有の環境)が一度にどれだけの仕事を進行中に持てるかを統制するものであり、ある一人がどれだけ触っていいかではありません。「チケットは二つまでしか開いてはいけない」というように、この制限を個人の業績目標として適用することは、この技法を誤って適用するものであり、本書が全体を通じて警告する個人レベルの操作をまさに招きます。この制限はシステム全体を通じたフローを守るために存在し、その執行は個人的な上限ではなくチームの規範であるべきです。

仕事がどれだけ長く手つかずのままかだけでなく、なぜそうなのかを調査する

フロー効率の分析が長い待ち時間を明らかにしたとき、具体的になぜかを問うてください。レビュー担当者が利用できないために仕事が待たされているのか、共有のテスト環境が予約で埋まっているからか、別のチームへの依存がまだ着地していないからか。これらのそれぞれは異なる修正を必要とします。この具体的な調査なしの一般的な「待ち時間を減らせ」という指示は、一般的で効果のない対応を生み出す傾向があります。

最初の改善の後にWIPが忍び寄るように戻ってくることに注意する

WIP制限をうまく採用したチームは、新しい取り組みを始めるプレッシャーが戻ってくるにつれて、時間とともにそれが蝕まれていくのをよく見ます。「今回だけは、この緊急のものも始める必要がある」といった具合です。すべてのWIP制限の例外を、静かで日常的な上書きとしてではなく、述べられた理由を伴う意図的で目に見える決定として扱ってください。そうすれば、その制限の規律が静かに元の状態に戻ってしまうことがありません。

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

アプローチ	長所	短所
WIP制限なし	柔軟に感じられる。新しい仕事を始めるときに摩擦がない	コンテキストスイッチとキューイングがすべてを静かに遅くする
チームレベルのWIP制限	スループットとフロー効率を測定可能に改善する	特に締め切りのプレッシャーの下で、守るための規律が必要
個人レベルのWIP割り当て	述べるのが簡単	この技法を誤って適用する。個人の操作のリスクがある
厳格で曲げないWIP制限	フロー効率の最大の利益	本当に緊急で例外的な状況では硬直的に感じられることがある

中心にある緊張関係は柔軟性とフローです。緊急に見えるときはいつでも新しい仕事を始めることは応答性があるように感じられますが、フロー効率とWIPの研究は一貫して、この柔軟性が何かを速く終わらせることの代償として得られることを示しています。より多くの同時並行の仕事は、すでに進行中のすべてにとって、より長いキューとより多くのコンテキストスイッチを意味するからです。この緊張を解消するには、厳格で例外なしのルールでも、無制限で柔軟な無秩序状態でもなく、本物の緊急事態のための意図的で目に見える稀な例外プロセスを伴う、チームレベルのWIP制限を既定として採用してください。

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

実際のサイクルタイムのデータから測定された私たちの実際のフロー効率はどれだけで、その数字は私たちを驚かせるでしょうか。 ほとんどのチームはこれを計算したことがなく、実際よりもはるかに高いと想定しています。本トピックの他の何かを議論する前に、最近の変更のサンプルを持ち出し、正直にその比率を計算してください。
私たちは今、チーム全体を通じて実際どれだけの仕掛かり作業を抱えており、数える前に誰かその数字を知っていたでしょうか。 高いWIPは、各個人が自分自身の部分しか見ていないために、明示的に測定されるまで見えないことがよくあります。今日誰もアクティブに触っていない仕事も含め、現在進行中のすべてを数えてください。
もし私たちがWIP制限を採用したら、新しい緊急の依頼にどう応えるかについて何を変える必要があるでしょうか。 この問いは、WIP制限が中断するように設計された本物の組織的な習慣、つまり反射的に新しい仕事を始めることを表面化させます。そしてそれは、制限を執行しようとする前に、後ではなく、話し合う価値があります。
仕事が私たちのパイプラインで手つかずのまま座っているとき、その具体的な理由は何で、それは毎回同じ理由でしょうか。 「物事が待たされる」という一般的な感覚は、利用できないレビュー担当者、予約で埋まった共有環境、チーム間の依存関係といった、具体的で繰り返される原因よりも役に立ちません。実際の最近の例から実際のパターンを名指ししてください。
私たちはWIP制限を採用し、それが例外を通じて静かに蝕まれていくのを見たことがあるでしょうか。 これは極めて一般的であり、正直に話し合う価値があります。何のプレッシャーが最初の例外を引き起こしたのか、そしてその例外は、誰も明示的にそう決めることなく新しい常態になったでしょうか。
私たちの文脈でのWIP制限は、個人、チーム、あるいは共有資源(レビューキューやテスト環境のような)のどのレベルで適用される必要があるでしょうか。異なるボトルネックは異なるレベルでの制限を必要とし、間違ったレベルで制限を適用すること、共有キューの上限ではなく個人の割り当てにすることは、技法全体を誤って適用することになります。

業種別の視点

スタートアップ。 人数が少なければ、単純に多くの仕事を同時に始めるのに十分なエンジニアがいないという理由で、WIPは自然に低いことがよくあります。危険なのは逆で、創業者やリードエンジニアが自分で気づいている以上にはるかに多くの同時並行の取り組みを個人的にやりくりしていることです。これは、正式なカンバンツールがなくても測定する価値があります。

中小企業。 明示的な列の制限を伴う、物理的あるいは基本的なデジタルツールの単純な目に見えるボードで、洗練されたフロー指標のツールに投資することなく、ほとんどの利益を得るのに十分です。寛大な制限から始め、チームがその規律に慣れるにつれて徐々に締めてください。

企業。 高いWIPはここで特に一般的で特に高くつきます。なぜなら、多くの同時並行の戦略的取り組みが同じ共有されたエンジニアリング容量を奪い合い、新しいものを始めることは、それをスポンサーした誰にとっても常に進歩のように見えるからです。チームレベルだけでなくポートフォリオレベルでWIPを可視化し、指導層が現在のものを終える前にもう一つの取り組みを始めることのコストを見られるようにしてください。

政府。 複数年にわたるプログラムは、それぞれ個々には正当化されるものの、総計についての組織全体の可視性がないまま、多くのワークストリームにわたって巨大な暗黙のWIPを蓄積することがよくあります。ポートフォリオレベルのWIPの可視性を、非公式にであっても導入することは、しばしば、すべてを並行して実行するのではなく仕事を順序づけるための唯一最も説得力のある議論です。なぜなら、高いWIPのフロー効率コストは、測定されると目に見える形で積み重なるからです。

事例

企業。 ある金融サービス企業のプラットフォームチームは、わずか12人のエンジニアで18件の同時並行の取り組みをやりくりしており、このWIP対容量の比率は、新しいエンジニアリング担当ディレクターが直接それを求めるまで誰も実際に計算していませんでした。チームの仕事にわたるフロー効率は12%未満でした。このチームは、エンジニア2人あたり1件のアクティブな取り組みという明示的なWIP制限を採用し、容量を薄く広げ続けるのではなく、いくつかの優先度の低い取り組みを意図的に一時停止しました。四半期ごとに本当に完了した取り組みとして測定されたスループットは、チームが特定の瞬間に目に見えて「より少なく行っている」ように見えたにもかかわらず、2四半期以内に倍以上になりました。

政府。 ある国家インフラ機関のデジタルトランスフォーメーションプログラムは、そのポートフォリオにわたって40を超える同時並行のワークストリームを蓄積しており、それぞれ独自のスポンサーと独自の正当化を持ちながら、進行中の総作業についての単一の見通しがありませんでした。プログラムレベルのフロー効率レビューは、中央値のワークストリームが経過時間の15%未満しかアクティブな開発に費やしておらず、残りは共有資源、小さな中央のアーキテクチャレビューチーム、共有のテスト環境、機関を横断した承認を待っていたことを発見しました。このプログラムは明示的なポートフォリオレベルのWIP制限を導入し、40すべてを並行して実行するのではなくワークストリームを順序づけました。そして、この機関自身の追跡は、一度に実行される総数が急激に減ったにもかかわらず、アクティブなままのワークストリームについて測定可能に速い完了を示しました。

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

フロー効率とWIPを意図的に管理することからの見返りは、直感に反するもののよく文書化されています。組織が一度に行うことを減らすと、スループットは下がるのではなく上がる傾向があります。なぜなら、コンテキストスイッチが減りキューが短くなることで、個々の仕事の各部分がより速く終わるからです。上記の金融サービスの例、同時並行の仕事を意図的に減らすことでスループットが倍になったことは、組織がより多くの並行した仕事が常により多くの進歩を意味すると想定するのではなく、実際にフロー効率を測定し行動すると見られる一般的なパターンです。

この規律を採用する総コストは、主に技術的なものではなく組織的なものです。目に見えるボード、合意されたWIP制限、そして制限に達したときに新しい仕事を始めることにノーと言う規律です。その規律は採用するよりも維持する方が難しく、だからこそ上記の「WIPが忍び寄るように戻ってくることに注意する」という推奨事項が、最初の採用そのものと同じくらい重要なのです。

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

フロー効率を測定せずにアクティブな努力が提供時間を支配していると想定する。 たいてい間違っており、改善の努力を間違ったレバーへと誤って方向づけます。
WIP制限をシステムの制約ではなく個人の割り当てとして適用する。 この技法を誤って適用し、個人の操作のリスクを招きます。
進歩のように感じられるという理由で反射的に新しい仕事を始める。 フロー効率とWIP制限が中断するように設計された核心的な習慣です。
WIP制限の例外が日常的で目に見えないものになるに任せる。 誰も意図的にそう決めることなく、規律を元の状態へと蝕みます。
チームレベルでのみWIPを測定し、ポートフォリオレベルの過負荷を見逃す。 多くの同時並行の戦略的取り組みを実行する大規模な組織でよくあることです。
低いフロー効率の数字を悪いチームの兆候として扱う。 それはほとんどの提供パイプラインに典型的なものであり、判決ではなく調査の出発点です。

成熟度モデル

レベル1、開始: 仕掛かり作業は追跡されておらず、チームは総同時負荷への可視性なしに反射的に新しい仕事を始めます。
レベル2、発展: 一部のチームは非公式なボードを使いますが、WIP制限は一貫して執行されず、フロー効率は一度も計算されません。
レベル3、標準化: チームはシステムレベルで明示的で目に見えるWIP制限を持ち、フロー効率は実際のサイクルタイムのデータから定期的に測定されます。
レベル4、管理: WIP制限の例外は意図的で目に見える決定として追跡され、フロー効率は時間とともに蝕まれていないか監視され、下がったときには調査されます。
レベル5、最適化: WIPはチームレベルだけでなくポートフォリオレベルでも可視化され管理されており、組織は同時並行の仕事を意図的に減らしたことで生じた具体的なスループットの改善を指し示すことができます。

議論のためのアイデア

実際のデータから正直に計算した、私たちの実際のフロー効率は何でしょうか。
この議論の前に誰も数えていなかった、私たちが現在抱えている仕掛かり作業はどれだけでしょうか。
本物のWIP制限を執行するために、私たちは何にノーと言う必要があるでしょうか。
私たちのパイプラインで仕事が手つかずのまま座っている、唯一最も一般的な理由は何でしょうか。
私たちの組織のどこで、ポートフォリオレベルのWIPが見えず、おそらく高すぎるでしょうか。

主な要点

フロー効率、つまりアクティブな時間と総時間の比率は、実際の提供パイプラインでは典型的に25%未満です。努力ではなく待ち時間が支配的です。
仕掛かり作業を制限することは、コンテキストスイッチを減らしキューを短くすることで、スループットを減らすのではなく増やす傾向があります。
WIP制限をシステムの制約として適用し、個人の割り当てとして適用しないでください。
一般的な「待ち時間を減らせ」という指示を出すのではなく、仕事が手つかずのまま座っている具体的な理由を調査してください。
WIP制限が日常的な例外を通じて蝕まれることに注意してください。すべての例外を意図的で目に見える決定として扱ってください。
トピック2.4はこの量をフロー負荷と呼び、トピック2.7はこの関係をリトルの法則として形式化します。仕掛かり作業は、どんな安定した待ち行列についても、到着率にサイクルタイムを掛けたものに等しいのです。

参考文献とさらなる読書

The Principles of Product Development Flow, Donald G. Reinertsen 著。
Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson 著。
Actionable Agile Metrics for Predictability, Daniel S. Vacanti 著。
The Goal, Eliyahu M. Goldratt 著。