「SAFe」とは（その6）：SAFeのイベント

今回は、SAFeの概要解説の締めくくりとして、SAFeで定義されている「イベント」について、最も特徴的で重要なイベントである「PIプランニング」を交えて説明します。SAFeがどのようにして複数のチームでアジリティを保ったまま開発を行うのか、組織全体のAlignment（ベクトル合わせ）を行うのかを見ていきましょう。

組織全体のタイムボックス：プログラムインクリメント（PI）とイテレーション

スクラムでは1回の開発期間（スプリント）の長さや、その中で行う各イベント（セレモニー）のタイムボックス（上限時間）を設けますが、それと同様にSAFeにもタイムボックスが存在します。

SAFeにおける一番大きなタイムボックスは「プログラムインクリメント（PI：Program Increment）」です。1つのPIは、開発作業などのための複数の「イテレーション（スクラムにおけるスプリント）」と、ARTの改善やイノベーション、次のPIのプランニングなどを行う「IP（Innovation and Planning）イテレーション」で構成されます。

通常、1イテレーションは2週間で、1つのPIに含まれるイテレーションの数は任意です。しかし、さまざまなプラクティスを集約したSAFeでは、ARTが機能し、テストされた状態のソフトウエアやシステムが価値を創出するようにするためには、1つのPIに含まれるイテレーションの数は3～5回で、PI全体の期間は8～12週間が良いとされています。

1つのイテレーションの中でのアジャイルチームごとのイベントは、スクラムと同様です。ただし、PI最後のイテレーションは「IPイテレーション」と呼ばれ、通常のイテレーションと内容が異なります。

IPイテレーションの前半をどのように使うかは、各アジャイルチームに任せられます。開発期間のバッファとして残作業を行ってもよいですし、次のPIに向けた調査や検討を行っても構いません。後半は、PIの振り返り（I&Aワークショップ）と、次のPIの計画（PIプランニング）に使います（これらのイベントについては、後述します）。

ここで重要なのは、上の図で示すように、繰り返されるPIやイテレーションの長さ（ケイデンス）を組織全体でそろえた上で、その中で実施される各種イベントを通してART間／チーム間の同期（シンクロナイゼーション）を行うことです。

PIの最初のプランニングで最新の状況を踏まえつつ方針と計画に関する意思統一を図った後、ART間／チーム間での状況／課題共有と依存関係の問題解決、お互いの成果物の統合と価値検証を定期的に実施することで、組織全体としてアジリティを確保しながら継続的な価値を創出します。

SAFeのイベント

続いて、SAFeのイベントをレベルごとに見ていきましょう。主なイベントは次表の通りです。

以降では、一番小さいアジャイルチーム単位のイベントから順に説明していきます。

エッセンシャルレベル（アジャイルチーム単位）のイベント

アジャイルチームごとのイベントはスクラムと同様で、そのイテレーション期間でアジャイルチームが何を達成するかのゴールを決める「イテレーションプランニング（計画会議）」、チームがゴールの達成に向かっているかどうかを日々確認する「デイリースタンドアップ」、イテレーションの最後にプロダクトオーナーに成果物のデモをする「イテレーションレビュー」、アジャイルチームのプロセスの改善を検討する「イテレーションレトロスペクティブ」があります。

また、その他の時間は開発作業を実施するほか、プロダクトオーナーが中心となって「バックログリファインメント（バックログの詳細化）」を行います。

エッセンシャルレベル（ART単位）のイベント

PI開始前に実施するイベント

◆PIプランニング(PI Planning)

8～12週間のPIの期間の最初に、ARTごとに関係者（ART内のARTロールや各アジャイルチームのメンバーはもちろん、必要に応じてラージソリューションレベルやポートフォリオレベルのメンバー、関係する幹部／管理職なども含む）が一堂に会して、2日間の計画会議を行います。PIプランニングで実施する項目は、以下の通りです。

• ART全体でビジョン／方向性の意識を合わせる
• ARTロールの方針を各アジャイルチームが理解し、PI期間中の計画を具体化する
• ARTにとって障害となり得る依存関係やリスクを洗い出し、調整／解決を図る

具体的には、次のような流れで進行していきます。

