読書メモ『ユーザーストーリーマッピング』

『ユーザーストーリーマッピング』（以下、本書）を読んで、個人的に大事だなと思ったことを、3つのトピックに絞って書き残します。

ストーリーは共通理解を築くためのメカニズム

ソフトウェア開発に関係のある方であれば、ストーリーという概念は日常的によく触れているものだと思いますが、ここで改めて「なぜストーリーなのか？」というところに立ち返ってみます。

「プロダクトとして何を作るか」を決めるのものといえば、要件が一般的だと思います。
しかし、ドキュメントだけで相手に正しく意図を伝えるのは、非常に難しいです。本書では伝言ゲームの比喩が用いられていますが、要件に書かれた指示を読んだ人は、それぞれが異なる解釈をし、本来の意図とは異なった理解をしてしまいがちです。そういった認識齟齬を生まない理想的なドキュメントを作るには、膨大な労力を必要とします。

完璧なドキュメントをつくるよりも、ずっとシンプルで効果的な方法があります。それがストーリーです。
ストーリーとは、単に"As a role, I want to..."というフォーマットに従ったドキュメントではありません。ユーザーの抱える問題について、関係者が言葉と絵を使って議論する中で作り上げていくものです。重要なのは共通理解を築くことであり、関係者の頭の中にあるものです。ドキュメントとして残すのは、あくまで記憶を補助するための情報だけです。

ユーザーストーリーマッピングは、効果的に議論するための一つの方法論で、ユーザーの行動（タスク）とその詳細や、それに対する望ましい成果をカードに書いて並べていきます。
マップの並べ方については、ストーリーの順序に従って左から右に向かってタスクを並べる、上から下に向かってタスクの詳細や代替案を並べる、優先順位によって上下を並べ替える、といったプラクティスはあるものの、厳密な手順やルールはないようです。
目的はあくまで共通理解を築くことであり、具体的な方法はそれぞれに合ったやり方にカスタマイズしていくものなのだと思います。

作るものを減らす

関係者で議論してストーリーの全体像が明らかになると、人や時間、資金といったリソースに対して、作るべきものが多すぎることに気付きます。本書では「いつでも仕事は多すぎる」と強調されています。

そこで、投資対効果（ROI）を最大化するという思考が必要になります。本書では「アウトプットを最小限に抑え、最大限の成果とインパクトを獲得しよう」と表現しています。
注意しなければならないのは、アウトプットを最小限に抑えるという点です。実装した機能の多さと、ユーザーに提供できる価値の大きさは、必ずしも一致しないのです。

作るものを減らすためには、優先順位をつける必要があります。そして、優先順位をつける際は成果、つまりユーザーが必要としているものに着目するようにします。ストーリーがユーザー中心となっていることの意味は、ここにも表れています。

大きすぎず、小さすぎないサイズ

ストーリーは適切なサイズに調整する必要があります。

大きすぎるストーリーは、ユーザーに価値提供するまでの期間が長くなってしまいます。そうすると、リリースと検証のタイミングが遅れることになり、無駄な努力となってしまうリスクが高くなります。また、開発工数の見積もりも難しく、難易度も高くなるでしょう。
一方で、小さすぎるストーリーは、ユーザーに提供できる価値も小さく、検証によって得られる学びも少なくなってしまいます。また、リリースやテストなどの手続きが増える分、ムダが生まれてしまいます。

適切なサイズに調整するためには、やはり会話が重要になります。ストーリーマッピングも有効な手段です。
ビジネス、ユーザー、開発者それぞれの視点によって、適切なサイズ感は異なるので、関係者で会話を重ね、何を作るかについての意見を一致させていきます。このプロセスは開発がスタートしてからも継続し、開発中のものにフィードバックを提供して、より良いものへと磨き上げていきます。

まとめ

個人的には、ストーリーは共通理解を築くためのメカニズムである、という点が一番印象的でした。
完璧なドキュメントを作ろうとするのはやめて、関係者での会話を大事にしなければならない、というのは大きな学びになりました。

これ以外にも多くのことが本書に綴られていますが、隅から隅まで読んで全てを理解しようとするよりも、ある程度内容を掴んだら、あとは実践の中で学んでいくことが大事なのかなと思います。

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