“User Story Mapping“は、Jeff Patton氏が提案する計画手法です。バックログには背骨が欠けている（InfoQ）でJeff氏が説明するように、バックログを効果的に見える化することにより、システムの全体像を捉えようとしています。そして、ユーザーストーリーマッピングによって、UX（User Experience：ユーザーの体験）指向のストーリーとして整理され、より高いユーザーバリューへとプロダクトを導いていきます。
Jeff氏は、来年2月に『User Story Mapping』という書籍をオライリーからリリースするため、この手法がより広がっていく可能性があります。それでは、ユーザーストーリーマッピングの旅に出かけましょう。
ユーザーの行動を洗い出す
今回は、Jeff氏のプロダクトオーナートレーニングで学んだ方法を使って、ユーザーストーリーマッピングの作り方を確認します。
Jeff氏のトレーニングでは「映画を調べるアプリ」がお題でした。このアプリのバックログを作るために、まず、「映画を見る」行為に対する、活動（Activity）を付箋に書きだしてみましょう。
- ネットで面白い映画を調べる
- 見る映画を決める
- 劇場を探す
- 時間を調べる
- チケットネット予約をする
- 映画館に向かう
- チケットを発見する
- 映画チラシを見る
- ポップコーンと飲み物を買う
- スクリーンに向かう
- 映画を見る
- パンフレットを購入する
- 家に帰る
- 感想をブログに書く
私は映画館に毎週行っていた時期もあり、どちらかというとヘビーユーザーです。私の映画に対する活動は、上記のようになるのですが、映画を見るだけの行為であっても、人によっていろいろな活動があるでしょう。また、「ブログを書く」のように、見た後の行為も人によってあることに気がつきます。こういったユーザの活動や体験（UX）を中心に、ストーリーの地図を作っていきます。
ユーザーの行動を整理する
懸田さんのスライドがわかりやすいので引用させて頂きました。
関係者数人で活動を付箋に書き出し、それらをテーブルに並べます。Jeff氏は「ダイナミックに床や壁を使う」方法を推奨しているようでした。次に、似た活動を集めるように並べ、カテゴライズ、整理します。そして、ユーザーの行動の順番に並べていきます。カテゴライズされたタスクを下方向に並べ、右方向は時間軸と捉えます。
活動を動詞で表現する
次に、それぞれのカテゴリに名前（Activity）をつけます。アクティビティは「動詞」であることが望ましく、Jeff氏に確認したところ「チケットを買う」と書くよりも「買う」と書いたほうがシンプルに整理できるそうです。アクティビティは、上の図でいうと黄色い付箋のように、 カテゴライズされたタスクの上にラベリングします。
このアクティビティは、その名の通りユーザの活動を表し、バックログ上の背骨（Backbone）となるワークフローを意味するものになります。それぞれの活動には、カテゴライズされたタスクがぶらさがる形になります。
Jeff氏のトレーニングでは、用意されたバックログを使ってのワークショップがありました。タスクを床に並べ、次にこれから計画づくりを行います。
ユーザーストーリーマッピングを使った計画づくり
出来上がったバックログのタスクを見てみましょう。タスクはまだ、無造作に並んでいるだけです。重複するものをマージし、優先順位をつけていきます。
トレーニングでは、開発するアプリを利用するであろうユーザを、ペルソナとして複数用意し、ペルソナ別にタスクを優先順位付けしました。ペルソナを一番左に置き、青いテープでリリースするタスクを特定し、ユーザーごとにカテゴライズします。この青いラインがリリース計画となるのです。
例えば、私のような映画館のヘビーユーザの場合、「映画を調べる機能」や、「予約を簡単に済ませる機能」があると、とても便利になります。このように、対象となるユーザを優先順位付けし、さらに、ユーザにあわせて、タスクを優先順位付けすることもできます。
また、ユーザを考えずに、リリース計画を考えることもできます。
バックログは、優先順位の付けられた1方向にならんだものというイメージがありますが、Jeff氏の『ユーザーストーリーマッピング』を使うことで、時間という軸が加わり、ユーザーストーリーの地図が出来上がります。さらにそれを、ペルソナや、ことなった視点によって区切ることで、リリース計画が具体的に見えるようになります。
さらに、バックログからは想像が難しいシステムの全体図が、アクティビティから見えるようになり、ユーザーストーリーマッピングによってワークフローが表現されます。Jeff氏の手法によって、バックログにしっかりとした「背骨」ができたのです。
ユーザーストーリーマッピングの後に
リリース計画ごとにまとめられたタスクは、タスクボードへと移動し、「TodoからDoing、DoingからDone」へと状態遷移していきます。また、あるユーザを対象にしていたリリース計画を変更する場合は、ユーザーストーリーマッピングを一気に入れ替えればOKです。
まさに、「アジャイルな計画づくり」が可能になります。
参考
Jeff氏のサイトには、ユーザーストーリーマッピングの資料が公開されています。「Agile teams plan product construction in layers（アジャイルチームのレイヤごとの計画の作り方）」というスライドは、ユーザーストーリーマッピングの守備範囲がよく分かるため、必読だと思います。「Segmenting scope into incremental releases also segments use, user goals, （使い方やユーザゴールを考えたインクリメンタルなリリース）」というスライドは、きちんとビジネスゴールまで考えた、ミニマムの機能を備えたプロダクトのリリース計画づくりのポイントが、わかりやすくまとめられています。
ユーザーストーリーマッピングについては、懸田さんが公開されている資料にわかりやすく整理されています。
また、”ジェフ・パットン氏によるアジャイルな要件定義手法「ユーザーストーリーマップ」のチュートリアル“で@kawagutiさんが説明されているので、そちらも参考にしてください。
“バックログには背骨が欠けている via InfoQ“では、Jeff氏のインタビューが書かれており、ユーザーストーリーマッピングの目的が説明されています。
ユーザーストーリーマッピングは、まだ新しい手法ですので、現場ごとの工夫でさらに進化する可能性を秘めています。
旅と子育てとアジャイルコーチのブログ「世界」 