こんにちはwebチームでエンジニアをしている村上です。 今回の内容はユーザーストーリーマッピングについてです。
社内でワークショップをした話と実際に仕事で使った話をしたいと思います。
p.s. 最近のマイブーム: ヨーグルト・ジャム・シリアルの組み合わせを模索中。(おすすめ: ブルガリアヨーグルト(400g)・フルーツのみの甘さいちごジャム(セブン)・玄米フレーク)
ユーザーストーリーマップとは
下記、オライリー本が有名(他に知らないだけ)なのですが、この本の序章を読む限り次のようにまとめられます。
全体像を把握するためのツールで、 これによってエンジニア・デザイナー・ビジネスサイドそれぞれのコミュニケーションが円滑になるなどプロダクト開発(主にアジャイル開発)において効果がある。
これだけ読むと、何でもできてしまう最強のツールのように思えてきます。
amazon: ユーザーストーリーマッピング ＊以降、本とはこれを指します。
学ぶきっかけ
MTGでぼんやり決まったことを後から再度確認することが増えてきたなという課題感があったので解決方法を探していました。
ユーザーストーリーマッピングというツールor考え方があるのは前々から知っていましたが、「どうせ付箋貼っていくやつでしょ」くらいにしか思っていなかったですし、
こういうツールは、使うことが目的になってしまったり、いかにチーム内で浸透させていくかが難しいところだと思うので、開発メンバーをどう巻き込んでいけばいいのかも含め興味がありました。
どんなスタイルで学ぶか
ビザスク開発チームでは「プロダクト全体を通してUXを底上げしたい」という趣旨から、UXに関する事例やツールを学ぶ社内勉強会を行う習慣があり、ちょうど一巡して自分の番で新しいトピックにうつるというタイミングだったのでその場を活用することにしました。
とりあえず、最初の方だけでも輪読しようと思い、社内勉強会で発表したのですが、
- 「内容がコンセプチュアルすぎてつらい」
- 「こういうのはやりながら覚えた方が早いよね」
という意見が出たので輪読形式はすぐにあきらめ、なにかしらワークショップ形式で次週やることに決まりました。
薄々こういう反応になることは想像できたのですが、ワークショップを企画するのも大変だろうと避けてしまっていたので、今思えばその時点で誰かに壁打ちを付き合ってもらっていたら良かったと思います。
ワークショップ
テーマ選び
本の5章が実践的な内容だったので、開発チームから呼びかけて私を含め3人で試した際、 「本に紹介されている例では物足りない」、かといって「テーマが具体的すぎても答えを出すことが目的になってしまいそう」というジレンマがあり、テーマ選びに苦戦しました。
あるべきは、エンジニアだけでなくデザイナーやカスタマーサクセスのメンバー含めて、開発チーム全体でフローの共通理解がありつつ、役職によって別の目線でディスカッションできることだと考え、
「プロジェクトの開始から機能リリースまでのプロセス」 に着目することに決まりました。
スケジュール
当日の流れはこんな感じです↓
- 2グループにわける(1グループ4人)
- ワークショップの目的の共有
- お題の提示
- 各個人で思いつく限り書き出す(5~7分)
- 一つのマップにする(20分)
- グループ間で見合わせ(8分)
計画とのギャップ
タスクを時系列に並べた後に、担当別にスライスして遊んだり等いろいろやりたかったのですが、 グループで共有しながら並べるだけでもけっこう時間がかかりました。
1人であれば机の上に並べてでもいいのですが、付箋を貼るためにホワイトボードor壁は必須です。
最後にグループ別で代表者に発表してもらう予定でしたが、場所を交代して見合わせるだけになりました。
うまくいったところ
付箋にタスクを書き出してもらうところが進まないと話にならないので、このセッションがスムーズにいくようにするところを一番意識しました。
- 大きな塊のタスクを書き出してください。
- 細かすぎるのはやめましょう(ex. ブランチを切るとか)。
- 思い付いたものからどんどん書き出していってください。
というのを開始前、作業中に繰り返し唱えました。
アウトプット
それぞれのグループの成果が以下です。aにはあってbにはない、その逆もなど比較するとおもしろいです。「実装するまでにいろいろやることあるなあ」という見合わせ直後の感想が印象的でした。
グループa
グループb
フィードバック
どんな反発があるのかと恐れていましたが、皆んな楽しそうにやってくれたのでホッとしました。以下がワークショップ後にいただいたフィードバックの一部です。
チーム内で認識がずれている箇所があぶり出されたかんじ ただただワークショップ形式楽しかった 限られた時間で書いたので、やはり人によって優先的に書いたタスクに少し違いがあったと思う（←意図されていると認識） ワークショップで書き出してくと、あぁこれって普段から頭の中でやっていることだよね、と納得
ファシリの心構え
前提として、具体的なソリューションを出すことが目的か、ストーリーマップの威力を体験することが目的かで異なります。今回は後者の立場です。
当日はファシリテータが選任で1人必要だと思います。一緒につくりながらは難しいです。 できれば、スクラムマスターのようなプロにお願いするのが一番ですが、いない場合はまず少人数(2,3人)で実験すると良いと思います。
私も素人なので「30分だけ時間をください」とお願いしましたし、ここでの協力者が当日いい感じに動いてくれるといった効果もありました。
結局、企画とテーマ設定で全ては決まるので、事前準備は欠かせません。 参加者全員が当事者意識を持って取り組めてかつ、アウトプットからそれなりの発見が得られそうなテーマを決めるところが最も重要で難しいところだと思います。
会が始まってしまえば、やることはほとんどタイムキーパーです。もちろん達人は絶妙なタイミングでの仕切を要求されますが、これは場数の話だと思います。
実務で使うとこうなる
ある施策の振り返りをしている時に、 「そもそもこの後どうやって進めます？」というつっこみから、 「ホワイトボードにまとめますか」と、自然な流れでユーザーストーリーをベースに議論する形になりました。
ある1人がストーリーのステップを書き始め、その間にエンジニアがCVRを求め、それに基づいて各々がアイデアを書き出していくといった感じです。出来上がったのが以下↓
[caption id="attachment_741" align="alignnone" width="300"]
[/caption]
この画像で、実際のユーザーストーリーが書かれているのは上の一行のみです。 他は、補足情報と各ステップで打てそうな施策アイデアについてなので、 ストーリーは骨格・土台のようなものということがよくわかります。
こういう絵を瞬時に自然とチームで描けたのも、共通認識を持てたという意味でワークショップをやったかいはあったのかなと思います。
まとめ
みんな無意識にそれぞれが重要だと思っているストーリーをベースに話すので、 意外なところで認識が合っていなかったり、同じ議論を繰り返しがち。一度、チーム内でストーリーマップをつくっておくと後々の振り返り・深堀りがスムーズだと改めて感じました。
個人的には「ストーリーに沿って、もっとシンプルに考えようよ！」といった展開がMTGなどで増えてきたのが収穫です。
ここまで書いておいてなんですが、一番の学びとして 肝心なのは、本を読むことでもワークショップをすることでもなく、
- 施策を考える時に、メインのストーリーから入ること
- 議論の中で、そのベースとなるストーリーをだれかが書き出すこと
につきるなと思いました。
p.s. 会議室の壁一面をホワイトボードにする。 or ガラスにマーカーで書くとか？ やりたいなあ・・
