だいぶ時間があいてしまいましたが、ユーザーストーリーのセミナーに参加してきましたので、そのメモです。

アジャイル開発で要望の表現に用いるユーザーストーリー入門 | 株式会社オージス総研

ユーザーストーリーマッピング

すでに多くの記事やスライドが公開されていますので、詳細はそちらに譲りますが、すごく大雑把に言えば簡潔なフォーマットでユーザーストーリーを書き出し、それらをリリースや要求種別を軸に並べ替え製品全体のユーザーワークフローを見えるようにしたものをユーザーストーリーマッピングといいます。

参考： speakerdeck.com

よくある悩み

ユーザーストーリーマッピングはシンプルで素晴らしいものですが、ソフトウェアの機能的な要求ばかりに目が行きがちです。また、3C（カード、会話、確認）というプロセスはあれど、抜け漏れの防止や発想の仕方まではカバーすることが難しい面があります。特に実現性や品質特性なども踏まえて検討するには、異なる視点の人々を参加させる必要があります。

その不足を補うために提案されたのがDtoD（Discover to Deliver）という手法です。今回のセミナーはこのDtoDを実際に試して学ぼうというものでした。

DtoD

資料はオージス総研さんのWebページで公開されています。

DtoD手法に基づくアジャイル要求 | 株式会社オージス総研

「Discover to Deliver」は、米EBG Consulting社のエレン・ゴッテスディーナーとメアリー・ゴーマンによって考案されたフレームワークです。特徴を記事より抜粋します。

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

合意形成まで如何に早く到達するか、が重要なポイントのように思います。そのために、ワークショップを開催し、多面的に要件を捉えるためのフレームワークを提供する、という感じでしょうか。分析者がファシリテーターになるというのも面白いですね。プロダクトオーナー1人をたてて集中させるのではなく、分業することでチームによるプロダクトづくりを推進していけるように思えます。

How to

DtoDは以下のステップで進んでいきます。

プロダクトビジョン、目的、目標を決める
プロダクトパートナーを整理する
価値観点を整理する
7つの側面それぞれのオプション（選択肢）を考える
価値観点を実現するオプションの組み合わせをストーリーにして考える
絞り込んだオプションの妥当性を確認する

1. プロダクトビジョン、目的、目標を決める

プロダクトが誰を対象にしており、他のプロダクトと違うどのような特色を持つか等を簡潔に記述した プロダクトビジョン を作成します。そして、達成すべきことを定性的に箇条書きしたものを目的、目的に対する定量的な指標を目標と呼びます。

DDDでもドメインビジョン声明文というものがありますが、これとの関連はまた別の記事で考えたいと思います。

2. プロダクトパートナーを整理する

DtoDでは3種類のプロダクトに関わる人（パートナー）を定義しています。記事より抜粋します。

顧客パートナー
ユーザーの立場でプロダクトを使う人
業務パートナー
プロダクト開発の予算を獲得し、ビジネス目的やビジネス目標の達成に責任を持つ人
技術パートナー
プロダクトを開発したり、運用する人

プロダクトパートナーの中で要となるのはプロダクトオプションの取捨選択をする人であり、DtoDでは プロダクト擁護者 と呼びます。プロダクト擁護者はスクラムではプロダクトオーナーに相当し、業務パートナーの一員です。このステップ以降の価値観点の検討する中心になるのは、プロダクト擁護者を含む業務パートナーと技術パートナーの立場の人です。技術パートナーには、分析者やアーキテクトが参加していることが望ましいとされます。

3. 価値観点を整理する

価値観点とは、プロダクトによって提供したい価値です。これは、 「このような価値を提供すればそれによりビジネス目的やビジネス目標を達成できるだろう」 という仮説です。アジャイル開発では価値観点を実解するソフトウェアを早期にリリースして仮説を検証していきます。

ここでの整理は、前述のパートナーそれぞれの視点でプロダクトが提供すべき価値を考えます。手順としては次のような形です。

先の各プロダクトパートナーの中から特に重要なパートナーを選ぶ
そのパートナーが何を得るかを列挙する
その中から特に重視するものをピックアップする

書籍「ユーザーストーリーマッピング」の中でも、ユーザーストーリーマッピングの中で、特に重視するロールを絞って計画をたてる事例が出ていましたが、それと同様に注力するところを決めることが大切です。私たちは望む全てを手に入れられないという現実を受け入れて、その限られた時間をどこに注力するかを決める必要があります。

4. 7つの側面それぞれのオプション（選択肢）を考える

