11.6

View in English

11.6 バリューストリームマッピングと遅延のコスト

概要と動機

デリバリーチームの10人に、アイデアと本番の結果の間で時間がどこに行くかを尋ねれば、10の異なる推測が得られるでしょう。そのほとんどは間違っていて、ほとんどが楽観的です。理由は、全員が自分のステップははっきり見えるのに、ステップの間の待ちがまったく見えないからです。開発者は、機能のコーディングに2日かかったことを知っています。その後、それがレビューのキュー、テスト環境の予約、変更承認の委員会、リリースの窓で過ごした11日を、誰も追跡していません。仕事は数時間で行われ、キューで失われます。この章は、その全体像を見て、それに基づいて行動する二つのレンズを与えます。アイデアから価値までのフローを可視にするバリューストリームマッピングと、待ちに経済的な値段をつけて、意見ではなくお金で優先順位をつけられるようにする遅延のコスト。

これら二つのレンズは、第11部の残りを補完します。11.1章は何を築くかを決めるディスカバリーパイプラインを、11.2章はそれを出荷するデリバリーパイプラインを述べます。バリューストリームマッピングは両方にまたがり、最初の思いつきから測定された成果までの全経路を、見て改善すべき一つのシステムとして扱います。11.3章は待ち行列の数学を与え、この章は、それらの待ち行列があなたの組織で実際にどこにでき、何のコストがかかるかを見つける実践を与えます。11.4章(OKR)と11.5章(KPI)が良いものがどう見えるかを教えるのに対して、遅延のコストは、それを追求する順序を教えます。

大きなチームにとって、見返りは莫大です。数十のチームにわたる調整は引き継ぎを倍にし、すべての引き継ぎは仕事が待つ場所です。企業の設定では、機能は顧客に届くまでに、プロダクトチーム、プラットフォームチーム、セキュリティレビュー、リリース管理の機能を横切りえ、それらのグループ間の待ちは、通常その内側の仕事を小さく見せます。政府では、複数年のプログラムが法定の期限に対して公的資金をコミットし、地図にされていないバリューストリームは、無駄とリスクの両方を、支出に説明責任を負う人々から隠します。フローを可視にし、遅延に誠実に値段をつけることが、大きな組織が逸話から議論するのをやめ、証拠から決め始める方法です。

主要原則

  • 自分が所有するステップだけでなく、アイデアから価値までのフロー全体を見る。
  • プロセス時間(本物の仕事)と待ち時間(純粋な遅延)を分ける。その隔たりがあなたの機会である。
  • フロー効率を測り、改善前は衝撃的に低いと予期する。
  • スループットを支配する一つのボトルネックを見つけ、他のあらゆる所を最適化するのをやめる。
  • 遅延にお金で値段をつけ、優先順位が音量の競争ではなく経済的な決定になるようにする。
  • 最も声の大きい者ではなく、遅延のコストを所要期間で割ったもので仕事を順序づける。
  • バリューストリームの管理を、一回限りのワークショップではなく継続的な実践として扱う。

推奨事項

アイデアから価値までのバリューストリームを地図にする

バリューストリームとは、組織が要求を届けられた価値に変えるために行うステップの完全な連なりです。それを地図にするとは、その連なりを歩き、各ステップ、誰がそれを行い、そして各ステップについて二つの数字を書き出すことを意味します。プロセス時間(仕事が積極的に行われている時間)と、リードタイム(ステップが始められた時から、すべての待ちを含めて引き継がれる時までの総経過時間)。代表的な仕事の項目について、アイデアが受け入れられた瞬間から、その効果が本番で測定される瞬間まで、これを行います。11.1章のディスカバリーのステップと11.2章のデリバリーのステップを含めます。結果は、組織図にあるものではなく、あなたの本物のシステムの一枚の図です。

理想化されたプロセスを地図にしたい衝動に抵抗してください。記憶ではなく、ツールのタイムスタンプを使って、最近の三、四の項目に実際に起こったことを地図にします。求めているのは真実で、真実はステップの間の隙間に住んでいます。チームが初めてこれを誠実に行うと、必ず誰かが「そこに1週間も止まっていたとは知らなかった」の変奏を言います。その反応こそ要点です。全体として見たことのないフローは改善できません。

プロセス時間と待ち時間を分け、フロー効率を計算する

