異動で初体験したユーザーストーリーマッピングについてを紹介します!
こんにちは。バックエンドの川原です。
直近異動になり、リプレイス業務を中心に取り組んでおります。
チーム異動で川原が初めて体験したユーザーストーリーマッピングについてご紹介させて頂きます!
営業と開発の連携についてはこちらの記事もご参照ください。
ユーザーストーリーマッピングについて
ざっくり言うと、要件定義に近いものになります。
用語について説明していきます。
ユーザーストーリーとは
まず、ユーザーストーリーというものの説明をさせていただきます。
本の流用となりますが、要件定義方法の1つで、
「〇〇(ユーザー)として、✕✕(行動)をしたい。それは、▲▲(目的)だからだ」の形式で書くことで、わかりやすく誰でもわかるように書くことができる手法の一つです。
私が所属しているチームではプロダクトバックログとスプリントバックログをこの形式で書いて定義しています。
ユーザーストーリーマッピングとは
ユーザーストーリーを時系列順に、優先順位順に配置したものがユーザーストーリーマップと呼びます。(手法自体をユーザーストーリーマッピングと呼ぶ。)
エンドユーザーの行動とプロダクトに求める価値を時系列で整理し、それを実現するために必要な機能や要件をマッピングすることで、プロダクトの開発に関わる全てのメンバーが価値の目的や優先順位を視覚的に捉えることができるようになります。
どのようにやっているか?
弊社では現在ダッシュボードのリプレイスプロジェクトを進めており、移行する機能単位でプロダクトオーナーがステークホルダーを呼んで、ミーティングを開催するところからスタートします。
ミーティング
ミーティング内では、各機能において
[いつ]、[どこで]、[誰が]、[何を]、[なぜ]、[どのように]
などの機能や使い方、ユーザーなどを細かく知っていきます。
その上で、あって欲しい機能、あったら使うであろう機能なども必要優先度を無視してヒアリングする形式で進めています。
ここで大事なのは、最低限あって欲しい機能は何なのかを明確にすることです。
そのために必要なことはここで聞けるように機能の概要を把握していき、この後の優先度付けに必要なことを聞いていきます。
機能を書き出す
ヒアリングした内容元に、実装すべき機能を付箋に書き出していきます。
弊社ではmiroを使用しています。
マッピングする上でのルールは
カテゴリ(一番上)
アクティビティ(二番目)
各機能(三番目)
これらに分類し、左から順に作っていきます。
特に各機能は動詞で終わるように記載して「〜できる」という形で書いていきます。
その上で優先度を付けて高いものを上から並べていきます。
すぐに実装しなくて良いものは、線を引いてその下に貼り付けていきます。
体験してみて感じたメリットデメリット
メリット
手戻りが発生しにくい
これが一番感じるメリットでした。行なっているのがリプレイスなのもあって、現状で不便に感じている部分なども同時に聞くことができ、どうあって欲しい機能なのかがわかりやすい。
そのため、「え?この機能も必要だったの?」とか、「実装イメージがあっていなかった」などのコミュニケーション不足によるやり取りの追加や無駄な作業などが発生しにくかったです。開発者間のコミュニケーションが最低限になる
一緒にユーザーストーリーマッピングをして、分担して作業を行うのですが、機能の全体感は掴めているので、説明したりするコミュニケーションコストがなくなる。地味ではありますが、かなりのメリットに感じました。
デメリット
バリデーションなどは別途設定する必要がある
この時点で、聞いたりして設定できるものもあるが、実装が具体的になってきてから設定する必要のあるものは別途考える必要がある。弊社ではプロダクトオーナーに聞いてもらったり、作ってもらったりして設定を行なっている。ステークホルダーへのヒアリングスキルが重要
ステークホルダーが実装イメージが湧いていなかったり、ユーザーストーリーマッピングに慣れていなかったりすると、必要なことを聞ききれなかったりするケースがあるので、ヒアリングしていくスキルが重要となってしまっている。ステークホルダーが同一人物でないケースが多いので難しい課題でもあります。
最後に
まだまだ改善できる余地は残っていて、書籍などで勉強したいなと思っていますが我々のチームではこのように進めています。
行うプロジェクトがリプレイスであったり、新たな機能を作る場合で最善の形は異なってくると思います。
また、フォローしきれていない部分をどうカバーするかも変わってくるかと思います。
今後も改善を続けて、より効率的で最適なユーザーストーリーマッピングを実施できたらと思います。