2.1 Flow Framework

概要と動機

Flow Frameworkは、ミック・カーステンが生み出し、2018年の著書『Project to Product』で発表した経営上および構造上のモデルです。これは、純粋なパイプライン指標では答えられない問いに答えるために存在します。コードがコミットから本番までどれだけ速く、どれだけ安全に動くかだけでなく、そもそもそのパイプラインを通じてどんな種類の価値が流れているのか、そしてその組み合わせがビジネスの実際の戦略を反映しているかどうかです。このフレームワークは、ソフトウェア提供をバリューストリーム、つまりアイデアを顧客が受け取る価値へと変える活動のエンドツーエンドの連鎖として扱い、リーン製造業のバリューストリームマッピングの伝統から直接借用しています。

本書は、Flow Frameworkを第2部の組織化の構造として使います。トピック2.2はその4つのフローアイテムを紹介し、トピック2.3とトピック2.4はその5つのフロー指標を紹介し、トピック2.8はそれらの指標を古典的なリーンのバリューストリームマッピングにおける起源までたどり、トピック2.10は、このパートがもはやそれを先頭に置かなくなった、より狭い、パイプラインに焦点を当てた参考フレームワークとしてDORA指標を扱います。これは意図的な選択であり、DORAの研究を軽視するものではありません。DORAは本物の統計的厳密さをもってシステムのスループットと安定性を測定しますが、ビジネスリーダーが実際に最も気にかけている問い、つまりエンジニアリング組織が今四半期に出荷したすべてのもののうち、どれだけが新しい顧客価値であり、どれだけが欠陥の修正、リスクの管理、あるいは負債の返済によって静かに消費されたのかについては沈黙しています。Flow Frameworkは、特にその組み合わせを可視化するために存在します。

大規模なチームにとって、この区別は学術的なものではありません。数十のバリューストリームを運営するプラットフォーム組織は、優れたDORAの数字、つまり速く、頻繁で、安定したデプロイを持ちながら、その実際の製品アウトプットが静かにほぼ純粋な保守作業へとずれていくことがあります。これは、パイプラインの仕組みしか測定しないダッシュボードには見えないパターンです。エンジニアリング投資を、パイプラインの言葉ではなくビジネスの言葉で考える利害関係者に正当化しなければならない企業や政府の組織は、提供活動を戦略的意図に結びつける語彙を必要とします。それこそが、このフレームワークが提供するものです。

重要な原則

バリューストリームが測定の単位であり、チームやパイプラインではない。 それは、顧客やビジネスのニーズから、届けられた成果まで広がり、仕事が実際に横断するどんなチームの境界をも横断します。
フローアイテムは「どれだけ速いか」だけでなく「何か」を可視化する。 トピック2.2の4つのカテゴリー、機能、欠陥、リスク、負債は、暗黙の優先順位づけの決定を、明示的で測定可能なものに変えます。
フローアイテムをまたぐ容量配分はゼロサムである。 あるアイテムの種類により多くの容量が費やされれば、他の種類に使える容量は少なくなります。このフレームワークは、そのトレードオフを暗黙のままにせず可視化します。
5つのフロー指標は、エンジニアリングの問いだけでなくビジネスの問いにも答える。 それらは、エンジニアリングチームの内側にとどめられるのではなく、非技術的な利害関係者に提示されるように設計されています。
バリューストリーム管理は、一度きりのマッピング演習ではなく継続的であるべきだ。 静的なバリューストリームマップは古びていきます。このフレームワークは、チームがすでに使っているツールから計装されるように作られています。

推奨事項

何かを計装する前にバリューストリームを地図に描く

どんなフロー指標を採用する前にも、ビジネスのニーズが特定されてから顧客が価値を受け取るまでに、ある仕事が実際にたどる経路を歩いてみて、すべての段階とチーム間のすべての引き継ぎに名前をつけてください。これは、リーン製造業から適応された、古典的なバリューストリームマッピングの演習であり、これを省くことは、Flow Frameworkの採用が誰も信頼しない数字を生み出す最もよくある理由です。検証されていない、非公式にしか理解されていないプロセスに対して計算された指標は、実際に起きていることとめったに一致しません。

フロー指標をチームがすでに使っているツールに結びつける

