僕の所属する HERP では、プロダクトを作る際にしょっちゅうユーザーストーリーマッピングをしている。プロダクト全体から小規模な機能まで、僕がこれまでやったユーザーストーリーマッピングの回数は数十回に上るはず。
特に、大きめの機能の全体像についてのユーザーストーリーマッピングはほぼ必須だと感じている。
というのも、大きい機能に対してありえる幅広いニーズを捉えることで将来像についての共通認識を持てる上、そこからMVPとして必要なものを切り出していくと、将来を見据えた設計を織り込んだ開発に入りやすいためだ。
また、MVP やその後のリリースで作るものについて見える形で合意しておけるので、あとからわかったニーズをどの段階で織り込むのかについても柔軟に対応しやすくなる。
この辺の嬉しさについては巷で言われてることでもあるし、HERP での具体例については以下の記事でも詳細に紹介しているのでそちらも参照してほしい。

ということで、ユーザーストーリーマッピング最高！これぞ銀の弾丸です！……と昔は素朴に思っていたが、最近なんとなくユーザーストーリーマッピングに難しさを感じる機会が増えてきていた。

そこで、通常のユーザーストーリーマッピングよりブレスト性を高めたやり方を始めてみたところ、これがたいへん捗ると気づいた。このやり方を「ブレスト的ユーザーストーリーマッピング」と個人的に呼んでおり、この記事で紹介したい。

ブレスト的ユーザーストーリーマッピングの進め方

これまで HERP でのユーザーストーリーマッピングは、大抵以下のように進んでいた。

1. 登場人物の洗い出し

2. 軸となる大きなストーリーの策定

3. 詳細なストーリーの洗い出し

4. リリースラインの設定

ユーザーストーリーマッピングの完成図を上から下に、具体性をだんだん高めていく方針だった。

例えばこの記事を書く際のユーザーストーリーマッピングは以下のように進む。

一方、ブレスト的ユーザーストーリーマッピングでは、ざっくりいうとユーザーストーリーをガンガン出していくやり方になっている。

1. 思いつく限りユーザーストーリーを出しまくる

2. ある程度出たらカテゴライズしていく

3. 各カテゴリを見ながら、思いついたユーザーストーリーを更に追加する

4. リリースラインを設定する

実際にこの記事でもやってみると、以下の通りになる

ざっくり元のやり方の逆になっており、さらにアイディアを足す余地を増やしているのが伝わるだろうか。
いわゆる発散と収束を繰り返す点が、ブレインストーミングから取り入れた箇所になっている。

「ブレスト的」なので、すすめる際の注意点はほとんどブレインストーミングと一緒で、だいたい以下のことに注意すると良い。

1. アイディアを否定せず、変なアイディアが出るのを歓迎する

2. 他の人のアイディアを参考に新たなアイディアを発見する

3. 質より量を重視する

4. 発散と収束を繰り返す

ブレインストーミングは広く受け入れられた方法だから既存のプラクティスも巷に多いので、それを参考にするとよいだろう。
例えば https://www.lucidchart.com/pages/ja/brainstorming など。

何がいいのか

ということで、普通の記事なら課題を提示してからやり方を紹介するところだが、いきなりやりかたを紹介してしまった。
というのも、この手法は正直思いつきでやったものであり、結局何が良かったのかは自分でも明確には言語化出来ていないためだ。

とはいえ、何度かこの手法をやる中で、この手法の良さみたいなのがなんとなく見えてきたので紹介してみる。

不確実性に対処しやすい

まず、この手法は不確実性が高い状況で特に便利であると感じている。
というのも、不確実性の高い状態では登場人物や大きなストーリーを描ききるのがそもそも難しい。
ある程度はその段階での仮説をもとに作ることもできるだろうが、その大きなストーリーが誤っていた場合ユーザーストーリーマッピング全体が揺らいでしまうので、リスクが大きい。
一方ブレスト的ユーザーストーリーマッピングでは、先に大きなストーリーを固定せず色々なアイデアを盛り込んでいくので、不確実な状況の中でわかっていることもわかっていないことも反映しやすい。
「ありえるかもしれない」程度のニーズが組み込めるユーザーストーリーは、未知の未知に遭遇したときにも対処しやすいんだと思う。

