ユーザーストーリーマッピング の商品レビュー

ジェフ・パットン(著者),川口恭伸(訳者),長尾高弘(訳者)

2024/04/29

アジャイル開発、特にスクラム開発では、ストーリーを優先度をもとに一次元のバックログに並べますが、ユーザーストーリーマッピングはストーリーの元となるユーザーペルソナなどと合わせ、ストーリーを二次元的に並べて整理するもの、でしょうか。

挙げられたストーリーがなぜこのプロダクトに必要なのかや、ナラティブフロー（ユーザーがプロダクトを使うときに体験する内容を時系列で並べたもの）の実現のために不足しているストーリーの可視化、不要ストーリーのあぶり出しなどにとても効果的だと感じました。

特にゲーム開発の場合、ユーザーの志向を無視した適当な機能実装を要求されることが多いので（ほとんどの場合、売れてる他ゲームの機能を何も考えずに入れ込もうとするケース）それを却下したいときに役立ちそうな気がします。

とても勉強になった本書ですが、難点があるとすれば、洋書特有のまわりくどい表現と冗長な文章でしょうか。変な比喩表現をなくしたり、要点を箇条書きにするなどすれば、すっきりした内容になって重要なポイントをつかみやすくなりそう（多分…）。

2024/01/16

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

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

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

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

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

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

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

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

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

2023/04/21

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

2023/04/15

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

2023/02/26

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

2022/11/30

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

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

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

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

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

2022/03/13

開発においてどうストーリーを位置づければよいのかについて知りたくて手にとった。ところが、この本はどうやってストーリーを作るのかについての本ではない。どうやって必要なものをリリースできるのかについての本だったのだ。完全なものを求めてもリリースできなければ仕方がないのだ。そこをどう折り合いをつけるというよりは決めるのかについての本なのだ。そのためにストーリーをマッピングするというのがこの本の提案。日本に馴染みのない例の部分はわかりにくい部分は多少あるけれど，それを補う面白さがある。次に作るものではこの方法を取り入れて考えてみたい。

2021/07/24

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

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

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

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

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

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

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

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

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

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

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

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

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

2021/05/22

新しいソフトウェアを開発する上でのユーザーストーリーの重要性が理解はできた。実践の中で読み返しながら、つまづいたポイントについては再学習が必要なほど、内容は充実していた。

2019/11/12

大事だなと思ったところ。

・ストーリーを使う目的は共通理解を作ること。
・ストーリーは要件ではない。
・ドキュメントで共通理解を作るのは難しいので、記憶を助けるドキュメントを。
・作れるものは限りある中で最大限の成果とインパクトを狙う。

中盤から文章が頭に入ってこなかったり、実装にどう繋げるか理解出来なかったので読み直したい。