1. ビジネスオーナーから3カ月間のビジョンをART全員に対して説明する
2. プロダクトマネジメントがプロダクトのビジョンと3カ月間で実現するフィーチャーの内容を、システムアーキテクトがアーキテクチャの方針を説明する
3. 各アジャイルチームは、割り当てられたフィーチャー（やイネイブラー）をストーリーに分解し、各イテレーションの開発計画を検討する
   　・スクラムと同様、これまでの実績に基づきPI期間内にどの程度開発できそうか見積もる
   　・不明点があれば、プログラムマネジメントや幹部／管理職と議論する
   　・リスクについても洗い出しておく
4. 各チームが開発計画を持ち寄り、プログラムボードを作成して、チーム間での依存関係を明らかにする
5. チーム間での依存関係を考慮しながら、各チームで計画案を決める
6. 各チームは計画案をビジネスオーナーに発表し、ビジネスオーナーはビジネス価値やリスクを考慮しながら、開発計画に合意する

なお、2回目以降のPIプランニングはIPイテレーション期間中に実施します。

PI期間中に各イテレーションで実施するイベント

◆ARTシンク（ART Sync）

ART内では各アジャイルチームの状況や成果がお互いに影響を及ぼすため、各イテレーションにおいて「ARTシンク」という状況確認のイベントを行います。

ARTシンクの目的は以下の通りです。

• ARTのPIの目標達成に向けた進捗、依存関係、障害の可視化と、解決に必要な調整の実施
• 開発上の問題点の議論と、必要に応じたフィーチャーの優先度／スコープの調整

具体的なイベントとしては「スクラムオブスクラムズ(Scrum of Scrums)」と「POシンク(Product Owner Sync)」の2種類があります。前者は、リリーストレインエンジニアが主催し、ARTレベルでの進捗状況や阻害要因の確認、チーム間での依存関係の調整を行います。一方後者は、プロダクトマネジメントまたはリリーストレインエンジニアが主催し、成果物の開発と統合が順調に進んでいるかどうかを確認した上で、必要であればフィーチャーの優先度／スコープの調整を行います。

なお、これらのイベントで状況や依存関係を可視化する際には、前回説明した「プログラムボード」を使用します。

◆システムデモ(System Demo)

各イテレーションの終了後に、プロダクトマネジメントと各チームのプロダクトオーナーは協力し、全てのアジャイルチームで作られたフィーチャーを結合します。その上で、ビジネスオーナーやその他のステークホルダー（経営層、顧客など）に向けてデモを行い、フィードバックを得ます。

PI期間中にIPイテレーションで実施するイベント

◆I&A(Inspect＆Adapt)ワークショップ

I&A(Inspect＆Adapt)ワークショップは、各PIの終わりのIPイテレーションにおいて、ARTの全員が集合して実施します。まず、システムデモを行い、プログラムマネジメントやビジネスオーナーからフィードバックを得ます。その後、定量評価、振り返り活動を通して、ART全体の問題の解決と次のPIでの改善アクションの導出を行います。

ここまでをまとめたエッセンシャルレベル(ART単位)のイベントの全体像は、下記のようになります。

なお、プログラムマネジメントやシステムアーキテクトは、各アジャイルチームが開発を行っている間に、次のPIに向けて新たなフィーチャーのバックログを準備します。

ラージソリューションレベル（ソリューショントレイン単位）のイベント

PI開始前に実施するイベント

PIプランニングはARTごとに行いますが、複数のARTから構成されるソリューショントレインについては、各ARTのPIプランニングの前後に「Pre PIプランニング」、「Post PIプランニング」というイベントを実施し、ソリューショントレインとしての意識合わせと計画を行います。

◆Pre PIプランニング

PIプランニング実施前に開催するイベントです。次のPIでソリューショントレインが実現するソリューションバックログやソリューションロードマップを検討し、各ARTのPIプランニングにおいて、ソリューショントレインとしてART間で整合の取れたビジョンや方針を提示できる状態にします。

◆Post PIプランニング

PIプランニング実施後に開催するイベントです。各ARTのPIプランニングの結果や依存関係、リスクを共有し、再計画が必要かどうかを判断します。

PI期間中に各イテレーションで実施するイベント

◆ソリューショントレインシンク(Solution Train Sync)

