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

本記事の前半では、前回の記事の続きで主要概念であるビュー、構造化された会話、プロダクトの7側面の概要を説明します。また、後半では前回の記事で導入した「地域リユースオークションサイト」を題材にして事前ビューの計画/分析セッションの進め方を説明します。

DtoDの主要概念（続き）

計画策定ビュー

DtoDでは、価値観点を実現するためのソリューションの候補やオプションを以下の3つの計画期間範囲（ビュー）で考えます。

• 全体ビュー：複数のリリースを経たプロダクトのロードマップを考える
• 事前ビュー：次のリリースを構成するプロダクトオプションを考える
• 現在ビュー：次の反復で実現する要求を考える

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

これらのビューで議論される機能の粒度は以下のようになります。

• 全体ビュー：各リリースのソリューション候補
• 事前ビュー：「イベントと応答」や 1 回の反復で開発しきれないような大きめのユーザーストーリー
• 現在ビュー：1 回の反復で開発できるような通常のユーザーストーリー

なお、DtoDではユーザーストーリーをストーリーと呼んでいます。

事前ビューや現在ビューは以下の 3 ステップで構成される「構造化された会話」で検討を進めます。

• 調査する：プロダクトオプションを広く考える
• 評価する：価値と計画対象期間を考慮してプロダクトオプションを絞り込む
• 確認する：絞り込んだプロダクトオプションの妥当性を確認する

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

後述する例を読めば気付かれるかもしれませんが、これらの 3 ステップを必ずしも順番に行う必要はありません。「調査する」と「評価する」の 2 ステップは頻繁に繰り返され、「確認する」はそれらの 2 ステップの繰り返しで得られたプロダクトオプションの妥当性を確認するために実行されます。

「確認する」というステップで妥当性を確認するために行うことは、以下のようにビュー（プロダクトのソリューションやオプションの粒度）によって異なります。

• 事前ビュー：プロダクトオプションが提供された場合のシナリオを書いて、そのプロダクトオプションの妥当性を確認する
• 現在ビュー：セッションの結果として得られるストーリーに対する受け入れテストケースを定義する

現在ビューで定義された受け入れテストケースは、DtoDでは前提-条件-結果 ( Given-When-Then: GWT )という形式で定義されることを推奨されています。GWTの形式で定義されているテストケースは、Cucumberなどの受け入れテスト自動化フレームワークにより自動化することが可能であり、それにより繰り返し発生する受け入れテストの作業の手間を削減することができます。

プロダクトの 7 側面とプロダクトオプション

プロダクトを構成するオプションは、以下の 7 側面に渡って抽出されます。

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

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

これらのプロダクトの 7 側面の定義は、技術パートナーの一員として参加する分析者が支援します。

プロダクトの 7 側面は、開発すべきプロダクトのオプションを書き出す（貼り付ける）ための区画になります。DtoDでは、各側面について見出されたプロダクトオプションを記入する区画を設けたオプションボードというボードが用いられます。

ストーリーは、プロダクトのアクション側面のオプションとして位置づけられます。そのため、識別されたストーリーはオプションボードのアクション側面の区画に貼り付けられます。各側面は、短文記述や図で表現されます。それらの短文記述や図のいくつかは次の節以降で紹介しますが、より詳しい説明についてはDtoD本[1]や『実践ソフトウェア要求ハンドブック』[2]をご参照下さるようにお願いします。

事前ビューの計画/分析セッションの例

セッションの進め方を考える

事前ビューの計画/分析セッションの目的は、次のリリースを構成するアクション及びそれ以外の側面に対するプロダクトオプションにプロダクトパートナーが合意することです。そのために、まずセッションの切り口となるプロダクトの側面を決めて、それを起点に 1 つずつプロダクト側面を取り上げてプロダクトオプションを調査、評価します。さらに、プロダクトの全側面のプロダクトオプションが得られたら、確認によりそれらの妥当性を確認します。

DtoDを円滑に実行すると、このようなセッションを数時間という短時間で実施できるそうです。

事前ビューの場合に、プロダクトの各側面で考えるプロダクトオプションの識別方法や表現方法は以下のようになります。

ここで、この表で挙げている表現方法は、DtoDで推奨する表現方法の一部であること、及びビューによってプロダクトのオプションの表現方法は異なるという点に注意する必要があります。

「地域リユースオークションサイト」では、ユーザー側面を最初の切り口とし、そこからアクション側面、インターフェイス側面、データ側面、制御側面、環境側面、品質特性側面の順に検討することにします。

調査し、評価する

ユーザー側面

まず「地域リユースオークションサイト」のユーザー側面に注目します。ユーザー側面のオプションとしてロールオプションを使うとすれば、以下のようなオプションを識別することができます。

• リユース品を提供したい個人 → 出品者
• リユース品を購入したい個人 → 購入希望者
• オークションサイトの管理者 → サイト管理者
• オークションサイトの分析者 → サイト分析者

さらに、出品者や購入希望者に対するペルソナを考えることもできます。識別したユーザーロールをオプションボードのユーザー側面の区画に列挙します。

