ユーザーストーリーマッピング
ユーザーストーリーとは
>新しい機能を使いたい人 (通常はその製品のユーザーや顧客) の視点から製品の機能を短く簡潔に説明したもの
ユーザーストーリーマップを利用するメリット
>作業の優先順位を付けられる
> ユーザーストーリーマップを作成することでユーザーエクスペリエンスの全体像をチームで把握でき、メンバーが必要なタスクを決定してスプリントやリリースにまとめる作業がしやすくなります。
> ユーザーに対する価値を重視できるようになる
> ユーザーの視点からストーリーを構築することで、開発チームは、ユーザーと製品との関わりを把握し、その関わりの促進のために満たすべき要件を理解できるようになります。
> 障壁が見えやすくなる
> 製品を俯瞰的に見られるユーザーストーリーマップを使うことで、問題、リスクや課題が明らかになり、問題が発生する前に予防策を取れるため、時間の節約につなげることができます。
> チームの結束力が高まる
> ユーザーストーリーマッピングの過程では、その名の通り、チーム全体でユーザーストーリーに対する合意を形成し、これに従って製品の製作を進めます。進むべき道を見失った際には、いつでもこのマップに立ち返り、原点を確認することができます。
> 継続的改善が実現できる
> ユーザーストーリーマップを入念に定義し、優先順でストーリーをグループ化してイテレーションの中で処理していくことで、プロセスの早い段階でフィードバックを集め、プロジェクトの進行に合わせて改善することができます。
>O’Reilly Japan - ユーザーストーリーマッピングには…
> ストーリーマップを作ると、ユーザーとそのエクスペリエンスに意識を集中でき、より良い会話を交わすことができ、最終的には良い製品が生まれる。
>バックボーンと呼ばれる左から右に流れるアクティビティを書く
>アクティビティは動詞で書くことを推奨とのこと
>図ではバックボーンは2段で書いていますが、別に1、2段でも良いらしく、最初は1段で書いて多くなったら2段にして分類分けなど柔軟な運用も可
> それぞれのレベルに名前が欲しいところですが、書籍によるとまだ無いとのこと
> バックボーンを書いたら、アクティビティの詳細を書いていく
> 機能と呼ぶことが経験上多いです
ユーザーストーリーマッピングでできないこと
> 要件定義ではないので、細かな仕様整理には使えない
> 当然、画面表示項目や、入力バリデーション規則などは定義できない