ユーザーストーリーマッピング 13章から18章を読んで
上記の本を読んでいて、13章から18章まで各章ごとに印象に残ったことをメモりました。
13章 オポチュニティから始める
- 浮かんだばかりの大きなアイデアはエピックと呼んだりオポチュニティ(作者はこちら)と呼んだりする
- オポチュニティはすべて構築するのではなく、詳細に検討して先へ進むかボツにするか再考するか決める
- その手法として、オポチュニティキャンバスがある
- やるべきことがロードマップに載っているものでも誰のために何をなぜ作るのかについて会話を行おう
- ストーリーマッピングでジャーニーマップを作ってホットスポットからオポチュニティを探す
- ジャーニーマップに暗黙の前提がないか暴き出す手法としてリハーサル・リ・マッピングがある
- オポチュニティはすべて受け入れたとしてもダメ
14章 ディスカバリーを介して共通理解を築く
- ディスカバリーは構築ではなく学習のための仕事でオポチュニティに対し、問題の形、価値、利用可能性、実現可能性を問うて答えていくプロセス
- 議論する製品や機能の細部はすべて小さなストーリーのタイトルになる
- ディスカバリーの4つの基本的なスタイル
15章 ディスカバリーによる検証された学習
- 私たちはほとんどの機能追加の際、成果を出せないリリースをしてしまう
- それなのに、昔は素晴らしいアイデアだと肉づけることや素晴らしいリリースだったことに見せかけることに手間をかけていた
- デザイン思考を使おう
- 「その製品のユーザーになると、実際どう感じるものなのか」を理解するため、課題についてユーザー、顧客と「共感」しよう
- 共感フェーズで学んだことからこれから重点的に取り組む「特定の人々」および「特定の問題」を「定義」しよう
- 定義フェーズで定義した問題に対するソリューションの「アイデア」を意図的に複数「創出」しよう
- シンプルな「プロトタイプ」を作ってソリューションを研究し、顧客とユーザー自身が評価できるくらいまでプロトタイプを改良しよう
- ユーザー、顧客の問題が本当に解決できるソリューションかどうかを「テスト」しよう
- 動くように見せかけるフェイクを使っても問題解決に役立つかのテストに使える
- デザイン思考はビジネスニーズとターゲットとする人々をはっきりさせなかったり、調査と理解のために時間をかけすぎたりすることで簡単に失敗するプロセスになる
- リーンスタートアップ思考では、製品全体のプランを立てるのではなく最も小さいプロトタイプを作るように努力する
- ディスカバリーの段階では構築段階とストーリーの使い方に大きな違いがある
16章 リファイン、定義、構築
- カード - 会話 - 確認の3つのCのうち、最後のCに到達するために最後の最良の会話(ストーリーワークショップ)を行う
- ストーリーワークショップに参加すべきなのは通常は以下の3~5人
- 開発者
- テスター
- ユーザー
- UIデザイナーやビジネスアナリスト
- 会話に参加するかどうか、チームメンバーにオプトインを認めよう
- ストーリーワークショップは具体的に何を作るのかという質問に答えることに集中する
- その中で分割とスリム化を行うが、ストーリーの分割方法としてグッド・ベター・ベストゲームという手法がある
- デリバリーの状況を確認するためにストーリーマップを活用する
17章 ストーリーは実際にはアステロイドに似ている
- ストーリーは少しずつ、タイミングよく分解していかなければならない
- オポチュニティでは、ストーリーが誰のためのもので、彼らが解決したい問題は何か、その仕事が会社の事業戦略に沿ったものか、といった方向性の議論が中心で、それでも膨れ上がったオポチュニティを分解することはある
- ディスカバリーでは、誰がどのようにしてプロダクトを使うのかの具体的な内容を議論するため、何度も分解を行う
- 開発戦略のプランニングでは、リスクがどこにあるかを議論する。学習を念頭において岩を砕く
- 次の開発サイクルのプランニングでは、完成したことを確認する方法について意見を一致させる。一つのストーリーが一つの合意を満たすようにするために、ストーリーをさらに分割することになる場合がある
- バックログをクリーンにするため、小さなストーリーを一つにまとめる
- 機能についてのストーリーを語るために必要なだけマッピングをする
