ユーザーストーリーマッピング

著者 : Jeff Patton 長尾高弘

• オライリージャパン (2015年7月25日発売)

作品紹介・あらすじ

「ユーザストーリマッピング」提唱者による書き下ろし！
「ユーザストーリマッピング」は、Jeff Patton氏が提案する計画手法で、顧客の視点からサービスや商品の要件を記述することを特徴とします。XPを実践するためのプラクティスの一つで「ユーザストーリー」があり、これはワークショップ形式で機能を洗い出しながら、インデックスカードに記録して並べ替えていく手法です。

感想・レビュー・書評

[yoskhdiaさんの感想 · 2016年1月21日]

プロダクト開発に関わるあらゆる人にとって福音書となり得る。
アジャイル開発について、これまで色々なものを読んできたが、この本で自分のなかでは一通りの道具が揃ったように思える。これからアジャイル開発を勉強する人には、以下の書籍と併せて本書をオススメしたい。

・アジャイルサムライ−達人開発者への道−（http://booklog.jp/item/1/4274068560）
・アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~（http://booklog.jp/item/1/4839924023）

アジャイルサムライで、その意義とチームとしてどうあるべきか、全体像を学ぶことができた。次に、アジャイルな見積もりと計画づくりで、計画そのものではなく”計画づくり”が重要であることとその技法を学んだ。この時点でも、アジャイル開発について、ある程度は腑に落ちていたのだが、出発地点であるストーリーの作り方については、ずっと模索している状態だった。これを解決したのが本書で、ストーリーの出し方、整理の仕方、ステークホルダーとチームへの活用など、あらゆることが惜しみもなく書かれている。

システム開発ではなく、プロダクト開発としてみると、例えば営業のプラン作りにも活用できるのではないかと思える。プロダクトはシステムだけで成り立つわけではなく、そこには沢山の役割の人が関わる。ストーリーマップの主戦場はシステム開発なのかもしれないが、これを介してプロダクトをプロダクトに関わる人すべてが考えることができる優れたものであることが分かった。
著者も言うように、端々のトピックは誰かが既に述べていたものであるかもしれないが、それらをストーリーマップという言葉と形でまとめあげ、通貫したものとしたことは賞賛に値する。オライリーから出ているから技術書だろう、などと思っては非常に損。

[2319chanさんの感想 · 2021年7月24日]

　アジャイル開発のお勉強。

■シンプルな優先順位付けモデル
・差別化機能：ライバルとの差を生む機能
・相殺化機能：ライバルの差別化機能に近づく機能
・コスト削減機能：組織のコストを下げる機能
・テーブルステークス機能：市場での競争のための必要な機能

■ストーリーマッピングの６つのシンプルなステップ
１．問題の枠組みを明らかにする
２．全体像をマッピングする
３．掘り下げる
４．リリース戦略を切り出す
５．学習戦略を切り出す
６．開発戦略を切り出す

■私たちは同じドキュメントを読むことができるが、違う理解をする
　ドキュメントにはたいてい何が必要かが書かれていて、なぜ必要なのかは書かれていない。ソフトウェアを作る人が、将来ソフトウェアを使うユーザーと彼らがそれを使う理由を理解している人と話すことができれば、コストをかけずにそれらのユーザーを喜ばせる方法が見つかる。話をしなければ、大切なことは決してわからない。

■最良のソリューションは、解決すべき問題を抱えている人々と、その問題を解決できる人々の間のコラボレーションから生まれる
　…完璧なドキュメントを必死に書くのをやめ、ともにストーリーを語ることにしたのである。

■ストーリー駆動とドキュメント駆動
・ストーリー駆動：
　共通理解を築くところから始める
　→議論を通じて共通理解を広げる
　→共通理解を形にしたソフトウェアを作る
・ドキュメント駆動
　共通理解を築くところから始める
　→ドキュメントだけを読んだのでは理解にずれが生じる
　→作られたソフトウェアが期待はずれのものになっても不思議ではない

　効率的な議論や意思決定は、２人から５人の少人数のグループがもっとも適している。…しかし、人数が５人よりも多くなると、１つの話題で話をするためには努力が必要になってくる。

■仕事の結果を点検する
・ユーザーエクスペリエンスの質
・機能の品質
・コードの品質
　書いたコードの品質は高いか？標準に合致しているか？しばらくこのコードを手元に置いておく場合もあるので、拡張、メンテナンスしやすい感じがするか、後で対応しなければならない「技術的負債」があるかどうかを把握しておくといい。

■これはあなたのためのものではない
　チームの全員がユーザーの横にいる必要はない。実際、全員が雁首を揃えて待ち構えていたら、ユーザーは逃げ出すだろう。しかし、そこにいると、他の方法では得られていない共感が生まれる。ユーザーが自分の製品を使って苦闘しているところを見ると、俄然やる気が出てくるものだ。

■ストーリーが表しているソリューションがコストのかかりすぎるものなら、目標達成に近づく別のソリューションを検討しよう。

■ストーリーがコスト的に問題はなくても、大規模なソリューションを表している場合、早い段階で進行状況を評価、確認できる小さな部品に分割しよう。

