今回は、複数チームで効果的にコミュニケーション統制を取るしくみについてご紹介していきます。

今回解決する課題

今回解決する課題は次の2つです。

  • A-4：開発規模の小さなITシステムの開発方針を柔軟に変更できていたが、システムの規模が大きくなると、アジリティが低下してしまう
  • B-3：先行する競合他社の成功事例に、すぐに追随できていない

アジャイル開発、特にScrumを適用する場合には、原則的に10人以下のチームであることが求められます。しかしながら、システム規模や構成によっては10人以上で取り組む必要がありますし、その規模でアジリティの高い状況を作ることが求められるケースもあります。自分たちが望む構成で高いアジリティを保ちながらプロダクトをかたちづくり、アーキテクチャを構築していくには何らかの方法論が必要です。

今回は、複数のチームで進めていく上で高いアジリティを保つためのコミュニケーション方法について説明していきます。

複数チームで作業する際の弊害

同じ拠点で作業をしている場合、2～3チームならばチーム間の連携はアジャイルチーム内の行動と同様、個々人がコミュニケーションをとることでチーム間の障害を解消できるでしょう。しかし、目安として50人以上に増加すると、コミュニケーションパスが複雑化し、個人の把握できる範囲を超えるため、全体のパフォーマンスが下がってきます。また、関連するチーム全員を同じ拠点に集約することが難しくなり、自然とコミュニケーション不足が発生して混沌としてしまうケースもあります。

このような状態において各チームのタスクに依存関係がある場合、第12回で紹介したPI(Program Increment)プランニングで関係性を整理できたとしても、チームの作業遅延や優先順位の変更など、常に生じ得る変化に対してほかのチームが柔軟に対応しにくくなります。

依存関係のあるチームが1～2チームであれば調整できますが、あるタスクに関連するチームが数チーム、さらにその先に関連するチームが数チームと階層的に依存関係がある場合は、どこかで破綻しかねません。

SAFeでは、これらをマネジメントする役割としてリリーストレインエンジニアを設置しますが、ハブ型コミュニケーションではアジリティが上がらないことは、アジャイルを実践している方ならば周知のことでしょう。あるべきスタイルとしては、リリーストレインエンジニアが中心にはなりますが、各チームが自律的にコミュニケーションできる状態にすることが求められるようになります。

また、開発環境のトラブルや新規技術の調査など、チーム内の障害として対応していたことが、実はほかのチームでも同様に生じており、各チームで対処していた、というのもありがちです。SAFeでは、これらの統制を図り、全体最適化することで組織全体のアジリティを上げていきます。

複数チームを統合するためのイベント

SAFeでは、関連する複数チームが共通の目標を達成し、継続的に改善していくために、ART単位でPDCAサイクルを実現するための公式イベントを設定しています。

イメージ

ARTのイベント／出典：https://www.scaledagileframework.com/program-increment/

ここでは、チーム間のコミュニケーションにスコープを当て、「PO Sync」と「Scrum of Scrum(SoS)」について説明します。

PO sync

PO syncは、プロダクトマネジメントと各アジャイルチームのプロダクトオーナーを中心に、1時間以内のタイムボックスで1週間に1回以上開催されるイベントです。プログラムレベルのバックログリファインメントに位置付けられます。

PO syncでは、各チームの成果を統合したインクリメントに対し、以下のような観点で状況把握と次のアクションの方向性を調整します。

  • プログラムPI目標を達成するために順調に進んでいるか
  • プロダクト開発における問題（開発の進捗、外部環境によるニーズの変化、など）があるか
  • 今のPIにおけるフィーチャー(要件)のスコープや優先順位を変更するか
  • 次以降のPIで対象とするフィーチャーをどうするか（追加フィーチャーの内容、優先順位など）

なお、扱うフィーチャーは、プロダクト機能（business feature）だけでなく、技術検証や環境準備（enabler feature）も対象となるため、必要に応じてシステムアーキテクトも参加します。

Scrum of Scrum

Scrum of Scrumは、リリーストレインエンジニアと各アジャイルチームのスクラムマスターを中心に、1時間以内のタイムボックスで1週間に1～2回程度開催されるイベントです。PI計画で作成したプログラムボードを参照し、共通のマイルストーンとPI目標に対する各チームの進捗、および障害要因を共有することで、チーム間の依存関係を可視化／調整します。

また、各チームの障害に対して全体最適の視点から対応策を検討します。対応策の詳細は、タイムボックスの後に別途ミーティングを開催して決定します。SoSのアジェンダの例は次の通りです。

イメージ

SoSのアジェンダの例示／出典：https://www.scaledagileframework.com/program-increment/

ScrumでDaily Scrumでの確認事項を挙げつつも、チーム連携がもたらす副作用を確認する点が印象的な特徴です。

なお、「すでにチームが成熟している」といった理由からこのイベントを必要としない場合は、前出の図「ARTのイベント」で示すように「ART sync」としてScrum of ScrumとPO syncを合同で開催するケースもあります。

*　*　*

今回は、複数チームを統制するためのイベントを中心に解説しましたが、複数チームの体制論や、技術的な統制も重要です。複数チームでの体制論については、拡大に適したチーム体制論のナレッジ「Organizing Agile Teams and ARTs: Team Topologies at Scale」がありますが、こちらは別の機会に紹介します。

また、技術面で複数チームの依存性を軽減するには「Microservices」「Anticorruption Layer」など、複数チームの責務分割を具体化する実装パターンがあります。Microservicesについては本誌連載「AWSで作るマイクロサービス」で解説されているので、興味のある方は合わせてご確認ください。