2.2 フローアイテム:機能、欠陥、リスク、負債

概要と動機

フローアイテムはFlow Frameworkの作業単位であり、すべてのフローアイテムは4つの種類のうちちょうど一つに属します。機能、顧客に届けられる新しいビジネス価値あるいは能力。欠陥、ユーザーやテストによって見つかったバグに対する品質修正。リスク、ビジネスを守るセキュリティ、コンプライアンス、プライバシー、ガバナンスの仕事。そして負債、技術的負債、アーキテクチャの改善、将来の速度を可能にするインフラストラクチャの仕事です。トピック2.1は、この4つのカテゴリーが属するフレームワークを紹介しました。本トピックは、この分類法そのものを深く掘り下げます。なぜなら、これらのカテゴリーは、チームが自らの仕事を誠実かつ一貫してそこに分類したときにのみ価値を届けるからです。

フローアイテムの決定的な特性は、4つの種類にわたる配分がゼロサムゲームであるということです。任意の期間において固定量のエンジニアリング容量が存在し、機能に費やされた1時間は、負債、リスク、欠陥の仕事に費やされなかった1時間です。これはソフトウェア提供についての新しい事実ではありません。どのエンジニアリングリーダーも、容量が有限であることをすでに知っています。しかし、ほとんどの組織には、実際の内訳を見るための一貫した誠実な方法がありません。スプリント速度は種類にかかわらずストーリーポイントを数えます。消化されたバックログは、その背後にある仕事が新しいチェックアウトフローだったのか、3か月間の地味なセキュリティ対応だったのかにかかわらず、同じように見えます。フローアイテムは、特にその見えない内訳を可視化するために存在します。

大規模なチームにとって、この可視性は資源配分の会話の性質を変えます。エンジニアリングリーダーが「技術的負債のためにもっと時間が必要だ」という定量化されていない主張をする代わりに、フローアイテムの分類は実際の数字、たとえば負債が前四半期の容量の30%を消費した、を生み出します。これはビジネスの利害関係者と議論し、擁護し、意図的に調整できるものです。多くの同時並行の製品ラインを運営する企業や、新しい市民向け機能性とレガシーシステムのリスクとのバランスを取る政府機関は、どちらも「保守に時間を使いすぎている」という私的で非公式な感覚よりも、はるかにこの種の擁護可能で定量化されたトレードオフに依存しています。

重要な原則

すべてのフローアイテムはちょうど一つの種類に属する。 混ざった、あるいは曖昧な分類を許すのではなく、単一の分類を強制することが、この分類法を集計報告に使えるものにします。
配分は加算的ではなくゼロサムである。 機能により多くの容量を割けば、同じ期間において欠陥、リスク、負債に使える容量は必然的に少なくなります。
普遍的に健全な分布というものは存在しない。 成長期にある若い製品は、正当に機能へと偏るべきです。本物の技術的リスクを抱える成熟したシステムは、正当に負債とリスクの仕事へと偏るべきです。
この規律がなければ、負債とリスクの仕事は慢性的に過小報告される。 それは静かに起こる傾向があり、一般的な「エンジニアリングタスク」に吸収され、フローアイテムの分類がそれを表に引き出すまで続きます。
分類の質が、この分類法全体の価値を決定する。 一貫性なく適用された、あるいは事後に操作された分類法は、情報を与えるのではなく積極的に誤解を招く数字を生み出します。

推奨事項

各種類について書かれた定義を使い、受け入れ時点ですべてのアイテムを分類する

あなたの特定の文脈において、何が機能、欠陥、リスク、負債としてカウントされるかについて、簡潔で書かれた定義に合意し、新しい仕事がバリューストリームに入った瞬間に、完了後ではなく、その定義に照らして分類することを要求してください。事前に合意された定義は、ある仕事がどう見えたかという結果に基づいて事後に分類したくなる誘惑に抵抗します。これはまさに、本トピックがこの後すぐに直接名指しする操作のリスクです。

フロー分布を単一の一時点ではなく傾向として報告する

単一の期間の分布は、複数の期間にわたる傾向よりも少ないことしか教えてくれません。一つのアイテムの種類への着実な偏り、たとえば機能が上昇し続ける一方で負債が四半期ごとに静かに縮小していくことは、どの単一期間の数字よりもはるかに強い信号であり、通常、それは危機になる前に利害関係者に提起する価値のあるパターンです。

