ユーザーストーリーマッピング

概要

O'REILLY ユーザーストーリーマッピングの内容を概要レベルで記載する

以下の点を重点的に記載する

• ユーザーストーリーマッピングの目的は何か
• スクラムにおいて開発者がどのようにユーザーストーリーマッピングにかかわっていくか

ユーザーストーリーとは

• プロダクトを利用する顧客(エンドユーザー)目線で、そのプロダクトで顧客にどのような価値を提供するかを簡単に記述したもの
  • ストーリーの会話は誰のためなのか、なぜなのか、誰のためかについても話す
  • アウトプットではなくアウトカム(成果)にフォーカスがある
• ストーリーは、共通理解を作成するために作成する
  • 共有ドキュメントは共通理解ではない
    • 共通理解があることとは、互いに相手がイメージしていることとその理由を理解していること。

ユーザーストーリー作成までのプロセス

以下のサイトの記載が詳しいので、こちらを参照する
(ロンジェフリーズの3Cについては少し説明が雑なので後に補足)
https://it-trend.jp/development_tools/article/32-0045

ユーザーストーリーマッピングとは

ユーザーストーリーマッピングには以下の記載がある

ストーリーマップを作ると、ユーザーとそのエクスペリエンスに意識を集中でき、より良い会話を交わすことができ、最終的には良い製品が生まれる。

アジャイルやリーンプロセスを使うことで、ストーリーを使うことで小さいことを作ることに注目しているため、アプリの全体像が分からなくなってしまうことがある。

ユーザーストーリーマッピングは、アプリケーションの全体像をつかみ、ビジョンを共有し、会話を交わし、良いアイデアをプロダクトに追加するために作成する
(思考の穴があった場合、追加することが出来る)

また、ストーリーマッピングではカードを並び替えるだけでコミュニケーションができる
(カードを並び替えながら共通理解を作り出すことが出来る、カードの配置は優先順位を表す)

以下のページに記載されている図がわかりやすい
(さらに追加でペルソナを定めることが多いと思う)
https://qiita.com/Koki_jp/items/6aebc73bedd0a932dcb8

ユーザーストーリーマッピングで実現できること

1. (MVP)リリースのスコープを定める
   • MVPは仮説を証明または反証するために作れる、あるいは実行できる最小のもの
   • 生み出せる機能ではなく、特定の成果に絞ってリリースを区切ろう
     • ペルソナを定めることによりリリースのスコープを狭める
2. リリースロードマップを作成する
   • スライスごとにリリースするとは限らない
     • スライスはそれぞれの学習目的が達成できているかチームメンバーが立ち止まって振り返るタイミングである

ユーザーストーリーマッピングのステップ

書籍には以下の方法が一例として紹介されている

1. 問題の枠組みを明らかにする
   • なぜマップを作っているか(何のために共通認識を作りたいのか)
2. 全体像をマッピングする
   • ユーザーが感じてる苦痛、喜びを含めて現状をマッピングする
3. 掘り下げる
   • ユーザーストーリーを切り出す
   • スケッチ、プロトタイプ、ソリューションの改良案のアイデアなども出す
4. リリース戦略を切り出す
5. 学習戦略を切り出す
   • MVPから学習できることを洗い出す(構築-学習-測定ループの定義)
     • 参考資料:https://www.e-mtb.space/practice-lean-startup-simple-summary/
6. 開発戦略を立てる
   • MVPの中でも早めに構築するもの、後回しにするものを定める
     • 例.) 開発リスクの高いものは早めに着手する

以下のページに、上のステップの2~4の部分までについて詳細に記載があるので、こちらも参考にしてほしい
https://do-scrum.com/userstory/

開発の流れ

開発の全体像をつかむために、ストーリーを細かい粒度に分解しデリバリーするまでの流れを以下に記載する
また、各ステップの詳細を以下に記載する

1. オポチュニティを評価する
2. MVPをディスカバリしストーリーを分割
3. ストーリーの細部について決定する
4. 評価を行う
5. リリースしユーザーからのフィードバックを得る

1. オポチュニティを評価する

• オポチュニティとは、実現する新機能や新製品、機能改善のこと
  • エピックとも呼ばれる
• オポチュニティバックログという形でリスト化されているとよい

2. MVPをディスカバリしストーリーを分割

• オポチュニティをユーザーストーリーに変換する
• ユーザーストーリーマッピングこの段階で行われる
• ワイヤーフレームやプロトタイプはこの段階で作成される
• プロダクトオーナーが率いる組織横断チームがプロダクトディスカバリーを行う??
  • 大きなアイデアを実際に実行可能なサイズに変換する
  • プロダクトディスカバリーはデザインの専門能力と技術的な専門能力を持ったメンバーで構成される

3. ストーリーの細部について決定する

• 具体的に何を構築するかを意見を一致させる
  • チームメンバーとともに、ストーリーの細部を掘り下げストーリーの受入れ基準について意見を一致させる
  • スクラムでいうところの、バックログリファインメントにあたる
• またバックログの受け入れ条件についても合意をとる
• スプリント内で作っているなかでも細部について会話を続ける

4. 評価を行う

大きく以下の三つの評価がある

• チーム内部での評価
  • 製品の品質、スプリントのプラン二ング、作業方法が適切だったかを振り返る
  • スクラムでいうところのスプリントレビュー、スプリントレトロスペクティブ
• ユーザー・顧客との評価(期待を満たしているか)
• ビジネスステークホルダーとの評価(期待を満たしているか)

5. リリースしユーザーからのフィードバックを得る

リリースできる状態になれば、ユーザー・顧客向けにリリースする
その結果、ユーザーからのフィードバックをとともに、次のオポチュニティバックログを得る(構築-学習-測定ループ)