nav_Value-Streams

持続可能な最短のリードタイム。人と社会にとっての最高の品質と価値。

– リーンの家

 

価値のストリームの概要

価値のストリームは、価値を理解し整理し納品するためのSAFeの主要構成要素である。それぞれの価値のストリームは、顧客に価値のフローを継続的に提供するために企業が使用する、長期にわたる一連のステップである。SAFeポートフォリオの第一の役割は、一連のソリューション開発作業(開発の価値のストリーム)に資金を提供して育成することである(この開発作業には、エンドユーザーに価値を直接納品するものも、他のビジネス(運用)の価値のストリームをサポートするものも含まれる)。価値のストリームの特定と最適化は、リーン-アジャイルな企業にとって非常に重要なスキルである。

価値を中心に組織を構成すると、学習が早くなる、市場投入までの時間が短縮される、品質が向上する、生産性が向上する、ソリューションが意図した目的に沿ったものになるなど、組織に多大な恩恵がもたらされる。SAFeでは、まず価値のストリームを理解し、それからSAFeのアジャイルリリース列車(ART)を編成してそれを実現するという方法で、価値を中心にした組織構成を行う。ARTで価値のストリームを実現する方法は、SAFeの「技」であり科学である。

さらに、価値のストリームは、バリューストリームマッピングを使用して行う系統だった分析や改善に役立つ。このバリューストリームマッピングは、遅延や付加価値のない作業を特定して対処するのに使われ、結果として持続可能な最短のリードタイムを達成するのに役立つ。

詳細

リーンとアジャイルの手法はどちらも継続的な価値の納品を極度に重視するが、その価値は、エンドユーザーや顧客や社内ビジネスプロセスが新しいソリューションシステム能力のビジネス上の恩恵を手にすることができてはじめて達成できる。リーンでは、さまざまな価値のフローを特定し理解することが、企業全体の業績を向上するために最も重要な(実際には出発点となる)ステップである。結局のところ、何をどうやって納品するかを企業が明確に思い描いていなければ、改善のしようがないのである。

簡単に説明したが、このような背景が大きな原動力となって、SAFeでは価値のストリームという価値のフローを中心に開発ポートフォリオが組織されている。

価値のストリームとは、価値を納品するための長期的な一連のステップであり、概念や顧客の注文から実体のある成果を顧客に納品するところまでを含む。

図1は、価値のストリームの骨格である。

Figure 1. Anatomy of a value stream
図1. 価値のストリームの骨格

価値のフローは、顧客の発注書や新しいフィーチャーの依頼のような重要なイベントがきっかけとなって始まる。そして、出荷、顧客の購入、ソリューションの配置などによって価値が納品されると終了する。途中のステップは、この快挙を企業が達成するために行う作業である。価値のストリームには、作業を行う人、開発または運用するシステム、そして情報や物のフローが含まれる。きっかけから価値の納品までの時間がリードタイムである。リードタイムを短縮すると市場投入までの時間も短くなる。これが重点項目である。

価値のストリームの種類

SAFeのコンテキストにおいて、企業にはたいてい2種類の価値のストリームが存在することを、システム構築者は意識しておく必要がある。運用の価値のストリームには、社内外の顧客に対して物やサービスを提供するためのステップが含まれる[2]。これによって会社はお金を稼ぐ。開発の価値のストリームには、新しいプロダクトやシステムやサービスのシステム能力を開発するためのステップが含まれる。ソリューションプロバイダが販売用のプロダクトを開発し、販売も直接行う場合(小規模なSaaS会社など)のように、この2つが同じであることもある。その場合には、開発と運用が同じなので、価値のストリームは1つだけでよい。

しかし、大規模なIT会社などの場合には特に、両方の種類の価値のストリームを理解することが欠かせない。開発の価値のストリームが運用の価値のストリームの入力となるからである。その様子を図2に示す。

Figure 2. Development value streams build the systems that operational value systems use to deliver value
図2. 開発の価値のストリームがシステムを構築し、それを運用の価値のストリームが使って価値を納品する

SAFeの第一の目的はシステムを構築する人のために指針を提供することだが、リーンなシステム構築者であれば、最終的な価値のフローをまず理解することで、システムを構築し最適化して最終結果を前倒しできるようにする。そのためには、SAFeで実施する最初のステップの1つとして、価値のストリームを特定しなければならない。さらに、開発の価値のストリームにとって非常に重要な要求(機能だけではなくシステムや企業のアーキテクチャーも含む)の多くは、運用の価値のストリームから直接生じたものである。