プロダクトオプションとは、イテレーションやリリースで作成されるプロダクトを構成しうる1つの 選択肢 です。 DtoDでは、複数のプロダクトオプションを識別して、それらの中で作るものを取捨選択していくことが中心的な活動になります。

このプロダクトを構成するオプションは、以下の7つの側面で考えていきます。記事より抜粋します。

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

これらの定義は、技術パートナーの一員である分析者が支援します。 7つの側面は区画であり、見つけたプロダクトオプションはその区画に貼り付けていきます。これをオプションボードと呼びます。

例： http://www.ogis-ri.co.jp/pickup/agile/docs/EducationSystemOptionBoard.pdf

7つの側面の内、品質特性などはストーリーに現れるというより非機能要求として検討されるものです。ユーザーストーリーから考え始めることで漏れがちな非機能面をここでカバーできるのがポイントのように思います。動くソフトウェアをリリースするには、環境や品質特性も重要なオプションです。

5. 価値観点を実現するオプションの組み合わせをストーリーにして考える

オプションボードに貼り付けられた優先度の高いプロダクトオプションから（粒度の大きな）ストーリーを組み立てます。このときのフォーマットはユーザーストーリーと同じく、以下のような形式にします。

＜役割＞として＜機能、サービス＞ができる　それにより＜価値＞がもたらされる

この＜役割＞と＜機能、サービス＞のところに、ユーザー側面やアクション側面、データ側面などの言葉を使います。

オプションを整理して、重要なものを組み合わせることで、より洗練されたストーリーをつくることができるように思います。いきなりストーリーを書きだした場合、個人の主観が混じりやすく、またどれも必要なように見えてしまいます。選択肢というより小さなものから組み立てるという点がポイントですね。

6. 絞り込んだオプションの妥当性を確認する

後述の3つのビューにおいて、それぞれ行うことが異なります。

事前ビューでは

優先度の高いオプションからストーリーを作ったら、それに対するシナリオを記述して妥当性を確認します。シナリオとは、ユーザーの観点にたって、プロダクトを利用する具体的な状況を記述したものです。このとき、全体として最低限必要な機能が網羅されているかも確認します。

現在ビューでは

ストーリーに対する受け入れテストケースを定義します。 DtoDでは前提 - 条件 - 結果（Given - When - Then：GWT）の形式で受け入れテストケースを作成することが推奨されます。

"分析"という面が強めにあらわれているように感じますね。先に述べた通り、ここまでの内容が素早く合意形成されることは、ひとつの目指すところです。

3つの計画期間範囲（ビュー）

DtoDは、3つの計画期間範囲（ビュー）を用います。

全体ビュー
プロダクトのロードマップを考える
事前ビュー
次のリリースを構成するプロダクトオプションを考える
現在ビュー
1回のイテレーションで実現する要求を考える

前述4〜6を"構造化された会話"と呼び、事前ビューや現在ビューはこれによって検討が進められます。事前ビューで検討した粒度の大きなストーリーから、現在ビューでは更に同様の手順で深掘りをして、粒度の小さなストーリーにします。

事前ビューでは、妥当性が確認できたら、ストーリーを開発する労力を見積もり、次のリリースで予定するかなどを確認します。このリリース計画は事前ビューの最後のアウトプットです。事前ビューでは、価値の高いプロダクトオプションを調査、評価、確認して、リリース計画を作成します。

構造化された会話

"構造化された会話"は3つのステップで構成されます。

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

これらの3ステップは必ず順番に行う必要はありません。調査と評価は頻繁に繰り返し、確認はそれらで得られたものに対して行います。

感想

実際にセミナーで体験してみると、とりあえずユーザーストーリーを考えだすよりも、DtoDを用いた方が進め方が分かりやすかったです。プロダクト開発は正解のわからない中で進めなければいけないので、DtoDを用いたとしても迷いがなくなるわけではありません。やはり最終的には人と人の会話によって、プロダクトは形作られるものと思います。その会話のきっかけや議論の順序というものをDtoDのようなフレームワークで補うという点は良かったと思いました。

一方で、セミナーではかなり短い時間設定で体験したため、実際にこれらを毎イテレーションの最初に行うと実は重いのではないかとも感じますが、そこは試してみないと判断できないところです。毎回7側面すべてをゼロから考え直すわけではなく、反復の中で蒸留していく考えだと思うので、重すぎるとまではいかないと思いますがどうなんでしょう。チームの習熟度やパートナーとの関係なども踏まえて工夫しなければいけないのは、どんな手法でも変わらないところですね。

本当はDDDとユーザーストーリーマッピング、そしてDtoDで絡めて書きたかったのですが、力尽きたのでまた機会があれば改めて書きたいと思います...