本記事では、直近 2 回の記事で説明したDtoD (Discover to Deliver)とA-TDD (Acceptance Test Driven Development)とスクラムを組み合わせたOGIS Scalable Agile Method 2.0基本形での開発の流れを説明する。
OGIS Scalable Agile Method 2.0基本形
OGIS Scalable Agile Method 2.0基本形の開発の流れ
OGIS Scalable Agile Method 2.0 (以降, OSAM2.0と略す）基本形とは、本連載の第2回目の記事で記したように「スクラム＋ユーザーストーリーをDtoDとA-TDDとで補う」というコンセプトに基づく開発手法である。OSAM2.0基本形の開発の流れを図示すると以下のようになる。
スクラムの部分を除いたOSAM2.0基本形の開発の流れを一覧表にすると以下のようになる。
| ステップ名 | 実行タイミング |
|---|---|
| 開発構想等の策定 | 複数のリリース毎に１回 |
| DtoDの価値観点の識別 | |
| 業務要求の理解 | 必要に応じて実行 |
| DtoDの事前ビューセッションの準備 | リリース毎に1回 |
| DtoDの事前ビューセッションの実行 | リリース毎に1回（リリース計画） |
| DtoDの現在ビューセッションの実行 | スプリント毎に1回（バックログの手入れ） |
| A-TDDのGWTの作成 | スプリント中に実行 |
| A-TDDのテストコードの拡張 | スプリント中に実行 |
| A-TDDの受け入れテストの実行 | スプリント中またはスプリントレビューで実行 |
この表の7行目から9行目に記されたA-TDD関係の作業の説明は、本連載の第4回の記事に記されているので、本記事での説明を省略する。以降、この表の1行目から6行目の作業の概要を説明する。
開発構想等の策定
まず、開発対象となるプロダクトの競合製品や既存システムに対する優位性をビジョン[1]、[2] としてまとめるとともに、そのビジョンにより達成しようとするビジネス目的やビジネス目標[3]を定める。ここで、ビジネス目的は開発対象のプロダクトがリリースされることで期待される定性的な成果を意味し、ビジネス目標は開発対象のプロダクトがリリースされることで期待される定量的な成果を意味する。
価値観点の識別
このステップからDtoDに入る。まず、DtoDの推進者であるプロダクト擁護者（業務パートナー）がユーザーの代表者やその代弁者（顧客パートナー）や、分析者やアーキテクト（技術パートナー）を集めて、これら3種類のプロダクトパートナーの観点でビジョン、ビジネス目的、ビジネス目標を達成するためにプロダクトが提供すべき価値を挙げる。これにより得られた価値を価値観点と呼ぶ。
価値観点は、プロダクトが3種類のプロダクトパートナーにもたらす価値を定性的に表現したものである。価値観点は、プロダクトオプションの優先順位を判断する土台となる。価値観点の具体例は、[2] 、[4] に記載されているので御参照下さい。
業務要求の理解
すでに既存の業務が存在したり、複雑な業務知識や業務ルール等が存在する場合はそれらの業務の調査や理解を行い、DtoDの事前ビューに備えて業務知識や業務ルールを整理したり、モデル化する。
DtoDの事前ビューセッションの準備
DtoDの事前ビューセッションは、スクラムの「リリース計画」に対応する。事前ビューセッションでは、プロダクトパートナーを集めて本連載の第3回の記事で説明したように以下の作業を行う。
- プロダクトの7側面に渡り優先度の高いオプションを調査し、確認する。
- 得られた優先度の高いプロダクトオプションを組み合わせることで、粒度の大きなストーリーを作成する。
- これら粒度の大きなストーリーに対する散文シナリオを書き、ストーリーが価値観点や業務要求を満足するかを確認する。
- ストーリーが価値観点や業務要求を満足することが確認できたら、それらのストーリーの開発労力を見積もる。
DtoDでは、シナリオの表現形式として以下の2種類を用いる。
- 散文シナリオ：ストーリーやソリューション等が実現された場合のユーザー体験の具体例を文章で記述する
- ケースシナリオ：ストーリー等を実行する場合の存在し得るケースを簡潔な文または式で表現する
注：シナリオの表現形式
「散文シナリオ」、「ケースシナリオ」は、本記事の執筆者が勝手に行っている分類であり、DtoD本ではこれらは「シナリオ」と呼ばれています。
ここでソリューションは、ユーザーに価値をもたらすことが可能な一連の機能を備えたソフトウェア、システム、サービスを意味する。
散文シナリオは、ユーザー体験の具体例を書き下してストーリーやソリューション等の妥当性を確認するためのものである。それに対して、ケースシナリオは以下の2つの用途に用いられる。
- ある要求表現を場合分けした粒度のより小さな要求表現を識別する
- スプリント単位で実装できる粒度の小さなストーリーが実行される際の複数の場合(ケース）を識別する
前者は、例えばフィーチャーをストーリーに分解したり、粒度の大きなストーリーをより粒度の小さなストーリーに分解することである。後者は、例えばストーリーを実行する際に守るべきビジネスルール上の場合分けに対応するものである。後述する現在ビューで識別され、受け入れテスト駆動開発の受け入れテストケース（GWT）へとつながるのである。
事前ビューセッションの準備では、本番の事前ビューを効率的に実行するために、準備に参加可能なプロダクトパートナーを集めて前記の4つの作業を実行する。
DtoDの事前ビューセッションの実行
事前ビューセッションでは、リリース内容の判断に関与すべきプロダクトパートナーの参加の下に、前述した「DtoDの事前ビューセッションの準備」で得られた結果を使いながら「DtoDの事前ビューセッションの準備」で行った4つの作業を実行する。これらの4つの作業を繰り返すことで、比較的短時間のセッションでプロダクトオプションの抜けや優先度の設定に間違いがないかを確認するとともに、プロダクトオプションやストーリーの優先度を確定させる。
さらに、結果として得られた優先度の高いストーリーに対して、次回のリリースで提供できそうな範囲を検討する。この次回のリリースで提供できそう範囲のストーリーが次回のリリース目標になる。
DtoDの現在ビューセッションの実行
DtoDの現在ビューセッションは、スクラムの「バックログの手入れ」に対応する。現在ビューセッションでは、開発チームを含むプロダクトパートナーを集めて事前ビューで行った以下の作業をより詳細なレベルで実行する。
- プロダクトの7側面に渡り優先度の高いオプションを調査し、確認する。
- 得られた優先度の高いプロダクトオプションを組み合わせることで、粒度の小さなストーリーを作成する。
- これら粒度の小さなストーリーに対するケースシナリオを書く。
なお、現在ビューのインターフェース側面では必要に応じてUIのモックを描き、アクション側面では業務フローを描くなど事前ビューとは異なる形式でプロダクトオプションを表現することになる。
これらの作業の結果として、得られた粒度の小さなストーリーがプロダクトバックログの項目になる。3のシナリオを書く作業は、現在ビューの時間的な制約ではごく限られた範囲に留まる。この作業は、現在ビューセッションの終了後も以下のような形で継続する。
- 粒度の小さなストーリーに対するケースシナリオをさらに拡充するとともに、それらに対するデータ例を考える
- ケースシナリオとデータ例に基づいて、受け入れ基準を策定する
5で得られたケースシナリオとデータ例はA-TDDのGWT(Given-When-Then, 前提-場合-結果)を作成するための入力になるので、それらを入力として本連載の第4回の記事の「OSAM2.0におけるA-TDDの実行」を実行する。
第 5 回の終わりに
本記事では、DtoDとA-TDDとスクラムを組み合わせたOSAM 2.0基本形での開発の流れの概要を説明した。
次回の記事では、SAFe (Scaled Agile Framework)とOSAM 2.0発展形の概要を説明する。
参考文献
[1] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014
[2] エレン・ゴッテスディーナー, 実践ソフトウェア要求ハンドブック, 翔泳社, 2009
[3] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[4] 藤井 拓, DtoDに基づくアジャイル要求入門, https://www.ogis-ri.co.jp/pickup/agile/docs/IntroARWithDtoD.pdf