アジャイル要求の考案と検討、素早い合意を形成するための「DtoD(Discover to Deliver)」のご案内

プロジェクトをアジャイルで成功に導くには これまでのやり方では不十分

アジャイル開発では、ユーザーストーリーと呼ばれる簡潔なユーザーニーズの記述を元にして開発を進めます。ユーザーストーリーには、簡単な形式でニーズを表現できるという点で大きな利点がありますが、業務、ユーザー、技術などの複数の利害関係者が関与する開発の内容を判断するためにはユーザーストーリーに書かれた情報や観点だけでは不十分です。

ニーズと実現スケジュールを利害関係者で話し合い 合意する“DtoD”

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

Discover To Deliver(発見から納品へ):顧客を喜ばせるために不可欠である「正しいプロダクト」を納品するための強力なフレームワーク です

 

DtoDが生まれた背景

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

図2 スクラムにおける開発の流れ

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

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

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

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

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

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

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

スクラムの課題:多面的な分析手段の欠如、プロダクトオーナーに役割の重さが集中

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

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

 

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

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

  1. ワークショップの活用

    専門家単独で行うのではなく、顧客、業務、技術という異なる視点の人々が参加するワークショップを開催して、迅速にニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成する。

  2. 多様なモデルの活用

    ワークショップで、ニーズや開発内容を軽量でとっつきやすい様々なモデル(短文記述を含む)により多面的に表現し、理解する。これらは、「プロダクトの7側面」という形でまとめられる。

  3. 分析者の役割の変更

    分析者がワークショップのファシリテーターやモデラーの役割を担うことで、プロダクトオーナーの役割を分担する。

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

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

DtoD関連資料

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

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

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

 

・書籍

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

 

書籍詳細は こちら

「Discover To Deliver に基づくアジャイル要求トレーニング」

「Discover To Deliver(DtoD)に基づき、納得感のある要求(ユーザーストーリー)を検討、 合意する方法を2日間で学習できるトレーニングをご用意しています。 グループワークで、要求獲得セッションを一通り体験できる内容です。
詳細・お申し込みはこちらから


オージス総研は1990年代から、反復開発やアジャイル開発に取り組み、大規模アジャイル開発の経験等を通じてノウハウを蓄積してまいりました。昨今は、上記、「DtoD」の紹介はもとより、下記取り組みを通じて、お客様のアジャイル開発、企業としてのアジャイルな取り組みを支援し続けています
  • アジャイル開発に取り組み始めた方向けのトレーニングコースの提供:
    「アジャイル開発超入門」、「スクラム入門」 など
  • 企業や事業部レベルでリーンとアジャイルのプラクティスを適用するために実証され、公開された
    フレームワークであるScaled Agile Framework(SAFe)の導入支援、トレーニング
  • アジャイル&リーン開発をサポートするALM、PPM全般をカバーするクライアント・サーバー型の
    アジャイル開発支援ツールHansoftの取り扱い など

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

 

ページトップへ戻る

お問い合わせ

お問い合わせ

アジャイル開発に関するお問い合わせはこちら