読書メモ。2025年35冊目。
『ユーザーストーリーマッピング』を読んでの感想となります。（2025/6/8記載）
本の概要
本書はユーザーストーリーマッピングの作者、ジェフ・パットンが自ら開発した手法について書き下ろした書籍です。ストーリーマッピングの概要、優れたストーリーマッピングを作るためのコンセプトから、ユーザーストーリーを完全に理解する方法、ストーリーのライフサイクルの認識、イテレーションやライフサイクルごとにストーリーを使う方法まで、手法全体を包括的に解説します。マーティン・ファウラー、アラン・クーパー、マーティ・ケーガンによる序文、平鍋健児による「日本語版まえがき」を収録。製品開発、UXデザイン、業務要件定義の現場で、関係者が共通理解を持ち、使いやすく・実現可能なサービスや商品を作りたいと考えているすべての人、必携の一冊です。
引用：
動機
-
ユーザーストーリーマッピングは名前やなんとなくの形式だけしか知らず、アジャイルに携わる人間としていつか本質を知りたいと思っていた。
-
要求定義、要件定義とどう接合するのかイメージがつかず、ずっともやもやしていた。
- 現在のプロダクトチームでユーザーストーリーマッピングを試すことになり、今こそと着手！！
感想
今こそ読んでよかった一冊でした。
10年前に発売された書籍とは思えないほど、今読んでも学びが多かったです。
本書を読む前に思っていた「要求定義、要件定義とどう接合するのか」は、プロダクトを実現するためのアプローチから異なる内容でした。
そして、常々思っていた設計ドキュメントだけではコミュニケーション不足が発生し、開発チーム内で意図せぬサイロが生まれるといった危惧を解消してくれるプラクティスでもありました。
誰かが要求を定義し、誰かが要件を定義し、誰かが設計するという伝言ゲームで抜け落ちるものを、皆でユーザーストーリーマッピングで認識を揃えることでチームという集合体でプロダクトの実現に向き合えるイメージをつけることができました。
ストーリーを語ることを通して、チームでプロダクトで実現するものに向き合いたい。
忘れたくないメモ
■会話と協働（序文）
エクストリーム・プログラミングの中で、なぜ、要求ではなくストーリーを使うのかについて、深く話をしたのを覚えています。それは、会話と協働こそがエクストリーム・プログラミングの重要な構成要素だからです。書かれたものを投げ合うことよりも、会話を交わすことが重要なのです。
『エクストリームプログラミング』でも、ドキュメントと会話でのコミュニケーションについての話がありました。会話がチームとしての認識を醸成していく。
■共有ドキュメント
共有ドキュメントは共通理解ではない。
端的だけど刺さりまくる一言。
ひとりでメンテしているドキュメントは捨てても良いと思えました。
■共通理解を発展させる
私たち全員が別の重要な側面を見ているということだ。みんなのアイデアを組み合わせ、磨いていくと、全員の最良のアイデアを包み込んだ共通理解にたどりつく。アイデアを外に出すことが大切なのはそのためだ。私たちは、絵を描き直したり、ポストイットをあちこちに動かすことができる。すばらしいのは、私たちが本当にアイデアを動かしているところだ。私たちが実際に行っているのは、共通理解を発展させることだ。これは、言葉だけではとても難しい。
目に見える形で共通理解を作る重要性。
最近、こうした個々人の認識や思考のすりあわせのためにスクラムマスターが存在するのではと思っています。
■読んで思い出せること
もっとも大切なのは、書き出したものではない。それを読んで思い出せることだ。
こちらも端的だけど刺さりまくる一言。
仕様書よりSlackでのやり取りの方が忘れていた仕様を思い出させてくれたりします。
■誰のものなのか
あなたの目標は、新しい製品や機能を作ることだけではない。その機能について会話するときには、それが誰のためのものなのか、その人たちは(まだ機能がない)現状ではどうやっているのか、(その機能を提供したら)今後はその人たちを取り巻く状況がどう変わっていくのか、といったことを話題にする。そうした将来のポジティブな変化があるからこそ、それを欲しいと思うようになるのだ。
プロダクトオーナーと開発チームのコミュニケーションどの粒度で行われるかが重要と思っています。
既に実現したいプロダクトの姿が明瞭な状態で開発チームにやってくると製品や機能のことをメインに考えがちだと思います。
そうではなく、要求や課題が見える形でやってくると、開発チームはプロダクトの使われ方を意識しやすくなると思います。
そうして、その意識をどうプロダクトで実現していくか考えていく手段としてユーザーストーリーマッピングがよさそうであると理解できました。
■ストーリー
ストーリーは、要件を形式に落とし込むためのものではない。言葉と絵を使いながらストーリーを話すのは、共通理解を築くためのメカニズムだ。
ストーリーは要件ではない。会社、顧客、ユーザーが抱える問題の解決についての議論であり、何を作るかについての意見を一致に導くものだ。
あなたがしなければならないことは、より早くより多くのソフトウェアを作ることではない。作ると決めたものから最大限の成果とインパクトを生み出すことだ。
ストーリーについて初めて理解ができた気がする一文。
ストーリーは共通理解を築くためのメカニズム。
■誰もがすぐにそれについて話した内容を思い出す
言葉が消えていくのに任せてはならないということだ。カードに書き出して、後で読み返せるようにする。カードに書かれた単語を指さすと、誰もがすぐにそれについて話した内容を思い出すことがわかる。カードは、テーブルの上で動かして、再構成することができる。そのうち、カードを指さし、これとかあれといった便利な言葉を使い始めるようになる。これらを使うと、時間が大きく節約される。
誰かが仕様を書いたり、仕様を相談するための会議の議事録を取るのではなく、
チームが共通の認識を持って形に残すことが重要なんだと思っています。
今、WEB会議はトランスクリプトを取って、同じように扱えないかを試したいと考えています。
その会議での言葉は消えず、生成AIが重要な部分だけ切り取って教えてくれないだろうかと考えています。
■望まれる成果を実現できる最小のソリューションリリース
minimumは主観的な言葉だ。だから誰の主観なのかをはっきりさせよう。それはあなたではないのだから。あなたの顧客、ユーザーが誰なのか、彼らが何を達成しなければならないのかをはっきりさせるのである。では彼らにとってminimumとはなんだろうか。この質問が、会話をより有益なものにしてくれることは間違いないと約束できる。それでも、こうした会話はなかなか難しい。代替案として、HiPPO (Highest Paid Person's Opinion: もっとも給料の高い人の意見）方式というのもあるが、これはもっとダメだ。
最近、私はMVS (Minimum Viable Solution) という言葉を好んで使うようになった。私が企業とともに開発するほとんどのものは、まったく新しい製品ではなく、新しい機能、能力の追加やすでにある機能の改良である。そのため、製品というよりソリューションと言った方が適切な感じがする。そこで、私の定義を改訂しよう。
MVSとは、望まれる成果を実現できる最小のソリューションリリースである。
いつの間にかプロダクトのminimum、プロダクトオーナーの考えるminimumと思考がいってしまうので、注意したい。
■検証された学習
私たちの目標は、何かを作ることではなく、正しいものを作っているかどうかを学ぶことだ。なぜ、そう思うかというと、顧客の目の前に出せる何かを作ることこそ、正しいものを作っているかどうかを学ぶための最良の方法だからだ。
ユーザーに届けない限りプロダクトに求められるフィードバックを受け取ることはできない。
■マップをスライスして開発戦略を生み出す
顧客やユーザーに出しても大丈夫な第1リリースになると確信できるものを見つけたなら、全員でその最初の一般公開リリースを序盤・中盤・終盤のストーリーにもう1度スライスする。リスクと学習チャンスがどこにあるのかを突きとめる点で、製品を作ったチームより優れた存在はいない。デリバリーチームは、協力して作ったプランに対して自分のものだという気持ちを強く持つだろう。顧客やユーザーにとって価値のある(最初の)リリースになると確信できたら、チーム一丸となって序盤、中盤、終盤のストーリーとして、そのリリースをもう1度スライスする。
ウォーキングスケルトンという考え方。
■同じドキュメントを読んでも、読んだ人が異なれば、イメージすることだって異なる
ストーリーのアイデアは、ケント・ベックという非常に頭の切れる男が考え出したものだ。ケントは、90年代末に他の人々とソフトウェア開発の仕事をしていた。そして、ソフトウェア開発の最大の問題のひとつは、何を望むかを正確に記述したドキュメント、すなわち要件を使う従来のプロセスに起因するものだと気づいた。あなたはもうその問題が何なのかおわかりだろう。人々は同じドキュメントを読んでも、読んだ人が異なれば、イメージすることだって異なる。それなのに、彼らが合意に達したと信じこんでいるドキュメントには署名することすらあるのだ。
ドキュメントのコミュニケーションの不十分さ。
工程毎で人を分けてはいけない。
■最良のソリューション
最良のソリューションは、解決すべき問題を抱えている人々と、その問題を解決できる人々の間のコラボレーションから生まれる。
コラボレーションをどのように実現していくか。
どのようにそのための会話を実現させていくかが重要。
■どのように使われるかの視点
ケントのアイデアは、シンプルにやめることだった。完璧なドキュメントを必死に書くことをやめ、ともにストーリーを語ることにしたのである。ストーリーという名前は、どのように書くべきかではなく、どのように使われるかの視点から付けられた。
要求定義、要件定義は作るもののためのINPUTとしての価値にフォーカスされるのに対し、ストーリーは使われ方がフォーカスされる。
それを皆で考えることで、プロダクトに求められる価値にチームとして向き合えることができると思いました。
■あなたが作るものでユーザーが助けられることに関して、合意する
従来の開発プロセスでは、要件を知っている人の目標は、それを正しく書き出すことであり、ソフトウェアを開発する人の目標は、それを正しく理解することだった。
しかし、私たちの方法はストーリーに導かれていくプロセスなので、それぞれの立場で共有される目標は異なる。あなたの目標は、共同作業を通じて、新しいソフトウェアが解決するはずの問題を理解し、その問題をできる限り良い形で解決することだ。 最終的には、あなたが作るものでユーザーが助けられることに関して、合意する必要がある。
この一文からも、10年前に書かれた本だということに驚きます。
ただ、10年前の自分がこの本を読んでも、どう扱ってよいか分からず、あまり実感を得られなかった気もします。
■失っているかもしれない部分に自分で気づくのは不可能に近い
あなたと他の人々が何を作るべきかを理解するために共同作業を行い、作る人が知っていなければならない重要ポイントをすべてドキュメントにまとめた場合、そのドキュメントを誰か他の人に渡して開発を託したくなるかもしれない。なにしろ、自分でその情報を見る限り、自分にとっては一点の曇りもなく明確なのだ。だが現実を直視しよう。それほどはっきりとわかるのは、書き出されていない細部があなたの本当に優秀な頭脳にすべて入っているからだ。人の頭脳はこうした補完にとても長けているので、見失っているかもしれない部分に自分で気づくのは不可能に近い。それらの細部はあなたのバケーションの写真であり、彼らの写真ではないことを思い出そう。
猛省を促される一文。
そして、ドキュメントだけで自分の思考を伝えきることも無理に等しいと思っています。
■学習
ポイントとなる単語は学習である。学習が検証された学習になるのは、何かを作る過程で何を学びたいかを議論し、作った後で結果について考えるからだ。何を学んで何を学ばなかったかをじっくり考えるのである。そして、私たちは、学ぶために必ずしもソフトウェアを作る必要はないことを少しずつ理解し始めている。しかし、私たちは一般的に、何かを作るか何かを行う必要がある。
学習と議論が重要。そのためにも行動する。
■アウトプットを最小限に抑える
私たちの目標は、構築する量（アウトプット）を最小限に抑え、仕事から得られる利益(成果とインパクト)を最大限に引き上げることだと忘れてはならない。あなたのオポチュニティは、多数のより小さなストーリーに分解される。それを全部作ることは絶対にない。それではアウトプットを最小限に抑えることはできない。
残したアイデアよりも、捨てたアイデアの方が多いくらいでなければ、おそらくディスカバリーの仕事を正しくできていない。
我々は本当に必要なものだけをプロダクトに乗せているのか。肝に銘じたい。
■ワークショップ
これは会議ではなくワークショップである。会議という言葉は、今や非生産的なコラボレーションを表す婉曲語になっている。ストーリーワークショップは、たくさんの生産的な議論、ジェスチャー、ホワイトボードの画像、スケッチがぎっしり詰まっていなければならない。何を作るのかを正確に判断するために、私たちは共同作業する必要がある。この会話を終えるときにはしっかりとした共通理解に達していなければならない。生産的な言葉と絵による会話のための空間が必要だ。
我々はワークショップと呼ぶべき場をミーティングと呼んでしまっていないかと反省しました。
ワークショップとしてその場に臨むべき。
■機能するワークショップ
次のようなときには、ワークショップは機能しない。
・誰も参加しない。1人の人間が必要なものを説明し、全員がそれを聞いているとき。
・全員が受入基準のことばかり考えていて、誰が何をなぜしているかについてのストーリーを語る人がいないとき。
・機能と技術の両方の視点からオプションを検討できていないとき。
開発チームはどうしても主観的になってしまう。
そうした主観になりがちなところを補正するためにスクラムマスターがいると嬉しい。
