概要

本書は、アジャイル開発における要求定義、要件定義の手法として「ユーザーストーリーマッピング」についてまとめられている。重要なポイントは手法ではなく、なぜ使用するのか、理由と目的が中心となっている。アジャイル開発で陥りがちな罠、誤解、それを「ユーザーストーリーマッピング」を適用することで、どのような改善が表れたのか、実際にあった事例を交えて解説されている。手法はあくまでも道具であり、会話すること。会話して学ぶことがいかに大事であるかが学べる。「ユーザーストーリーマッピング」の手法の本と言うよりは、アジャイル開発を良くするためのことが書かれているため、アジャイル開発に関わる人はとっては、とても有益な学びが得られると思われる。

本書の使い方

なぜ「ユーザーストーリーマッピング」という手法を使用した方が良いのか。手法の使い方ではなく、手法を使うことで、どのようになってほしいのかが冒頭の0章にまとめられている。本書の本質はここに全てまとめられており、以降はそれが出来るようになるための手法の使い方の紹介である。0章が本書の一番大事なこと、最も読者に伝えたいことである。
本書では、「ユーザーストーリーマッピング」の具体的な手順、考え方や事例、練習に向いた題材も紹介されている。本書の通りに準備して、紹介されている題材を使い、0章の内容を理解した後、実際に「ユーザーストーリーマッピング」をやりながら、読み進めていくと、より理解を深めることができる。
なお、本書では、適度に読み飛ばす方法も紹介されている。読み飛ばせるように、各章では、テーマ（伝えたいこと）が目立つように、要所要所に見出しで書かれている。全てを読む時間が無いときなどはこの見出しのみを押さえていくと良い。
以下の「学べること」に、本書に書かれている主な見出しもまとめた。気になる見出しがあるようであれば、本書を読むことをお勧めする。

何を学べるか

0章　まず最初に読んでください
アジャイル開発における一番大事なこと、見誤りがちな本質が学べる。
・共有のためのドキュメントは、共通理解を得られるということではない。
・完璧なドキュメントを作成しようとすることはやめよう。
・ストーリーを作る目的は、共通理解を得ること。
・作ろうとしているものではなく、誰のために何故作成するのかについてを話そう。
・作るものは減らそう。

1章　全体像
アジャイル開発における「ストーリー」とは？「ストーリー」に対して「ストーリーマッピング」がどのように働きかけるのか？
・「ストーリー」は書くのではなく語るもの。
・「ストーリーマッピング」によって思考の穴が見つかりやすくなる。

2章　ソフトウェア資産化の技術がリコール防止につながる
ソフトウェア開発の理想と現実。開発の現実に対する「ストーリーマッピング」の活用事例。
・作るべきものは、常に、人、時間、資金以上に存在する。
・スコープクリープは無い。
・システム内部の機能を決めるには、まずシステムの外側で起きてほしいことを考える。
・開発における優先順位付けとは、特定の成果に的を絞ること。
・成果を実現できる最小の製品のリリースを考える。

3章　より早く学ぶためのプラン
ソフトウェアを作る前に行うことは、要件を定義することではなく、なぜそれを作りたいのかを学ぶこと。
・使う価値のあるソリューションなのかどうかは、プロトタイプを作成してユーザーに見てもらわないと分からない。
・すべてのリリースは実験である。

4章　時間どおりに終わらせるためのプラン
共通理解を築かなければ、最良の見積もりは出来ない。インクリメンタル思考な見積りは上手くいかない。イテレーティブ思考で評価する。
・イテレーティブ思考で評価し、すでに作ったものに変更を加える。
・インクリメンタル思考で追加し続ける。

5章　あなたはもうやり方を知っている
実践演習。自身の朝の生活を題材にストーリーマップを作成してみる。

6章　ストーリーについての本当のストーリー
ドキュメントはたいてい「何が」必要かは書かれているが、「なぜ」必要かは書かれていない。「なぜ」は話をしないと分からない。大事なのはドキュメントを作ることではなく、会話すること。
・私たちは同じドキュメントを読んでも、違う理解をする。

7章　より良いストーリーテリングのために
より良い会話をするために意識すること。

