ユーザーストーリーマッピングをやってみた

#DevOps

#アジャイル

aratafuji

2018.11.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、DevOps導入支援担当の藤村です。

今回はアジャイル開発において、初期プロダクトバックログを作成する上でとても有益なプラクティスであるユーザーストーリーマッピングのワークショップを、株式会社パソナテックの皆様と実施してきたので、その内容をご紹介したいと思います。

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

ユーザーストーリーマッピングとは、ストーリー(ユーザーにとっての価値)を付箋紙などに書き出し、ユーザーの体験順に時系列で左右に整理、似た機能は上下(基本機能を上、派生的な機能は下)に整理して壁などにマッピングしていく手法です。

二次元の表に整理することでストーリーの抜け漏れに気づくことができるだけでなく、会話を通してプロダクトオーナーがストーリーに込めた思いを理解することができたり、複数のストーリーを分割する線を左右に引くことでリリース計画を表現することもできます。

やったこと

準備したもの

皆が集まれる時間(3時間)
会議室 × 3
- 今回は3拠点(東京、島根、ベトナム　ハノイ)をGoogle Meetでつないで実施しました
ホワイトボード
模造紙
付箋紙(3色)
水性ペン(黒)

当日の流れ

自己紹介、ワークショップの流れの説明
リーンキャンバス作成
- 課題
- 顧客
- 独自の価値提案
- ソリューション
インセプションデッキ作成
- エレベーターピッチのみ
ユーザーストーリーマッピング実施
- 実装済みフィーチャーのマッピング
- 今後実装したいフィーチャーのマッピング

それでは順に説明していきます。

リーンキャンバス作成

簡単に自己紹介、本日の流れを説明した後に、まずはリーンキャンバスの一部（課題, 顧客, 独自の価値提案, ソリューション）を参加者の皆さんと作成していくところからはじめました。リーンキャンバスはプロジェクターでLEANSTACKの画面を映しながら作成していきます。

いざリーンキャンバスを作成してみると、ターゲットの顧客については参加者の皆様の間で認識はあっていましたが、課題については人によって認識にズレがあることが分かりました。そのような状態でユーザーストーリーマッピングを始めてしまうと、人によって書き出すストーリーが誰の何の課題を解決するためのものなのかがぶれてしまい、一貫性のない結果に終わってしまうため、ユーザーストーリーマッピングを実施する前にまずはリーンキャンバスを作成し、このプロダクトは誰の何の課題を解決するためのものなのかの認識を合わせるところから始めることをお勧めします。

インセプションデッキ作成

次に、インセプションデッキのエレベーターピッチを参加者の皆様に考えてもらいました。インセプションデッキのテンプレートを以下からダウンロードし、こちらもプロジェクターで映しながら作成していきます。

blank-inception-deck

※このテンプレートの緑色の部分を書き換えていきます

事前にリーンキャンバスがしっかり書けていると、上から5個目まではある程度すんなり埋めることができるのではないでしょうか。

「課題」 => 「潜在的なニーズを満たしたり、潜在的な課題を解決したり」
「顧客」 => 「対象顧客」
「独自の価値提案」 => 「重要な利点、対価に見合う説得力のある理由」

一方、私がエレベーターピッチで一番難しいと考えているのは、「差別化の決定的な特徴」です。ここがすんなり書けないようなサービスは、本当に作る必要があるのかを今一度考え直すべきでしょう。

ここまででやっとユーザーストーリーマッピングを実施する準備が整いました。

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

今回の対象となるプロダクトはちょうど初回リリースを終えたタイミングだったので、まずは初回リリースに含まれていたストーリーを空色の付箋紙に書き出してもらいました。各ストーリーは以下のフォーマットに統一してもらうことで、誰向けの価値なのかを明確にしています。

「<役割>として<機能>ができる」

次に、似たストーリー同士を縦に並べ、それらに共通する名前(フィーチャー名)をピンク色の付箋紙に書き出してもらいました。ここまでは既にリリース済みのアプリを見ながら進めることで、特に混乱することなく進められました。一点注意すべきなのは、ストーリーを書く際に画面につられないということです。既に存在するアプリからストーリーを抽出しようとすると、どうしても画面とストーリーを紐づけて考えてしまいがちです。1画面1ストーリーの場合もあれば、複数画面1ストーリー、また1画面複数ストーリーなど、必ずしもストーリーと画面が一対一に対応するとは限りませんので注意しましょう。

続いて、これから実装していきたいストーリーを書き出していきます。今回はリーンキャンバスを書いた時点で解決したい課題が複数あったので、分かりやすいように一つ一つの課題ごとに時間を区切ってストーリーを書き出してもらいました。

ここで重要なのは、付箋紙に書き出して壁にマッピングする間は、一切会話を禁止することです。ユーザーストーリーマッピングなどのワークショップを行う際、課題解決のアイデア出しのような発散フェーズを会話しながら進めていくと、話が四方八方に発散し、収集がつかなくなることも多いかと思います。口を開くのではなく付箋紙に書き出すことに集中することで、ムダな会話を行わずにアイデアを収集します。また、壁にマッピングする際も無言で他の人が書いた付箋紙の優先順位(縦列の並び)を変えてもらいます。これも会話しながら行うと、一つ一つの順番を全員で確認しながら行うことになり、時間内にユーザーストーリーマッピングを終えることは難しくなるでしょう。もちろん人が並び替えた順序を別の人が元に戻すこともできます。将棋の千日手のように、参加者間で優先順位の考えの違いが平行線を辿った時に初めて口を開いて議論します。

一通りストーリーを出し切ったら、改めて全体を俯瞰して見てもらい、フィーチャーとストーリーの関係が適切か、同一フィーチャー内のストーリーの優先順位が適切かを皆で議論しながら整理してもらいました。

最後に次のリリースのスコープに何を含めるかを皆で考え、スコープの境界線として赤い線をストーリーの間に引いてもらいました。ここでは、一度のリリースに含めるストーリーの数を可能な限り少なくすることが重要です。サービスを考える立場の人は、一度のリリースでできるだけ多くのストーリーを含めたくなるかと思います。当たり前ですが、一度のリリースに含めるストーリーの数が増えると、その分リリースまでの時間が延び、その結果エンドユーザーからのフィードバックをもらえるタイミングも先に延びてしまいます。そこで、一番優先したいストーリーに絞って開発、リリースし、エンドユーザーからのフィードバックからの学びを元にユーザーストーリーマッピングの結果をアップデートしていくのが良いでしょう。

ここまでのステップを経て完成したものがこちらとなります。

ピンク色の付箋紙がフィーチャー名、空色の付箋紙がリリース済みストーリー、黄色の付箋紙が今後実装したいストーリー、左から右にかけてのジグザグな赤い線がリリースを区切る線となります。

反省点

冒頭で書いたとおり、今回は3拠点(東京、島根、ベトナム　ハノイ)をGoogle Meetでつないでユーザーストーリーマッピングを実施してみました。東京側でマッピングしている壁を常にiPadのカメラで撮影して共有してもらいましたが、やはり島根、ハノイの参加者が積極的に参加することは難しかったと思います。