Flow Frameworkは、定期的な手動のマッピング演習のためではなく、継続的で自動化されたバリューストリーム管理のために作られています。フローアイテムの追跡を、仕事がすでに流れているツール、Jira、Azure DevOps、GitHubに直接統合してください。チームが手で更新しなければならない並行した追跡システムを構築するのではなくです。フローアイテムの状態は、根底にあるチケットやプルリクエストが動くのに合わせて自動的に更新されるべきです。これは、本書のあらゆるメトリクスについてトピック1.5が推奨する、自己申告よりも計測基盤を優先する規律と同じものです。

フロー分布をエンジニアリングの指導層だけでなく、ビジネスの利害関係者に直接提示する

このフレームワークにおける最大の見逃された機会は、それを内部のエンジニアリングツールとして扱うことです。フロー分布、つまり機能に対する欠陥、リスク、負債に向かう仕事の割合(トピック2.3)は、特にプロダクトとビジネスの指導層との会話であるように設計されています。なぜなら、それは暗黙の優先順位づけの決定、つまりどれだけの容量が新しい価値に向かい、どれだけが現状維持に向かうのかを、想定されたままにするのではなく、明示的で交渉可能なものにするからです。

4つのフローアイテムを形式ではなく本物の分類法として扱う

すべての仕事の単位を、事後にではなく受け入れ時点で、4つのフローアイテムの種類のうちちょうど一つに分類することを要求してください。事後に適用された分類、あるいは「基本的には機能だから」という理由でゆるく適用された分類は、分類法全体の価値を損ないます。なぜなら、その要点は、容量が実際どこへ行ったかについての、誠実で一貫した記録だからです。

組織が変わったときにバリューストリームマップを見直す。固定されたスケジュールではなく

バリューストリームマップは、チームの境界、ツール、あるいは製品そのものが大きく変わった瞬間に古びていきます。何らかの恣意的な年次の頻度ではありません。組織再編、大きなツールの移行、あるいは重大な製品の方向転換を、バリューストリームを再び歩くきっかけとして扱ってください。なぜなら、古びたマップに対して計算されたフロー指標は、静かに間違ったものを測定するからです。

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

アプローチ	長所	短所
パイプライン指標のみ(DORA、トピック2.10)	単純で、よく検証されており、既存のCI/CDデータから安く計装できる	どんな種類の価値が届けられているかについて沈黙している
Flow Frameworkの完全な採用	提供をビジネス戦略に結びつけ、価値の組み合わせを可視化し交渉可能にする	誠実なバリューストリームマップと一貫したフローアイテムの分類規律が必要
静的で一度きりのバリューストリームマッピング	安く、ワークショップの演習として素早く実行できる	すぐに古びる。生きたメトリクスではなく一枚の写真を生み出す
継続的で、ツールに統合されたバリューストリーム管理	生きた、常に最新のデータ。多くのバリューストリームにわたって規模を拡大できる	前もって本物のツール統合作業が必要

中心にある緊張関係はビジネスの可読性と計装の労力です。パイプラインはすでにデータを生成しているため、パイプライン指標は安く済みますが、バリューストリーム指標は、パイプライン指標が一度も要求しなかった、プロセス全体の誠実なマップと規律ある受け入れ時点での分類の習慣を必要とします。この緊張を解消するには、組織全体を一度に対象とするのではなく一つのバリューストリームから始め、それを適切にマッピングし、その後初めて、すべてのチームを対象にした一斉展開を試みるのではなく、既存のツールにフローアイテムの追跡を統合してください。

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

私たちの最も重要な製品について、今、正確なバリューストリームマップを描けるでしょうか。それとも、いくつかの引き継ぎについて推測することになるでしょうか。ほとんどの組織は、この経路を実際にエンドツーエンドで歩いたことがありません。この演習を正直に試み、グループが実際に何が起きているかについて意見が一致しない場所すべてに注目してください。なぜなら、その不一致自体が診断的だからです。
もし私たちのチームが前四半期に出荷したすべてのものを機能、欠陥、リスク、負債に分類したら、その結果は私たちのプロダクト指導層を驚かせるでしょうか。ほとんどのチームは、この区分を明示的にしたことがありません。そして答えは、以前は単純な「届けられたストーリーポイント」の件数の中では見えなかった保守の負担や負債の問題を明らかにすることがよくあります。
私たちには、フローアイテムを追跡するための本物の、ツールに統合された方法があるでしょうか。それとも、これには誰かが手で仕事を分類し、再分類する必要があるでしょうか。手動のシステムは実際の作業量のもとで急速に劣化します。ツールに統合されたシステムはそうなりません。実際にどちらを維持する準備ができているかを正直に評価してください。
私たちのバリューストリームマップが最後に変わったのはいつで、それを反映するように私たちのメトリクスを更新したでしょうか。 組織再編やツールの移行は、バリューストリームマップを静かに無効にします。そして、それが起きたときにそれを見直すことを覚えている組織はほとんどありません。
私たちのフロー指標は、ビジネスやプロダクトの利害関係者に直接提示されたことがあるでしょうか。それともエンジニアリングの内側にとどまっているでしょうか。パイプラインだけの指標に対するこのフレームワークの最大の優位性は、まさにこの会話であり、それを省くことはフレームワークの価値のほとんどを放棄することになります。
誰かが紙の上では何も不誠実なことをせずに、私たちのフローアイテムの分類を操作するには何が必要でしょうか。 提供のプレッシャーの下にあるチームが、より生産的に見せるために、負債やリスクの仕事を静かに機能として再分類する様子を思い描いてみて、今現在それに気づくかどうかを話し合ってください。

