オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

アジャイル

SAFe (Scaled Agile Framework) 3.0 入門 (第5回)

SAFeのプログラムレベルとチームレベル
株式会社オージス総研 技術部アジャイル開発センター
藤井 拓
2015年6月11日

今回の記事では、企業や事業部が一丸となって強力なプロダクト、サービス、システムを企画し、開発する姿を描いたフレームワークであるSAFe (Scaled Agile Framework) [1], [2]のプログラムレベルとチームレベルを説明します。今回の記事でも、前回の記事に引き続いて架空の家電メーカーのプロダクト開発を題材に用います。

1. SAFeの 3 つのレベル （続き）

1.1. プログラムレベル

開発に着手することが判断されたエピックに対して、プロダクト管理者がそのエピックを実現する最上位の要求をフィーチャーとして定義し、さらにビジョンやロードマップを定義します。これらのフィーチャーは、優先順位付けされてプログラムが開発する機能候補としてプログラムバックログに取り込まれます。このフィーチャーの優先順位付けにおいて本記事の連載第3回のプロダクト開発フローの節 [3]で記述した「遅延のコスト」などを考慮します。

注：SAFe 4.0 での変更点
SAFe 4.0 では、今後開発するエピックをプログラムレベルで自律的に評価/審査するために、プログラムバックログの前にポートフォリオレベルと同様のカンバンを設けることができる。

次に、これらのバックログの項目を開発するチームを編成し、これらのチームが8-12週毎にプログラムインクリメント(PI)と呼ばれる動くシステムを開発します。PIは、開発の客観的な進捗の評価に用いられますが、さらにプロダクトの方向性の評価に用いられたり、リリースされてお客様に提供されることもあります。1つのPIは、複数回の反復を通じて開発されます。この1つのPIを開発するサイクルをPIリリースサイクルと呼ぶと、このサイクルは以下のように進行します。

  1. 全チームが一堂に会して次のPIに対するリリース計画の策定を行う
  2. リリース計画後に全チームは同じ反復周期でインクリメントを開発する
  3. 各反復毎にシステムチームが全チームのインクリメントを統合し、統合したもののテストやデモを行う
  4. PIリリースサイクルの最後の反復は機能追加をしない特別な反復になる。この特別な反復をIP（Innovation Planning）スプリントと呼ぶが、この反復で行うことは以下の4点である。
    • 必要に応じて、リリース前の最終テストを行って品質を確保する
    • 今後の開発に備えて新技術の習得などを行う (イノベーション：Innovation)
    • 検査と適合ワークショップで利害関係者向けのPIのデモを行うとともに、プログラムレベルでの改善を行う
    • 次のPIに対するリリース計画の策定を行う（計画策定：Planning）

注：SAFe 4.0 での変更点
SAFe 4.0 では、「リリース計画」は「PI計画」へと名称が変わった。その結果、SAFe 4.0の用語では「PIリリースサイクル」を「PIサイクル」と読んだ方が適切である。

ここで「インクリメント」とは、機能追加されたソフトウェアのことを意味します。

このようなA-Dの開発の進め方をアジャイルリリース列車と呼びます。このアジャイルリリース列車が円滑に進むように支援するためにSAFeではリリース列車エンジニア(RTE)という役割が設定されています。

A のステップで、直近のPIの目標に含まれるフィーチャーは、開発チームによりユーザーストーリーに分解されてチーム単位のバックログ（チームバックログ）へと変換されます。

B において反復期間を統一しているのは、頻繁に同期することで計画からの進捗のバラツキの累積を防ぎ、リリーススケジュールの確実性を高めるというプロダクト開発フローの考え方に基づいています。

D では、リリース計画でPIの目標とされたフィーチャーが実装されるので、それを利害関係者が評価し、その結果を考慮して次のリリース計画に策定します。

SAFeのプログラムでの管理は、チームやメンバーの自己組織化や自己管理に基づくものになっています。そのような点を含めて、表 1 に示すようにSAFeのプログラムレベルはスクラムを素直に拡張したものになっています。

表 1 スクラムとSAFeのプログラムレベルの対比
スクラムSAFeのプログラムレベル
プロダクトバックログプログラムバックログ
インクリメントプログラムインクリメント(PI)
スプリント計画リリース計画
スプリントレビューと振り返り検査と適合ワークショップ
プロダクトオーナープロダクト管理者
スクラムマスターリリース列車エンジニア

SAFeのプログラムレベルには、先に言及したプロダクト管理者やリリース列車エンジニア以外にもシステムアーキテクトやUX、DevOpsなどの専門家がおり、プログラム全体でのアーキテクチャー、UXなどの品質を確保したり、開発環境から運用環境へのプロダクトの配置の自動化を推進したりします。

プログラムレベルの例

