「ユーザーストーリーマッピング」をよみました
Jeff Pattonによる「ユーザーストーリーマッピング」を読みました。
## ストーリーを使う目的は、良いストーリーを書くことではない
ストーリーは、ステークホルダー間で良い会話を行うための材料にすぎないということです。本著ではユーザーストーリーマッピングのフレームワークが丁寧に記載されていますが、フレームワークそのものよりも、そのフレームワークからもたらされる良質な会話からステークホルダーの共通理解を得ることが非常に重要なのであると、Jeffは繰り返し述べています。「テンプレートにしたがって書かれたものでなくても、ストーリーはストーリーだ。」
## 製品開発の目標は、製品を作ることではない
アウトプットを最小限に抑えた上で、出来る限り早く、良きフィードバックを受けることで製品を小さなループで改善していくということです。場合によっては、ソフトウェアを作る必要すらなく、デザインコミック（アイデアを使って実際の問題を解決するシーンを漫画で描いたもの）やペーパープロトタイプを使うことで、アイデア〜アウトプットまでの時間を最短で数時間にまで短縮できます。そうすることで、ユーザーから素早くフィードバックを受け取ることができます。仮にユーザーから良い評価を得られないとしても、無駄になるのは数時間だけです。もし勝手な思い込みで、重厚長大なソフトウェアを作り始めていたとしたら、ゾッとしますね。。
## 「会話」で岩を砕いていく
大きなストーリー（＝オポチュニティ）からスタートし、会話によって徐々にストーリーを砕いていきます。
- ナラティブ・ジャーニーマップを使って会話し、オポチュニティを導く。
- オポチュニティキャンバスをつくり、会話でオポチュニティを絞る。
- ユーザーストーリーマッピングでMVSをプロトタイプし、ユーザーからフィードバックをもらう。
- フィードバックをふまえ、徐々にソフトウェアを膨らませていく。
ユーザーストーリーマッピングの実施方法については、以下のサイトも参考になります。
## さいごに
本著にはたくさん写真が掲載されていて、皆がいきいきとストーリーについて会話している様子が伝わってきます。ただただ、楽しそう。一方的に押しつけられる「要件」ではなく、双方向的な「会話」によってユーザーにとって本当に価値のあるものを、すばやく作っていく開発の現場を私はあまり知りません。GW明けに自分のチームでも実践してみたいと思います。
