nav-portfolio-coordination

連携の概要

価値のストリームが1つのアジャイルリリース列車(ART)で実装できるのであれば、複数のチームから構成される自己組織化および自己管理するチームに、作業を連携させるための構成要素を追加する必要はない。しかし、価値のストリームが大きくて1つのARTで実装できない場合には、価値を納品するために複数のARTが必要になり、通常は機能面や技術面、場合によっては人の面でも依存関係が生じて、それを日常的に管理しなければならない。この場合、エンドユーザーにとっての価値を納品できるかどうかは、内容管理統合、およびリリース連携にかかっている。

詳細

連携の必要性

1つの価値のストリームで複数のアジャイルリリース列車(ART)が必要な場合、価値のフローを得るには、列車間の依存関係を管理したり、価値のストリームのビジョンが効果的に実現されるよう気を配る必要がある。連携は、比較的簡単に行える場合もあれば、役割やプロセスを追加しなければならない場合もある。価値のストリーム内の列車自体が列車間の依存関係を管理できればよいが、それは常に可能であるとは限らないし、経済面から見て効率的であるとも限らない。次の2つの例はこの状況を表すものである。

  1. ある企業では、1,000人以上のアジャイルな実務者が、1つの目的に特化した1つのコードベースに対して主に作業を行っている。このコードベースは、300以上の個別の出荷可能なデバイスを作成するために使われる。この例では、20ほどの個別のARTが、さまざまなエンドユーザーフィーチャーや技術コンポーネントに対して作成されているが、1つのARTだけでは、あるいは少数のARTが協力しても、エンドツーエンドの価値を納品することはできず、納品するにはまず他のソリューション要素と統合しなければならない。そのため、出荷可能なソリューションを構築するために、最終的な統合とテストのための組織が必要となる。非常にアジャイルな会社ではあるが、ソフトウェア資産を個別に構築した後で、追加の作業が必要である。
  1. ある価値のストリームは、400人程度の実務者が必要で、主として1つのプラットフォーム上で動作し、はっきりと区別できる十数個のサービスを構築している。これらのサービスは、直交する(横断的な)「バンドル」にまとめられて販売される。各バンドルは、十数個の具体的な縦割りの市場のいずれか1つに対応する。各バンドルには、さまざまなサービスの、ほとんど共通するさまざまなフィーチャーが必要である。サービスを構築する列車がそのサービス自体の効果や品質を検証することはできるが、最終的なエンドツーエンドのテストが実行可能になるのは、市場に出せるソリューションセットとしてサービスがまとめられた後である。

最初の例では、パッケージ化とリリースのプロセスは数多くの組み合わせが存在する複雑なものになるため、列車間で幅広い連携が必要である。2番目の例では、用意したサービスから顧客が使用するバンドルへとマッピングするために、最初に内容を連携させバンドルを検証する必要が生じる。企業がSAFeを使って継続的に拡大しているときには、このような複雑な状況に対処するメカニズムが欠かせない。

SAFeでは、システム思考とフローに基づく原則を使用して、大規模な価値のストリームに伴う複雑な問題に対処する。企業のポートフォリオのこのような大規模構成要素の構造と連携に関する一般的な指針はSAFeが提供しているが、その原則を自分の会社の具体的なビジネスコンテキストにいつどのように適用するかを判断するのは、リーン-アジャイルなリーダーの責任である。

リズムの整合と同期化

最初の段階は比較的簡単である。価値のストリームの中で計画点、同期点、および統合点が共有されていると、内容と統合の連携は非常に単純になる。また、進捗測定の信頼性を上げるにはやはり動くソフトウェアを基に測定しなければならないので、動くソフトウェアを定期的に確実に作成できるよう調整しなければならない。1つのART内に複数のチームが存在する場合はチームとプログラムインクリメントのリズムを同じにする(プロダクト開発フローの原則: 入れ子になったリズムを複数で調和させる[1])必要があるのと同様に、同じ価値のストリーム内のARTのリズムはどれも同じにすることをSAFeでは推奨している。その様子を図1に示す。