業種別の視点

スタートアップ。 誰もがすでにプロセス全体を暗記している5人のチームにとって、完全なバリューストリームマップはたいてい過剰です。この規模で役立つ習慣は、単純に、計画の会話の中で4つのフローアイテムの種類を声に出して名指しすることです。そうすれば、機能の締め切りが迫った瞬間に、負債やリスクの仕事が静かに視界から消えてしまうことがなくなります。

中小企業。 専用のバリューストリーム管理製品ではなく、すでに使っている軽量な追跡ツールの中に、ラベル付きの列やカスタムフィールドとして、フローアイテムの分類を導入してください。一貫した分類の規律は、その背後にあるツールの洗練さよりもはるかに重要です。

企業。 ここでこそこのフレームワークがその価値を発揮します。なぜなら、多くの製品ラインにわたって数十のバリューストリームを運営する大規模な組織には、エンジニアリングの容量が機能、欠陥、リスク、負債にわたって実際どう配分されているかを一か所で見る、他に信頼できる方法がないからです。ツール統合に投資してください。手動の代替手段は実際の規模との接触を生き延びません。

政府。 フロー分布は、公共部門のエンジニアリング組織に、「なぜもっと多くの新しい機能性が出荷されないのか」という問いへの、擁護可能で、ビジネスに理解可能な答えを与えます。正直な答えが、容量のますます大きな割合がセキュリティ対応やレガシーの負債に向かっているというものであるときです。そのトレードオフを静かに吸収するのではなく、可視化し明示的にすることは、しばしば、このフレームワークが政府の技術指導者に提供する最も有用な単一のものです。

事例

企業。 ある大手保険会社の保険金請求プラットフォーム組織は、スプリント速度の報告に基づいて、自分たちが主に新機能を出荷していると信じていました。最初のバリューストリームマッピングとフローアイテムの分類の演習は、負債とリスクの仕事、その多くが10年前の中核システムからの文書化されていない技術的負債であったことが、実際にはエンジニアリングの総容量の半分近くを消費していたことを明らかにしました。これは、その仕事が常に一般的な「エンジニアリングタスク」の中に折り畳まれていたため、以前のどの報告も表面化させていなかった事実でした。この区分を経営委員会に提示することで、プラットフォームの歴史上初めて、専用の負債削減予算が確保されました。それまでは負債の仕事が、あらゆる機能要求に対して静かに競い続けていたのです。

政府。 ある国税当局のデジタルサービス部門は、着実なスプリント完了にもかかわらず、ある旗艦の市民向け機能がなぜ1年以上「進行中」だったのかを診断するためにバリューストリームマッピングを使いました。このマップは、そのバリューストリームが実際には、組織図には反映されていない3つの引き継ぎを伴う5つの別々のチームにまたがっていたことを明らかにし、フローアイテムの分類は、その機能の実際のエンジニアリング時間がその全フロータイムのごく一部にすぎず、残りはどの単一チームの自分自身のメトリクスでも見えないチーム間の引き継ぎの遅延によって消費されていたことを示しました。この部門は、その特定の製品ラインについて、組織図ではなくバリューストリームを中心に再編し、2四半期以内にフロータイムを大幅に削減しました。

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

Flow Frameworkを採用することからの見返りは、パイプライン指標では答えられない問いへの、擁護可能でビジネスに理解可能な答えです。エンジニアリングの容量は、経営陣が信じているとおりに配分されているか。上記の保険の例、容量のほぼ半分が以前は見えなかった負債の仕事に向かっていたことを表面化させたことは、組織が実際に自らの仕事を誠実に分類すると一般的に見られるパターンであり、その可視性は、「技術的負債のためにもっと時間が必要だ」という漠然とした要求が決してできなかったはずの投資をしばしば解き放ちます。

