本記事では、アジャイルなプロダクトの計画策定や分析に役立つ DtoD (Discover to Deliver)というフレームワークの概要を説明します。本記事の前半では、DtoDが登場した背景を説明し、後半ではDtoDの主要概念であるビジョン、目的、目標、価値観点の概要を説明します。なお、DtoDが登場した背景の文章はDtoD本 [1] の書籍紹介の文を再利用していますが、その点は御容赦のほどお願い致します。
DtoDが生まれた背景
2001年にアジャイル開発宣言が起草されて以来13年が経過し、欧米ではアジャイル開発が当たり前になってきています。そのようなアジャイル開発の普及に大きく貢献したのが「アジャイル開発のミニマムセット」と呼ばれる「スクラム」 [2] というコンパクトなアジャイル開発フレームワークです。「スクラム」は、単純化すると以下の4つの特徴を持ちます。
- スプリントという一定の期間毎に動くソフトウェアを作る
- 要求はプロダクトバックログという優先順位付けされた一覧表に保管される
- 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
- スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う
1.のように一定期間毎に動くソフトウェアを作ることを本記事では時間枠（タイムボックス）納品と呼びます
スクラムは、優先順位付けされたバックログ項目の優先順位順に動くソフトウェアを作り、作成されたソフトウェアを評価する形で開発を進めることに可能にしました。その結果、開発依頼者や市場のニーズに即したソフトウェア（プロダクト）をすばやく開発することが可能になりました。この利点がスクラムの普及の大きな原動力となったのです。
その一方で、スクラムはコンパクトなアジャイル開発フレームワークとして誕生したために以下のようなことの具体的な実行方法が当初提示されていませんでした。
- プロダクトバックログ項目の表現形式
- プロダクトバックログ項目の定義プロセス
これらについては、スクラムが発展する過程で、XP(eXtreme Programming) [3] というアジャイル手法の考え方を取り入れて 1. として図 2に示すようなユーザーの声形式の「ユーザーストーリー」を用いることや、2. として Ron Jefferies の 3C （カード、会話、確認）の3段階でユーザーストーリーを発展させる方法が提案されました。
- カード：1 枚の情報カードにユーザーストーリーを書き記す
- 会話：カードは、ユーザーストーリーの詳細をさらに会話する約束を表す
- 確認：カードに記されたユーザーストーリーが完了したかどうかの判断のための受け入れ基準を設定する
さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案されました。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になりました。
ただ、これらはユーザーストーリーの表現形式やそれを検討する過程を3段階で発展させ、さらに計画と結びつけた方がよいということについて優れたアドバイスではあるものの、ユーザーストーリーをどのように考案するのかという具体的な方法を示すものではありません。また、具体的な方法が示されてもその方法によりプロダクトオーナーが単独でユーザーストーリーの考案や優先順位付けを実際に行えるのかという問題もあります。
また、ユーザーストーリーはソフトウェアの機能的な要求しか表現しておらず、データや品質特性、環境などプロダクト開発に関係するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することには役不足です。言いかえれば、従来開発の分析に相当する作業が入りこむ余地があまりないのです。確かに従来開発の分析作業はある程度の専門性が求められ、時間もかかりますし、文章を中心とした成果物を作るという点でもアジャイル開発とは相いれないものと思われるかもしれません。しかし、業務システムのように多数の利害関係者が関与するプロダクトに対するニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成することが求められる場合も多いでしょう。
DtoDとは
「Discover to Deliver (DtoD)」 [1] は、ファシリテーション [4] と要求/分析 [5] の分野で長年に渡り活躍してきた米国EBG Consulting社のエレン・ゴッテスディーナーさんとメアリー・ゴーマンさんが考案したフレームワークであり、従来開発の要求定義や分析作業を以下のように変えてアジャイル開発とうまく組み合わせられるものに発展させるものです。
- ワークショップの活用
- 専門家単独で行うのではなく、顧客、業務、技術という異なる視点の人々が参加するワークショップを開催して、迅速にニーズをより多面的に理解し、表現し、開発内容を検討し、合意を形成する。
- 多様なモデルの活用
- ワークショップで、ニーズや開発内容を軽量でとっつきやすい様々なモデル（短文記述や図等）により多面的に表現し、理解する。これらは、「プロダクトの7側面」という形でまとめられる。
- 分析者の役割の変更
- 分析者がワークショップのファシリテーターやモデラーの役割を担うことで、プロダクトオーナーの役割を分担する。
ここでプロダクトと言っているのは、開発の結果として作成されるものであり、一般消費者が使うソフトウェアやハードウェア製品やクラウドサービスだけではなく、業務システムのように特定の企業の業務を支援するシステムも含みます。
DtoDでは、要求定義、分析、計画策定を行うワークショップを計画/分析セッションと呼びます。DtoDの計画/分析セッションは、複数のリリース（全体ビュー）、次のリリース（事前ビュー）、次の反復（現在ビュー）という3つの計画策定期間に対して開催します。
また、先の説明ではスクラムを補うものとしてDtoDを説明してきましたが、DtoDはこれらの計画/分析セッションの開催のタイミングを調整することで、カンバン（フロー納品）や従来開発（従来納品）の中でも活用することができます。
以降の節では、DtoDの主要概念を地域リユースオークションサイトという架空の例を交えて説明します。
DtoDの主要概念
プロダクトパートナーと価値観点
DtoDを開始する時点で、まずプロダクトビジョン、目的、目標が決める必要があります。プロダクトビジョンは、プロダクトが誰を対象にしており、他のプロダクトと違うどのような特色を持つか等を簡潔に記述したものです。
DtoDの主要概念に対する具体的なイメージを提供するために、ここで環境に優しい社の地域リユースオークションサイトという例を考えてみます。
背景：
環境に優しい社は、近畿圏を中心にいくつかのリサイクルセンターを持ち、家庭の不用品のリサイクルを行っていた。ただ、環境に優しい社は自社のリサイクル技術をwebで説明することで、不用品の処理を行いたいと考えている個人にアピールしてきたが、最近他社も同様の技術をアピールするようになったためにビジネスが頭打ちになってきている。このままでは、会社の将来は危ういと考えた経営陣は地域内のリユースオークションサイトを運営することで、不用品のリユースを向上させるとともに、自社のリサイクルビジネスの知名度も向上できるのではないかと考えた。
地域リユースオークションサイトのビジョン：
地域内のリユースオークションサイトを提供することにより、単なるリサイクルに留まらない、個人間のリユースを促進し、地球環境の保護に貢献する。自社のリサイクルセンターを介した商品の受け渡しを可能にすることで、オークションで取引された商品の運送料を節約できるようにする。将来的に、地域リユースオークションサイトがある程度成功をおさめたら、このオークションサイトの外販を考える。
次に、地域リユースオークションサイトのビジョンに対して達成すべきビジネス目的とビジネス目標を設定します。DtoDでは、達成すべきことを定性的に箇条書きにしたものを「目的」と呼び、「目的」に対する定量的な目標を「目標」と呼びます。
- 目的：
- 地域リユースオークションサイトを通じて、リサイクルビジネスの潜在顧客を増やす
- 地域リユースオークションサイトの手数料収入により、リユースオークションサイトの運用費用の持ち出しをなるべく減らす
- 目標：
- オークションサイトの登録者数として10,000名を目指す
- オークションの取引件数として1000件、取引高として初年度100万円を目指す。
続いて、これらのビジョン、目的、目標を起点にして、次にプロダクトが利用者にもたらす定性的な価値を考えます。つまり、プロダクトがどのような価値をもたらしうるかということです。この定性的な価値をDtoDでは、「価値観点」と呼びます。「価値観点」は、プロダクトの価値について「このような価値を提供すればそれによりビジネス目的やビジネス目標を達成できるだろう」という仮説です。アジャイル開発では、「価値観点」を実現するソフトウェアを早期にリリースすることでこの仮説の妥当性を確認します。
DtoDでは、価値観点や開発すべきプロダクトオプションを以下の3種類のプロダクトパートナーが連携して検討します。
- 顧客パートナー：ユーザーの立場でプロダクトを使う人
- 業務パートナー：プロダクト開発の予算を獲得し、ビジネス目的やビジネス目標の達成に責任を持つ人
- 技術パートナー：プロダクトを開発したり、運用する人
出典: エレン・ゴッテスディーナー、メアリー・ゴーマン 著, 『発見から納品へ：アジャイルなプロダクトの計画策定と分析』, BookWay, 2014. 56
ここでプロダクトオプションとは、反復やリリースで作成されるプロダクトを構成しうる 1 つの選択肢です。DtoDでは、複数のプロダクトオプションを識別し、それらの中で反復やリリースで作るべきものを取捨選択するということが最も中心的な活動になります。
プロダクトパートナーの中で要となるのはプロダクトオプションの取捨選択を決める人であり、DtoDではこの人をプロダクト擁護者と呼びます。プロダクト擁護者は、スクラムでプロダクトオーナーに相当し、業務パートナーの一員です。
価値観点を検討する際の中心になるのは、プロダクト擁護者を含む業務パートナーと技術パートナーの立場の人です。その際に、技術パートナーとしては分析者やアーキテクトなどの立場の人が検討に参加した方がよいでしょう。
分析者は、技術パートナーの一員として後述するプロダクトオプションの分析を支援します。また、プロダクトオプションの技術的な実現性や品質特性をある程度考えられるという点でアーキテクトが参加する必要があります。
地域リユースオークションサイトについて前記の目的や目標が達成されるために、プロダクトが提供すべき価値を3種類のプロダクトパートナーの視点で考えると以下のような価値観点が考えられます。
- 価値観点：
- 顧客
- 利便性：欲しいものがすぐに見つかる、簡単に出品ができる
- 経済性：新品よりも安く購入できる
- 業務
- 信用：入金後に確実に商品が届く
- 環境保護：地球の温暖化を防ぎ、ごみを減らす
- プライバシー：利用者の個人情報が確実に守られ、安全に利用できる
- 法令順守：個人を偽装した法人の取引は許さない
- 技術
- マルチデバイス対応：PC、スマホ、タブレットなどに対応する
- 顧客
第 1 回の終わりに
今回の記事の前半では、DtoDが登場した背景を説明し、後半ではDtoDの主要概念であるビジョン、目的、目標、価値観点の概要を説明しました。次回は、価値観点の識別の次に実施するプロダクトオプションの識別で登場する以下の主要概念を紹介する予定です。
- ビュー
- 構造化された会話
- プロダクトの７側面
- プロダクトオプション
参考文献
[1] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプロダクトの計画策定と分析, BookWay, 2014
[2] ケン・シュエイバー, マイク・ビードル, アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
[3] ケント・ベック, XPエクストリーム・プログラミング入門―変化を受け入れる, ピアソンエデュケーション, 2005
[4] エレン・ゴッテスディーナー, 要求開発ワークショップの進め方, 日経BP, 2007
[5] エレン・ゴッテスディーナー, 実践ソフトウェア要求ハンドブック, 翔泳社, 2009