価値のストリームの特定

組織によっては、価値のストリームの特定は簡単な作業である。多くは開発や販売を行うプロダクトやサービスやソリューションがそのままそれにあたるからである。しかし、組織の規模が大きくなると、その作業はどんどん複雑になる。価値のフローが、さまざまなアプリケーションやサービスに、分散した組織の数多くの部分に、社内外を問わずさまざまな種類の数多くの顧客に関係するからである。たとえば非常に大きなIT会社では、価値のストリームが複数の部門や組織を通って流れたり、配置済みの多数のシステムをまたいでいる可能性がある。そのような場合には、価値のストリームの発見はビジネスコンテキストに基づいた重要な分析作業であり、その結果として、リーン-アジャイルへ転換するためのもっとも基本的な土台ができあがる。

価値のストリームを特定するための検討事項

企業における実際の価値のフローを理解することは、具体的なビジネスのコンテキストの中でなければ対処できない難問である。表1に示すような項目を検討すると、価値のストリームの発見に役立つことがある。

一般的な検討事項 市場においてビジネスを差別化するための、大きなソフトウェア、システム、ソリューション関連の目標にはどのようなものがあるか。
社外の顧客は、自分たちが受け取る価値のフローをどのように表現または認識しているか。
現在の取り組みのうちで、相当数の開発者やテスト担当者が協力して実施しているものはどれか。
独立ソフトウェアベンダー向けの検討事項 企業が販売しているプロダクト、システム、サービス、アプリケーション、ソリューションにはどのようなものがあるか。
組み込みシステムおよびサイバーフィジカルシステムを構築する場合の検討事項 企業が販売しているプロダクトやシステムにはどのようなものがあるか。大きいサブシステムやコンポーネントは何か。提供している主なシステム運用機能にはどのようなものがあるか。
実装または機能拡張を行っている重要な非機能要求にはどのようなものがあるか。
IT部門向けの検討事項 提供している主なビジネスプロセスにはどのようなものがあるか。
サポート対象の社内部門はどこか。
それらの部門は、社内外のどのような顧客に対してサービスを提供しているか。IT部門が提供する価値をそれらの部門はどのように表現しているか。
対象とされているプロセス、費用、KPI、業務改善の取り組みには主にどのようなものがあるか。

表1. 企業における価値のストリームを特定するのに役立つ検討事項

価値のストリームの定義用テンプレート

価値のストリームを特定したら、それぞれについてさらに特徴を記述して、理解を深める。表2に示すのは、ある1つのテンプレートに運用の価値のストリームの例を記述したものである。

名前 顧客の注文
説明 モバイルまたはWebから顧客がすばやく一貫したやり方で注文できるようにする。
顧客 小~中規模の会社
きっかけ 顧客からの新しい注文または注文の更新
入力 新規注文の詳細(顧客情報を含む)
出力 出荷担当への出荷依頼、会計担当への請求情報
関係者/関連項目 社内の顧客注文ワークフローおよび担当者、SAP注文管理、ヘルプデスク、モバイル/Web注文入力アプリケーション

表2. 価値のストリームの定義用テンプレートに運用の価値のストリームの例を記入したもの

境界をまたがる開発の価値のストリーム

価値のストリームを特定したら、次のステップとして、それを実現するためのアジャイルリリース列車(ART)の編成方法の検討を開始する。このARTには、価値のフローを強化するのに必要なすべての人やその他の資産が含まれる。分析時には、まず、その価値が組織のどこで作り出されているかを理解しなければならない。というのも、人やプロセスやシステムはそこで見つかるためである。その際に、開発の価値のストリームが多くの境界をまたいでいることが明らかになる。企業が今そのような組織になっているのには、これまでの経緯、職務上の都合、中央集権化による効率の向上、買収、地理上の都合など、さまざまな理由がある。結果として、価値の納品に役立つシステムを継続的に開発および拡張していくのに必要な一連のイベント全体を、本当の意味で理解している人が誰もいないことになりかねない。さらに、改善の試みは機能的/局所的な改善に集中しがちで、一部の機能やステップは最適化できても、エンドツーエンドのフローが最適状態に及ばないことがある。

