プロダクトマネージャーの zak です。 この記事では、実際にテックタッチの開発チームで行ったユーザーストーリーマッピングの様子を紹介します。
ユーザーストーリーマッピングとは
「ユーザーストーリーマップ」とは、ユーザーと対象製品とのやり取り（ユーザーの体験）をステップ別に分解した図です。
ユーザーの体験にフォーカスすることで、チーム内でよりよい会話が生み出され、ビジョンを共有しやすくなり、結果としてよりよいプロダクトを提供できるようになります。
詳細については割愛しますが、以下の2つの Webサイトを参考にして、ワークショップのイントロダクションとして読み合わせを行いました。 ユーザーストーリーマッピングを体験したことがないメンバーが大半でしたが、チーム内でユーザーストーリーマッピングへの認識を揃えられました。
より詳細な情報が必要な場合はこちらの書籍がおすすめです。 前半はストーリー仕立てでユーザーストーリーマッピングについて記載されており、後半部分はユーザーストーリーの取り回しについての解説されている構成になっています。
やったこと
実施の背景
- 大規模な開発に向け新チームを組成するにあたり、新チームでの活動内容の青写真をチーム全員で共有するため
- プロダクトオーナー（私）の頭の中には、課題を解決するために必要な機能の大まかなイメージが存在していました。チームメンバーとともに議論することで、開発する機能やその順序をより精緻なものにするため
- 機能のメインターゲットとなる顧客はいわゆるエンタープライズ企業であり、チームメンバーの経験からは要件やその背景が想像しづらく、より時間をかけてユーザー理解を進める必要があったため
実際にやったこと
参加者
総勢10名で行いました。
エンジニア（6名）、デザイナー（1名）、QAエンジニア（1名）、プロダクトオーナー（1名）、スクラムマスター（1名）
実際のアジェンダ
■イントロダクション
- PO から顧客ペルソナ、要件、機能のラフ案などを説明（10分）
- ユーザーストーリーマッピングの説明（15分）
- 前述の通り、わかりやすい説明が掲載されているWebサイトを2つピックアップしておき、チーム全員で読み合わせを行いました
■本編
Miro 公式が提供しているこちらのテンプレートを利用しました。
予めアクティビティ、タスク、ストーリー、リリースラインが設定されているため、テンプレートを修正することなく直感的に使い始めることができました。
また、Miro であれば、関連資料を同じボードに埋め込んでおくことや、詳細な議論が発生した際のホワイトボードとして利用することができるので、非常に便利でおすすめです。
- タスク(ユーザーの動作 ※画像内の黄色の部分)を各自が同時編集で書き出す（10分）
- ここまで：会話の種が蒔かれている状態
- 書き出したタスクを起票者が説明しながら、チームメンバーで会話を進める。同時にアクティビティ(タスクの上位概念 ※画像内青色の部分))を追加する。（20分）
- 会話の中でタスクを新たに追加したり、類似のものを統合したり、逆に分割したりといった整理が行われます
- ここまで：最初から終わりまでユーザー体験のおおまかな流れが見通せている状態
- 各タスクに紐づくユーザーストーリー(※画像内の灰色の部分)を各自で書き出す （15分）
- 書き出したユーザーストーリーを起票者が説明しながらチームメンバーで会話を進める。（20分）
- 会話の中で、新規のユーザーストーリーを追加したり、類似のものを統合したりといった整理が行われます
- ここまで：タスク（場面）に応じたユーザーの要求が明らかになっていて、開発する機能のイメージが膨らんでいる状態
- リリースライン（複数可）を設定することで、各リリースで提供できるユーザー価値とそれに必要な機能を整理する（20分）
- ユーザーストーリーを「リリース」というグループに分類することで MVP が定義されます
- もともとのテンプレートにはない項目ですが、各リリースで実現したいことやリリースの位置づけを明文化すると共通認識を形成しやすかったです（例：xxxxxができるようになる、ただしUIの使いやすさは劣後）
- ここまで：優先するべき対象が明確になり、開発する機能の順序や依存関係が可視化されている
以下の画像が実際にできあがったユーザーストーリーマップです。
リリースは5回に分かれており、それぞれのリリースで段階を追ってユーザーストーリーが実現されていくように計画されています。
（公開できる情報がほとんどなくモザイクだらけになっていますが、雰囲気だけでも掴んで帰って下さい。）
やってみた感想
チーム内で会話が生まれるよいきっかけになった
ユーザーストーリーマッピングという決められたフォーマットに沿って進めることで、実施のハードルは低かったです。
職種や雇用形態を問わずチームメンバー全員が参加して、それぞれの立場からアイディアや意見が飛び交う活発なものになりました。
また、会話の中でペルソナの重要性を認識できたため、ペルソナをより詳細に設定しようというアクションにつながるという相乗効果も生まれました。
肝はリリースラインの設定
このテンプレートで優れていると思う箇所は「リリースライン」です。
ユーザーに届けるべき価値の中で重要なものを考えるよいきっかけになりました。また、タスクが左から右に並んでいることで体験全体を見渡すことができるためリリースに含まれるストーリーに過不足がないかを簡単に確認できました。
作って終わりではない
ユーザーストーリーマッピングが終わって、開発フェーズに入った後も何度も参照、修正する機会がありました。
特に前述のリリースラインについては、時間が経って議論が深まっていく中でよりよい分類があることに気付けたため、修正しました。
大きな開発案件を進めている中で、全体像が見えなくなる（忘れてしまう）こともしばしばありますが、マッピングが理解の大きな助けになる場面がありました。
参加者の声
エンジニアAさん
色々なことについて共通認識を作ることができた。
リリースの単位を分けることができた。何を最低限最初にリリースして、どう膨らませていくのか。
MVP がその内容で MVP たる所以をみんな知って納得することができた。
PO
一人では気づけなかった要件や仕様の考慮漏れにも気づくことができた。
エンジニアBさん
ワークショップから始めてタスクの意図や MVP の切り出しがすっと頭に入ってきた。
xxxxの機能とか結論だけ聞いていたら腹落ちしにくかったかも。
MVP をちゃんと切り出せてた。大抵膨らみがちなので。