理解度の個人差が見えやすい

次に、このやり方だと理解度の個人差が見えやすい気がする。
なんといってもブレストなので、確からしさや現状の理解度などの質にこだわるよりも、量にこだわってアイディアをたくさん出すのが推奨される雰囲気を作ることになる。
すると、ユーザーや業務についての理解が浅いメンバーがいても、彼らが現状の理解でどんな物が必要と考えているのがわかる。
これを見ると、参加メンバー間での理解度のギャップがわかるので、ユーザーストーリーマッピングの目的であるところの共通認識の醸成がしやすくなると感じる。

HERP ではオンラインホワイトボードツールの miro を使ってユーザーストーリーマッピングを行うことが多い。なので、列や記入者やラベルなどを柔軟に使いながら、誰が書いたユーザーストーリーなのかを見やすくしており、これはオススメ。

多様な観点を組み込みやすい

一つ前の話とも関連するが、多様な参加者の視点を反映しやすいのも利点として感じる。
例えば開発者にとってはパフォーマンスや運用性も気になるところだが、そういった観点のものも雑多にアイディア出しをする段階で、ある種の要望としてユーザーストーリーの形で出てきやすい。
経験上、通常のユーザーストーリーマッピングではそういった非機能要件の観点が漏れやすかった。が、開発者を巻き込んでとにかくいろんな観点での要望を出してもらうと、非機能要件についても考慮しやすくなるし、リリース段階でのクオリティコントロールもしやすくなるので、よりよいプロダクト開発に繋がりやすいと思う。

おわりに

この記事では最近ハマっているブレスト的ユーザーストーリーマッピングを紹介してみた。
とはいえ、僕らもまだこのやり方を取り入れてみたばかりなので、改善の余地はいくらでもあると思う。また、そもそもユーザーストーリーマッピング原典への理解が万全とは言えないし、最新のプラクティスへの追従は全然できていない。なので、もっとベターなやり方は確実にあるだろうと思う。
とはいえ、現時点での自分たちのやり方を記録しておいて今後の改善に活かしたいし、アジャイル開発コミュニティに何らかの貢献ができたら良いと思っている。
通常のユーザーストーリーマッピングで行き詰まりを感じている人や、そもそもプロダクト開発を進める中でつくるものの決め方に迷っている人に参考になれば嬉しい。

一緒に良いプロダクト作りましょう

ちなみに、HERP ではいろんなプラクティスを取り入れながらプロダクト開発を一緒に進めていってくれる人を大募集している。
特に、ユーザー理解が極めて重要なプロダクトデザイナーやフロントエンドエンジニアはめちゃめちゃ募集中である。

ぜひ、一緒に良いプロダクト開発のあり方を模索しながら、日本の採用を変えるプロダクトを作っていきましょう。

（あとがき）

ほとんど書ききってから、最後の仕上げとしてブレスト的ユーザーストーリーマッピングの実例のために画像を用意する段階で、「炎上を避けたい」というストーリーアイディアが出てきた。
元々一番強いニーズは「雑に書きたい」だったし、実際この記事は仙台の寿司屋に並んでいる段階で雑に書いたものだったので精査は後回しにしていたのだが、念のため本来のやり方について『ユーザーストーリーマッピング』原典にあたってみた。
すると、原典で推奨されている流れは以下のようだった：

1. ユーザータスクをたくさん洗い出す

2. ユーザースタスクをまとめてサマリレベルのタスクを作ったり、逆に多いイタスクを分割したりする

3. ユーザータスクを時系列に並べ直してナラティブを作る

4. 別のストーリーを探る

5. 共通の目標にむかうタスクを集約したアクティビティを抽出し、バックボーンを作る

6. 望ましい成果を得るための最小限のスライスを作る

めちゃめちゃブレスト的やんけ〜〜！！
じゃあなんすか、僕らが元々やっていただんだん詳細度を高めるやり方がめちゃめちゃ間違ってたってことっすか。
なんか「ブレスト的ユーザーストーリーマッピングを私が発明しましたw」みたいなテンションの記事書いたのめちゃめちゃ恥ずかしい。

でもまあこれが守破離してから螺旋のように原典に戻るってことですかね。

みなさんも原典を読んで試行錯誤していきましょう。