エンジニアリングだけでなくビジネスの利害関係者とともに意図的な目標分布を定める

プロダクトとビジネスの指導層とともに、あなたの特定のバリューストリームの現在の段階にとって健全な分布がどのようなものかを決め、その目標を既定で漂わせるのではなく定期的に見直してください。成長段階にある若い製品と、安定段階にある成熟したシステムは、正当に異なる健全な目標を持ちます。そして目標そのものが、エンジニアリングが静かに一人で決めるものではなく、交渉されたビジネスの決定であるべきです。

フローアイテムの分類を独立した証拠と照らし合わせて確認する

自己分類に依存しない指標、つまり流出欠陥率(トピック5.1)、技術的負債の測定(トピック4.5)、脆弱性管理の指標(トピック6.4)と、あなたのフロー分布を定期的に比較してください。「欠陥」と「リスク」のフローアイテムの割合が横ばいか縮小しているのに、欠陥や脆弱性が上昇しているなら、その不一致は、分類が現実からずれてしまったことを示す最も明確な、入手可能な信号です。

特に機能工場パターンに注意する

フロー分布が、四半期を追うごとに機能がほぼすべての容量を一貫して吸収しており、負債とリスクの仕事が名目的な割合を決して上回らないことを示しているとき、そのパターン(「機能工場」と呼ばれることもあります)は、通常、システムが本当に保守を必要としていないのではなく、負債とリスクが容量を奪われていることを意味します。このパターンは短期的には心地よく、後で高くつきます。根底にある蓄積が一度も可視化されなかったために、フロー分布のグラフには何の予兆もなく、やがて品質やセキュリティの危機として現れます。

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

アプローチ	長所	短所
正式な分類なし(一般的なバックログ)	プロセスのオーバーヘッドがない	負債、リスク、欠陥の仕事が見えないままになり、資源配分の決定を擁護しにくい
4種類のフローアイテム分類	容量配分を可視化し、利害関係者と交渉可能にする	受け入れ時点での規律と、種類ごとの書かれた合意済みの定義が必要
より細かい分類(多くのサブタイプ)	より診断的な詳細	より多くの分類の労力、利害関係者に説明すべきより多くの数字
事後の分類	適用しやすく、前もってのプロセス変更が不要	操作に非常に露出しやすく、分類は見栄えの良い方向へとずれていく

中心にある緊張関係は分類の規律とプロセスのオーバーヘッドです。4種類の分類法は意図的に粗く、あるアイテムを分類するのが議論ではなく数秒で済むほど粗いものですが、その粗さが成り立つのは、受け入れ時点で、書かれた定義に照らして分類する規律が本当に維持される場合だけです。この緊張を解消するには、分類法を正確にこの単純さ(4種類だけ、それ以上はなし)に保ち、追加の厳密さはすべて、実際の作業量のもとで崩れていくより精巧な分類の枠組みにではなく、(独立した証拠と照らし合わせる)監査の段階に投資してください。

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

もし私たちのチームが前四半期に出荷したすべてのものを分類したら、機能、欠陥、リスク、負債にわたる実際の内訳はどう見え、それは私たちの利害関係者を驚かせるでしょうか。ほとんどのチームは、この演習を誠実に行ったことがありません。すでに答えを知っていると仮定する前に、実際のデータでそれを試みてください。
私たちの特定の文脈において、何が機能、負債、リスクとしてカウントされるかについて、書かれた合意済みの定義があるでしょうか。それとも分類は、たまたまチケットにラベルをつけた人次第でしょうか。非公式で一貫性のない定義は、正確に見えるが実際には期間を通じて比較可能ではない数字を生み出します。
私たちのフロー分布は、誰も意図的にそう決めたわけでもないのに、着実に一つのアイテムの種類へとずれていったことがあるでしょうか。 ゆっくりとしたずれは、期間ごとには見逃しやすいものの、傾向としてプロットすれば明らかになります。もしデータがあれば複数の期間のデータを持ち寄り、正直にこのパターンを探してみてください。
私たちの製品の現在の段階にとって、健全なフロー分布はどのようなものであり、私たちは実際にビジネスの利害関係者とともにその目標に合意したでしょうか。ほとんどの組織は、この目標を明示的にしたことがありません。これは、実際の分布がそこからずれていったときにそれに気づくための共有された基盤がないことを意味します。
私たちのフロー分布は、流出欠陥率や未解決の脆弱性の件数のような独立した証拠と一致しているでしょうか。それとも調査する価値のある不一致があるでしょうか。ここでの不一致は、分類が仕事の実態からずれてしまったことを示す最も明確な、入手可能な兆候です。
私たちのチームの誰かが、提供のプレッシャーのもとで、負債やリスクのアイテムを静かに機能として再ラベル付けすることができるでしょうか。もしそうしたら、私たちは今現在それに気づくでしょうか。これが、本トピックの中心的な操作のリスクを直接述べたものです。実際に誰かが意図的にそうするかどうかだけでなく、現在のプロセスが実際にこれを捉えられるかどうかを話し合ってください。