数字が得られたら、足し合わせます。フロー効率は、付加価値時間の総リードタイムに対する比率で、プロセス時間の合計を、開始から終了までの総経過時間で割ったものです。機能が40時間の実作業を要し、ストリームを通るのに20営業日かかるなら、そのフロー効率はおよそ40割る160、つまり25パーセントで、それは異例に良いでしょう。多くの本物のストリームは5から15パーセントの間に着地します。残りは純粋な待ちです。キューに座っている、依存関係でブロックされている、誰かの受信箱に置かれている仕事。

この数字は、あらゆる改善の会話を捉え直します。フロー効率が15パーセントのとき、仕事自体を20パーセント速くしても、全体は3ポイントしか改善せず、待ちの半分を取り除けば速度はほぼ倍になります。チームは本能的に、速くコードを書き、速くレビューし、速くテストしようとします。地図は、てこがほとんど決して作業のステップになく、ほとんど常にそれらの間の待ちにあることを教えます。箱ではなく余白を追ってください。

引き継ぎと手戻りのループを名指しする

地図上の二つの構造に特別な注意が必要です。引き継ぎは、仕事が一人あるいは一チームから別のものへ渡る点で、それぞれが、項目が次の当事者に容量ができるのを待つキューです。すべての引き継ぎはまた文脈を失うので、受け手は送り手がすでに知っていたことを再構成するのに時間を費やします。手戻りのループは後ろへ向かう矢印です。コードを開発者に戻す失敗したテスト、レビューの委員会に戻される却下された変更、ストーリーをプロダクトに戻す確認。手戻りのループは二重に高価です。容量を消費し、手戻りされた項目が列の後ろでキューに再び加わるからです。

両方を数えてください。九つの引き継ぎと三つの手戻りのループを持つストリームは、人々がどれだけ熟練していても、構造自体が待ちを製造するので、ひどいフロー効率になります。引き継ぎを減らす(チームにエンドツーエンドの所有を与えることで)ことと、手戻りの原因を取り除く(11.2章のように品質チェックを早めることで)ことは、通常、個々のステップを速くしようとするどんな努力にも勝ります。

ボトルネックを見つけ、制約理論を尊重する

すべてのバリューストリームには、パイプの最も狭い点が流れを制限するように、スループットを制限するステップがちょうど一つあります。エリヤフ・ゴールドラットの制約理論は、そのための規律を与えます。制約を特定する、それを活用する(決して遊ばせず、間違った仕事をさせない)、他のすべてをそれに従属させる(それが吸収できるより速く供給しない)、それを引き上げる(容量を加える)、そして制約が移っているので繰り返す。決定的で直感に反するルールは、制約以外のどのステップを改善しても何も改善されないことです。制約でないステップを速くすることは、単にボトルネックの前に在庫をより速く積み上げます。

地図上で制約を見つけます。その前に最も長く最も持続的なキューがあるステップです。ソフトウェアでは、それはしばしば、単一のセキュリティレビューの機能、一人のデータベースの専門家、乏しいテスト環境のような、共有の専門的な資源です。それを知ったら、守ってください。入力を待って遊ばせず、より安いステップができる仕事をさせず、その下流や上流の何かを最適化する前によく考えます。システム全体は、その一つのステップのペースで動きます。

遅延のコストを使って経済学で優先順位をつける

遅延のコストとは、仕事の一部がまだ届けられていない時間の単位ごとに、失う、あるいは得そこなうお金です。「後で」の経済的な重みです。月に10万ドルを稼ぐ機能が2か月遅れると、その数字が予算に現れるかどうかにかかわらず、20万ドルのコストがかかります。これを明示的にすることは、大きな積み残しを苦しめる「すべてが最優先」という病理への、最も強力な唯一の解毒剤です。すべての利害関係者が自分の項目は緊急だと主張するとき、音量では解決できません。それぞれに「1か月の遅延は私たちにいくらかかるか」と尋ねて、答えを並べて解決します。

遅延のコストの見積もりに精度は要りません。価値を理解する人々が合意した大まかな数字は、すべてが等しく重要だという偽の合意に勝ります。三つの構成要素を考えます。価値そのもの(収益、コスト削減、リスクの低減)、時間への敏感さ(待つと価値が減衰するか)、そして固い期限(規制、契約、季節の窓)。これは、10.15章の見積りと予測の規律に直接つながります。工数だけでなく、危うくなっている価値を予測しているのです。数字は1ドル単位で正しい必要はありません。仕事を行う順序を変えるのに十分に正しければよいのです。

