ユーザーストーリーマッピング 0章から6章を読んで
上記の本を読んでいて、0章から6章まで各章ごとに印象に残ったことをメモりました。
0章 まず最初に読んでください
- 言葉で表現された文章が正確な製品の実態を示すものではない
- ストーリーを用いるときは、ストーリーを作ること自体ではなく絵や写真も用いて「共通理解」を築くことが大切
- アウトプットを最小限に抑えて、最大限の成果とインパクトの獲得を目指す
1章 全体像
- ただ単にストーリーを作っていくとその粒度の差から開発可能な粒度に揃えると全体像が見えなくなってしまう
- ストーリーマッピングでは、１つのストーリーを掘り下げる前に全体像としてどのようなストーリーがあるか明らかにする
- その過程で思考の穴が見つかりやすくなる
- 複数のユーザーのストーリーが見つかることもある
- ストーリーマッピングでは、ストーリーの全体像を作ってから詳細や代替案を考えていく
2章 作るものを減らすためのプラン
- いつでも作る量に対して、時間や資源は少なすぎる
- 複数のチーム間で共通理解を深めたりチーム間でタスクに漏れがないか確認するためにストーリーマッピングを用いることができる
- マップの最上部がバックボーンと呼ばれ、バックボーンがマップを体系化する
- ユーザーが必要とすること(成果)が生まれるリリースを切り出し、リリースの優先順位の基準に成果を用いよう
- MVPは、仮定を証明または反証するために作れる、あるいは実行できる最小のものである
3章 より早く学ぶためのプラン
- 大きなアイディアをオポチュニティとして扱い、オポチュニティの枠組み(そもそも何か/顧客は誰か/ユーザーは誰か/彼らはなぜ製品を使いたいと思うか/なぜ私たちはそれを作るのか)の枠組みを確認する
- 顧客開発パートナーと話をして、解決しようとしている問題が本当にあるか確かめよう(その結果によってオポチュニティは変化する)
- ソリューションをイメージするためにプロトタイプを作り、ユーザーに見てもらおう
- 人々が実際に毎日それを使うことを選んだときに証明は得られる
- minimum未満のものを作ってviableになるまで開発パートナーに対するリリースを繰り返す
- その時々ごとに利用することができ学ぶことがあるような形でリリースをしよう
- MVPに向かう過程でさまざまなツールやテクニックを使って行っていることをプロダクトディスカバリーと呼ぶ
- 目標は自分が正しいものを作っているかどうかをできる限り早く学ぶことだ
4章 時間通りに終わらせるためのプラン
- マップは会話の助けに必要な分だけ作ればよい
- 最良の見積もりは、自分が何を見積もっているのかを本当に理解している開発者から出てくるので開発チームと共通理解を築く必要がある
- 機能の最後まで道をつなげるスライス(歩くスケルトン)、それをもっと良くするスライス、機能を磨けるだけ磨くスライスを分ける
- 上記スライスは開発用マイルストーンなのでいちいち顧客にリリースしない
- 作るのにどれだけかかったか測定することで多少は見積もりを正確にできる
- リスクの多いプロジェクトの場合、リスクストーリーを追加することで状況を可視化できる
- インクリメンタル戦略(個々の部品を順に完成させていく)とイテレーティブ戦略(下書きから徐々に構図や色を変更していく)
- イテレーティブ思考で評価し、インクリメンタル思考で追加し続けよう
- リリースバックログを製品全体に関わる基礎的な機能や基本的なユーザー行動、リスクの高い部分に注力する序盤、仕上げの部分を埋めていく中盤、リリースを磨く終盤に分ける
5章 あなたはもうやり方を知っている
- タスクは短い動詞句で構成され、目標を達成するためにすることを表している
- ユーザータスクはソフトウェアを使う人々が目標達成のためにしているタスク
- ゴールレベルの概念を使って、小さなタスクを一つにまとめたり、大きなタスクを分割したりしよう
- ストーリーのマッピングは、ナラティブフローを使って左から右へ向かう
- 細部、代わりのタスク、変種、例外などはマップの縦方向に入る
- 目的ごとにタスクをアクティビティという形で集約する
- アクティビティと大まかなタスクがストーリーのマップのバックボーンを形成する
- 特定の目標を実現しやすいようにタスクをスライスする
- ユーザーが将来、製品を届けられたときに振る舞う将来のマップと現在の振る舞いについてのマップがある
6章 ストーリーについての本当のストーリー
- 私たちは同じドキュメントを読むことができるが、違う理解をする
- ストーリーという名前は、どのように書くべきかではなくどのように使うべきかについて付けられた名前だ
- ストーリーの思想は語ることにある
- ロン・ジェフリーズの３つのC ... スローリーのプロセスの説明
- Card ... ソフトウェアに望むことをインデックスカードに書いていく
- Conversation ... 集まってどのようなソフトウェアを作るかについて豊かな会話を交わす
- Confirmation ... ソフトウェアが完成したことをどのように確認するかについて意見を統一する
- 製品全体、あるいは既存の製品に加えたいすべての変更を記述しているカードの山のことをプロダクトバックログと呼ぶ
