OGIS Scalable Agile Method 2.0入門 第6回
本記事では、まずチームレベルを越えてアジャイル開発をスケールするためのフレームワークであるSAFe (Scaled Agile Framework)の概要を説明し、次いでSAFeに基づくOGIS Scalable Agile Method 2.0発展形 (以降、OSAM2.0発展形と略す) の概要を説明する。
SAFeとは
SAFe (Scaled Agile Framework) は、企業や事業部の戦略に沿い、企業や事業部が一丸となって強力なプロダクト、サービス、システムを企画し、開発する姿を描いたフレームワークである。SAFeの考案者は、ソフトウェア要求の権威であり、かつ自身がいくつも企業を起業し成功を収めているDean Leffingwell氏である。SAFeは、アジャイル、リーン思考、プロダクト開発フロー、要求プラクティスを融合してLeffingwell氏が考案し、John Deer社（農機具製造業）、BMC Software社（ソフトウェア製品ベンダー）、Discount Tire社（小売業）、TradeStation社（金融サービス業）などの様々な分野の大規模開発に適用した経験を経て体系化したものである。SAFeはLeffingwell氏の著書である「アジャイルソフトウェア要求」[1]という書籍で最初に世に出たが、表 1 に示されるような改訂も経ながら現在も発展し続けている。
| リリース年 | SAFeのバージョン | 説明 |
|---|---|---|
| 2012年 | 1.0 | -書籍“Agile Software Requirements”でSAFeの全体像と全体像を構成する要素が解説された |
| 2013年 | 2.0 | -ポートフォリオレベル：価値のストリームを導入するとともに、アジャイルリリース列車(ART)の自立性を高めた |
| 2014年 | 3.0 | -ポートフォリオレベル：投資テーマが戦略テーマに変わるとともに、複数のアジャイルリリース列車による開発が描かれる |
| -プログラムレベル：潜在的に出荷可能なインクリメント(PSI)等の用語が変更された |
これらの改訂を取り入れて発展した最新のSAFeの説明はwww.scaledagileframework.comというwebサイト（日本語訳はSAFe日本語サイトで提供）から一般向けに提供されている。
注：SAFe本家サイト日本語サイトのバージョンの違い
日本語訳に要する時間による遅延のために、SAFe日本語サイトは本家サイトよりも前のバージョンになっている場合があります。
SAFeでは、経営レベルで意思決定した戦略を複数のアジャイルチームからなるプログラムが競争力のあるプロダクトに具体化するという事業部や企業の姿を提示する。そのために、SAFeは、意思決定及び実行のための3階層と、カンバンや複数のバックログ（待ち行列）による企画審査及び開発の連携を基本的な骨格としている。これらは、プロダクト開発フロー[2]のテーマである分散された制御や待ち行列に基づいている。
SAFeの最大の特徴は、意思決定及び実行の階層として以下の3つのレベルを設定したところにある。
- ポートフォリオレベル：プロダクト等の企画を評価、審査する
- プログラムレベル：複数チームが連携してプロダクトのリリースを開発する
- チームレベル：1つのチームがプロダクトの自チーム担当部分を開発する
ここで、「プログラム」とは複数チームで構成される大規模な開発体制のことを意味する。SAFeのプログラムレベルでは、5-10チーム程度（開発者数が50-100名程度）の規模を想定している。
これらの3つのレベルを図示したものが図 1であり、これをSAFeの全体像(big picture)と呼ぶ。これらの3つのレベルの概要については、[3]に記述されているのでそちらの御参照をお願いする。
出典：www.scaledagileframework.comに掲載されていた図をLeffingwell LLC.の許可の下で翻訳
これらのレベルを通じて、SAFeが実現しようとしているのが以下の4つの価値である。
- ベクトル合わせ：3つのレベルのメンバーが戦略的な目標を共有し、その方向に向かって力を合わせる
- コード品質：技術プラクティスを実践することで大規模で品質のよいプロダクトを実現する
- プログラムの実行：開発メンバーの自律性に基づく自己組織化や自己管理、及び反復のサイクルを自然な形でプログラムレベルにスケールアップすることで、大規模プロジェクトを確約に基づきスケジュール通りに実行する
- 透明性：3つのレベルのメンバーが包み隠さず現状を共有することで、より良い連携をもたらす信頼関係を醸成する
SAFeのもう1つの特徴は、以下のようなカンバンや複数のバックログを介して経営陣、プログラム、チームが目標を共有し、連携することを提案している点にある。
- ポートフォリオカンバンシステム：プロダクト等の企画を評価、審査するためのカンバンシステム
- ポートフォリオバックログ：承認済みのプロダクト等の企画を保持するバックログ
- プログラムバックログ：1つのプログラムで共有する要求のバックログ
- チームバックログ：１つのチームで共有する要求のバックログ
これらのカンバンやバックログには、プロダクトの企画や要求を表す以下のような項目が入る。
- エピック：プロダクトやシステムに対するニーズとそれを解決するソリューション
- フィーチャー：エピックから導き出した最上位の要求
- ユーザーストーリー：フィーチャーを実現するために必要なチームレベルの要求
ここで注意して頂きたいのが、「要求」という言葉の意味である。アジャイル開発では、「要求」は開発依頼者が開発して「欲しい」と考えている機能等を表現するのにすぎず、開発されることが約束されたものではないということである。
エピックは1-2ページ程度の分量で、1つのフィーチャーやユーザーストーリーは索引カード１枚に記述できるようなものであり、従来の要求成果物よりも軽量なものになっている。また、エピックには以下の2種類のものがある。
- ビジネスエピック：ユーザーに直接的に価値を提供するプロダクト、システム、サービス
- アーキテクチャーエピック：ユーザーに直接的には価値を提供しないプロジェクト横断的な共通アーキテクチャーやインフラ、UXガイドライン
これらの要求がカンバンやバックログを介して3つの意思決定及び実行のレベルを流れることで、SAFeでは戦略的な意思決定がチームレベルで開発される詳細な機能に具体化されるのである。
OSAM 2.0発展形
OSAM2.0発展形では、SAFeのチームレベルやプログラムレベルでのイベント、役割、成果物等を取り入れることで複数のチームによる開発を実現する。SAFeのチームレベルは一部拡張されたところがあるものの基本的にはスクラムとXPのプラクティスを組み合わせたものである。以降、OSAM2.0発展形で取り入れるSAFeのプログラムレベルのイベント、役割、成果物を中心に説明する。
SAFeのプログラムレベルは複数チームを連携させるために以下のような仕組みを取り入れている。
- アジャイルリリース列車
- 複数のチームが共通の開始、終了日に基づく2週間のサイクルで開発を進めて、8-12週毎に評価可能なシステム（プログラムインクリメント）を提供する
- リリース計画策定
- 各プログラムインクリメント(PI)サイクルの開始前に、プログラムにおいて優先度の高いフィーチャーをチームに仮割り当てをして、それらのフィーチャーのPIでの実現性を全チームのメンバーで検討するリリース計画策定打ち合わせを実施する
- 検査と適応ワークショップ
- 8-12週で作成した評価可能なシステム（プログラムインクリメント）をデモし、計画の達成度を評価するとともに、プログラムレベルでの改善を考えるためのワークショップを開催する
これらを支援する役割として、SAFeではプログラムレベルでのプロダクトオーナーに相当するプロダクト管理者という役割やプログラムレベルでのスクラムマスターに相当するリリース列車エンジニアという役割を設けている。
SAFeのプログラムレベルの中心的なイベント、役割、成果物は、以下のようにスクラムのイベント、役割、成果物を比較的自然にスケールさせたものになっている。
- イベント：リリース計画策定、検査と適応ワークショップはスクラムにおけるスプリント計画、スプリントレビュー、振り返りを拡張したもの
- 役割：アジャイルリリース列車、プロダクト管理者、リリース列車エンジニアはスクラムの開発チーム、プロダクトオーナー、スクラムマスターを拡張したもの
- 成果物：プログラムバックログ、プログラムインクリメントはスクラムにおけるプロダクトバックログ、インクリメントを拡張したもの
このようにSAFeのプログラムレベルは、スクラムを比較的自然にスケールさせたイベント、役割、成果物で構成されており、チームレベルでのスクラムの良さである自律性や自己管理を活かす形で開発をスケールアップしている。
さらに、SAFeのプログラムレベルでは複数チーム間の連携を強化し、システムアーキテクチャー、テスト、リリースの判断など1チームに収まらない作業の実行者を明確にするために、以下のようなSAFe固有のイベント、役割、成果物も追加されている。
- イベント
- システムデモ： 2週間毎にプログラム全体で作成したシステムをデモする
- スクラム・オブ・スクラムズ：各チームの進捗状況、予定、障害を共有する
- リリース管理打ち合わせ：開発の状況等を共有し、リリースの判断を行うための打ち合わせ
- 役割
- システムチーム：プログラム全体の開発環境を整備したり、各チームが反復毎に開発したコードを受け取り、統合及びシステムテストを行い、システムデモを行う
- システムアーキテクト：開発チームとともに、システムのアーキテクチャーを考案し、アーキテクチャーの実装を支援する
- リリース管理：開発の状況等からリリースの可否を判断する
- 成果物
- プログラムボード：各チームのフィーチャーの開発スケジュールとフィーチャー間の依存性の掲示板
- PI目標：今回のプログラムインクリメント(PI)で達成しようとしている目標の一覧
以上説明したようなSAFeのプログラムレベルのイベント、役割、成果物を取り入れることで、OSAM2.0発展形において複数チームによる開発が可能になる。
本連載の終わりに
本連載では、要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かすために以下のフレームワークや手法でスクラムを補うことが有効なことを説明した。
- DtoD (Discover to Deliver)
- 受け入れ駆動開発（A-TDD）
さらにこれらをスクラムと組み合わせた開発の進め方をOSAM 2.0基本形という形で提示した。
また、自己管理や自己組織化というスクラムのチームの連携を活かしたスケールアップを実現する手段として以下のフレームワークが有効なことを説明した。
- SAFe (Scaled Agile Framework)
また、これによりOSAM 2.0基本形をスケールアップ可能にしたものとしてOSAM2.0発展形を提示した。
OSAM2.0を構成するA, Cについてさらに知りたい場合は、本記事の参考文献に書籍や解説文書などを挙げているのでそちらを参照して頂くようにお願いします。さらに、スクラム、A、Cを習得したい方向けにはそれらの トレーニング の提供も行っておりますので、それらの受講をご検討頂けたら幸いです。
参考文献
[1] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014
[2] Donald G. Reinertsen, The Principles of Product Development Flow―Second Generation Lean Product Development, Celeritas Publishing, 2009
[3] 藤井 拓, SAFe入門, https://www.ogis-ri.co.jp/pickup/agile/docs/safe_intro.pdf
[4] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[5] 藤井 拓, DtoDに基づくアジャイル要求入門, https://www.ogis-ri.co.jp/pickup/agile/docs/IntroARWithDtoD.pdf