8章　カードに書かれていることがすべてではない
共通理解を築くためには様々な人との会話が重要。共通理解を築くことが出来た時には細部まで思い出せるようにするには？
・会話の内容を写真などで残す。写真に残すとその時の会話の内容が思い出しやすくなる。

9章　カードは始まりにすぎない
ストーリーは学ぶために作る。
・ストーリーの詳細を他の誰かに渡して、ソフトウェアを作ってもらおうとしても、決してうまくいかない。
・動くソフトウェアよりも「検証された学習」を。
・ソフトウェアでもそうでなくても、ものを作るときはストーリーを使って作業を導く。

10章　ケーキのようにストーリーを焼く
ストーリーを小さく分割していくための計画の立て方。
・ストーリーが表しているソリューションが、コストのかかりすぎるものなら別のソリューションを検討する。
・ストーリーがコスト的に問題無くても、大規模なソリューションである場合、進行状況を評価、確認できる小さな部品に分割する。
・大きなものを大きなプランに分割してはいけない。大きなものは小さなプランの小さなものに分割する。

11章　岩を砕いていく
ストーリーはそれぞれの立場によって適切な大きさがある。
・ユーザーの視点から見た適切なサイズのストーリーは、ニーズを満たすストーリーである。
・開発チームの視点から見た適切なサイズのストーリーは、ビルド、テストに数日しかかからないストーリーである。
・ビジネスの視点から見た適切なサイズのストーリーは、会社が業績を上げるのに役立つストーリーである。
・会話は、大きなストーリーを分解するための最良のツール。

12章　岩を砕く人
アジャイル開発でソフトウェアを開発していく上で、本当に必要な人たちとその立ち位置。
・すべてのストーリーを書き、ストーリーについてのすべての会話に参加する、ひとりのプロダクトオーナーを設けても破綻する。
・プロダクトオーナーが率いる小規模な組織横断チームがプロダクトディスカバリーの仕事を取りしきる。
・ユーザーエクスペリエンス、デザインの専門能力と技術的な専門能力を持った人々を含む、コアチームでプロダクトオーナーをサポートする。
・他のステークホルダーが出したアイデアのために、プロダクトオーナーの任にあたるときは、プロデューサーの役割となる。

13章　オポチュニティから始める
ボツになることは良いことである。積極的にボツにしよう。
・共通理解を築き、チーム内に共感を生み出すために、軽めのペルソナを共同で作る。
・ソリューションの共通理解を築くために、ユーザーインターフェースを可視化する。

14章　ディスカバリーを介して共通理解を築く
ディスカバリーについて。ディスカバリーはソフトウェアを構築することではない。
・残したアイデアよりも、捨てたアイデアの方が多いくらいでなければ、ディスカバリーの仕事は正しくできていない。
・機能の優先順位を考える前に、具体的なビジネスゴール、顧客、ユーザーの目標の優先順位付けをする。

15章　ディスカバリーによる検証された学習（Validated Learning）
自分たちが出したアイデアはほとんど間違っている。
・ユーザー、顧客と直接話す。解決したい課題を実際に経験すべき。
・1つ、またはごく少数の問題だけに絞り込んで、それらを具体的にする。
・ユーザー、顧客の問題に対する可能なソリューションを意図的に複数用意する。
・シンプルなプロトタイプを作って最もすぐれたソリューションを研究する。プロトタイプを改良して、問題が本当に解決されるかどうかをユーザーと顧客自身が評価できるようにする。
・最初から成功すると思ってはならない。反復的に改良していく。
・学習し損なうことが最大の失敗。

16章　リファイン、定義、構築
ストーリーの会話は、会議ではなくワークショップである。拷問のような会議はやめよう。

17章　ストーリーは実際にはアステロイドに似ている
ストーリーは、すべてを分割してしまうと、全体像が分からなくなる。少しずつ分割していかなければならない。

18章　構築するすべてのものから学ぶ
レビューについて。ユーザーから学ぶ。
・ソフトウェアに本当の完成はない。
・成果が保証されることは決してない。
・リリース後に加えた改良はもっとも価値がある。

19章　終わり？それとも
まだまだ触れられていない部分はたくさんある。この本に書かれていることがすべてというわけではない。