The whole is greater than the sum of its parts.

—Aristotle, Paraphrased from Metaphysics [1]

システムチーム

システムチームは、継続的デリバリーパイプラインの開発とメンテナンスを含め、アジャイル開発環境の構築とサポートを支援する専門のアジャイルチームです。さらに、アセットの統合、エンドツーエンドのソリューションテスト、DevOpsのマインドセットとプラクティス、デプロイメント、リリースオンデマンドをサポートする場合もあります。

詳細

現代のソフトウェアシステムは複雑化が進み、それが顧客にバリューを提供する速度、品質、フローに著しい影響を与える可能性があります。今日のインフラストラクチャを大きく特徴付けているのは、「diverse to a fault (欠点と呼べるほど多様)」 [2] であることです。このため、きわめて複雑なソフトウェア開発ツールチェーンに関連する問題の管理と、顧客バリューのデリバリーの両方に時間を割く必要があり、開発者はどこに重点的に取り組むべきかを見失いがちです。

さらに、人には誰しも認知限界があり、頭の中に保持できる情報の量は限られています。システムチームを設ける主な理由は、チームが新しいソリューションバリューを提供する能力を損なうことなく、ARTのスピード、品質、生産性を向上させることです。アジャイルチームの仕事の負荷は、かつてないほど高まっています。新たなソリューションバリューの創出に加え、チームには継続的にソリューションをテスト、デプロイ、リリースし、場合によっては運用することが求められます。効率を高め、規模の経済を実現するためには、ARTが自分たちの時間の大半をソリューション開発に集中できるよう、システムチームの助けが必要になる場合があります。

システムチームは、アジャイル開発環境インフラストラクチャの構築とメンテナンスを通じて、ARTのベロシティを加速し、開発チームの認知負荷を減らします。以下に、例を示します。

継続的デリバリーパイプラインツールチェーンを作成し、メンテナンスする。このツールチェーンは、継続的な統合、構築 (検証テストを含む)、デプロイメント、リリースの自動化を含む。
開発、ユーザー受け入れテスト、ソリューションデモ、デプロイメント、本番のためのプラットフォームと環境を整備する。
ホスティングサービスやデータサービスのプロバイダーなどのサードパーティとのコラボレーションにおける技術的要素を支援する。
ARTがインフラストラクチャに対する意図的なアーキテクチャを持ち、チームが標準ツールとDevOpsプラクティスを活用するようにする。

責任

図1は、システムチームの5つの主要な責任分野を示しています。ここではシステムチームの責任として紹介していますが、これらはシステムチームとアジャイルチームで共通です。そうでなければ、システムチームがボトルネックとなり、アジャイルチームがエンドツーエンドのバリューのデリバリーを十分に遂行できない可能性があります。以下のセクションでは、これらの各分野について説明します。

図1 システムチームの主な責任分野

注: ARTによるCDPツールチェーンの自動化が進み、単独および協力してバリューを提供する方法についての学びが深まるにつれ、専任のシステムチームの必要性は減少すると考えられます。時間の経過とともに、システムチームの知識がARTへと広まり、チームはより広範な責任の共同オーナーシップを引き受けるようになります。ただし、下のソリューショントレインのセクションで説明するように、大規模なソリューションの場合には、依然として1つまたは複数のシステムチームが専門知識の担い手となる可能性が高くなります。

開発インフラストラクチャの構築

堅牢な技術インフラストラクチャはARTのベロシティを高めることから、システムチームは次のことを行う場合があります。

CDPツールチェーンの作成とメンテナンス – 継続的な統合、構築および検証テスト、デプロイメント、リリースツールの自動化を含みます。
プラットフォームと環境の整備 – クラウドまたはオンプレミスで開発、ソリューションデモ、ユーザー受け入れテストのための環境を整備します。
コラボレーションの技術的側面の支援 – データ、サービス、サプライヤー、ホスティングプロバイダーなどのサードパーティとのやり取りの窓口を務めます。

ソリューション統合のサポート

複雑なソリューションでは、システムチームによるソリューションの統合のサポートが必要です。次のようなアクティビティが含まれます。

バージョン管理 – バージョン管理とマネジメントのための判断や方針を決定し、維持するのを支援します。
統合スクリプトの作成と実行 – ソリューションレベルのビルドスクリプトおよび統合スクリプトを作成して実行するか、まだ自動化されていない場合には手動で統合します。
各種シンクイベントへの参加 – システムチームの仕事のほとんどは、他のアジャイルチームから来ます。このため、さまざまなシンクイベント (POシンク、コーチシンク、アーキテクチャシンク、チームシンクなど) に参加することで、トレインのニーズが深刻な緊急事態に発展する前に、遅れずに対処できます。

エンドツーエンドのテストの支援

システムチームは、アジャイルチームをサポートする一部のテスト業務も行う場合があります。

新たな自動テストシナリオを作成する – 多くのチームは、機能をエンドツーエンドでテストするためのインフラストラクチャや知識を持っていないと考えられます。そこでシステムチームが、そのための環境を提供し、チームが新機能や既存の機能に対応した自動テストを作成できるようサポートします。場合によっては、より複雑なテストシナリオの一部をシステムチームが記述することもあります。
データセットを提供する – 繰り返し利用できるテストデータを作成し、バージョン管理の下でメンテナンスします。
テストケースを整理し、管理する – 個々のチームが設計したテストケースを、秩序立ったテストスイートに整理し、時間のかかるテストに優先順位をつけ、テストインフラストラクチャを改善します。
手動テストを実施する – 複雑なシナリオ (エンドツーエンドや探索的テストなど) や一部のシステム間共通のフィーチャーなど、まだ自動化が実現できない場合に、チームが手動テストを行うのをサポートします。
システム統合テストを実施する – 開発チームが異なるシステム間の統合を検証できるよう支援します。ソフトウェアコンポーネント間やソフトウェアとハードウェア間の統合を含め、最終的なプロダクトを形成するさまざまな統合をテストします。
スモークテストを作成する – ビルド検証テストの作成を支援し、開発者が自分たちのビルドを迅速にかつ単独で検証できるようにします。
テストソリューションのパフォーマンス – NFR (セキュリティ、信頼性、パフォーマンス、ユーザビリティなど) のテストの作成および実行をサポートし、システムアーキテクトとソリューションアーキテクトがシステムに不足している部分やボトルネックを特定できるよう支援します。

