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

アジャイル

OGIS Scalable Agile Method 2.0入門 第3回

DtoDの概要
株式会社オージス総研 技術部アジャイル開発センター 藤井 拓
2016年2月9日

本記事では、OGIS Scalable Agile Method 2.0(以降、OSAM2.0と略す)基本形の構成要素の1つであるDtoD (Discover to Deliver) [1]の概要を説明する。DtoDは、スクラムのプロダクトバックログ項目であるユーザーストーリーの考案を支援するフレームワークである。本記事では、DtoDの基本概念とリリース内容を考案するための事前ビューセッションの進め方を中心に説明する。

DtoD

DtoDとは

「Discover to Deliver (DtoD)」 は、ファシリテーション [2] と要求/分析 [3] の分野で長年に渡り活躍してきた米国EBG Consulting社のエレン・ゴッテスディーナーさんとメアリー・ゴーマンさんが考案したフレームワークであり、従来開発の要求定義や分析作業を以下のように変えてアジャイル開発とうまく組み合わせられるものに発展させるものである。

  • ワークショップの活用
    • 専門家単独で行うのではなく、顧客、業務、技術という異なる視点の人々が参加するワークショップを開催して、迅速にニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成する。
  • 多様なモデルの活用
    • ワークショップで、ニーズや開発内容を軽量でとっつきやすい様々なモデル(短文記述や図等)により多面的に表現し、理解する。これらは、「プロダクトの7側面」という形でまとめられる。
  • ビジネス分析者の役割の変更
    • ビジネス分析者がワークショップのファシリテーターやモデラーの役割を担うことで、プロダクトオーナーの役割を分担する。

ここでプロダクトと言っているのは、開発の結果として作成されるものであり、一般消費者が使うソフトウェアやハードウェア製品やクラウドサービスだけではなく、業務システムのように特定の企業の業務を支援するシステムも含む。

DtoDでは、要求定義、分析、計画策定を行うワークショップを計画/分析セッションと呼ぶ。DtoDの計画/分析セッションは、複数のリリース(全体ビュー)、次のリリース(事前ビュー)、次の反復(現在ビュー)という3つの計画策定期間に対して開催する。

また、先の説明ではスクラムを補うものとしてDtoDを説明してきたが、DtoDはこれらの計画/分析セッションの開催のタイミングを調整することで、カンバン(フロー納品)や従来開発(従来納品)の中でも活用することができる。

DtoDの基本概念

DtoDとは、プロダクトを構成し得るオプションを考え、それらのオプションの中で優先度の高いものの組み合わせでストーリーを作るためのフレームワークである。このプロダクトを構成し得るオプションをプロダクトオプションと呼ぶ。

DtoDでは、特定の計画範囲を設定し、以下の3種類の参加者が参加してプロダクトオプションやソリューションの候補を検討する。

  • 顧客パートナー:システムやプロダクトの利用者を代弁する人
  • 業務パートナー:業務的な観点でシステムやプロダクトのニーズを考える人
  • 技術パートナー:開発や運用の観点でプロダクトの実現性や品質を考える人

用語注:ソリューション
ソリューションとは、各リリースで提供されるプロダクトの機能を大きな観点で分類したものであり、プロダクトオプションよりも大きな粒度のものである。ロードマップのように、複数のリリースにおいてプロダクトが提供する機能を示す時にソリューションを用いる。

これらの3種類の参加者をプロダクトパートナーと呼び、プロダクトオプションやソリューションの候補を検討する打ち合わせをセッションと呼ぶ。スクラムのプロダクトオーナーをDtoDでは「プロダクト擁護者」と呼ぶが、「プロダクト擁護者」は業務パートナーに分類される。また、顧客の代表者が顧客パートナーになり、アーキテクト、ビジネス分析者、開発メンバーが技術パートナーになる。

また、DtoDでは以下の3つの計画範囲でセッションを開催する。

  • 全体ビュー:複数のリリースを通じてどのようなソリューションを提供するか
  • 事前ビュー:次のリリースでどのようなシステムやプロダクトを提供するか
  • 現在ビュー:次の反復でどのようなシステムやプロダクトを提供するか

ここで、全体ビューではソリューションの候補を検討し、リリース毎にどんなソリューションを提供するかという現時点での見通しをロードマップにまとめる。それに対して、事前ビューや現在ビューでは後述する以下の7つの側面により、より詳細なレベルのプロダクトオプションを検討する。

  • ユーザー:プロダクトの利用者や利用者の役割を表現する
  • インターフェイス:プロダクトとユーザー、他システムとの相互作用を表現する
  • アクション:プロダクトが提供する機能を表現する
  • データ:プロダクトが対象とするドメイン(業務)やデータと、それらのデータ間の関係を表現する
  • 制御:プロダクトが機能する際に守るべき業務ルールや法規制を表現する
  • 環境:プロダクトが利用される環境や開発される環境を表現する
  • 品質特性:プロダクトが達成すべき利用上あるいは開発上の品質を表現する

事前ビューや現在ビューのセッションでは、7つの側面に識別された優先度の高いプロダクトオプションを組み合わせることで優先度の高いストーリー とストーリーの妥当性確認をするための成果物が得られる。

DtoDの事前ビューセッションの進め方

以降、事前ビューセッションの進め方を中心に説明し、その後で現在ビューの違いを説明する。

事前ビューのセッションでは、これらの側面の検討の順番を決めて、各側面に対してプロダクトオプションを識別する。その際に、事前ビューのプロダクトオプションは以下の表で示されるようなモデル等の形で表現される。

プロダクトの側面オプションの識別方法オプションの表現方法(一部)
ユーザー側面どんなユーザーロールを対象にすべきかユーザーロールマップ
インターフェイス側面どんなユーザー、デバイスと他システムと連携をするかコンテキスト図
アクション側面どんな業務上のきっかけに対してプロダクトはどのようなことを行わければならないかイベントと応答
データ側面問題領域を構成する概念やエンティティーとしてどのようなものが存在し、それらの間にどのような関係があるか概念モデル、論理データモデル
制御側面アクションが実行される際にどのような業務ルールが施行されるか決定表、決定木
環境側面プロダクトがどのような開発環境で開発され、どのような運用環境で用いられるか環境オプションの記述表
品質特性プロダクトが利用上、開発上でどのような品質を達成すべきかプランゲージ

なお、品質特性側面のオプションでは性能や可用性などの非機能要求が識別され、それらがシステムテストで行う性能テスト等の情報源となる。

各側面を検討する際に、識別されたプロダクトオプションを以下のオプションボードと呼ばれるボードの対応する区画に貼り付ける。

プロダクトの7側面

事前ビューや現在ビューのセッションは以下の3ステップで進める。

  • 調査する:ある側面のプロダクトオプションを思いつくがままに書き出す
  • 確認する:調査するで識別されたプロダクトオプションをシステムやプロダクトが提供する価値という観点で優先度の高いものに絞り込む
  • 評価する:全側面の検討が終わった段階で、得られたストーリーの妥当性を確認する

つまり、各側面で「調査する」でオプションをどんどん書き出し、それを「確認する」で絞り込み、すべての側面の検討が終わった段階で得られたプロダクトオプションの組み合わせからストーリーを作成する。次に、そのストーリーの妥当性確認を行う。その際に、事前ビューと現在ビューでは、ストーリーの粒度が異なるので異なる種類の妥当性確認を行う。

  • 事前ビュー:粒度の大きなストーリーに対して、そのストーリーが価値をもたらすかどうかをそのストーリーの具体的な利用シーンをシナリオとして記述して確認する
  • 現在ビュー:粒度の小さなストーリーに対して、そのストーリーの受け入れを行うためのシナリオやデータ例を書いて妥当性を確認する

これらの妥当性確認は、プロダクトの開発に先立って粒度の大きなストーリーが業務ニーズを満たすどうかや、粒度の小さなストーリーが実行される際に満たすべき業務ルールや法規制などを満たしているかを確認するために行う。

事前ビューでは、妥当性が確認された各ストーリーと非機能要求を考慮してTシャツサイズ(S、M、L)などの規模の概算見積もりを行い、リリースまでの(Tシャツサイズベースの)ベロシティーとの対比でリリース目標(計画)を策定する。

全体ビューと事前ビューセッションの入出力

DtoDの現在ビューセッション

現在ビューでは、事前ビューよりもより詳細にオプションを表現する方法が用いられるものの基本的には事前ビューと同じようにプロダクトの7側面を「調査する」と「評価する」の2ステップで順番に検討する。全側面の検討が終わったら、得られた粒度の小さいストーリーに対するシナリオやデータ例を記述して「確認する」を実行する。

現在ビューで得られたシナリオやデータ例に基づいて「前提-場合-結果(GWT)」が定義され、それらを利用して自動または手動でスプリント(反復)単位の受け入れテストが実行される。これらのより詳しい説明は、次回の記事の「受け入れテスト駆動開発とは」の節で説明する。

現在ビューセッションの入出力

DtoDとOSAM2.0の課題の関係

前節で説明したOSAM2.0の課題がDtoDによりどのように解決されるかをまとめたものが次の表である。

課題DtoDによる解決
A. プロダクトバックログの項目をどのように定義するか事前ビューと現在ビューのセッションを通じて定義する
B. プロダクトバックログに対応して作成されたものをどのように受け入れるか現在ビューの結果として得られるストーリーに対するシナリオ、データ例、GWTを用いて受け入れる
C. 仕様が暗黙知化し、開発者の理解の違いで仕様の不整合や仕様の抜けが発生するのを如何に防ぐか事前ビューと現在ビューのセッションにおいて7側面でプロダクトオプションを検討することで仕様の不整合や仕様の抜けが発生するのを防ぐ
D. リリースの見通しに関してどのように検討すべきか事前ビューのセッションの結果として、リリース計画が得られる
E. プロダクトのドキュメントをどうするか現在ビューの結果として得られるストーリーに対するシナリオ、データ例、GWTが最低限のドキュメントになる。さらにドキュメントが必要であれば、事前ビューと現在ビューのセッションで書きだしたプロダクトオプションに基づいてドキュメントを作成できる。(入力)
F. プロダクトの最低限の品質をどう確保するか前述したストーリーに対する受け入れテストと、品質特性側面から得られた非機能要求に基づいたシステムテストで品質を確保する。但し、単体テストやシステムの詳細な機能のテストは開発チームが実施することが前提となる。
G. プロダクトオーナーの役割が重すぎるビジネス分析者がプロダクトオプションを識別したり、シナリオ、データ例、GWTで受け入れテストを定義することでプロダクトオーナーの負荷を軽減する。

第 3 回の終わりに

本記事では、OSAM2.0 基本形の構成要素の1つであるDtoDの概要をDtoDの基本概念とリリース内容を考案するための事前ビューセッションの進め方を中心に説明した。DtoDをより詳しく知りたいと思われた方は、本記事や前回の記事と内容的に少し重複がありますが、例などを用いて説明しているオブジェクトの広場の「DtoDによるアジャイル要求入門」をご参照下さるようにお願いします。

次回の記事では、OSAM2.0 基本形のもう1つの構成要素の受け入れテスト駆動開発 (A-TDD) の概要を説明する。

参考文献

[1] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[2] エレン・ゴッテスディーナー, 要求開発ワークショップの進め方, 日経BP, 2007
[3] エレン・ゴッテスディーナー, 実践ソフトウェア要求ハンドブック, 翔泳社, 2009