一通りユーザーロールオプションが識別できたら、調査を終えて次は評価をします。プロダクト擁護者がこれらのユーザーロールオプションで優先度の高いものを選びます。「地域リユースオークションサイト」では、とりあえずオークションの基本機能のユーザーを優先させることにします。

• リユース品を提供したい個人 → 出品者
• リユース品を購入したい個人 → 購入希望者
• オークションサイトの管理者 → サイト管理者

オプションボード上のこれら優先度の高いユーザーロールオプションに星印を付けます。

アクション側面

次に、アクション側面に注目します。アクション側面では、優先度の高いユーザーロールオプションに対してアクション側面のオプション（アクションオプション）を「イベントと応答」で識別するとします。すると、識別の結果は以下のようになります。

• イベント：出品者が不用品をオークションに出品する
• 応答：オークションサイトは、リユース品を入札条件とともに掲載する
• イベント：購入希望者が購入したいリユース品を探す
• 応答：オークションサイトは、購入希望者の条件にマッチするリユース品の一覧を表示する
• イベント：購入希望者は、リユース品を応札する
• 応答：オークションサイトは、購入希望者の入札を受け付ける
  • その応札を他の購入希望者に通知するとともに、その応札が他の応札よりも条件が良いかを判定する
• イベント：入札期限が終了する
• 応答：オークションサイトは、応札の受付を終了し、落札者に通知する

「イベントと応答」では、システムを使うことになったなんらかのきっかけを「イベント」と呼び、それに対するシステムの応答を「応答」と呼び、イベントとそれに対する一連の応答によりアクションを表現します。このようにアクションを記述することで詳細に立ち入ることなく、リリースを構成する機能をすばやく識別することができます。なお、「オークションサイトは、購入希望者の応札を受け付ける」の下のインデントした行は応答としてはやや詳細すぎるので応答自身とは分けて記述しています。

実際に識別できるイベントと応答はもっと多いでしょうが、上記の例は評価において優先度が高いと思われるものだけを示しました。これら識別されたイベントと応答は、オプションボードのアクション側面の区画に記入されます。また、ユーザー側面と同様に識別されたイベントと応答の中で優先度が高いものをプロダクト擁護者が選択します。

インターフェイス側面

次に、インターフェイス側面に注目します。インターフェイス側面では、優先度の高いユーザーロールオプションがアクションオプション（イベントと応答）を実行する際に発生しうる相互作用を識別します。このような相互作用を高いレベルで表現する手段としてコンテキスト図を用いることができます。

コンテキスト図とは、最上位のレベルのデータフローモデルであり、対象システムに対するデータの入力、出力などを図示するものです。例えば、「落札したリユース品の代金のクレジットカードでの決済」というオプションを考えると、コンテキスト図では「オークションサイト」と「クレジット決済システム」との間で「クレジットカード決済情報」と「決済結果」などのデータのフローと表現できます。得られたコンテキスト図でも、プロダクト擁護者が評価を行い、優先度の高いデータフローを選択します。

これまでの側面と同様に、検討の結果得られたコンテキスト図をオプションボードのインターフェイス側面の区画に貼り付けます。

データ側面

次に、データ側面に注目します。データ側面では、優先度の高いユーザー、アクション、インターフェイスのオプションに関係するデータ側面のオプション（データオプション）を識別します。データオプションは、概念データモデルや論理データモデルで表現することができます。優先度の高いアクションオプションに基づいて、地域リユースオークションサイトのデータオプションを識別した結果が以下の図です。

データ側面のオプションについても評価を行い、プロダクト擁護者が優先度の高いものを選択します。インターフェイス側面と同様に、検討の結果得られた概念データモデルをオプションボードのデータ側面の区画に貼り付けます。

概念データモデルを考えることにより、業務用語の揺らぎに気づいたり、業務用語の間の関係をより正確に理解することができます。また、そのように気づいたことや理解に基づいて、他の側面のオプションの内容との一貫性を高めることができます。例えば、1つの業務上の概念に2つの呼び方が存在した場合、それらを整理せずにアクションオプションを記述すると開発チームは2つのエンティティーを定義してそれらにバラバラにアクションの結果を反映する恐れがあります。ここでデータ側面を考えることで、2つの呼び方が同一の業務上の概念を表していることに気づけば、そのような問題を防ぐことができます。

同様に、オークションサイトに対するビジネスルールオプションを制御側面で調査、評価し、環境側面では開発環境や運用環境のオプションを調査、評価し、品質特性等に関するオプションを品質特性側面で調査、評価し、オプションボードに貼りつけていきます。

第 2 回の終わりに

今回の記事の前半では、まず前回の記事の続きで主要概念であるビュー、構造化された会話、プロダクトの 7 側面の概要を説明しました。また、後半では前回の記事で導入した「地域リユースオークションサイト」を題材にして事前ビューの計画/分析セッションの進め方を説明しました。

今回の記事で、DtoDでのセッションの進め方の概要はなんとなくつかめたのではないかと思います。次回の記事では、事前ビューの計画/分析セッションの「確認する」というステップを中心に説明する予定です。

参考文献

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