どのようにして質の高いユーザーストーリーを作成するか
プロダクトマネージャーの日常業務といえば、ユーザーストーリーを作成して、エンジニアさんに実装していただくことで、プロダクトの付加価値を向上させていくことですが、エンジニアさんに依頼するときに、共感が得られなかったり、議論が紛糾して持ち帰りになってしまったりしたことはありませんか？
この記事では質の高いユーザーストーリーを作成するためのポイントを紹介します。
「課題」をハッキリさせる
ユーザーや顧客から「ooという機能がほしい！」と言われたり、Bizチームから「導入にはoo機能が必須！！」と言われたりと機能要望をきっかけにユーザーストーリーの起票に取り組むことが多いかと思います。
しかし、いったん立ち止まって、まず初めにそういった機能要望の背景にある**「顧客が抱えている課題がなにか」**をハッキリさせましょう
課題の解像度が低いまま解決策を提案しても筋の良いエンジニアや事業責任者に全く共感を得られず差し戻しになるか、そのままリリースされてしまうと最悪ほとんどのユーザーが利用してくれないプロダクト負債になってしまいます。
「Why so？」を繰り返して根本課題をあぶり出す
様々な寓話が示している通り、ユーザーや顧客は自分が本当に欲しいものがなにかわかっていません。
https://dqn.sakusakutto.jp/2012/03/post_46.html
プロダクト開発のプロでは無いので当然です。
機能要望という手段を用いて顧客の感じているペインを伝えているのです。
そこで、「Why So？（なぜそうなのか）」を繰り返し問いかけ、機能要望の背景にある根本的な課題をあぶり出していきましょう。
例えば、「プログラミングスクールに通いたい」と相談を受けたとして、根本課題を考えてみましょう。
「プログラミングスクールに通いたい」
(なぜプログラミングスクールに通いたいの？)
「手に職をつけたいから」
(なぜ手に職をつけたいの？)
「スキルもないし今のままでは年収が頭打ちだから」
(なぜ年収を上げたいの？)
「子どもが生まれて、今の年収で教育と生活を両立できるか不安だから」
「Why so？」を繰り返すことで、根本課題が「今の年収で教育と生活を両立できるか不安」であることがわかりました。
そうなると、プログラミングスクールに通うことの是非以外にも様々な解決策が提案できそうですね。
- フィナンシャルプランナーに相談して、現在の年収で希望する生活が実現できそうか相談してみる
- 生活費をみなおして、来る教育にかかる資金を蓄える
- 宅建や簿記2級など資格手当が狙える資格を取って転職する
「Why so？」を繰り返すときに大切なことは、推測や伝聞ではなく事実に基づいて深堀りをすることです。
「Why so？」を繰り返し聞いていると、「決済者が必要と言っているから」や「oooの事態が発生した場合にこの機能が必要だから」のような客観的な事実以外の推測や伝聞に基づいた回答が返ってくる場合がしばしばあります。
これは根本の課題を深堀るチャンスです。「決済者はどのようなユースケースを想定して必要と言っているのか？」「oooという事態は本当に発生するのか？発生したとして、どのぐらい大きい問題になるのか？」粘り強く深堀りをすることで、顧客も気がついていない課題を見つけることができるかもしれません。
課題による顧客の不利益はどのくらい？
課題をハッキリさせたら、次は、その課題によってユーザーや顧客が被る不利益が何でどのくらいか考えてみましょう。
先程の「今の年収で教育と生活を両立できるか不安」を例に取ると、年に1度ぐらい漠然と思い出す程度であれば、あまり気にせず忘れる選択肢もありますが、常に不安で、日常的な買い物のたびに「節約しないと」と思い悩んだり、普段の生活に充実感を感じられないぐらいであれば真剣に解決策を考えたほうがよさそうですよね。
このように課題によって生まれる不利益の程度によって、解決すべきか否か、どのぐらいコストを掛けてでも解決すべきかが変わってきます。
ですので、以下の観点から課題によって生まれる不利益を試算してみましょう。
- どういった不利益（金銭コスト増、時間増、売上逸失など）が発生するか
- 課題の発生頻度はどのくらいか
- 課題による強度（不利益の大きさ）はどのくらいか
- 課題を抱えているユーザーや顧客はどのくらいか
不利益の試算はBtoB向けプロダクトで特に重要です。
BtoBプロダクトは顧客の業務上必要だから導入しているため、「我慢して使ってもらう」や「手作業や代替手段で我慢してもらう」といった消極的な提案戦略も取りやすいです。
我慢できる程度の課題に開発リソースを投資してしまうと、投資自体が無駄になってしまい、プロダクトの競争力を低下させてしまいます。
BtoBプロダクトの場合は、課題によって顧客が被る不利益を可能な限り金額まで落とし込んで考えることをおすすめします。
課題と不利益を1つの文章にまとめてみる
箇条書きやパワーポイントのようなスライドツールは端的にわかりやすく表現することに長けていますが、その代償として論理的な整合性が不明瞭になったり、背景情報が削ぎ落とされて情報密度が低くなってしまいます。
Amazonではそういった問題を防ぐため、企画や報告など資料を1枚または6枚の文章にまとめることが推奨されています。
https://omachizon.blog/amazon_narratives/
そこで、顧客の課題と課題によって被る不利益を具体化したら、文章にまとめて1本のナラティブ(物語)を作ってみましょう。
文章を作成するときは6W3H（Why, What, Who, When, Where, Whom, How, How much, How often）をしっかりと盛り込んで具体的で実態に即した文章を心がけてください。
これはやってみると思っているよりも大変な作業です。
ロジックのヌケモレや飛躍がたくさん見つかりますし、そもそも書き出しから進まないこともしばしばあります。
しかし、顧客の課題と不利益を1本の文章としてまとめ上げたとき、その課題への理解度は飛躍的に向上します。
ここまでできれば、十分に課題をハッキリと理解できているようになっていると思います。
より深い内容を知りたい方はこちらを読んでみてください
解決策を複数個かんがえる
「課題」をハッキリさせたら、お待ちかねの解決策を考える段階です。
解決策を考えるときは1つだけでなく、必ず複数個考えましょう。
複数個と言っても、広告やデザインといったクリエイティブのように100個も200個も出す必要はありません。
解決策はふたつか3つあれば十分です。
ドイツのキール大学における研究によると、選択肢がなかった（「〜を実施するか否か」）意思決定のうち6%しか「成功」と評価されなかったのに対し、複数の選択肢が用意された意思決定では40%が「成功」と評価されました。
解決策を複数個考えるメリットはもう一つあります。
それは、解決策と提案者である自分との距離を保てることです。
解決策が一つしか提示されていない状態でそれを否定されるとどうしても自分自身を否定されたような気分になってしまい、過度に肩入れしてしまったり、否定的な意見が非常にストレスに感じてしまいます。
複数個の解決策が提示できると、そのような心理的負担は感じづらくなり客観的に議論をすることができます。
複数の解決策を考え出すには？
競合サービスを調査する
解決策の概形も掴めない場合はまず最初に競合サービスを調査してみましょう。
競合であれば似たような課題感を抱えていることが多く、機能として実装されている可能性が高いです。
ベストプラクティスを調査する
機能の概形（例えば権限機能）がわかっている場合は、ビックテック系や業界で評判のいいサービスではどのような機能として実装されているか調査してみましょう。
優秀なプロダクトマネージャーが考え尽くして実装された機能であるので、参考になる点は多くあると思います。
自身のプロダクトに反映するとして使えそうなところと不要なところを整理して、機能案として落とし込んでみてください。
解決策を構造化して偏りを見つける
ここからは応用編です。
いくつか解決策を考えてみて、どれも似たりよったりだと感じたり、いまいちピンとくる選択肢にならない場合は、それらの解決策の共通点を探してみてください。
そして、見つけた共通点とは真逆の解決策を考えられないか検討してみてください。
例えば出てきている解決策がどれも開発工数を意識するあまり暫定対応な印象があれば、開発工数を無視して理想的な解決策はどういったものなのか考えてみましょう。
解決策がどれもユーザーの操作ミスを気にして安全側に倒したものである場合、操作ミスが起きないとしたらどういった解決策が考えられるでしょうか？
真逆の解決策はそのままだと、前述の「偽の選択肢」となってしまうので、今まで出てきている解決策と真逆の解決策の間に、落とし所が無いか探してみましょう
共通の課題をもつ全く別のカテゴリから解決策を探る
それでもまだピンとくるものがなければ、全く違うカテゴリから解決策を参考できないか検討してみましょう。
課題を抽象化して、全く別のカテゴリで解決されている事例がないか探すのです。
有名な事例としてはAppleのMagSafeがあります。
macに電源ケーブルを繋いで使用しているときに誰かがケーブルを引っ掛けてしまうと、macが落ちて故障してしまう懸念がありました。そこでAppleの設計チームは「ティファール」などの電気ケトルに見られる磁気接続式の電源ケーブルにインスピレーションを受けて、MagSafeを開発したそうです。
このように、課題を抽象化して似たような課題をもつ商品やサービスから発想を得ると全く新しい解決策を考えることもできるかと思います。
解決策の評価はあとでする
解決策を考えているときは、個々の解決策の評価はせずに洗い出すことに集中しましょう。
しばしば見受けられるやり方として、解決策が思い浮かぶたびに、実現可能性などでその解決策を評価し、イケてないなと思ったら俎上にも乗せないというものです。
これは2つの点で問題があります。
まず効率が悪いです。
解決策を考えるときは様々なアイデアの種からイマジネーションを広げ、解決策に結びつけていく、いわゆる右脳をフル回転させるわけです。
解決策の評価・取捨選択をするときはその真逆で、客観的にその解決策のメリット・デメリットを論理的に整理していく、いわゆる左脳が主役になります。
解決策ごとに右脳と左脳を切り替えていてはオーバーヘッドが頻繁に発生して非常に非効率的な思考になってしまいます。
もう一つの問題点が、評価に客観性と一貫性が無いことです。
後述しますが、主観的な評価よりも客観的な評価や第三者による評価のほうが正確です。
しかも、解決策を考えるたびに評価していると、解決策ごとの評価軸も異なってしまいます。
偏った不正確な評価基準によって、別々に評価しても適切な意思決定にたどり着くことは困難です。
解決策の評価はあとからまとめて実施するので、解決策を考えているときは実現可能性とかあまり気にせずによさそうな案をどんどん出していきましょう。
解決策をえらぶ
解決策が複数個考えついたら、その中から最も課題に適した解決策を選択しましょう。
次のような流れで選ぶと良いです。
「偽の選択肢」を捨てる
偽の選択肢とはまともな選択肢を際立たせるための捨て案のことです。
偽の選択肢の判定基準としては、関係者に選択肢を提示したとき、どの選択肢もメリットとデメリットが甲乙つけ難く、関係者内で評価が割れそうな選択肢のみに絞り込んでください。
もしこのとき、一つの選択肢しか残らなかった場合は、もう一度追加の解決策を考えましょう。
評価軸考えて評価する
甲乙つけがたい選択肢がふたつ３つ残ったら、それらを評価するに適切な評価軸を設計して評価しましょう。
評価軸として代表的なものは、開発コスト、期待リターン、UX、実行速度などです。
解決策を考案するときに「解決策を構造化して偏りを見つける」を実施していた場合はその時に使用した構造化の軸も評価軸として有効です。
評価軸を設計するときに大切なことは、評価軸を作り、評価をしたときにそれぞれの選択肢が甲乙つけがたい状態が表現できていることです。
どれか特定の選択肢だけ際立って良かったり悪かったりする場合は、評価軸が適切でないか、「偽の選択肢」がまだ紛れているので再考してみてください。
色んな人から評価結果への意見をもらって決める
解決策を選ぶときは、可能な限り様々な職種の社内メンバーに課題、解決策の選択肢、解決策の評価結果を説明して、フィードバックをもらってください。
人間は自分が考えたアイデアを自身で評価することが苦手な生き物です。必ずバイアスがかかってしまいます。
そんなときに頼りになるのが他者の視点です。
他者はそんな先入観にわれていないため、（少なくともあなたよりは）客観的な視点で正確な判断を下すことができます。
自分の説明した内容で納得できないところがないか、より良い解決策が無いか質問してみましょう。
もし、スクラム開発を導入していて、定期的にバックログリファインメントを実施しているのであれば、リファインメントは意見をもらう場として最適です。開発メンバー以外にもBizやCSといったステークホルダーを招いて、意見を募りましょう。
フィードバックが出尽くしたら、評価結果とフィードバックを踏まえて、どの解決策を実施するか選びましょう。
どの解決策を選ぶかはプロダクトマネージャーであるあなたの仕事です。
意見を募る過程で、有力者の意見に寄せたり、全員が納得できるような解決策なるように妥協したりしないでください。
ユーザーストーリーをみなおす
一本のユーザーストーリーを完成させたら開発チームに依頼する前に、最後に見直してみましょう。
一度距離を置いて見てみるとバランスが悪かったり、意外なところにヌケモレが見つかることがあります。
以下のような視点で今一度確認してみてください。
この課題は本当に解決する価値があるか？
課題が起票されたときはユーザーや顧客もご自身も温度感高く感じられたでしょうが、今でもその温度感に変わりはありませんか？距離をおいてもなおまだやる価値があると説明できますか？
課題はプロダクトのOKRやプロダクトプリンシパルに合致していますか？
課題の深さや広さはプロダクトに機能追加するするほど重要なものですか？
解決策に余分なものは含まれていないか？
リファインメントなどで仕様を検討していると、課題とは関係ないところで、仕様が追加されたりすることがしばしばあります。
今一度冷静に振り返ってみて、解決策の中に課題解決に不必要な仕様が含まれていないか確認してください
課題の大きさと解決策のコストは見合っているか？
このユーザーストーリーが生み出す付加価値は課題の大きさが上限値になります。
解決策の開発コストと比較して、課題の大きさは十分大きいものになっていますか？
解決策の開発コストが大きすぎたり、課題の大きさに確信が持てない場合は、課題を小さく分割できないか検討してみてください。
もう一本記事を読んでみませんか？
このサイトではプロダクトマネジメント、組織マネジメントに役立つ情報を毎週発信しています。
この記事が面白かった、ためになったと思う方は、以下のリンクからもう一本記事を読んでいただけると大変嬉しいです！！
では、また！