Agile Release Train

足踏みを揃える原則: 局所の卓越より、全体の足踏みを揃えることによってより多くの価値を創出する。

– Don Reinertsen

アジャイルリリース列車概要

アジャイルリリース列車(ART)は、SAFeにおける価値の納品にかかわる主要構成要素である。それぞれのARTは、複数のアジャイルチームから構成される長期にわたる自己組織化するチームであり、協力して計画し全力を傾けて実行する(5~12チームからなる)仮想組織である。ARTは、企業の重要な価値のストリームを中心に構成され、エンドユーザーに利点をもたらすソリューションを構築することによって期待されたその価値を実現するという目的のためにのみ存在する。

ARTは、1つのビジョン、ロードマップ、プログラムバックログにより、複数のチームを共通の使命に向けて連携させる。プログラムインクリメント(PI)は、リズムと同期により、計画策定を促進し、WIPを制限し、発表に値するまとまった価値を提供し、一貫した振り返りを確実に行うための、開発の時間枠(デフォルトでは10週間)となる。PIの時間枠は、ポートフォリオレベルで検討を行ったりロードマップを作成する際の、思考の数量単位にもなる。各列車には、それぞれの反復において価値のある評価可能なシステム能力を継続的に定義、構築、テストするために必要な、専任の人とリソースが含まれる。列車は、現在および今後のユーザーおよびビジネスのニーズに応えるシステムをチームが構築するのに役立つ、アーキテクチャーや工学やユーザーエクスペリエンスの指針を提供する。

詳細

SAFeのプログラムレベルのチームや役割や作業は、アジャイルリリース列車を中心として構成される。このアジャイルリリース列車は、価値のストリーム価値を継続的なフローとしてインクリメンタルにリリースする、複数のアジャイルチームからなるチームである。

ソリューションの開発は標準のリズムで行われるが、列車チームは任意の時点でリリースを行うことができる(これについては「リズムに基づき開発する、随時リリースする」で説明する)。ビッグピクチャーに書かれている開発のリズムでは、PI計画セッションの後に4つの開発反復が続き、最後に1つの革新と計画(IP)の反復が行われている。SAFeではこの時間枠をプログラムインクリメントと呼ぶ。

ビッグピクチャーに示されたこのPIリズムは、参考にはなるが必ずしもこうでなければならないものではなく、1つのPI内でいくつの反復を行うかやIP反復にどれだけの時間を予定するべきかについての固定の規則はない。多くの企業ではPIの境界でソフトウェアをリリースすることを選択しているが、リリースもこのリズムに依存せず行うことができ、その判断はそれぞれの列車や価値のストリームに委ねられている。さらに、大規模なシステムでは、すべてを一度にリリースしなければならないわけではなく、ソリューションのさまざまな部分(サブシステム、サービスなど)をさまざまな時点でリリースすることができる。これについては「リリース」のページで説明する。

素早く価値を納品することに集中できるよう個々のチームに権限を移譲すると、指揮管理のモデルでは抑制されかねない生のエネルギーや生来のやる気や革新を解き放つことができる。しかしそれだけでは不十分である。チームには自然に局所最適化に向かう傾向があるためである。チームは要求されるものを顧客に納品するためにできるだけのことをするが、彼らに大域的な視点を持たせるのは困難である。ただし、利益を最大にするには全体最適化が必要なため、チームが共通の方向を向いて連携し、全体としてのチャンスに対応するためのより大きな力を出せるよう、ARTが手助けする。

主要概念

「アジャイルリリース列車」というメタファーは、次のようないくつかの主要概念を伝えるために使われている。

  • 列車は、信頼性の高いスケジュールに基づいて駅を発車し、次の目的地に到着する。これにより、固定のリズム、標準のARTベロシティー、予想可能な計画(、そして多くの場合にはリズムに基づくリリース)を実現できる。
  • プロトタイプ、モデル、ソフトウェア、ハードウェア、ドキュメントなどのすべての「貨物」は列車に載せられる。
  • 列車に必要なほとんどの人は、職務上どの組織に属しているかとは関係なく、フルタイムの専任である。参加したければ列車に乗る必要がある。