Figure 1. Program Increments and Sprints Aligned Across ARTs in the Value Stream

図1. 同じ価値のストリームに属するどのARTも、プログラムインクリメントとスプリントのタイミングを一致させる

こうすることで、価値のストリームが全体として反復を行うことができ、同期点と統合点を事前のかなり早い段階で定義できる。システムを全体としてとらえることで、計画策定やインクリメントおよびリリースの実施をART間で同期し、複数のARTにまたがるシステムデモでソリューションを定期的に評価し、プロセスについて検査と適応のセッションを実施する。どのプログラムインクリメントも、価値のストリーム全体に対応する動くソフトウェアの、価値のある目に見えるインクリメントである。

組織構造

価値のストリーム内で必要な連携のレベルは、価値を納品するための列車の構造に大きく依存する。ART定義時の主な目標は、依存関係のほとんどがそれぞれのART内に収まり、ARTをまたがった連携は最小限で済むような構造を構築することである。これはつまり、価値の納品のプロセス全体の中で、それぞれのARTができるだけ多くのステップを実施できるようにするべきだという意味である。

ARTは、ソリューションのサブシステムに対して作成することも、フィーチャー領域に対して作成することもできるが(図2を参照)、フィーチャー領域に対して作成すると1つのフィーチャーのエンドツーエンドの価値の納品をもっとも早く行うことができるため、この方法が望ましい。ただし、状況によって、この方法が常に可能であったり最適であるとは限らない。たとえば、さまざまに異なるプラットフォーム技術に対応しなければならない可能性もあるし、共同所有が成熟していなかったり、誰かがコードの一部を変更してシステムが予想外の動作をしたときにそれに対処できるだけの自動テストが整っていない場合には、複数のプラットフォームにまたがる1つのコードベースで価値のストリーム全体が動いていると、ART間の結合が著しく強くなり、システムレベルで不具合や遅延が生じたり予想できない動作をすることがある。そのような場合には、一部のARTをサブシステムの境界内で動かした方が効率が良いことがある。

Figure 2. ARTs can be organized around subsystems or business areas depending on context

図2. ARTは状況に応じてサブシステムまたはビジネス領域に対して作成する

さらに、価値のストリームの規模が大きい場合には、通常、フィーチャーに対応するARTとサブシステムに対応するARTの両方が必要になる。

プラットフォームART

最後にもう1つ考慮しなければならない状況がある。規模の大きな価値のストリームでも、1つのプラットフォーム上で動作する場合は幸運である。利点は明白だ。チームメンバーの使用しているプログラミング言語、技術、インフラ、自動処理およびCM/CI環境が全員共通であれば、価値の開発はずっと速く行うことができる。さらに、ソリューションの納品先の顧客もプラットフォームは同じなので、さまざまな顧客に必要な共通の機能をさまざまなプラットフォームで動作させなければならない場合に発生する組み合わせ分岐の問題(死のマトリックス)を回避できる。

ただし、不利なのは、数百人(場合によっては数千人)の開発者が、基本のプラットフォーム機能を素早く拡張しなければならないことである。実際に、それができれば理想的であるが、プラットフォーム自体のガバナンスが存在しない場合や、特定の要素が時間、トランザクション、技術、セキュリティなどの面で他と異なっていて非常に重要な場合には、リスクが高すぎたり、そもそも実現可能でなかったりする。

そのような場合には、プラットフォームARTを作成して動くプラットフォームコード(フィーチャー、ユーティリティ、サービスなど)をそこで提供し、それを価値のストリーム内の他のARTで使用するという方法が一般的である。そのプラットフォームARTは、プログラムインクリメント(PI)1つ分ほど先行して作業を行い、他のARTがその後のPIで必要とする機能を提供する必要があるかもしれない。