ポートフォリオレベルの説明で、題材として用いた「お掃除ロボット」をここで再び用います。「お掃除ロボット」エピックがポートフォリオバックログで最上位のランクにあり、開発リソースが確保できれば、「お掃除ロボット」の開発を進めるための体制（アジャイルリリース列車）が編成されます。「お掃除ロボット」の開発のためのアジャイルリリース列車は、以下の5チームで編成されるとします。

  • システムチーム
  • 走行機能チーム
  • 吸引機能チーム
  • 電源管理チーム
  • 全体制御チーム

まず、「お掃除ロボット」のエピックに基づき、プロダクト管理者が「お掃除ロボット」のビジョンを書くとともに、「お掃除ロボット」のフィーチャーを定義し、それをプログラムバックログに入れます。さらに、プロダクト管理者は次回のPIを含む、直近3回のPIに対するロードマップを策定します。

図 1プログラムレベルの例
図 1 プログラムレベルの例

リリース計画策定セッションでは、プロダクト管理者が定義したフィーチャーの上から10位までのフィーチャーを各チームに割り当てます。各チームは割り当てられたフィーチャーの実現に必要なユーザーストーリーを書きだし、それらの規模を見積もり、各チームがPIまでの期間に開発可能な機能を明らかにします。また、各チームで開発するフィーチャー間の依存性を明らかにします。リリース計画策定セッションの最後では、得られた計画の達成をプログラムのメンバー全員が確信しているかを確認します。

リリース計画が策定されたら、プログラムは開発を開始し、全チームが同じ反復周期で開発を行います。また、システムチームが各反復で開発されたコードを結合し、システムレベルのテストやデモを行います。

通常の反復を４回実行した後、お客様を始めとする開発の利害関係者を集めて検査と適合ワークショップを開催して、以下のようなことを実行します。

  • システムデモ
  • 定量的なデータに基づく振り返り
  • 定性的な振り返り

これらで得られたお客様のフィードバック等によりプロダクトの有効性を評価し、次のPIに向けたリリース計画の策定を行います。

1.2. チームレベル

チームレベルでは、本記事の連載第 1 回 [4]で説明したスクラムに基づき、チームバックログの内容を優先順位に従って開発します。ここで、チームバックログとはチーム単位のバックログを意味し、チームに割り当てられたフィーチャーを分解したユーザーストーリー等を保持するものです。また、開発するコードの品質を確保するために、SAFeでは「テスト駆動開発」や「継続的なインテグレーション」などXPというアジャイル手法で提案されたプラクティスや、アーキテクトと開発チームが連携してアーキテクチャーを構想し実現するアジャイルアーキテクチャーというSAFe固有のプラクティスの適用を推奨しています。

注：SAFe 4.0 での変更点
SAFe 4.0 では、チームレベルの開発においてスクラム以外にカンバンも適用できる。

各チームは、プロダクトオーナー、スクラムマスター、開発メンバーから構成され、7±2名のメンバーで構成されます。SAFeにおけるプロダクトオーナーは、プロダクト管理者と連携してチームが担当しているプロダクト部分のストーリーを定義し、開発メンバーからの質問に対応し、開発されたプロダクトの受け入れを行います。

チームレベルの例

各チームは、リリース計画策定の過程で得られたユーザーストーリーをチームバックログに保管し、反復毎に以下のようなことを実行しながら開発を進めていきます。

  • 反復計画の策定
  • 反復の実行
  • 反復デモと振り返り
図 2 チームレベルの例
図 2 チームレベルの例

第 5 回の終わりに

今回は、SAFeのプログラムレベルとチームレベルを説明しました。

SAFe のプログラムレベルとチームレベルでは、ポートフォリオレベルで下した戦略的な判断をプロダクトとして具体化します。これらの3つのレベルの連携で、戦略的な狙いであるエピックを具体的な顧客ニーズに対応するフィーチャーやプロダクトの詳細仕様に相当するユーザーストーリーへと展開されます。

このように、SAFe の3つの意思決定、実行レベルが連携して各レベル毎にそのレベルで判断できる肉付けを行うことは、本記事の連載第 3 回で説明したプロダクト開発フローの「制御を分散する」というテーマに基づいています。「制御を分散する」ことで、判断のスピードを上げるとともに、専門性に基づいた適切な判断を下すことができます。

また、前回の記事[5]で記したようにSAFe の3つの意思決定、実行レベルには複数の「待ち行列」があることや、プログラムレベルやチームレベルでPIや反復というリズムや同期点を設定しているところもプロダクト開発フローのテーマに基づいています。

本記事の執筆当時 SAFe の日本での適用事例はまだ報告されていませんでしたが、2016年12月にソニー・インタラクティブエンタテインメント様がエンタープライズアジャイル勉強会で PlayStation Network の開発へのSAFe の適用事例を紹介して下さいました。この事例紹介資料 [6] では、PlayStation Network という超巨大なサービスの開発において、チームレベルの開発がアジャイルリリース列車でまとまったことの利点や実践上の工夫が紹介されています。

参考文献