ARTによってリズムと同期を提供することで、チームの足並みを揃え、リスクと変動を管理することができる。これは以下の共通運営原則に基づいている。

  • アジャイルチームは、列車の動力源であり、フィーチャーやコンポーネントを定義、構築、テストできる機能横断的な自己組織化する実体である。
  • チームは、アジャイル宣言の原則とSAFeの価値および原則を受け入れてそれに従う。チームはSAFe、ScrumXP、XPのアジャイルプラクティスを使用する。
  • チームはローリングウェーブ計画を顔を合わせて頻繁に行う。
  • PIと反復の日付は固定である。品質は固定である。範囲は変更することができる。
  • 非中央集権的な計画によってチームが範囲を決定する。
  • チームは、長さが共通化された反復と標準化された見積もりによって、ARTレベルの見積もり、計画、統合を行う。
  • 列車に乗っているすべてのチームにまたがって継続的インテグレーションが行われる。
  • すべての反復でシステムデモを行って、統合が済んだARTレベルの動くソリューションを主な利害関係者に見せる。
  • 革新と計画の反復は、見積もりの保護帯域であり、PI計画、革新(ハッカソンなど)、継続的な教育、インフラ作業に割り当てられる時間である。
  • モデルやプロトタイプやその他のイネイブラーなどの特定のインフラコンポーネントの作業は、通常、開発に先だって行うべきである。

さらに、規模の大きい価値のストリームでは、複数のARTが協力して、ソリューションシステム能力という形態でより大きい価値を構築する。その場合、一部のART利害関係者は、ソリューションデモPI計画前/後ミーティングといった価値のストリームのイベントに参加する。

アジャイルリリース列車に関わる役割

アジャイルチームの他にも、次のような重要な役割がある。

アジャイルリリース列車の編成

アジャイルリリース列車の編成によって、誰が協力して計画を立て作業に当たるか、どのようなプロダクト、サービス、フィーチャー、コンポーネントを列車が納品するかが決まる。アジャイルリリース列車の編成はSAFeの「技」であり、考慮しなければならない点がいくつもある。

効率的な列車の規模

第一に考えなければならないのは規模である。効率的なアジャイルリリース列車は、通常、50~125人のメンバーから構成される。上限はダンバー数に基づいたものである。この数は、人が効率的で安定した社会的関係を築ける相手の人数の限界を示す。それより大きい列車も存在するが、その場合には次のような課題が大きくなる。

  • プログラムレベルのイベントの準備が複雑になる。
  • PI計画やシステムデモや検査と適応ワークショップを行うのに、期間の長い厳しい時間枠が必要になる。
  • 多くの依存関係を管理する必要がある。
  • プログラムバックログが大きくなり、プログラムインクリメントの待ち行列のサイズが増えてWIP(仕掛かり作業)が増える。
  • 使命に対する整合を取り、それを維持するのが困難になる。

繰り返すが、1つのARTの典型的な人数は50~125人である。

下限は、主に、大企業でSAFeを実施した経験によるものである。もちろん、50人に満たない列車でも、非常に効率的にすることもできるし(著者はそのような列車に属している)、従来のアジャイルプラクティスに比べるとアジャイルチームを連携させる上での利点が多い。ただし小さな列車では、多くの場合、状況に合わせてSAFeを変更して適用している。

価値のストリームの規模に応じたARTの編成

ARTの編成結果は、規模の制約に応じて、図1に示す3つに分かれる。

Figure 1. Organizing ARTs based upon value stream size
図1. 価値のストリームの規模に応じたARTの編成
  1. 複数の価値のストリームを1つのARTで実現できる場合:通常これは例外的な状況である。小規模の企業や、少ない人数で多数のプロダクトを構築する企業で発生する。
  2. 価値のストリームを1つのARTで実現できる場合:これが一般的な状況で、ARTと価値のストリームが一致するためもっとも管理が容易である。
  3. 価値のストリームが大きく複数のARTが必要な場合:この状況もシステム構築ではよく見られるが、後に示す余分な作業が必要になる。

大規模な価値のストリームの分割