価値のストリームは寿命が長いという性質を持っているため、リーンな組織では異なる考え方をしなければならなくなる。それに対処するために、企業は、システム思考を適用し、結果として、フローを改善するためにシステムのさまざまな部分がどのように協調する必要があるかを理解することになる。通常、大規模な組織は職務を中心に組織化されている。さらに、人は複数の場所、複数の国に分散している。しかし、価値はそのような境界をまたがって移動する。その様子を図3に示す。

Figure 3. Value flows across functional, organizational, and geographic boundaries
図3. 価値は機能、組織、地理上の境界をまたがって流れる

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

I値のストリームを特定し、組織内のフローを理解することは、価値の納品を改善するための重要なステップである。これによって、リーン-アジャイルな予算編成を実施する機会も得られる。この予算編成により、オーバーヘッドや摩擦を大幅に軽減し、さらにフローを加速させることができる。

これをサポートするために、SAFeの各ポートフォリオには一連の開発の価値のストリームが含められ、そのそれぞれに独自の予算が割り当てられる。プログラムポートフォリオ管理は、リーン-アジャイルな予算編成の原則に基づいて、各列車の予算の管理を手助けする。時間が経ってビジネスの状況が変わると、価値のストリームそれぞれの予算は必要に応じて調整される。これについては予算のページで詳しく説明する。図4は、さまざまな開発の価値のストリームそれぞれに割り当てられた独立した予算を示す。

Figure 4. Each development value stream is allocated its own budget
図4. 開発の価値のストリームごとに独自の予算が割り当てられる

アジャイルリリース列車による開発の価値のストリームの実現

価値のフロー(とその価値を納品する人やシステムがどこにあるか)を理解したら、企業は次に、フローを強化するためにアジャイルリリース列車をどう適用するかの検討を始める。ARTは、仮想組織であり、複数のアジャイルチームから構成されるチームであり、境界をまたいで作業して納品を加速するという明確な目的のために組織される。ARTの本質と目的については、 アジャイルリリース列車のページで説明している。重要な1つの結論は、ARTの作業がもっとも効率的に行われるのは人数が最大で100~150人のときだという点である。この制約を考慮すると、価値のストリームとARTの組織上の関係は、次の3つが考えられる。

  1. 複数の価値のストリームを1つのARTで実現できる
  2. 価値のストリームが1つあり、それを1つのARTで実現できる
  3. 価値のストリームが大きいため複数のARTが必要である

それぞれの例を後のセクションで説明する。

複数の価値のストリームを持つART

小さな会社の場合を考えてみる。主な価値のストリームはWebサイトである。これは無料で公開され、そこで販売するコースウェアが会社の収益となる。コースウェアは、開発してWebサイトに掲載される新しいコンテンツがきっかけとなって作成される。この例の時点では、この会社は合計50人未満の人でそのビジョンを実現できている。この場合、2つのまったく異なる価値のストリームが存在するが、それを1つのARTで遂行できている。その様子を図5に示す。

Figure 5. Small, independent software vendor with two value streams and a single ART
図5. 2つの価値のストリームと1つのARTを持つ小規模な独立ソフトウェアベンダー

上の価値のストリームは新しいコンテンツの知識がきっかけとなる。この知識はWebサイトの更新や新しいコースウェアとして現れる。

注:このケースは大きな企業ではあまり見られない。また、挙げた例でも、これを2つの小さいARTで実施することもできる。しかしそうするとARTをまたがる依存関係ができてしまい、それを基本のART計画とガバナンスのプロセスの外で管理する必要が生じる。さらに、それぞれの価値のストリームの価値のフローを検討することで、会社は正確な納品を行うための見識を得られている。そのため、両方を1つの価値のストリーム「フレームワークとコースウェア」に統合しても有益とは思えない。このモデルの別の例に、ずっと大きい会社がある。100以上のハイテクプロダクトを出荷し、600人ほどの開発者を雇用している。この会社は、共通性や依存関係が大きいプロダクトをグループにまとめ、それぞれのプロダクトグループに対してARTを編成している。ただし、各プロダクトは独立したエンドユーザー価値を納品し、それぞれに予算が割り当てられている。

1つの価値のストリームを持つART

2番目の例は、複数の市場向けに無人搬送車を構築する中規模メーカーである。重要な市場の1つがアミューズメントパーク業界である(バハアドベンチャーライドの例を参照)。社員の数は200人未満だが、軌道システムはサプライヤーに依存している。この場合の価値のストリームは2つあり、1つは乗り物とサプライヤー担当の軌道、もう1つはライド管理システムである。2つの価値のストリームはそれぞれ1つのARTによって実現される。ライド管理システムが別の価値のストリームなのは、異なる部門の予算で動くからであり、このグループではこのシステムを他の業界に応用したバリエーションも販売しているからである。この様子を図6に示す。