CD3と加重最短ジョブ優先で順序づける

遅延のコストは、何を遅らせると高くつくかを教えますが、それだけでは何を最初にするかを教えません。6か月かかる非常に価値の高い項目は、今週終えられる中程度に価値のあるものより、最初に選ぶには悪いかもしれないからです。これを解決するルールは、遅延のコストを所要期間で割ったもので、CD3と書きます。項目ごとに遅延のコストを計算し、それがかかる時間で割り、最も高い比率を最初に行います。これは加重最短ジョブ優先(WSJF)のソフトウェアへの適用で、遅延のコストをジョブの長さで割ることが、仕事の待ち行列全体の総経済コストを最小化することを証明するスケジューリングの結果です。

WSJFが符号化する洞察は、短く価値のあるジョブが列に割り込むべきだということです。素早く終えることが待ち行列を解放し、他の何をもほとんど遅らせずに価値を早く始めるからです。長いジョブは、どれだけ価値があっても、その後ろのすべてを足止めします。実際には、遅延のコストと所要期間を単純な相対的な尺度で見積もり、比率を計算し、それに積み残しを順序づけさせます。多くのスケールされた組織が使う枠組みは、WSJFを、(事業価値、時間的な重要性、リスクあるいは機会の実現可能性から構成される)遅延のコストをジョブの大きさで割ったものとして表現し、それは名前の付いた構成要素を伴う同じ考えです。

各項目の緊急度のプロファイルを読む

すべての遅延のコストが時間とともに同じように振る舞うわけではなく、形は大きさと同じくらい重要です。緊急度のプロファイルは、待つにつれて遅延のコストがどう変わるかを記述します。一部の価値はおおよそ線形です。無期限に毎週ほぼ同じ額を失う。一部には固定の日付、階段関数があります。期限まで遅延は何のコストもかからず、それからすべてが一度に大きなコストになる(規制上の切り替え、契約上のゴーライブ)。一部は減衰します。今は莫大な価値があり、6か月後にはほとんどない市場の窓や競争上の先行者の優位。そして一部はほぼ平らで、いつ出荷しても同じ価値です。

プロファイルを知ることは、順序づけを変えます。急激に減衰する価値の項目は、価値が侵食される前に、今行くべきです。固定日付の項目は、ちょうど十分なリードタイムが残るまで待てますが、それから遅れてはなりません。主要な取り組みの緊急度のプロファイルを、大まかにでもプロットすることは、遅延がいくらかかるかだけでなく、そのコストがいつ着地するかを教え、それがまさに競合のもとでスケジュールするのに必要なものです。

フロー指標をDORAとリトルの法則につなげる

バリューストリームマッピングは、継続的に追跡する価値のある四つのフロー指標を生みます。リードタイム(開始から完了までの経過時間)、サイクルタイム(特定の段階の経過時間で、しばしば積極的なデリバリーの部分)、仕掛かりの仕事(WIP、進行中の項目の数)、スループット(単位時間あたりの完了した項目)。これらは、11.3章のリトルの法則で結ばれます。平均リードタイムは平均WIPを平均スループットで割ったものに等しい。その式が最も実際的なてこです。スループットを容易に上げられないなら、WIPを下げることで即座にリードタイムを短縮できると言うからです。始めることを減らせば、終えることが増えます。

これらのフロー指標はまた、DORAの指標(DevOps Research and Assessmentプログラムから)に上向きにつながります。デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧までの時間。変更のリードタイムはバリューストリームの一部であり、マッピングはそれを改善するためにどのステップを攻略すべきかを示します。DORAを成果のスコアボードとして、バリューストリームマップをスコアを説明する診断として扱い、両方を1.10章のエンジニアリングの有効性の見方に結びつけます。

キュー、バッチサイズ、WIPを意図して管理する

