System Team

全体は部分の総和に勝る。

— アリストテレス

システムチームの概要

SAFeでは、アジャイルチームは独立なユニットではなく、より大きな価値を提供する責任を全般に負うアジャイルリリース列車(ART)の不可欠な一部である。アジャイルチームは列車のコンテキストで活動する。列車のビジョンを遵守し、他のチームと協力し、ARTの重要なイベントに参加する。チームと列車は分離できない。全体は部分の総合に勝る。

アジャイルへ移行中に、付加のインフラ作業は開発サイクルの終盤で1回のみで行うのではなく、頻繁に(時間毎、日次、週次)ソフトウェア資産と一緒に統合しなければならない。これを実現するために、システムチームと呼ばれる専門的なチームを1つ以上を組成することがよくある。これらのチームはシステムとソリューションの統合を支援し、進化するソリューションのデモを支援する。

詳細

役割の説明

システムチームアジャイルリリース列車価値のストリームにおける特殊なアジャイルチームである。継続的インテグレーションなどアジャイル開発環境インフラの構築と利用への支援、アジャイルチームからのコードの結合、エンドツーエンドのソリューションテスなどはこのチームの主要な責務である。また、システムチームは各反復終了時のシステムデモや、各プログラムインクリメント終了時のソリューションデモに参加するかもしれない。必要に応じ、頻度が高くなるかもしれない。システムチームは発展するエンドツーエンドソリューションの有効性と完全性に関する迅速なフィードバックを提供することによって、チームや他の利害関係者をサポートする。システムチームには、各リリース、及び大きな価値のストリームの連携を支援する特別の役割もあるかもしれない。

しかし、これらの作業はシステムチームとアジャイルチーム間で共有しなければならない。そうしないと、システムチームはボトルネックになりうるし、アジャイルチームも真の価値の提供に完全に対応できない。

大きな価値のストリームにおけるシステムチーム

大規模な複数ARTからなる価値のストリームでは、システムチームは非常に重要である。 大規模の場合、価値のストリームの範囲と複雑さに応じ、システムチームの組成は以下3つのパターンが観察されている。

  1. 各ARTは1つシステムチームを持つ。他の支援がなくて、システムの結合と妥当性検証が効果的に連携できる
  2. 価値のストリームレベルだけに1つシステムチームがある。ARTのために、責務を遂行できる
  3. 価値のストリームレベルとリリース列車内に、それぞれシステムチームがある

どのパターンを利用するかに関する判断は、価値のストリームの特定のコンテキストに大きく依存する。 一般的要素として、アジャイルチームの方向性(フィーチャーチームか、またはコンポーネントチームか)、価値のストリーム内のART構造(システム能力を中心に構築するか、またはサブシステムを中心に構築するか)、ソリューションアーキテクチャ、列車全体のブランチおよび統合ポリシー、システムのテスト容易性、開発インフラストラクチャなどがある。

責務

システムチームの主要な責務は以下である。

開発インフラの構築

よいインフラはARTの高いベロシティーをサポートするため、システムチームは

  • 継続的インテグレーション、自動化されたビルド、妥当性検証テストの自動ビルドを含むインフラを構築し、メンテナンスする。
  • ソリューションデモ、QAやユーザーテストなどのためのプラットフォームと環境を構築する。
  • 自動配置のためのプロダクト、ユーティリティ、スクリプトを作成する。
  • データやサービスプロバイダ、ホスティング設備など、サードパーティと連携するための技術的側面を促進する。

システムの結合

複雑なソリューションの場合、システムチームは以下のことを行わなければならない。

  • 結合対象、システム能力とフィーチャーを定義するために、価値のストリームレベルでのリリース計画策定事前及び事後リリース計画策定、及びバックログの手入れを参加する。
  • 適切なブランチモデルのための判断とポリシーを決定し、それらを維持することを支援する。
  • ソリューションレベルの結合スクリプトを実行したり、自動化が不可能あるいは適用されなかったところに関して、手動の結合を行う。
  • コンポーネントチームに協力し、コンポーネント内部のインタフェースを定義する。
  • 日々の活動を支援するために、他のチームのスタンドアップミーティングに参加する。

エンドツーエンドとソリューション性能テスト

システムチームはいくつかの自動化されたテストに関する責務を実施するかもしれない。

  • 新たな自動化されたテストシナリオを作成する。
  • 大規模データセットにまでテストシナリオを拡張する。
  • 個々のチームによって設計されたテストケースを順番付きのスイートにまとめる。
  • 新たなフィーチャーやストーリーのため、手動テストを実施したり、自動化されたテストを実行する。
  • 可能の場合、時間のかかるテストの優先順位付け、リファクタリング作業、再現テストスイートの実行を行う。
  • チームは自分自身が再現テストを実行できるように、再現テストスイートの作成に協力する。
  • 非機能要求(NFR)に対するシステム性能をテストしたり、システムとソシューションエンジニアリングとが協力し、システムの欠陥やボトルネックを識別する。

システムデモ

各反復における適宜の時期で、チームはシステムデモで利害関係者たちに現在の全体システムソリューションをデモしなければならない。同様に、価値のストリームはソリューションデモを通じ、結合を実施し、進捗を示す必要がある。

システムチームは通常、これらのデモの開催を支援する。また、新たなソリューション機能を確実にデモできるように、デモ環境が十分となるように支援する。

リリース

発展するソリューションに関して、システムチームは独自のスキル及び見方を持つことがしばしばある。このチームはシニアQA要員を含むかもしれないし、システムアーキテクト/エンジニアがチームメンバーの1人であるかもしれない。これらの役割は複数の反復にまたがってソリューションを見てきた上で、意図的な要求に満たすためにこれは何であるか、何をするか、どのようにする(しない)かを理解している。このような観点から、システムチームは直接的にリリース支援に関わり、DevOpsと密に協力し、列車のターゲット環境へリリースソリューションの準備、パッケージングとリリースを支援するために必要なことを行う。

ソリューション結合とテスト労力のバランスを取る

しかし、システムチームは、統合課題に対する完全な解決策ではない。アジャイルチームは自分たちが何を作っているのかに関するより大きな全体図の明確なビジョンを持たなければならない。さもなければ、一部アジャイルチームが局所最適化を実現できても、良好な経済的成果が得られない。プラクティスが適切に共有されることこそ効果的なシステム開発が成り立つ。例えば、もしシステムチームだけがNFRをテストし、個々のチームが軽量の性能テストさえも行なわなければ、全体のARTベロシティーは重要な品質テストをパスするために必要な手戻り作業によって低下するだろう。

同様に、もしアジャイルチームは自分とのインタフェースを持つコンポーネントを継続的に結合していない場合は、システムチームによる結合作業は、長く痛みを伴うプロセスになる。図1に示すように、ARTのベロシティーを最大化することは、アジャイルチームとシステムチームのバランス感覚が必要となる。

Figure 1. The optimum balance in terms of integration effort between Agile Teams and the System Team. With maturity and automation, the optimum point moves to the left.
図 1. アジャイルチームとシステムチームの統合作業に関する最適なバランス。成熟度と自動化度が高くなるにつれ、最適ポイントは左に移動する。

さらに知りたい場合

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

Last update: 14 September 2015