リーンのゴール: 持続可能な最短のリードタイム。
顧客、人々と社会に最高の品質と価値を
リーンの家

ボスは1人しかいない。顧客だ。彼らがどこかよそで金を使うだけで、わが社の全員を首にすることができる。

Sam Walton

価値のストリームの概要

価値のストリームは、SAFeで価値を理解し納品するための、組織の主要なメタファーである。それぞれの価値のストリームは、システムの定義、開発、配置というプロセスの長期にわたる一連のステップであり、これによって、会社や顧客やエンドユーザーに対してある種の価値の継続的なフローがもたらされる。価値のストリームは、アジャイルリリース列車(リーン-アジャイルな原則およびプラクティスを実施することで、開発を単純化し、不必要な引き継ぎや手順をなくし、より早く価値を納品することを目的とした、仮想の組織)によって実現される。価値のストリームは、バリューストリームマッピングのリーンなツールを使用して行う系統だった分析や改善に役立つ。

詳細

リーンとアジャイルの手法には共通点が数多くあるが、その中でも重要なのは、それぞれが継続的な価値の納品にしっかりと的を絞っている点である。その価値は、エンドユーザーや顧客や社内ビジネスプロセスが新しいシステム機能のビジネス上の利点を手にすることができてはじめて達成できる。そしてこれが、価値のストリームという長期にわたる価値のフローを中心にSAFeがまとまるための大きな原動力となる。

Figure 1 Value Stream

図1. 価値のストリーム

価値のストリームはアジャイルリリース列車によって実現される。価値のストリームの中で価値を構築し納品するために多数(10以上)のチームが必要な場合には、複数のリリース列車が作成され、それが連携して最終的な価値を納品する。それぞれのリリース列車は、仮想の組織またはソリューション用に作成された組織であり、具体的な価値のフローを定義し開発し納品するという1つの目的のためだけに存在する。ただし、価値を中心に組織を作成するには、まず価値を理解する必要があり、そのためにはおそらく重要な分析が必要になる。

価値のストリームの発見

一部の組織(ほとんどの小さい組織はここに含まれる)では、価値のストリームを発見するのは簡単な作業である。自分たちが販売するソフトウェア関連のプロダクト、サービス、ソリューションがそれにあたるからである。しかし、組織の規模が大きくなると、価値のフローが、さまざまなアプリケーションやサービスに、分散した組織の数多くの部分に、社内外を問わずさまざまな種類の数多くの顧客に関係するため、その作業はどんどん複雑になる。配置の済んだシステムを何百も抱え、山ほどの社内外の顧客やビジネスプロセスのサポートを行っている、非常に大きなIT会社では、価値のストリームはまるで見えてこないかもしれない。さらに、これまでITの資金をプロジェクトに対して割り当ててきている場合には、この大きな問題があいまいになる傾向がある。急を要するさまざまな取り組みのためにプログラムやプロジェクトが構成され、より大きな目的のコンテキストは推測でしかなくなるか、多くの(おそらくは矛盾した)推測の下に埋もれてしまうからである。そのような場合には、価値のストリームの発見は、完全にビジネスコンテキストに基づいた重要な分析プロセスであり、その結果として、その後リーン-アジャイルへ転換するための基盤ができあがる。発見すると、それを中心に組織を作成し、それを理解して分析し、新しい手法やプラクティスを使って価値をより早く納品できるからである。

価値のストリームを洗い出すための検討事項

企業における本当の価値のフローを理解することは、具体的なビジネスのコンテキストの中でなければ対処できない難問だが、実際にどのようなコンテキストでSAFeが適用されるかを我々があらかじめ知ることはできない。ただし、アジャイルやリーンへの変革を推進する人たちや、SAFeプログラムコンサルタント(SPC)や、この転換に着手しているリーン-アジャイルなリーダーと一緒に仕事をする中で、次の表1に示すような事柄を検討すれば、価値のストリームを発見できる、あるいは少なくとも発見のプロセスを開始できることに我々は気付いた。

一般的な検討事項 今後数年間で市場においてビジネスを差別化するための、進行中または予定されている、比較的大きなソフトウェア関連のビジネス目標、テーマ、取り組みにはどのようなものがあるか。
社外の顧客は、自分たちにとっての価値のフローをどのように表現または認識しているか。(ヒント: 会社のWebサイトのカテゴリを見るとよい。)
現在の取り組みのうちで、既に30人、50人、70人、またはそれ以上の開発者やテスト担当者が協力して実施しているものはどれか。また、フィーチャーやコンポーネントが相互に強く依存し合っているものはどれか。
独立ソフトウェアベンダー向けの検討事項 企業が現在販売しているプロダクト、システム、サービス、ソリューション、スイート、パッケージにはどのようなものがあるか。
IT部門向けの検討事項 提供している主なビジネスプロセスにはどのようなものがあるか。
社内のどの部門をサポートしているか。
それらの部門は、社内外のどのような顧客に対してサービスを提供しているか。自分たちが提供する価値をそれらの部門はどのように表現しているか。
今後1年間で対象とするプロセス、費用、KPI、業務改善の取り組みには主にどのようなものがあるか。
組み込みシステム向けの検討事項 提供している主なシステム運用機能にはどのようなものがあるか。
実装または対処している重大な意味を持つ非機能要求にはどのようなものがあるか。

表1. 企業における価値のストリームを洗い出すための検討事項の例

「腎臓」の発見