地図で見つけたキューは、リードタイムが生まれる場所で、11.3章は、稼働率が100パーセントに近づくにつれて、それらがなぜ爆発するかを説明します。二つのてこがそれらを手なずけます。第一はWIPの制限です。各段階で許される項目の数に上限を設け、容量があるときにだけ仕事が引かれるようにします。これはリトルの法則を通じてリードタイムを直接短くし、始めたが終わっていない仕事の山の下に隠すのではなく、ボトルネックを露呈させます。第二はバッチサイズです。大きなバッチ(四半期ごとのリリース、巨大なプルリクエスト、大きな要件の文書)は、長いキューを生み、フィードバックを遅らせ、すべての引き継ぎのコストとリスクを高めます。

小さなバッチは、より速く予測可能に流れ、それが11.2章のデリバリーパイプラインが、小さく、頻繁で、元に戻せる変更を好む最も深い理由の一つです。バッチサイズを減らしWIPに上限を設けることは、行える最も確実で最も低コストな二つの介入です。仕事自体を速くしようとするのではなく、待ちを直接攻撃するからです。

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

実践長所短所
バリューストリームマッピング隠れた待ちを明らかにする。チームを一枚の絵に揃えるスナップショットは古くなりうる。行動が続かなければ労力が無駄
フロー効率の指標労力を、てこが効く待ちに向け直す何が積極的な作業に数えられるかを再定義することでゲーム化できる
制約理論への集中実際にスループットを動かす所に労力を集中ボトルネックでないチームを放っておくのは政治的に難しい
遅延のコスト優先順位を経済学に変える。「すべて緊急」を沈静化見積もりは不確実で、議論されたり水増しされたりしうる
CD3/WSJFによる順序づけ総経済的遅延を最小化。クイックウィンを好む項目ごとに二つの見積もりが必要。偽の精度のリスク
WIPの制限リードタイムを即座に短縮。ボトルネックを露呈強制された遊びのように感じられる。文化的に抵抗される
小さなバッチサイズ速いフィードバック、変更ごとの低いリスク自動化が弱いと項目ごとのオーバーヘッドが高い

中心的な緊張は、測定の労力とそれが強いる誠実さの間にあります。バリューストリームマップも遅延のコストのモデルも、築くのに労力がかかり、組織が真剣でなければ、どちらもゲーム化されたり放置されて朽ちたりしえます。失敗の様式は、美しい図を生んで変更を何も生まないマッピングのワークショップ、あるいはすべての利害関係者が再び無意味になるまで水増しする遅延のコストの数字です。実践を、行動と、追跡される少数のフロー指標に結びつけて解決します。地図は、それが明らかにするボトルネックを攻略するつもりがある場合にだけ作る価値があり、遅延のコストの見積もりは、実際に積み残しを並べ替える場合にだけ議論する価値があります。精度が目標ではなく、より良い決定が目標です。

