リモートチームで行うユーザーストーリーマッピング
こんにちは、hacomonoデザインチームのさくです。
今回はhacomonoのプロジェクトで行っているユーザーストーリーマッピングの実例について紹介します。リモートで行う際の工夫など、参考になればと思います。
ユーザーストーリーマッピングとは？
ユーザーストーリーマッピングとはユーザーに提供する機能を「顧客の行動軸」と「優先順位軸」の２軸で整理し、何を優先的に提供すれば良いのかを視覚的に整理する手法です。
詳しくはこちらの本で紹介されています。
実施時の工夫
オンライン・オフラインで何度か実施していくなかで、やりやすくアレンジしてしまっている部分もあります。参考までに、私が実施する際に工夫している点を紹介します。
ターゲットやゴールなどの大きな要件が定まったあとに行う
開発初期段階で使われることが多いフレームワークですが、ある程度ターゲットやゴールなどの大きな要件が定まったあとワイヤフレームに落とし込む前に、機能の考慮漏れがないかチームで整理する際に行っています。大枠の要件が定まっていないと、ユーザーストーリーが枝分かれしてしまい、議論が発散してしまうためです。
実施前に参加者全員で前提条件の確認を行う
実施前には参加者に、前提条件や顧客調査の結果を共有します。こちらも、スコープを絞り、ターゲットに沿った主要なユーザーストーリーを中心に時間を割くためです。前提条件の整理はデザインブリーフについての別記事に書いた項目を活用しています。
発散も目線合わせには重要ですが、実際の業務ではメンバーの時間をとるのも大変なので、優先度の高い項目が先に議論できるような下準備は必須です。それでも議論になる場合は、前提条件が間違っていることもあるので、1段階戻って見直します。
オンラインの場合はmiroのテンプレートがおすすめ！
事前に公開してスピードアップ
リモートで行う場合は、miroのテンプレートを活用しています。
全員同時にゼロから書いてもいいのですが、初めて参加する人には手がかりがあったほうが書きやすいと思い、事前にmiroを公開して、書ける人には書いてもらってから開始しています。
ユーザーストーリーの書式はあまり制限しない
ユーザーストーリーの書式を「〜というユーザーが、〜という目的で、〜という機能を使いたい」となどに統一したほうがいいという説明をよく読みますが、読むのも書くのも時間がかかるので、「〜したい」「〜する」など、シンプルに記述しています。
また、慣れている人・初めての人など様々な人が参加するので、書式はあまり限定せず、まとめる際に整理していっています。記述方法より各自の気づきやアイデアが埋もれないことのほうが重要だと考えています。
実際の実施例
参加者
デザイナーがファシリテートする場合は、PdM、開発、QAを集めて行うことが多いです。QAメンバーは機能の細かい挙動を把握しているので、参加してもらうとより考慮漏れが減るように思います。ビジネスメンバーに参加してもらうこともあります。その場合、より顧客側のユーザーストーリーを深堀りできます。
ユーザーストーリーマッピングの記述例
hacomonoはBtoBtoCのサービスなので、多くの機能では、hacomonoを使う施設側と、施設の利用者のユーザーストーリーそれぞれの記述が必要になります。
その場合はブロックをわけて並べます。
まずはメンバー全員で未処理の項目に記載し、全体の記述が終わったあと、相談しながらMVP/要検討/やらないの項目に振り分けています。
「あったらいいね」という機能も、初期スコープで本当に必要か、ユーザーニーズと開発コストを天秤にかけて議論します。
まとめ
ユーザーストーリーマッピングの実施には工数がかかりますが、プロジェクトの全貌を見ながらメンバーで認識合わせができるので、考慮漏れや議論が減り、最終的には手戻りを大きく減らすことができます。
参加したデザイナー以外のメンバーからも、実施できてよかったという声があがり、中規模以上の案件ではなるべく実施するようにしています。
特に職域を越えた連携には使いやすいフレームワークだと思います。機会があれば、他の実施事例などもぜひ見てみたいです。
最後に
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報やhacomonoプロダクトデザインチームの詳細もぜひご覧ください！