大企業において、規模の大きな価値のストリームを複数のARTに分割する必要が生じるのは珍しくない。価値のストリームの分割は、技術でもあり、芸術でもあり、社会科学や組織科学でもある。以下に、大規模な価値のストリームをARTに分割する際の一般的なパターンを示す

  • ソリューションのシステム能力やフィーチャーの領域で分割(下記を参照)。
  • サブシステム(アプリケーション、コンポーネント、プラットフォームなど)で分割(下記を参照)。
  • 顧客や市場で分割。
  • 価値の部分集合に分割。フローや価値のストリームの各部分を有効にする。
  • その他に次のような点が影響することもある。
    • 列車は1つの主要プロダクトまたは主要ソリューションという目標に集中するべきである。
    • 相互依存性の高いフィーチャーやコンポーネントを担当するチーム同士は協力して計画や作業を行うべきである。
    • 場所を考慮することも重要である。可能な限り列車チームは同じ場所にいるべきである。少なくとも地理的な分散はできるだけ少なくするべきである。それにより計画関連作業やチーム間の協力が単純化されるからである。
    • 資金源。

列車を設計するにあたっては、トレードオフを注意深く検討する必要がある。一般的に、上記のさまざまなパターンを組み合わせなければならないことが多い。たとえば、複数のARTを含む規模の大きなストリームでは、システム能力とサブシステムの両方を使用する必要がある。次のセクションでは、この2つの一般的なパターンで列車を編成する際のトレードオフを取り上げる。

システム能力とサブシステムを中心とした列車の編成

ARTの主な編成パターンに、システム能力を中心とした編成と、サブシステムを中心とした編成の2つがある。その様子を下の図2に示す。たとえば、「顧客登録」というエンドツーエンドの機能に対応する列車を編成することもできれば(システム能力)、モバイルアプリケーションに対応する列車を編成することもできる(サブシステム)。

  • システム能力ARTでは価値のフローと納品速度が最適化される。通常はこれが好まれるが、アーキテクチャーの質が落ち、最終的にベロシティーが低下するのを防ぐには、技術ガバナンスが余計に必要である。
  • サブシステムARTでは、アーキテクチャーの堅牢性、最重要のコンポーネント、他の多くの要素で使われるコンポーネントが最適化される。しかし、依存関係を管理するために内容の調整をしっかり行ったり、適度なベロシティーを保つためにさまざまな列車に優先順位を付けたりする必要が生じることもある。
Figure 2. ARTs can be organized Capability and/or Subsystems
図2. システム能力やサブシステムを中心にARTを編成することができる

列車上のチームの構成

ARTの境界が決まったら、どのアジャイルチームが実際の価値の構築に携わるかが明らかになる。次の段階では、アーキテクチャー上/工学上の堅牢性とシステム品質を維持しながら依存関係と引き継ぎを最小限にしてベロシティーを最大化するという大きな目的に向けて、チームを構成する。以下の点に着目してチームを構成することができる。

  • フィーチャー:フィーチャーチームとは、ユーザー向け機能を中心に構成されたアジャイルチームである。各チームは、通常、エンドツーエンドのユーザー価値を納品することができる。フィーチャーチームは主に、 ユーザーストーリーリファクタリング及びスパイクに対処する。ただしその他に、技術ストーリーがバックログに含まれることもときどきある。
  • コンポーネント:コンポーネントチームとは、主な関心領域が特定のコンポーネントやコンポーネント群に制限されたアジャイルチームである。そのため、チームのバックログには、通常、(ユーザーストーリーではなく)技術ストーリー、リファクタリング、イネイブラーストーリー(スパイクなど)が含まれる。
  • その他:

ほとんどのARTでは、フィーチャーチームとコンポーネントチームが混在する。

  • 可能な限りフィーチャーチームを優先する。ベロシティーが高く依存関係が少なくなるためである。また、これはT字型スキルの育成にも役立ち、結果としてチームメンバー全員が目の前の作業に柔軟に対応できるようになる。
  • 再利用の機会が多い場合や、技術に高度に特殊化している場合、NFRが重要である場合には、コンポーネントチームを作成する。ただし、コンポーネントチームは、「各コンポーネントは明確に定義されたインタフェースを持つ潜在的に置き換え可能なシステムの部品である」という原則に従って仕事をしなければならない。それによって、モジュール性、関心の分離、再利用の容易性が保たれる。

ARTを「その他」(上記を参照)のものを中心に構成するのは一般に避けるべきである。結合度が高くなり、多くはフローが妨げられるためである。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[3] Gladwell, Malcolm. The Tipping Point: How Little Things Can Make a Big Difference. Little, Brown and Company, 2000.(邦訳:急に売れ始めるにはワケがある、SBクリエイティブ、2007 )

Last update: 12 September 2015