チームで議論すべき問い

  1. 最後の三つの機能について、アイデアから本番までの本物のバリューストリームを地図にしたら、実際のフロー効率はどれだけで、最大の待ちの溜まりはどこにありますか。 ほとんどのチームはこれを計算したことがなく、答えに驚きます。目に見える作業のステップは忙しく感じられる一方で、それらの間の待ちは見えないからです。記憶ではなくツールのタイムスタンプを持ち込み、最近の項目を一つ端から端まで歩き、各ステップのプロセス時間と総リードタイムを書きます。求める証拠は、仕事が動けたはずの時と実際に動いた時の間の単一の最大の隔たりです。その隔たりは、どの個人の速さでもなく、最初の標的で、それを声に出して名指しすることは、通常、チームにそれを直したいと思わせるのに十分です。

  2. 私たちの唯一の本物の制約はどこにあり、それ以外のすべてを偶然最適化していませんか。 制約理論は、ボトルネックだけがスループットを統べると言いますが、チームは日常的に、自分が制御するステップだからと、すでに速いステップに労力を注ぎます。その前に最も長く最も持続的なキューがあるステップを探し、最近の改善がそこに触れたのか、単にボトルネックでないものを速くしたのかを誠実に考えてください。不快だが価値のある結論はしばしば、共有の乏しい資源(一人のレビュアー、一つの環境、一人の専門家)が全員のペースを決めていて、その資源を守って引き上げることが、他の場所のどんな局所的な高速化よりも重要だということです。

  3. 二つの利害関係者がどちらも自分の仕事が最優先だと言うとき、今日どう決めていて、遅延のコストは異なる順序を与えますか。 今の答えはおそらく、年功、音量、最も強くエスカレーションした者のいずれかで、どれも経済的な価値を反映しません。本当に争われている項目を二つ持ち込み、大まかにでも、1か月の遅延が各々にいくらかかり、各々にどれだけかかるかを見積もり、それから遅延のコストを所要期間で割ります。要点は正確な数字ではなく、それが強いる会話です。依頼に遅延のコストを付けなければならない利害関係者は、突然異なる推論をし、経済学で勝つ項目は、音量で勝っていたものではないことがしばしばです。それが部屋に何をもたらすかを見てください。

  4. バリューストリームのどの引き継ぎを取り除くか集約でき、そのために誰が制御を手放さなければなりませんか。 すべての引き継ぎはキューであり文脈の喪失なので、引き継ぎの数は、どのチームの技能よりフロー効率をよく予測することがしばしばですが、引き継ぎは、所有、承認権、誰かの説明責任の感覚を符号化しているため続きます。大きな組織では、ここが地図が政治的になる所です。引き継ぎを集約することは、通常、一つのチームにエンドツーエンドの所有を与え、統制の機能に手作業の承認の代わりに自動化されたゲートを信頼するよう求めることを意味します。引き継ぎごとの待ち時間、各引き継ぎが引き起こす手戻りのループ、どの引き継ぎが本物のリスクの理由で存在し、どれが歴史的な習慣かについての誠実な注記を持ち込んでください。企業と政府の設定では、争われる各引き継ぎの統制の所有者と、どんな証拠(合格した自動チェック、監査証跡、委任された権限)が、それを取り除くことを受け入れさせるかを名指ししてください。誰も手放さない引き継ぎは、リードタイムへの恒久的な税だからです。

  5. シーケンスに使う遅延のコストの数字にどれだけ自信があり、すべての利害関係者が単に自分のものを水増しするのを何が防ぎますか。 遅延のコストは、見積もりにいくらかの規律がある場合にだけ「すべてが最優先」の膠着を破ります。大きい数字が勝つと各当事者が学んだ瞬間、全員がより大きな数字を出し、経済学の衣装を着た音量の競争に戻ります。相反する考慮は、精度を要求することが実践を殺すことです。価値を理解する人々が合意した大まかな数字こそ要点なので、偽の正確さを装わずに項目を比較するのに十分な厳密さが必要です。いくつかの本物の見積もりを、構成要素(価値、時間的な重要性、期限の圧力)に分けて持ち込み、疑わしいほど丸い、あるいは裏づけのないものを探してください。公的資金を使う企業のポートフォリオや政府のプログラムでは、争われる数字を誰が裁定し、見積もりが後で実現された成果と照合されるかを決めてください。現実に対して較正されない遅延のコストのモデルは、全員がいずれゲーム化するものだからです。

  6. 仕掛かりの仕事とバッチサイズを意図して管理していますか。それとも、リードタイムが静かに倍になるまで両方が上方へずれるのに任せていますか。 リトルの法則はてこを具体的にします。リードタイムは仕掛かりの仕事をスループットで割ったものに等しいので、管理されないWIPは、誰も遅く働いていなくても、すべての項目の待ちを長くし、大きなバッチは、すでに地図で見つけたキューに詰め込むことで効果を複合します。緊張は文化的です。WIPに上限を設けることは強制された遊びのように、小さなバッチは余分なオーバーヘッドのように感じられるので、チームは両方に抵抗しますが、それらは利用できる最も安い介入です。段階ごとの現在のWIPの数、典型的なバッチの大きさ(リリース、プルリクエスト、要件の文書)、それに伴うリードタイムの傾向を持ち込んでください。大きなあるいは公的な組織では、これを、契約上あるいは手続上縛られているリリースと変更承認の周期に結びつけてください。四半期ごとのリリースの窓や月次の委員会が大きなバッチを強いることがあり、その制約を名指しすることが、それを交渉で下げる第一歩だからです。

セクター別の視点

