ユーザーストーリーマッピングをやってわかった3つの事

はじめに

こんにちは。Satoshi Matsunagaです。

この記事はNEXTSCAPE Advent Calendar 2020の五日目の記事です。

今日はユーザーストーリーマッピングについてお話ししたいと思います。

ユーザーストーリーマッピングの紹介

なぜユーザーストーリーマッピングを使うのか

仕事では顧客と一緒にアジャイル開発の手法の一つであるスクラムを用いた開発を行っています。

顧客のシステムの開発になるので、プロダクトオーナーは顧客になります。

ですが、大概は顧客がアジャイル開発の経験が今までなく、プロダクトオーナーも初めてというケースが多いです。

スクラム開発におけるプロダクトオーナーの役割で重要な事はPBI（プロダクトバックログアイテム）の作成と、そのリストの管理です。

PBIを作成するためには、システムの全容を把握し、そこから最初に効果を測定したい最小限の構成のプロダクトであるMVP（Minimum Viable Product）を決めます。

MVPが決まったら、そのストーリーからPBIを起こしていくことになります。

この一連の流れを初めての人が行うのはなかなか難しい作業です。

勿論、私たちがサポートをするのですが、その際に使うのがユーザーストーリーマッピングになります。

ユーザーストーリーマッピングはシステムを使うユーザーの流れを整理し、MVPの洗い出しとPBIを起こす事を同時に進める事ができます。

また、プロダクトオーナーと開発者が一緒になって議論を交わす事で、システムの理解やユーザーの思いや痛みを開発者も共有することができ、その後の開発工程においてもユーザー目線で開発を考える事ができる様になるのです。

これまでのユーザーストーリーマッピングの経験

わたしがユーザーストーリーマッピングに初めて触れたのは３年ほど前だったと思います。

はじめに本を渡されて、自分で第5章に書かれた「朝起きてから家を出るまで」のユーザーストーリーマッピングを試した事が最初になります。

それから、社内のプロジェクトでユーザーストーリーマッピングを行い、徐々にいろいろなところで使い始めました。

これまでに社内外合わせて５つ以上のプロジェクトでユーザーストーリーマッピングを使ってきました。

また、ユーザーストーリーマッピングの講習も行ってきました。人数を数えた事がなかったのですが、改めて数えてみたら社内外合わせて３０人くらいには教えていました。 この経験を通して、私の中でユーザーストーリーマッピングをしてわかった事がいくつかあります。

今回その中でも特に重要だと思った３つについて書いていきたいと思います。

１.未来を語るのは案外難しい

例えばあなたが半年先に旅行を考えていたとします。

それをある日友人に話したところ、友人から次の質問が飛んできたとしたら、あなたはどう思いますか？

• 何日の何時にいくの？
• 交通手段は何を使うの？
• 最初に行く場所はどこを予定している？
• お昼は何を食べるの？
• ホテルはどこにしたの？

きっと、うんざりするんじゃないでしょうか。あるいはうーんと唸ってしまうかもしれません。

未来に旅行を考えているのは確かにその通りですが、半年先の旅行なんて、目的地と予算の大枠が決まっているなら良いくらいで、旅行の日程や食事など、細かい内容は特に決まっていないと思います。

実は、ユーザーストーリーマッピングを行うと同じ現象によく遭遇します。

顧客としては新しいシステムを作ることを目指していて、もちろん予算もあります。
ただ最初から具体的なユーザーの動きまで詳細に想像できているかというと、そんなことは決してありません。
ましてや、システムのユーザーの流れは旅行の日程よりもっと複雑です。

ですから、ユーザーストーリーマッピングを始めると、ユーザーがシステムのログインをしたあたりで、壁の前でうーんと唸ってしまい、ペンを持つ手が止まることが多いです。

また、それでも前に進めなきゃと書き進めていくと、今度はもう一つの落とし穴が待っています。

気づいたら、既存システムのユーザーのストーリーをなぞっているのです。

人は何か新しいものをする時、過去の経験から判断して行動をします。
生存していくために必要なこのスキルが、ここで邪魔をするのです。

目の前には既存のユーザーフローがちょっと改善したようなストーリーが出来上がっているかもしれません。

本当なら今までの既成概念やら何やらを横に置いておいて、頭の中をフラットな状態にして、ユーザーの痛みが少しでもなくなるようなストーリーを構築していきたいはずです。

ですが、それをすることは事前準備無くしてはなかなか難しいのです。

対処方法

もし、最初から行き詰まるようだったら、ユーザーストーリーマッピングを止めて、まずは未来のシステムのことについて語ったほうがいいかもしれません。

このシステムで解決したい問題は何か。そのためにどういうシステムをつくろうとしているのか。
そういったバッグボーンや思いを掘り下げることで、新しいシステムのユーザーはどういう振る舞いをするのかが自然と見えてくる様になります。

未来を見つめるために、既存システムを改めて見直してみるのも一つです。

既存システムのユーザーストーリーマッピングを行い、ユーザーの行動を整理しながら、そこにでてくるユーザーの行動と”痛み”（ユーザーにとって面倒なことや手間がかかっていること）を理解すると、その痛みを解消するための新しいストーリーが浮かんでくると思います。

２.ストーリが大きくなりすぎ

ユーザーが多いシステムでは、ストーリーも長くなりがちです。

壁が何メートルあっても足らない、まるで巨大な歴史の年表みたいな大作が出来上がるかもしれません。

その場合、作ったときには達成感を得られますが、しばらく経ってから眺めると、変更することが容易でないストーリーマッピングになっていることに気づくでしょう。

またこの場合、ストーリー一つ一つの粒度もバラバラになりがちです。

ストーリーの粒度をどれくらいに合わせるかは最初は難しく、本の中でもビジネスのストーリーとユーザーのストーリ、そして開発側のストーリーでは粒度が異なると言っています。