■大きなものを大きなプランに分割してはならない。大きなものは、小さなプランの小さなものに分割するのだ。

　ところで、そもそもカップケーキはウェディングケーキにはならないのではないだろうか？いや、そういうものもあり得る。

[mikuriyaさんの感想 · 2019年10月26日]

多くのユーザーのなかから一人に絞ってその人を満足させるとしたら、誰にする？

海外の人はこの手の質問が非常に上手い。問いが自由で本質的。

ー基本的な質問ー
大きなアイデアとはなにか？
顧客は誰か？ユーザーは誰か？
彼らはなぜ製品を使いたいと思うか？なぜ私たちがそれをつくるのか？我が社にとってどんな意味を持つのか？

すべてのリリースを実験として扱い、何を学びたいのかを忘れないようにする。リリースすると区切りのごとく打ち上げしてしまうが、本来ならKPI達成時点で打ち上げするべきだ。開発をしているうちにビジネスの目的が見えなくなっていく。

■ストーリーマッピングの6つのステップ
1.問題の枠組みを明らかにする
2.全体像をマッピングする
3.掘り下げる
4.リリース戦略を切り出す
5.学習戦略を切り出す
6.開発戦略を切り出す

学習戦略という考え方が斬新。

■ユーザーストーリーを確定するための3層構造
1.最初は粗いステップを明らかにする
2.ユーザーロールごとに細かいアクティビティに分割する
3.「〈ロール〉という立場から、私は〈価値〉を得るために〈機能〉が欲しい」という形式で具体化する。

例）
〈ユーザータイプ〉として、私は〈これこれの結果を得る〉ために、〈これこれ〉をしたい。
バンドマネージャーとして、私はチラシをカスタマイズするためにイメージをアップロードしたい。→ここから議論がはじまる

ーロンジェフリーズの3Cー
カード・・・ソフトウェアに望むことをカードに書いていく
会話・・・集まってどのようなソフトウェアをつくるかについて会話する
確認・・・ソフトウェアが完成したことをどのように確認するか意見を統一する（受入基準、デモ）

全体を可視化して議論する。見えているカードに対して意見を積み上げていくのだ。

ーぼやきー
価値とは何だろうか？どうパターン化されるか。
パターン化できるならばフレームに則って価値検討、実現手段に落とせる。価値とはなにか

[kotanitaさんの感想 · 2024年1月16日]

目的：ユーザーストーリーについて理解する

感想：とても勉強になりました。ユーザーストーリーという言葉の意味、実際の使い方がよく理解できました。

その他プロダクト開発の進め方について勉強になる点が複数あり、とても参考になりました。

今後も教科書的に読んでいきたいと思います。

要点：
・ユーザーストーリーはユーザーの行動ストーリーである。誰に、何を、なぜで考える

・ユーザーストーリーはプロダクト開発に関わる人たちとの共通理解のためにある

・ユーザーストーリーには大きさがある。時にはエピックと呼ばれたりする。開発用のストーリーは1日2日程度でテストまでできるもの(ここが1番知りたかった)

・ユーザーストーリーを考えて最小のアウトプットで最大のアウトカムを出す、結果インパクト(事業成長)を狙う

・オポチュニティ(アイデア)発生→オポチュニティ評価で進行判断→ディスカバリーでMVP(MVS)を決める→ストーリーワークショップでストーリーの分割調整→制作、の流れ

[さとうさんの感想 · 2023年7月14日]

BDD系の本
ソフトウェア開発をするのであれば、確実に読んでおきたい一冊

[noppoさんの感想 · 2023年4月21日]

本書の一番最初でも注意しているが、これはユーザーストーリーの書き方の本ではない。ストーリーはあくまで共通理解を得るためのものであり、大事なのは会話。という内容。

[mcmrさんの感想 · 2023年4月15日]

もう一週間早く読めば良かった…
プロダクトディスカバリーについてこれでもかとポイントをおさえている良書。早速実践します。

[mnagakuさんの感想 · 2023年3月18日]

気づきが多い本だった。ただ、今の自分には使いどころが難しい感じなのが残念。

[toshi591989さんの感想 · 2023年2月26日]

プロダクト開発を始める前に一度読んでおくと良い
自分達が作りたいプロダクトが誰にどんな価値を提供するのかを整理できる
※根本的に業務のやり方を変える場合はストーリーマッピングではなくクリティカルシンキングがベター

[ココ太郎さんの感想 · 2022年11月30日]

ソフトウェア開発の話が中心のため、思っていたよりもエンジニア向きな内容で、そうでないものにとっては少しイメージのしにくさを感じた。
ストーリーマッピングの意義(必要性)は本書を通じてよく理解できた。
ページ数は多いものの、同じことが繰り返し書かれている印象。

印象に残ったのは以下の内容。

・「要件」という便利な言葉を使うことのリスク
(ウェイターではなく医者であれ)

・あれもこれもとやろうとせず優先度の高いことの実現に集中すべき

・機能よりもユーザーの価値を優先すべき