スタートアップ。 少数のエンジニアとわずかな滑走路では、バリューストリームは短いですが、制約は通常人です。すべての設計とリリースを承認する一人の創業者、あるいはデプロイを所有する一人のエンジニア。重いマッピングの演習は行わないでください。タイムスタンプで最後の数機能を追って半日を費やし、人間のボトルネックを見つけ、その周りを委任するかバッチ化します。正式な遅延のコストのモデルは飛ばし、毎週の「次に何を築くか」の議論を終わらせるために、大まかな遅延のコスト割る所要期間の順位づけを使い、市場が何を望むかをまだ学んでいる間はフィードバックが速いままであるよう、バッチを小さく保ちます。

小規模事業者。 フロー指標の専門家はおらず予算も厳しいので、バリューストリームのプラットフォームを買うのではなく、すでに払っているツールに頼ってください。課題トラッカーとバージョン管理からタイムスタンプを引き出します。代表的な仕事の項目を一つ地図にし、概算のフロー効率を計算し、待ちの最大の溜まりを攻略します。それはしばしば、一人の忙しい所有者の所に座っている承認です。遅延のコストを、購入するスプレッドシートの製品ではなく会話として扱い、月額料金でフローを可視化すると約束するどんなツールよりも、仕掛かりの仕事とバッチサイズを削ること(どちらも無料)を好みます。

大企業。 価値は、機能がプロダクト、プラットフォーム、セキュリティ、リリース管理を横切り、グループ間の待ちがその内側の仕事を小さく見せる、多くのチームを横断して見ることにあります。バリューストリームマッピングを再現可能な実践として標準化し、グループが音量で議論するのをやめるよう、遅延のコスト割る所要期間を共有の優先順位づけの言語にし、始めたが終わっていない仕事の下に隠すのではなく本当の制約を露呈させるため、WIPの制限と小さなバッチを徹底します。ポートフォリオが一つの診断と一つのスコアボードを持つよう、フロー指標をDORAとリトルの法則に結びつけ、誰が制約を所有し、争われる遅延の見積もりを誰が裁定するかの周りにガバナンスを置いてください。

政府。 調達規則、透明性の義務、公的な説明責任があらゆる選択を形づくり、法定の期限が、通常、他のすべての緊急度のプロファイルを支配します。政策、エンジニアリング、セキュリティの認定、運用にまたがってストリームを地図にしてください。固い制約はしばしば、キューが数か月で測られる認定やコンプライアンスのゲートで、それを引き上げること(レビュアーの追加、証拠収集の前倒し)が、どんな下流の高速化よりも多くを買うからです。バリューストリームの管理を、監督機関が、支出だけでなくフローが改善していることの監査可能な証拠を得られるよう、定期的なレビューを伴う常設の実践にし、公的資金の順序づけが説明され擁護できるよう、遅延のコストを公然と値段づけます。

事例

スタートアップ。 15人のスタートアップは、自分のロードマップを外し続けて、エンジニアのせいにしています。半日のバリューストリームマッピングのセッションは、異なる話を語ります。機能は、すべての設計とすべてのリリースを承認する一人の創業者を待つことに、人生の大半を費やしています。フロー効率は10パーセント未満で、創業者が制約です。彼らは制約理論を直接適用します。創業者は、ある大きさの閾値以下の設計の承認を委任し、リリースを臨時の承認ではなく毎日の窓にバッチ化し、決められる以上の決定を供給されるのをやめます。リードタイムは1か月以内に、新しい雇用なしにおよそ半分になります。それから積み残しのために、単純な遅延のコスト割る所要期間の順位づけを採用し、それが毎週の何を築くかの議論を静かに終わらせます。

大企業。 大手銀行が、顧客向けの変更のバリューストリームを地図にし、それが九つのチームを横切り、リードタイムが11週間で、そのうち実際の作業はおよそ6日だと見つけます。残りはキューです。月次で走るセキュリティレビュー、週次で開かれる変更承認の委員会、日数で測られる環境の予約。チームにもっと速く働くよう押すのではなく、銀行は待ちを攻略します。セキュリティレビューを早め、そのほとんどを(11.2章のように)自動化し、週次の委員会を低リスクの変更のための軽量な常設の承認に変え、チームが始める前に終えるようWIPに上限を設けます。遅延のコストがポートフォリオの優先順位づけの言語になり、永続的な「すべてが重要」の積み残しを順位づけられたものに沈静化し、変更のリードタイム(DORAの指標)は11週間から2週間未満に下がります。