もう1つの方法は、プラットフォームコードベースを社内でオープンソースとして作成し、適切なチェックイン/ガバナンスモデルを使用することである。成熟しているプログラムの場合には、こちらの方が適していることが多い。(この方法でLinuxやApacheを開発できるなら、社内で同じことができないわけはないだろう。)

連携のさまざまな側面

価値のストリームの構造は、ビジネスコンテキストや、ARTの構造と成熟度、さらには技術スタックに応じて、場合により大きく異なる。価値のストリームによっては、同じ1つの大規模なコードベースに対して作業しなければならず、すべてのアジャイルリリース列車が非常に結合度の高い環境で同期的に稼働しなければならない。あるいは、各列車で構築しているのはそれぞれが比較的独立したサブシステムであるが、何を構築するか、どうリリースするかの面で整合が必要な場合もある。現実的な例を見ると、連携が必要になる側面が複数あり、価値のストリームのレベルのリーン-アジャイルなリーダーの主な仕事の1つは、その側面を理解して連携を行うために必要な明示的なプロセスを作成することだということが分かる。

SAFeのビッグピクチャーには、連携が必要になるかもしれない主な側面として、内容統合リリースの3つが挙げられている。ただしその他にも、ソリューションアーキテクチャーインフラ配置の共通の方法にも注意しなければならない場合がある。2つのシナリオを検討する必要がある。

ケースA: ほとんどまたはすべての作業をART自体で行うことができる
ケースB: 多大な連携および価値の付加を追加で行わなければならない

ケースAには、すべての列車にまたがった連携が必要だけれども、それらの列車のリリース管理チームで完全に管理することが可能なリリース管理作業が該当する。この場合、価値のストリームレベルでのリリース管理の役割を追加しなくて済む可能性がある。ただし、同じ列車でも、他の側面に関しては、連携のために追加の外部プロセスが必要になる可能性はある(UIチームが定期的に集まって、複数の列車に共通のルックアンドフィールを調整するなど)。

このページ冒頭の2つの例は、ケースBの顕著な例である。ガバナンスや指針が必要であり、多くは複数の追加の利害関係者が関与する。たとえば、価値のストリームの経済面を向上するためのアーキテクチャー上の共通の構成要素がある場合には、価値のストリームレベルでソリューションアーキテクトが必要になるだろう。役割自体だけでなく、アーキテクチャー関連の取り組み用に価値のストリームレベルのバックログを導入することにもなり、実装は完全に非中央集権的に行いながらも、ソリューションレベルのアーキテクチャー滑走路は中央集権的に作成することの価値が際立ってくる。

次の表1は、2つのケースにおける連携の側面と、それぞれのケースで検討すべきプラクティスの提案(と必要であれば追加の役割)をまとめたものである。

側面 説明 ケースA ケース B
内容 価値のストリームのART群が同期的に取り組まなければならない主な経済面の優先事項は何か? ARTのプロダクト管理者が管理する。リリース計画の準備や手短なデモなど、ARTをまたがったセッションが追加で必要になる場合もある。 価値のストリームレベルのシニアプロダクト管理者の役割が必要である。経済面の優先度を反映した価値のストリームレベルのバックログが必要になる場合もある。
統合/テスト ソリューションのエンドツーエンドの統合およびテストをどのように処理するか? ARTのアジャイルチームとシステムチーム。列車をまたがった特別な分岐方針が必要になる場合もある。 列車の作業の他に価値のストリームレベルのシステムチームが必要になる場合がある。
リリース 列車をまたがった連携が必要なリリース可能なフィーチャーセットは何か? ARTのリリース管理チームが管理する。リリースおよび管理についての列車をまたがった打ち合わせが必要になる場合がある。 中央集権的なリリース管理チームによる対処が可能である。
アーキテクチャー 今後のビジネスの優先順位やシステムの品質について、ソリューションアーキテクチャー、技術スタック、技術の使用可能性に関連して想定されている主な事柄は何か? 列車のシステムアーキテクトによって管理される。 ソリューションレベルのアーキテクトが必要である。価値のストリームレベルのアーキテクチャーの取り組みのバックログや、アーキテクチャー滑走路が必要になる場合もある。
インフラ 開発、ステージング、本番稼働にどのようなインフラを使用するか。それらの環境をどのように同期させるか? ARTのシステムチームおよびDevOpsチームによって管理される。 価値のストリームレベルのシステムチームおよびDevOpsが必要である。
配置 どのように顧客に価値を配置するか? 共有の検証手順が必要になる場合もある。 価値のストリームレベルのDevOps。ARTは、複雑な本番環境の代理となるステージング環境で作業をする。

 