業種別の視点

スタートアップ。 チーム全体がすでに誰が何に取り組んでいるかを知っているとき、正式な分類はしばしばオーバーヘッドのように感じられます。この規模で役立つ最低限のことは、単純に、計画の中で4つのカテゴリーを声に出して名指しすることです。そうすれば、機能の締め切りがプレッシャーを生むたびに負債とリスクの仕事が静かに優先度を下げられてしまうことがなくなります。このパターンは、コードベースとチームの両方が成長するにつれて悪く積み重なっていきます。

中小企業。 既存の追跡ツールの単一のカスタムフィールドやラベルで、専用のツール投資なしにフローアイテムの種類を捉えるのに十分です。受け入れ時点で一貫して分類する規律は、その背後にあるツールの洗練さよりもはるかに重要です。

企業。 フローアイテムの分類は、このフレームワークが規模において価値を発揮する場所です。なぜなら、多くの同時並行のバリューストリームを運営する大規模な組織には、容量が機能、欠陥、リスク、負債にわたって実際どう分かれているかを見る、他に信頼できる集計方法がないからです。ツールに統合された分類と、独立した証拠との定期的な照合に投資してください。手動の場当たり的な分類は、実際の組織規模との接触を生き延びません。

政府。 フロー分布は、公共部門の技術指導者に、なぜもっと多くの新しい市民向け機能が出荷されないのかと問われたときに、擁護可能で定量化された答えを与えます。正直な答えが、レガシーシステムのリスクと負債の負担が容量の正当な割合を消費しているというものであるときです。そのトレードオフを静かに吸収するのではなく、明示的にし交渉可能にすることは、定量化されていない「技術的必要性」への訴えよりも、監督機関との信頼を築く傾向があります。

事例

企業。 ある大手小売企業の電子商取引プラットフォームチームは、スプリント速度に基づいて、自分たちが安定した機能アウトプットを届けていると信じていました。最初の誠実なフローアイテムの分類演習は、「機能」が実際には完了した仕事のわずか40%しか占めておらず、負債、その多くが老朽化したチェックアウトシステムに関連していましたが、容量の3分の1近くを消費していたにもかかわらず、それまでどんな報告でもそのように名指しされたことがなかったことを発見しました。この区分を、負債の負担を裏づける上昇中の流出欠陥率とともにプロダクト指導層に提示することで、このチームが2年間、定性的な議論だけを使って求めても得られなかった、専用の近代化予算を確保しました。

政府。 ある州の自動車管理機関のデジタル免許発行チームは、根底にあるシステムの安定性に注目を集めた公開障害の後、初めて自分たちのバックログを分類しました。この演習は、主にセキュリティパッチからなる「リスク」の仕事が、目に見える市民向け機能を優先して繰り返し優先度を下げられ続け、前年を通じて容量の5%未満にまで縮小していたこと、そしてこのパターンがチームの標準的な報告の中では一度も見えなかったことを明らかにしました。この機関の指導層は、一般的な方針声明だけではなく、フロー分布のデータに裏づけられた、今後のリスク仕事の最低限の配分を義務づけるためにこの発見を使いました。

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

フローアイテムの分類からの見返りは、以前は定性的に議論され、しばしば利害関係者に最も目に見える仕事に負けていた資源配分の決定のための、擁護可能で定量化された基盤です。上記の小売の例、一般的な訴えではなく実際の容量データで近代化予算を確保したことは、この規律が確実に生み出すパターンです。具体的な数字は、「保守のためにもっと時間が必要だ」という一般的な印象よりも、はるかに退けにくいものです。