政府。 国の税務当局は、法定の期限のもとで複数年の近代化を運営します。プログラムが活動で報告してフローで報告しないので、リーダーシップは公的資金がどこで進捗を買っているかを見られません。機関は、政策、エンジニアリング、セキュリティの認定、運用にまたがってバリューストリームを地図にし、認定が、キューが数か月で測られる固い制約だと発見します。認定を引き上げるべきボトルネックとして扱い、スタッフを加え、証拠収集を前倒しして、項目がレビューの準備ができた状態で届くようにします。各義務づけの緊急度のプロファイルを使って遅延のコストを値段づけします。固定された立法上の期限が順序づけを支配し、平らな価値の整理の仕事は待ちます。バリューストリームの管理は四半期ごとのレビューを伴う常設の実践になり、支出だけでなくフローが改善していることの監査可能な証拠を監督機関に与えます。

ビジネスケース: 動機、ROI、TCO

これらの実践の見返りは、見えない待ちを、より早く届けられる価値に変えることから来ます。フロー効率が15パーセントのとき、リードタイムの大半は、すでに払っている無駄で、より遅いフィードバック、より遅い収益、ロードマップへの信頼を失う利害関係者という形で払っています。待ちを取り除くことは、雇用に比べてほぼ無料です。WIPの制限、より小さなバッチ、より早いセキュリティレビュー、委任された承認はほとんどコストがかからず、しばしばリードタイムを半分にします。取り除くリードタイムの1週間ごとに、1週間分の価値が前に引き寄せられ、遅延のコストは、リーダーシップがすでに追跡している同じお金でその利得を定量化させてくれます。

遅延のコストによる優先順位づけには、それ自体の独特な見返りがあります。CD3やWSJFで順序づけることで、積み残し全体の総経済的遅延を証明可能に最小化するので、同じチームが同じ時間働いて、単によりよい順序で物事を行うだけで、より多くの価値を届けます。それは、新しい容量をまったく要さないので、利用できる最も安い改善です。採用のコストは控えめで、ほとんどが一度きりです。数回のマッピングのセッション、軽量な遅延のコストのモデル、少数のフロー指標を追跡する規律。継続的なコストは、地図を最新に保ち、遅延の見積もりを水増ししない誠実さです。

怠慢のコストは静かに複合します。地図にされていないストリームは、誰も説明責任を負わない引き継ぎと手戻りのループを蓄積し、音量で優先順位づけされた積み残しは価値からずれ、組織は、キューが完全な稼働率の近くで爆発する間(11.3章)、平均を軸に計画します。リーダーシップに論拠を示すには、これらの実践を、彼らがすでに見ている指標につなげてください。DORAの変更のリードタイム、スループット、四半期ごとに届けられる価値。バリューストリームの管理を、それらの数字を説明する診断として、遅延のコストをそれらを改善する経済的論理として枠づけます。

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

  • 地図にして忘れる: ワークショップで作られた磨かれたバリューストリームの図が、実際のフローに何の変更ももたらさないこと。
  • ボトルネックでないものの最適化: すでに速いステップを速くし、本当の制約の前に在庫を積み上げるだけになること。
  • スイカのフロー指標: 緑のダッシュボード(高いスループット)が、赤い現実(巨大なWIPと伸びるリードタイム)を隠すこと。
  • 遅延のコストの水増し: すべての利害関係者が巨大な数字を割り当て、破ろうとした「すべてが最優先」の膠着を復活させること。
  • 所要期間への盲目: 価値だけで順位づけし、10のクイックウィンの前に価値の高い6か月のジョブを始め、CD3を無視すること。
  • 緊急度のプロファイルの無視: 減衰する価値の項目と平らな価値の項目を互換として扱い、間違ったものを先に出荷すること。
  • 局所的な効率の崇拝: すべてのチームを100パーセント稼働させ続け、フローではなくキューとリードタイムを最大化すること。
  • 大きなバッチのリリース: 変更を稀で大きな投下にまとめ、キューを長くし、フィードバックを遅らせ、各リリースのリスクを高めること。
  • 平均だけの計画: 平均リードタイムを使って変動を無視し、長い裾に驚くこと(11.3章)。