ほとんどのSAFeの価値のストリームでは、AとBが組み合わさっている。たとえば、ある価値のストリームでは、内容とアーキテクチャーを連携させるために価値のストリームレベルの役割を置いているが、リリース管理、インフラ、統合、テスト、および配置は価値のストリームが自身で連携を行う。その様子を図3に示す。

Figure 3. An Example of Value Stream Level Roles

図3. 価値のストリームレベルの役割の例

価値のストリームレベルで発生する特別な役割の人たちの多くは、通常のプログラムのイベントや作業に参加する必要がある。たとえば、ソリューションレベルのプロダクト管理およびアーキテクトは、リリース計画検査と適応にビジネス責任者として参加するべきである。さらに、連携を行うには、価値のストリームレベルで次のような追加のイベントが必要になるかもしれない。

  • リリース計画の準備
  • リリース管理ミーティング
  • 価値のストリーム内の全RTE向けのスクラムオブスクラムズ
  • ARTをまたがった統合ソリューションデモ

アンチパターンに注意!

価値のストリームレベルで構成要素を追加することは多くの場合に欠かせないが、正しく適用することが大切である。価値のストリームレベルの作業はすべて、価値を納品するプロセスのうち、合理的に考えて可能な限り多くのステップを列車自体が行うという前提で追加しなければならない。それを抜きに価値のストリームレベルの役割やチームを追加していくと、プロセスや指揮管理の意思決定があっという間にウォーターフォール化してしまう。気を付けなければならないアンチパターンを以下に挙げる。

  • 統合とテストを価値のストリームレベルでしか行わない。統合とテストを価値のストリームレベルでしか行わない。前提が逆でなければならない。ARTが、できるだけ多くの統合とテストを行い、ソリューションのうち合理的に考えて可能な限り多くの層まで担当するべきである。価値のストリームレベルのシステムチームが受け持つのは、列車では十分に手が届かない側面だけである。これは品質の作り込みに不可欠である。
  • 価値のストリームレベルで要求と設計を詳細化する。上記の6つの側面の中に内容とアーキテクチャーも含まれてはいるが、ジャストインタイムで詳細化することで制御を非中央集権化するよう努力しなければならない。この場合、全体的な方向性は価値のストリームレベルで決定するが、そこからはARTが引き継ぎ、次のレベルの具体化を行う。そうでなければ、結果的に価値のストリームで低いレベルまで範囲を確定するはめになり、価値のフローやアジャイルさが大幅に損なわれかねない。
  • 開発環境と本番環境の差異が大きい。多くの場合、ARTが変更を本番環境に直接反映させることは実際的に不可能だが、列車用に同等の開発環境またはステージング環境を作成して維持できるよう、価値のストリームは最大限の努力をするべきである(DevOpsを参照)。これは、最終的に大きな遅延を引き起こさないために重要である。プログラムの反復がリリースサイクルより速い場合には特に重要になる。
  • ARTサイロ。ARTは改善したり最適化することが可能であるしそうするべきであるが、それにはソリューションレベルで気を配る必要がある。そのため、価値のストリーム全体で上級管理者が協力することが不可欠である。

 Last modified  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.