システムデモとソリューションデモのサポート

ARTは各イテレーションの終わりにシステムデモを実施し、本番に近い環境 (通常はステージング環境) で完成したソリューションをテストして評価します。本番に近いインフラストラクチャとデータを使用した環境でソリューションをテストし、ステークホルダーからフィードバックを受け取るためです。ソリューションデモもこれと同様に、複数のARTとサプライヤーによる開発の成果を結集して披露し、顧客およびその他のステークホルダーにバリューを提供します。

システムチームは、システムデモおよびソリューションデモの計画、準備、実施において、ARTやソリューショントレインをサポートします。

デモを計画する – アジャイルチームと協力して、各イテレーションの最後にデモをする内容を定め、そのために必要な環境とインフラストラクチャを準備します。
アセットを統合する – アジャイルチームが作成したアセットやアーティファクトの統合をサポートします。
エンドツーエンドのソリューションデモを実施する – プロダクトマネージャーやプロダクトオーナーなどによる、主にエンドツーエンドのシナリオでのデモの実施をサポートします。
デモ環境をセットアップし、テストする – 新たなソリューション機能のデモを確実に行えるよう、必要な技術環境を準備します。また、新たなソリューションインクリメントごとに、新しいインターフェース、サードパーティのコンポーネント、シミュレーションツール、その他の環境アセットを含むデモ環境の拡張機能の追加が、システムチームに求められる場合があります。

システムチームがトレインをサポートして、タイムリーなケイデンスでシステムデモを行うのに必要な (DevOps、CDPなどへの) 投資ができるようにすることもよくあります。

リリースのファシリテート

システムチームは、ソリューションの計画、準備、デプロイ、リリースにおいてARTとソリューショントレインをサポートします。こうしたサポートには、以下が含まれます。

リリースガバナンス – ARTステークホルダーによるソリューションのリリースの計画、管理、ガバナンスを支援します。また、アジャイルチームが規制基準、業界標準をはじめとする関連基準とコンプライアンスを確実に満たせるようサポートします。
リリースに向けた準備 – DevOpsおよびCDPアクティビティの一環として、ソリューションをパッケージ化してデプロイします。これには、フィーチャーのオンとオフを切り替えるフィーチャートグルなどのさまざまなテクニックの使用が含まれます。
ソリューションのリリース – トレインがソリューションをエンドユーザーに一度にあるいはインクリメンタルに、または同じ顧客の異なるセグメントにリリースできるよう支援します。
安定化と運用 – 運用チームと協力して、機能要件と非機能要件 (NFR) の両面で、ソリューションが問題なく機能するようにします。
測定 – 新たにリリースした機能によって意図したとおりのバリューを提供できているかどうかを測定する手段を整備して定量化し、CDPの健全性と効率をアセスできるよう、トレインをサポートします。
学習 – さまざまなソースからフィードバックを収集し、次のCDPループに備えられるようにします。

ソリューショントレインの中のシステムチーム

ソリューショントレインの構造を必要とする、大規模で、多数のARTを擁するデベロップメントバリューストリームの場合、大規模な統合やリリースの課題をサポートするためにシステムチームが不可欠です。このときのシステムチームの構成パターンは、デベロップメントバリューストリームのスコープと複雑さに応じて、主に次の3通りがあります。

各ARTにシステムチームを1つ設けて、ソリューションの統合と検証を調整する
ソリューショントレイン全体で1つのシステムチームを設け、さらに各ARTに個別のシステムチームを設ける
ソリューショントレイン全体で1つのシステムチームを設けて、そこに含まれるすべてのARTに対して責任を果たせるようにする

どの編成パターンを使用するかは、コンテキストに応じて判断します。判断の要素には、デベロップメントバリューストリーム内のARTの構造、ソリューションのアーキテクチャ、ポリシーのブランチングと統合、システムのテスト可能性、開発インフラストラクチャなどが含まれます。

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

システムチーム単独では、CDPツール、インフラストラクチャ、統合の課題に対するソリューションにはなりえません。DevOpsやCDPの実装には、共有ビジョンに向かってベクトルを合わせた、他のアジャイルチームとのコラボレーションが必要です。効率的なソリューション開発では、複雑さを軽減するため、知識、ベストプラクティス、共通のインフラストラクチャおよびツールの共有が求められます。

ARTのベロシティを最大限に高めるには、アジャイルチームとシステムチームの間に最適なバランスを作り出す必要があります。それを図で示したのが図2です。成熟と自動化が進むにつれ、両チームの責任の最適な統合ポイントは左にシフトし、チームはより高いレベルの自律性と責任を達成できます。

図2 統合の取り組みの最適なバランス

詳しく学ぶ

[1] Aristotle. Metaphysics. Translated by W.D. Ross. CreateSpace Independent Publishing Platform, 2012.

[2] O’Grady, Stephen. The Developer Experience Gap. RedMonk, October 6, 2020. Retrieved October 10, 2023, from https://redmonk.com/sogrady/2020/10/06/developer-experience-gap/

最終更新: 2023年10月10日