【ユーザーストーリーマッピング】要約メモ[前半]

[※自身の理解のために、実際に本書で使われている言葉や見出し、構成と異なる部分があります。]

自分の会社で新規事業の立ち上げはいくつか経験していたが、今事業開発にデザインの側面から関わらせていただいているソフトウェアの新規アジャイル開発は初めてだったので、改めて、"ユーザーストーリーマッピング"を勉強してみた。

ソフトウェアに関わらず、ゼロイチでものを作る時の大切なことを学べます。

0章　まず最初に読んでください

「共有ドキュメントは共有理解ではない」

開発以外の場面でも、チームに新規開発のための共有ドキュメントを配れば、『これでみんな理解しているだろう』と勘違いする。

伝言ゲームが最たる例で、人間はそんな物だけで共通理解ができるようには設計されていない。

メンバー内で、顧客やユーザーのストーリーをスケッチやポストイットでアイディアやイメージを手を動かし、議論をしながら作り上げていく。

この体験が、文書化できないほどの共通理解とそれぞれの記憶を助ける。

「アウトプットよりも、顧客にどんなアウトカム・インパクトを届けたいか」

ストーリーを使って共通理解を得ようとする時、念頭におくべきことがある。

人々が不満に思っていることや抱えている課題があり、リリースしたものが使われることによって、どんなことが人々の間に起こるのか(=アウトカムoutcome)、それが社会にどんな影響を与えるのか(=インパクトinpact)。

"誰のための、何なのか"

あなたの大切なこの考え、モチベーションによって、あなたは世界を変える。

「作るものを減らそう」

時間もリソースも有限。最小のOutputで、最大のOutcome・Inpactを得るようにしなければならない。

そのためには、やはりユーザーの課題に注意を払う必要がある。

ストーリーマッピングをすべき理由

1. 全体を可視化することで、本当に必要なものは何か全員で考察することができる

2. 必要な要素の抜け漏れがなくなる

(p19 １章全体像)

アイディアから実装に練る過程には、拡散と収束がある。

誰に何の制限されることなく思いつくままにアイディアを広げていく拡散。その後に、ニーズから本当に必要な機能は？優先順位は？と、本当に使う価値のあるものにするためにブラッシュアップしていくという工程である収束を行う。

ストーリーマッピングは、例えば、ソフトウェア開発の場合に本当に実装すべきものは何か、現実的に減らしていく収束の過程を考えるという最も重要なことを行うことがしやすいメリットがあると思う。

収束の仕方

(p49 ２章作るものを減らすためのプラン))

1. MVPリリースで切り出す

成果(Outcom)に絞って、最優先で作り上げるべきものを分け、決めていく。

直近で必ずここまでに成果が必要なものから作るという、リリースロードマップで切り出す。

2. 機能ではなく、成果で優先順位をつける

まず、優先して生み出したい成果を決め、それに今必要か否かで、決めていく。

MVPの定義

(p56 ２章作るものを減らすためのプラン)

次項につながるので、端的に、本書の回答だけ記載。

MVPは、過程を証明または反証するために作れる、あるいは実行できる最小のものである。

MVPの、Minimum・Viableによって生み出されるOutcomeは、リリース後にしか判明しない。マッピングを行う段階では、必ず仮定が含まれてしまう。その仮定を結果から学ばなければならない。

学びのために、作る

オポチュニティを議論する

・大きなアイディアとは何か？

・顧客は誰か？この製品・サービスを買いそうな会社はどこか？

・ユーザーは誰か？それらの会社でこの製品を使いそうなのはそういうタイプの人々か？彼らは製品を使ってどのような問題を解決しようとするか？

・彼らはなぜ製品を使いたいと思うか？顧客、ユーザーは、今解決できないどのような問題を解決しようとするか？

・なぜ私たちはそれを作るのか？この製品を我が社にどのような意味を持つか？

この章では、特にこの内容が大事だと思ったので、抜粋します。

前半まとめ

前半は、新規開発に必要な考え方や基本的なマッピングのやり方、事例が中心でした。

弊社のシリコンバレーでも活躍していた優秀なエンジニアが言っていた「使わないものを作らせないでくれ」という言葉から、本当にユーザーが使うものを仮定の段階から想定して仕込んでいくということ大変さが透けて見える。。

でも、そこが面白さでもあるけどね。