いまのユーザーストーリーはどの粒度なのか、チームメンバーの中でもなかなか合わなかったりします。

ただ、最終的なゴールはPBIをつくることなので、開発サイドとして理想的な粒度はストーリー一枚一枚がPBIのタイトルになる事が望ましいです。

開発チームの視点から満た適切なサイズのストーリーとは
ビルド、テストに数日しかかからないストーリーのことだ。
（ユーザーストーリーマッピング第11章）

また経験的な話ですが、小さいユーザーストーリーはPBIの粒度を保ち安いですが、長く大きくなると粒度がどんどん荒くなっていきます。

特に後半は、議論のし過ぎで頭は疲れてる、ペンで書くのが面倒くさくなっている、更には壁のスペースが足りなくなる、という3条件が揃って、無意識にストーリーの粒度を荒くしてまとめようしたくなります。（実際そうして、あとで書き直したこと経験があります。）

対処方法

大きなストーリーは階層構造にするのが良いです。

まずは大きな概要ストーリーのユーザーストーリーマッピングを作ります。

そのストーリー一つ一つをクローズアップして、そのストーリーの細かいユーザーストーリーマッピングを作ります。この時に粒度をユーザーに焦点を当てたストーリーにします。

さらにそのストーリーを今度は開発チームが開発しやすいサイズ（PBIを起こすサイズ）に分割していきます。

こうすることで、ユーザーストーリーマッピングが大きくなることを防ぎ、変更もしやすくなります。

本では分割する事がわかっている大きなユーザーストーリーを”エピック”と言っています。
（用語なんてどうでも良いとも言っていますが）

エピックを分割していき階層構造にしていく事で、ストーリーの粒度の荒さを防ぎ、ユーザーストーリーマッピングを使いやすいものにしていきます。

３.MVPが全然ミニマムにできない

ユーザーストーリーマッピングで一番重要な事の一つはMVPを決める事です。

MVPは想定している成果を得られる最小限のプロダクトです。ですから、得られる成果に対して、限りなく作るものを少なくしていく必要があります。

MVPとは、望まれる成果を実現できる最小の製品リリースである。
（ユーザーストーリーマッピング第2章）

ただ、このMVPを実際に決めようとすると全然ミニマムに作れません。

例えば、商品の在庫情報を入力して確認する機能を作ることになったとします。 ユーザーとしては今まで個別に見ていた商品の在庫情報が一覧で見て把握できるようにしたいという思いがあり、それを念頭にユーザーストーリーマッピングを作りました。 そうした場合、MVPはどういう形になるでしょうか。 まず、ユーザーは商品の在庫情報の一覧見れればいいはずです。 ここまではみんなすぐにわかります。ただ、問題はこの先です。

商品の情報が必要だよね。それじゃあ入力するための機能が必要だ。
出力するってことは検索機能も必要になるなぁ
という話が上がってきたりするのです。

確かにユーザーストーリーマッピングには、情報を入力するというストーリーがあって、検索するというストーリーもあります。

そうなるとこれもMVPにしようということになります。

さらに一覧ってことはCSVやExcelに出力する機能が必要だねという話にもなるかもしれません。

そんな調子であれよあれよという間にMVPが膨れていきます。

気づいたらユーザーストーリーマッピングに書かれたストーリーの半分かそれ以上がMVPになっていたりする事も。これでは全くミニマムじゃありません。

対処方法

よく思い返してみてください。ユーザーは在庫情報が一覧で見られればいいのです。

入力のことも検索のことも一切ほしいと言っていません。

極端な話、入力情報を紙（所定のフォーマットでもらうとか、メモ書きでもいい）でもらい、それを誰かがExcelか何かに打ち込んで一覧表を作り、その結果をユーザーに返してあげればいいのです。
（こう言った裏で人力でやるシステムのことをオズの魔法使いの話になぞらえてオズシステムと呼んだりします）

この方法でも、ユーザーは在庫情報の一覧が見られるから、成果が上がっていますし、在庫情報の一覧について価値を感じられるでしょう。

なんといっても、この方法ならシステムを作らなくていいのですぐに成果を出せるし、ユーザーからフィードバッグもすぐにもらえます。

つまりフィードバックループが早く回せるのです。

もちろん全て人力でやることで果たしてユーザーが期待する価値を感じられ、フィードバックを返してもらえるかはチームで話し合う必要があるでしょう。

ただ何においてもすぐにシステム化をする話にするのではなく、簡易的な代替策ができないかを検討する意識は持っておいたほうが良いでしょう。

人力でもハリボテでも、ユーザーが価値を感じられ、フィードバックを得られればそれがMVPですから。

MVPは、仮定を証明または反証するために作れる、あるいは実行できる最小のものでもある。
（ユーザーストーリーマッピング第2章）

まとめ

ユーザーストーリーマッピングはプロダクトを作る上でユーザーを理解し、そしてMVPを見つけ出す有効なツールの一つです。

ただこの手法はそれだけに止まらず、ユーザーのストーリーをチームが同じ場所で一緒に会話をしていく事でコミュニケーションの量が増え、共通認識を形成し、話しやすいチームができる効果もあります。

普段のPCに向かって行う作業とは異なり、紙とペンを使ってユーザーのストーリーを整理していく事でリラックスして会話ができ、それがさらにコミュニケーションを促していくのです。

ちなみに、ユーザーストーリーマッピングやってわかったことは本当は３どころか、１０以上ありました。

議論を促すペーパープロトの効能や、開発につなげるためのデータモデルの話などなど。

ですが、それを書くと一冊本を出すくらいの文章量になるので、あきらめました。。。

残りはどこかでお話ができればいいなと思っています。

最後まで読んでいただきありがとうございました。