価値を洗い出したら、次のステップとして、その価値が組織のどこで作り出されているかを理解する。というのも、リーン-アジャイルな取り組みのターゲットとなる人やプロセスや資産はそこで見つかるためである。通常、アジャイルに転換する前の大規模な組織は、機能(プロダクトの管理、開発、テストなど)ごとのサイロにまとまっている。さらに、人は必ず複数の場所に分散していて、場合によっては複数の国で働いている。また、アジャイルは新しいものではないため、アジャイルなチームとアジャイルでない個人やチームが同じ価値のストリームに参加している。それは問題ない。最初にしなければならないのはそのような人やチームを丸で囲むことであり、そうすれば現在その価値を納品している仮想組織が定義できる。ある企業では、その結果は図2のような形になった。

図2. 腎臓の発見とは、価値のストリームに必要な人やチームやその他のリソースを洗い出すためのメタファーである

(面白いような面白くないようなメモ: 実世界を分析してできあがる図1の線の形から、我々はこのプロセスを婉曲的に「腎臓の発見」と呼んでいる。また、初めて転換を行う人が相手の場合には、冗談で「心配しなくても、最初に必要な腎臓は1つだけだから!」とも言う。)

リリース列車の編成

アジャイルリリース列車は、SAFeにおける組織、運用、および価値の納品にかかわる主要構成要素である。これは、複数のアジャイルチームから構成される、自己組織化および自己管理するチームであり、共有する使命に対して継続的に整合を取り、相互依存を自分で管理し、継続的な価値のフローを達成する。理想的には、上で特定した価値のストリームそれぞれを1つのリリース列車にできれば、それで終わりである。ただし、効率的なリリース列車の規模は、図3に示すいくつかの要因によって、たいていは50人から100人に制限される。

図3. リリース列車の規模を制約し、最適な規模を決めるいくつかの要因

ダンバー数は、非常に重要な1つの考慮事項を表す。動的に変化する困難なビジネス目標に向けて助け合って努力しようという、列車に乗った人たちの個人的および業務上のモチベーションが保たれた、効果的な人の輪を作成しなければならないからである。

価値のストリームを特定した後、この情報によって、次の3つのいずれかの結論が得られる。

  1. 必要な人数が最適な範囲に収まるなら、することは(比較的)簡単で、価値のストリーム自体が1つのアジャイルリリース列車になる。
  2. 必要な人数が最適な範囲より少なければ、価値のストリームは、a) 小さめのアジャイルリリース列車にするか、b) 別の列車に組み込んで組織やガバナンスを単純化することができる。
  3. 最適な数を超えていれば、価値のストリームを複数のアジャイルリリース列車に分割する必要がある。その様子を図4に示す。分割は簡単な問題ではなく、考慮しなければならない主な点として、列車間の相互依存を最小化するための地理的な配置と組織設計の最適化、場所やさらには予算のメカニズムなどが挙げられる。詳しい指針は、連携の記事に記載する。

このようにしてついにリリース列車という仮想組織を特定できたら、次はチームのトレーニングを行い、アジャイルリリース列車を発車させなければならない。これについては、実装で詳しく説明する。

価値のストリームの予算編成

プログラムポートフォリオ管理は、リーン-アジャイルな予算編成の原則に基づいて、価値のストリーム内のリリース列車それぞれに予算を割り当てる。価値のストリーム内の各列車の予算の合計は、価値のストリーム全体への投資を表す。ビジネスの状況が変化して、列車から列車へリソースを移動したり、それぞれの価値のストリームに対する投資を増減させる必要が生じれば、予算は随時調整される。

バリューストリームマッピング

価値のストリームを洗い出し、それを中心にリリース列車を構成することには、もう1つ、大きな目に見える利点がある。それぞれの価値のストリームが、顧客にとって特定および測定しやすい名前の付いた価値のフローになることである。そのため、価値のストリームを体系的に改善して、納品のベロシティーと品質を向上することができる。そのための理想的なツールが「バリューストリームマッピング」である。リーン生産方式から生まれ、シックスシグマにも組み込まれているバリューストリームマッピングは、プロダクトやサービスを作成するために必要な情報のフローを文書化、分析、改善するためのツールである。ソフトウェア開発へのこのツールの適用方法は、ポッペンディーク[参考文献1]らによって解説されているため、詳細を知りたい場合はそちらを参照してほしい。次の図5は、大規模ソフトウェア組織の実際のバリューストリームマップを示したものである。一部、独自の要素は目立たせてある。

図5. バリューストリームマッピングの例/出典: ポッペンディーク(参考文献1)

要約すると、バリューストリームマッピングによって、衝撃的だが当を得た次のような結論が得られる。

ソフトウェア開発におけるタッチタイム(価値を付加する時間)は、顧客にソフトウェアを納品するまでにかかる全時間のごく一部(5~10~20%)である。時間のほとんどは、引き継ぎや遅延に費やされる。

企業内のソフトウェア開発作業だけに注力していても、確実に生き残るだけのビジネス結果を得られるとは限らないのは明らかである。より広い視点で観察して、大きな遅延に着目しなければならない。そのため我々は、リーン-アジャイルなリーダーの道具箱にはバリューストリームマッピングが不可欠であり、それを定期的に適用して企業がより確実に持続可能な範囲での最短のリードタイムを達成できるようにしなければならないと考えている。


さらに知りたい場合

[1] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2007.(邦訳:リーン開発の本質、日経BP社、2008)

Last update: 25 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.