成熟度モデル

  • レベル1、開始: 誰もエンドツーエンドのフローを見られません。優先順位は音量、年功、エスカレーションで設定され、「すべてが最優先」が規範です。ステップ間の待ちは見えず、改善の労力はチームが忙しいと感じる所に着地し、通常は制約ではありません。誰もプロセス時間と待ち時間を分けないので、巨大なキューの溜まりは気づかれず、値段もつきません。
  • レベル2、発展: 一つか二つのチームが少なくとも一つのバリューストリームを地図にし、最大のキューと大まかなフロー効率を指せます。一部のフロー指標(リードタイム、WIP)が局所的に追跡され、優先順位づけは時に価値を考慮しますが、実践はチーム間で一貫しません。遅延のコストは非公式で、地図は一回限りの成果物で、各グループは、行うとしても独自のやり方で行います。
  • レベル3、標準化: バリューストリームマッピングは文書化された再現可能な実践として組織全体で使われ、制約が特定されて制約理論に従って守られ、WIPの制限と小さなバッチは局所的な実験ではなく徹底される標準です。遅延のコスト割る所要期間(CD3あるいはWSJF)が、チーム間で積み残しを順序づける合意された方法で、フロー指標は、リードタイム、サイクルタイム、WIP、スループットの共有の定義を使ってDORAに明示的に結びつきます。
  • レベル4、管理: フローはベースラインに対するデータで測定され制御されます。フロー効率、リードタイム、WIP、スループット、DORAの変更のリードタイムが合意された目標に対して継続的に追跡され、ストリームがずれたときに旗を立てる管理限界を伴います。遅延のコストの見積もりは実現された成果に対して較正されるので水増しが捉えられ、制約のキューは本物の数字で監視され、プロセスの変更の実行か中止かの決定は意見ではなく証拠に基づいて行われます。
  • レベル5、オーケストレーション: バリューストリームの管理は継続的で、組織全体に統合され、適応的です。緊急度のプロファイルが順序づけに情報を与え、制約は引き上げられて移るにつれて再特定され、遅延のコストのモデルは本物の成果から洗練され、マッピング、優先順位づけ、キューの管理は互いに、そしてより広いポートフォリオに供給します。組織は条件が移るにつれてフローを再均衡させ、監査可能な証拠で改善を証明できます。

議論のためのアイデア

  1. 現在のフロー効率はどれだけで、仕事を速くするのではなく待ちの半分を取り除いたら、どれだけ速くなりますか。
  2. 今、あなたの唯一の本当の制約はどこにあり、それを決して遊ばせず、より安いステップができる仕事をさせないようにするには何が必要ですか。
  3. 積み残しの上位五項目について、1か月の遅延は各々にいくらかかり、遅延のコスト割る所要期間で順位づけると順序は変わりますか。
  4. 主要な取り組みのうち、減衰する緊急度のプロファイルを持つものはどれで、価値の大半がすでに蒸発した後に出荷するリスクはありませんか。
  5. 明日WIPを半分に削ったら、リトルの法則はリードタイムについて何を予測し、試すためにどんな文化的な抵抗を乗り越えなければなりませんか。
  6. 典型的なバッチ(リリース、プルリクエスト、要件の文書)の大きさはどれくらいで、それを半分にしたらフィードバックの速度と変更ごとのリスクはどうなりますか。

要点

  • フロー全体を地図にしてフロー効率を計算します。てこは、ステップの内側の仕事ではなく、ステップの間の待ちにあります。
  • 単一の制約を見つけ、制約理論を尊重します。他のステップを最適化しても何も改善されず、ボトルネックにより速く供給するだけです。
  • 「すべてが最優先」を打ち破るために遅延のコストをお金で明示的にし、各項目の緊急度のプロファイルを読んで、コストがいつ着地するかを知ります。
  • 遅延のコスト割る所要期間(CD3あるいはWSJF)で順序づけて総経済的遅延を最小化し、短く価値のある仕事が列に割り込めるようにします。
  • WIPの制限と小さなバッチでキューを管理し、フロー指標をDORAとリトルの法則に結びつけ、バリューストリームの管理を継続的な実践として運営します。

参考文献とさらなる読み物

  • Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development
  • Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement
  • Mike Rother and John Shook, Learning to See: Value Stream Mapping to Add Value and Eliminate Muda
  • Karen Martin and Mike Osterling, Value Stream Mapping: How to Visualise Work and Align Leadership for Organizational Transformation
  • Mik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
  • Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
  • Dean Leffingwell, SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework