DtoD手法に基づくアジャイル要求

「Discover to Deliver（DtoD）」は3つの時間軸とプロダクトの7側面の観点を用いてプロダクトに対するニーズとその実現スケジュールを利害関係者で話し合い、合意するためのフレームワークです。

出典: エレン・ゴッテスディーナー、メアリー・ゴーマン著, 『発見から納品へ：アジャイルなプロダクトの計画策定と分析』, BookWay, 2014. 55

また、DtoDは顧客を喜ばせるために不可欠である「正しいプロダクト」を納品するための強力なフレームワークでもあります。

DtoDが生まれた背景

スクラム※の普及

2001年にアジャイル開発宣言が起草されて以来13年が経過し、欧米ではアジャイル開発が当たり前になりつつあります。そのようなアジャイル開発の普及に大きく貢献したのが「アジャイル開発のミニマムセット」と呼ばれるスクラムというコンパクトなアジャイル開発フレームワークです。

スクラムは、単純化すると以下の4つの特徴を持ちます。

スプリントという一定の期間毎に動くソフトウェアを作る
要求はプロダクトバックログという優先順位付けされた一覧表に保管される
各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う

1.のように一定期間毎に動くソフトウェアを作ることを時間枠（タイムボックス）納品とここでは呼びます。

スクラムは、優先順位付けされたバックログ項目の優先順位順に動くソフトウェアを作り、作成されたソフトウェアを評価することで開発依頼者や市場のニーズに即したソフトウェア（プロダクト）をすばやく開発することを可能にしました。これがスクラムの普及の大きな原動力となったのです。

プロダクトバックログ項目を表現するユーザーストーリー

その一方で、スクラムはコンパクトなアジャイル開発フレームワークとして誕生したために以下のようなことの具体的な実行方法が当初規定されていませんでした。

（ア）プロダクトバックログ項目の表現形式
（イ）プロダクトバックログ項目の定義プロセス

スクラムが発展する過程で、XPというアジャイル手法の考え方を取り入れて（ア）としてユーザーの声形式の「ユーザーストーリー」を用い、（イ）としてRon Jefferiesの3C（カード、会話、確認）の3段階でユーザーストーリーを発展させる方法が提案されました。さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案されました。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になったのです。

スクラムとユーザーストーリーの組み合わせにおける課題

ただ、これらはユーザーストーリーの表現形式やそれを検討する過程を3段階で発展させ、さらに計画と結びつけた方がよいということについて優れたアドバイスではあるものの、ユーザーストーリーをどのように考案するのかという具体的な方法を示すものではありません。また、具体的な方法が示されてもその方法によりプロダクトオーナーが単独でユーザーストーリーの考案や優先順位付けを実際に行えるのかという問題もあります。

また、ユーザーストーリーはソフトウェアの機能的な要求しか表現しておらず、データや品質特性、環境などプロダクト開発に関係するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することには役不足です。言いかえれば、従来開発の分析に相当する作業が入りこむ余地があまりないのです。確かに従来開発の分析作業はある程度の専門性が求められ、時間もかかるし、文章を中心とした成果物を作るという点でもアジャイル開発とは相いれないものと思われるかもしれません。しかし、業務システムのように多数の利害関係者が関与するプロダクトに対するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することが求められる場合も多いのです。

DtoDは分析者が関与してそれらの課題を解決します

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

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

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

DtoDでは、要求定義、分析、計画策定を行うワークショップを計画/分析セッションと呼びます。DtoDの計画/分析セッションは、複数のリリース（全体ビュー）、次のリリース（事前ビュー）、次の反復（現在ビュー）という3つの計画策期間に対して開催します。先の説明ではスクラムを補うものとしてDtoDを説明してきましたが、DtoDはこれらのセッションの開催のタイミングを調整することで、カンバン（フロー納品）や従来開発（従来納品）の中でも活用することができるのです。

DtoD関連資料

・DtoDに基づくアジャイル要求入門

DtoDの概要について詳しくは以下の資料をご覧ください。この資料ではDtoDを構成する概念を説明し、さらに、地域リユースオークションサイトを題材にして事前ビューの計画/分析セッションの進め方の概要を説明します。

「DtoDに基づくアジャイル要求入門（PDF）」
「DtoDに基づくアジャイル要求入門」のWeb版は「オブジェクトの広場」に連載しています。

・書籍

DtoDに関するさらに詳しい内容をお知りになりたい方は、DtoDの考案者であるゴッテスディーナーさんとゴーマンさんの著書である『発見から納品へ：アジャイルなプロダクトの計画策定と分析（BookWay, 2014）』というDtoDの解説書をお薦めします。
当書籍ではDtoDおよび、それらを支援するテクニック群を解説しています。さらに、通常の業務アプリ開発に近い例として、ガラス清掃業のためのシステム開発を題材とした事例を掲載しています。

書籍詳細はこちら

アジャイル開発関連のトレーニング

オージス総研は1990年代から、反復開発やアジャイル開発に取り組み、大規模アジャイル開発の経験等を通じてノウハウを蓄積してまいりました。昨今は、上記、DtoDの紹介はもとより、下記取り組みを通じて、お客様のアジャイル開発、企業としてのアジャイルな取り組みを支援し続けています。

・アジャイル開発に取り組み始めた方向けのトレーニングコースの提供：
体験！アジャイル超入門
 スクラム※入門
・企業や事業部レベルでリーン、アジャイル、DevOpsのプラクティスを実践するためのナレッジベース「SAFe®」の導入支援やトレーニングコースの提供：
大規模アジャイルフレームワークSAFe®導入支援
 SAFe®研修

アジャイル開発の導入、推進等に関して、お気軽に、お問い合わせください。

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。