分類法とその定義が合意されれば、総所有コストは低いものです。分類は受け入れに数秒を加えるだけで、意味のあるプロセスの負担にはなりません。そしてそれを追跡するために必要なツール統合は、たいてい単一のカスタムフィールドやラベルです。本物の継続的なコストは、提供のプレッシャーのもとで誠実な分類を維持する規律であり、だからこそ独立した証拠との定期的な照合が、最初の採用と同じくらい重要なのです。

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

結果が分かってから事後に仕事を分類する。 本トピックの中心にある操作のベクトルです。提供のプレッシャーの下で、チームは、どの単一の決定もそれ単独では不誠実に見えることなく、事後に負債やリスクの仕事を静かに機能としてラベル付けしたり、曖昧なアイテムを分布グラフでより良く見える方の種類に寄せたりすることができます。ガードレールは、書かれた定義に照らした受け入れ時点での分類と、流出欠陥率(トピック5.1)や脆弱性の指標(トピック6.4)のような独立した証拠とフロー分布を比較する定期的な監査を組み合わせることです。これは、本書のあらゆるメトリクスについてトピック1.2が求めるのと同じ、独立した証拠に照らした監査の規律です。
機能に一貫してほぼすべての容量を吸収させ続ける(機能工場パターン)。 危機として表面化するまで負債とリスクの仕事を静かに奪います。
単一期間の分布を全体像として扱う。 傾向の見方が明確に明らかにする、ゆっくりとした累積的なずれを見逃します。
ビジネスの利害関係者なしに目標分布を設定する。 このフレームワークの主な価値、つまりトレードオフについての共有され交渉された理解を放棄します。
種類ごとに一貫性のない、あるいは文書化されていない定義を使う。 正確に見えるが実際には時間を通じて比較可能ではない数字を生み出します。
多くのサブタイプで分類法を過剰に作り込む。 比例した洞察を加えることなく、規律を損なう分類のオーバーヘッドを加えます。

成熟度モデル

レベル1、開始: 仕事は一般的に追跡され、フローアイテムの分類はなく、負債とリスクの仕事は報告の中で見えません。
レベル2、発展: 一部のチームは非公式にフローアイテムを分類していますが、定義は一貫性がなく、分類はしばしば事後に行われます。
レベル3、標準化: すべてのチームが、共有された書かれた定義に照らして受け入れ時点で分類し、フロー分布は傾向として追跡されます。
レベル4、管理: フロー分布は独立した証拠と定期的に照合され、目標分布はビジネスの利害関係者とともに意図的に設定されます。
レベル5、最適化: フローアイテムのデータは組織全体にわたる資源配分と投資の決定に直接情報を与え、指導層は、分類が以前は見えなかったトレードオフを明示的にしたために行われた特定の決定を指し示すことができます。

議論のためのアイデア

前四半期の仕事の誠実なフローアイテムの内訳は何を示し、それは誰かを驚かせるでしょうか。
4つのフローアイテムの種類それぞれについて書かれた定義があるでしょうか、それとも分類は誰が仕事にラベルをつけるか次第でしょうか。
私たちのフロー分布は、その背後に意図的な決定なしに一つのアイテムの種類へとずれていったことがあるでしょうか。
今日、私たちのフロー分布と照合できる独立した証拠には何があるでしょうか。

主な要点

フローアイテムは、機能、欠陥、リスク、負債という4つの種類のうちちょうど一つに属し、それらにわたる容量配分はゼロサムです。
普遍的に健全な分布というものは存在しません。 正しい組み合わせは製品の段階に依存し、ビジネスの利害関係者との意図的で交渉された目標であるべきです。
本トピックの中心的な操作のベクトルは事後の分類、つまり負債やリスクの仕事を事後に静かに機能として再ラベル付けすることです。ガードレールは受け入れ時点での分類に加えて、独立した証拠に照らした定期的な監査です。
特に機能工場パターン、つまり機能が一貫してほぼすべての容量を吸収することに注意してください。これは危機として表面化するまで負債とリスクの仕事を奪います。
フロー分布は傾向として最も価値があり、その最大の見返りは、それをビジネスの利害関係者と直接共有することから来ます。

参考文献とさらなる読書

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018。
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013。
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009。