総所有コストは二つの場所に集中しています。最初のバリューストリームマッピングの演習、これを誠実に行うには本物のファシリテーションの時間が必要です。そして、フローアイテムのデータを手作業なしに最新に保つために必要なツール統合です。どちらのコストも、一度うまく行えば一度きりか保守の負担が低いものであり、このフレームワークを採用するよりも維持する方がかなり安くなります。

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

バリューストリームマッピングを、二度と見直されることのない一度きりのワークショップとして扱う。 組織が変わった瞬間にマップは古び、古びたマップに対して計算されたメトリクスは間違ったものを測定します。
並行した、手動で維持されるフローアイテムの追跡システムを構築する。 実際の作業量のもとで急速に劣化します。代わりに既存のツールに統合してください。
フローアイテムを受け入れ時点ではなく事後に分類する。 本トピックの中心にある操作のベクトルです。提供のプレッシャーの下で、チームは、フロー分布のグラフしか見ない利害関係者により生産的に見せるために、誰も明示的で目に見える決定をすることなく、負債やリスクの仕事を事後に静かに機能として再分類することができます。ガードレールは、結果が知られる前の受け入れ時点での分類を要求すること、そして分類されたアイテムのサンプルを、根底にある変更が実際に何をしたかと定期的に照らし合わせて監査することです。これは、本書のあらゆるメトリクスについてトピック1.2が求めるのと同じ監査の規律です。
フロー指標をエンジニアリングの内側だけにとどめる。 このフレームワークの主な優位性、つまりビジネスの利害関係者との共有語彙を放棄します。
実際のバリューストリームではなく組織図を地図に描く。 しばしば遅延の最大の原因であるチーム間の引き継ぎを隠します。
一つのバリューストリームで検証する前に組織全体でフレームワークを採用する。 根底にあるマップが正確であると一度も確認されなかったために、誰も信頼しないメトリクスへの大きな投資をするリスクがあります。

成熟度モデル

レベル1、開始: バリューストリームマップは存在せず、仕事はフローアイテムの分類のない一般的なチケットとして追跡されます。
レベル2、発展: 一つのバリューストリームがマッピングされ、フローアイテムは非公式に分類されますが、追跡は手動で一貫性を欠いて適用されています。
レベル3、標準化: フローアイテムの分類が既存のツールに統合され、主要なバリューストリームにわたって受け入れ時点で一貫して適用されています。
レベル4、管理: フロー分布はビジネスの利害関係者と定期的にレビューされ、組織が変化するにつれてバリューストリームマップは能動的に最新に保たれます。
レベル5、最適化: 組織はフローデータを使ってバリューストリームにわたってエンジニアリング投資を意図的に配分し、このフレームワークが以前は見えなかったトレードオフを可視化したために行われた特定の戦略的決定(負債削減予算、チームの再編)を指し示すことができます。

議論のためのアイデア

今日、推測することなく、私たちの旗艦製品について正確なバリューストリームマップを描けるでしょうか。
誠実なフローアイテムの分類は、前四半期の容量のうち何パーセントが機能に対して負債とリスクに向かったことを明らかにするでしょうか。
私たちのフロー指標は現在ビジネスの利害関係者に届いているでしょうか、それともエンジニアリングの内側にとどまっているでしょうか。
私たちのバリューストリームにおける、組織図には反映されていない最大のチーム間の引き継ぎは何でしょうか。

主な要点

ミック・カーステンの『Project to Product』によるFlow Frameworkは、提供パイプラインがどれだけ速く動くかだけでなく、どんな種類の価値がその中を流れているかを測定します。
チームやパイプラインではなくバリューストリームがこのフレームワークの測定単位であり、それを誠実に地図に描くことが、何かを計装するより前に来ます。
受け入れ時点でのフローアイテムの分類、事後ではなくは、本トピックの中心的な操作のベクトルに対するガードレールです。負債やリスクの仕事を、より生産的に見せるために静かに機能として再分類することです。
実際の作業量を生き延びない並行した手動の追跡システムではなく、フロー指標を既存のツール、Jira、Azure DevOps、GitHubに結びつけてください。
フローデータをビジネスの利害関係者に直接提示してください。内部のエンジニアリングダッシュボードではなくその会話こそが、パイプラインだけの指標に対するこのフレームワークの主な優位性です。

参考文献とさらなる読書

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018。
Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999。
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013。
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016。