Figure 6. Medium-size manufacturer with value streams, two release trains, and a Supplier
図6. 複数の価値のストリーム、2つのリリース列車、1つのサプライヤーを持つ中規模メーカー

新しいシステムはどれもまったくの特別注文なので、新しいアドベンチャーライドの注文をきっかけにして価値のストリームが作成される。さらにそれがきっかけとなって、レールサプライヤーへの注文が行われる。

複数ARTからなる価値のストリーム

3番目の例は、「ビッグデータ」のIT会社で、開発/配置担当者は900人を超え、さらに運用担当者が数百人いる。車両やモバイルデバイス向けのマッピングデータとアルゴリズムを作成している。価値のストリームは1つだと考えているが、開発は6つのARTで行っている。その様子を図7に示す。

Figure 7. Big Data IT shop with a single value stream organized into six ARTs
図7. 1つの価値のストリームを6つのARTで組織化したビッグデータIT会社

この場合、企業の価値のストリームには、データを準備、編集、正規化し、使いこなす運用担当者も全員含まれるが、ARTは開発チームとそれを支える役割だけで構成される。

価値のストリーム内のアジャイルリリース列車の連携

図7から興味深い疑問が湧いてくる。ART間に何らかの依存関係が存在すると想定すると、企業はその作業をどう連携させて1つの総合的なソリューションセットを作成するのだろうか。これには、相当な協力が必要になる可能性がある。共通の価値のストリームのバックログ、新しい横断的システム能力の実装、追加のシステム統合、追加の役割や責任、PI計画およびPI計画前/後作業についての特別な配慮、程度も種類もさまざまなDevOps のサポートなどである。これは大規模なリーン-アジャイル企業で発生する主要な問題の1つである。

幸い、1つの価値のストリーム内で複数のアジャイルリリース列車を連携させる方法は、価値のストリームレベルページで主題として取り上げている。

ポートフォリオ内の価値のストリームの連携

もちろん、多くの重要なポートフォリオには複数の価値のストリームが含まれる。これらは設計上できるだけ独立させておくべきだが、それぞれの価値のストリームに企業の目標と足並みを揃えさせることで企業全体が前に進むには、おそらくある程度の連携が必要になる。これについては連携のページで説明する。

バリューストリームマッピングによる市場投入までの時間の短縮

最後になったが、価値のストリームを特定し、それを中心にリリース列車を編成することには、もう1つの大きな利点がある。それぞれの価値のストリームが、顧客にとって特定および測定しやすい価値のフローになることである。そのため、価値のストリームを体系的に改善して、納品のベロシティーと品質を向上することができる。たとえば、図6のライド管理システムの価値のストリーム/ARTが常にクリティカルパスになり、車両の出荷準備が済んでもライド管理ソフトウェアの準備ができていないとしたらどうだろうか。これでは遅延コストが大きくなってしまう。

この場合、ライド管理ARTはバリューストリームマッピング[3]を適用してシステム全体を通したステップとフローを特定し、図8のようなフローを記述する。

Figure 8. Ride management system value stream mapping example
図8. ライド管理システムのバリューストリームマッピングの例

チームはこれを見て、価値を付加するタッチタイムが、最終結果を納品するまでにかかる時間全体のごく一部でしかないことにすぐに気付く。結局のところ、新しいフィーチャーを作成する作業には11時間しかかかっていないのである。それなのに納品できるようになるには7週間もかかる。時間のほとんどは、引き継ぎや遅延に費やされている。彼らは一生懸命働いていて、それが効率的であることもタッチタイムを見ると明らかだが、それでもシステムを通した全体のフローは要望を満たせていない。コーディングやテストの速度を上げても役に立たない。それよりも、システム的な目で見て遅延に重点的に対処するべきである。

価値のストリーム内の遅延を減らすことは、常に、市場投入までの時間を短縮するための一番の近道である。


Learn More

[1] Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2014.(邦訳:トヨタが実践する価値創造の確かな進め方 リーン製品開発方式、日刊工業新聞社、2014)

[2] Martin, Karen, and Mike Osterling. Value Stream Mapping. McGraw Hill, 2014.

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

Last update: 4 October, 2015