ソリューショントレインの作業状況を把握し、必要に応じて調整を行うイベントです。特に複数のARTにまたがる、依存関係にある作業の調整を行い、進捗、障害、リスクの最新状況を継続的に可視化します（ここで前回説明した「ソリューションボード」を使用します）。

◆アーキテクトシンク (Architect Sync)

変更されたソリューションを速やかに環境に反映できるよう、アーキテクチャをメンテナンスしておく必要があります。SAFeでは、アーキテクトのロールはエッセンシャルレベル、ラージソリューションレベル、ポートフォリオレベルの3段階がありますが、問題や懸念が生じたときに対処できるように、レベル間で定期的に情報連携するためのイベントです。

◆ソリューションデモ (Solution Demo)

ソリューショントレインの現状の成果を確認し、今後の方向性を修正する機会として、ソリューションデモを実施します。

PI期間中にIPイテレーションで実施するイベント

ARTと同様に、各PIの終わりのIPイテレーションではI&Aワークショップを実施します。

ここまでをまとめたラージソリューションレベル（ソリューショントレイン単位）のイベントの全体像は下記のようになります。

なお、各ARTが開発を行っている間に、ソリューションマネジメントやソリューションアーキテクトは次のPIに向けて新たなケイパビリティのバックログを準備します。

ポートフォリオレベルのイベント

ポートフォリオレベルでは、本稿で紹介するイベント以外にも、組織戦略の立案やビジネス目標の策定、ビジネス成果の評価など、重要かつ多様なイベントやタスクがあります。次回以降に扱う課題解決のアプローチでもポートフォリオのイベントについては説明しますが、今回は特徴的なイベントに絞ってご紹介します。

PI開始前に実施するイベント

◆参加型予算編成（Participatory budgeting）

SAFeのポートフォリオレベルでは複数のデベロップメントバリューストリームを管理し、デベロップメントバリューストリームごとに予算を配分します。定期的に予算編成の見直しを実施するのですが、その際、「参加型予算編成」という方法をとります。

この手法では、LACE、リーンポートフォリオマネジメント（LPM）、エピックオーナー、エンタープライズアーキテクトといったポートフォリオのロールの人々から、ビジネスオーナー、プロダクトマネジメント、システムアーキテクトなどのARTロール、その他のステークホルダーまで、多様なメンバーが参加することによって、多面的に予算編成の検討を行います。PIの切り替えタイミングに合わせ、通常は半年に1度のペースで計画／実行されます

PI期間中に各イテレーションで実施するイベント

◆ポートフォリオシンク (Portfolio Sync)

ラージソリューションレベルやエッセンシャルレベルを含めたポートフォリオ全体の運営について、状況の確認と改善／最適化、デベロップメントバリューストリームの上の各エピックの継続判断や追加／優先順位付けなどを行うためのイベントです。エッセンシャンレベルとの同期を取るために、通常は月に1回実施します。具体的に実施する項目は、以下の通りです。

• ポートフォリオ戦略と目標に対する進捗状況の確認と、現在進めているエピックの継続判断
• 新たなエピックの承認と優先順位付け
• ポートフォリオ全体に関わる継続的な改善の推進および障害の除去
• ポートフォリオ全体の投資／効果／リスクの把握と継続的な最適化

◆戦略的ポートフォリオレビュー (Strategic Portfolio Review)

全社方針や市場の変化に対応できるよう、ポートフォリオの戦略を見直すためのイベントです。次のPIプランニングの少なくとも1か月前、ほぼ四半期ごとに実施します。一例として、以下のような項目を実施します。

• ポートフォリオビジョンの更新
• 戦略テーマの見直しと更新
• ポートフォリオのメトリクス／KPIの見直し
• ポートフォリオロードマップの見直し

*　*　*

今回は、SAFeで実施するイベントをご紹介しました。各イベントは、継続的な改善と価値検証を行いながら大規模なプロダクトやソリューションの開発を進められるように定義されています。

今回でSAFeの概要説明は終了です。次回からは、いよいよ課題解決のアプローチに入っていきます。今後読み進める上で不明な用語があれば、適宜、本連載の第1回～7回に立ち戻り、リファレンスとしてお使いいただければ幸いです。