フラットなバックログは優先度でソートされたリストです。次に何を構築するかは示しますが、各パーツがどのように組み合わさるかは示さず、ユーザーが完了できない10個の磨き上げられた機能をリリースしがちです。ユーザーストーリーマップは、ストーリーをユーザーの旅に沿って配置することでこれを解決し、製品全体を見渡して、開始から終了まで機能する最初のリリースを切り出すことができます。
このガイドでは、ストーリーマップの作成方法、その最上位のスライスをMVPの範囲に変換する方法、各ストーリーをINVESTで検証する方法、そして大きなストーリーをスプリントサイズに分割するためのパターンについて説明します。まず基礎から始めたい場合は、 ユーザーストーリーの書き方.
ユーザーストーリーマップとは何か
ストーリーマッピングはJeff Pattonによって提唱され、まず2005年の記事「It's all in how you slice it」で、その後2008年の投稿 The new user story backlog is a map、さらにその著書『User Story Mapping』（O'Reilly, 2014）で詳述されました。また、彼の ストーリーマッピング関連リソース や Agile Allianceの用語集エントリ.
マップには2つの方向性があります：
- 左から右はナラティブです。ユーザーが順番に経験する大きなアクティビティと、その中のステップを示します。この最上段の行はバックボーンと呼ばれます。
- 上から下は優先度と詳細です。各ステップの下には、それを可能にするストーリーが配置され、最も本質的なものが上、代替案やエッジケース、nice-to-haveが下に来ます。
マップを横切る水平線は、リリーススライスに分割します。最初の線より上にあるものが最初のリリースです。それはバックボーンのすべてのアクティビティを、どれだけ薄くてもカバーする必要があります。
6つのステップでストーリーマップを作成する方法
壁に付箋を使うか、デジタルホワイトボードで実行できます。スコープを決定する人と、構築する人を招待してください：プロダクト、デザイン、少なくとも1人の開発者、できれば顧客と話す人。小規模なプロダクトの最初のマップは、数時間の作業セッションで通常作成できます。
1. 問題をフレームワーク化する
プロダクトの対象者、解決する問題、最初のリリースが成功したことを示すアウトカムを記述します。マップの上部に3文にまとめます。その後のすべての切り捨ては、このアウトカムに対して判断されます。
2. バックボーンをマップする
「ユーザーは何を最初に、次に何をしますか？」と問い、各アクティビティをカードに左から右へ書き出します。動詞を使用します：「ウォーカーを見つける」ではなく「検索」など。次に各アクティビティをステップに分解します。進めながら声に出してストーリーを語りましょう。誰かが「待って、どうやってここに来たの？」と言ったとき、ギャップが明らかになります。
3. 詳細を探索する
各ステップの下に、それを機能させるストーリーを追加します：オプション、代替案、エラーケース、管理者のニーズ。まだフィルタリングしないでください。全体像を一度に見られるため、欠けている部分に気づくことができ、ここでマップの価値が証明されます。
4. ウォーキングスケルトンを見つける
ウォーキングスケルトン（Alistair Cockburnによる用語）は、エンドツーエンドで機能するプロダクトの最も薄いバージョンです。各ステップの下にある、ユーザーがなしにはできない1つのストーリーを選び、上部に移動します。もしどのステップにも本質的なものがなければ、それがバックボーンに属するかどうかを問いましょう。
5. リリースをスライスする
水平線を描いてストーリーをリリースにグループ化します。各スライスには、アウトカムを述べる名前を付けます。例えば「オーナーが1回の散歩を予約し、支払いできる」など、「リリース1」ではなく。各スライスは単独で使用可能であり、プロダクトに関する質問に答えられる必要があります。
6. 最初のスライスを計画し、マップを維持する
最初のスライスのストーリーに受け入れ基準を書き（当社の ユーザーストーリーテンプレート には3つの形式があります）、それぞれをINVESTでチェックし、大きすぎるものを分割してスプリントバックログに移動します。マップを可視化し、各リリース後に更新してください。これは計画ツールであり、一度きりのワークショップの成果物ではありません。
例：ドッグウォーキングアプリのストーリーマップ
ここでは、犬のオーナーと近隣のウォーカーを繋ぐマーケットプレイスの圧縮されたマップを示します。列はバックボーン、各行はリリーススライスです。
| スライス | サインアップ | ウォーカーを見つける | 散歩を予約する | 支払い | 散歩中 | 散歩後 |
|---|---|---|---|---|---|---|
| ウォーキング・スケルトン（MVP） | メールで登録し、犬を1頭追加する | 郵便番号付近で承認されたウォーカーの一覧を表示する | 時間帯をリクエストし、ウォーカーがメールで受諾する | 予約時にカードで支払う | ウォーカーが散歩の開始と終了を記録する | オーナーにサマリーメッセージが届く |
| リリース2 | GoogleまたはAppleでサインインし、複数の犬を登録する | 価格と空き状況でフィルタリングし、写真付きのウォーカープロフィールを表示する | アプリ内での受諾・辞退機能、リマインダー | カード情報の保存、キャンセル時の自動返金 | 地図上でのリアルタイム位置情報 | 評価とレビュー |
| 後で | 紹介コード | お気に入りのウォーカー | 毎週の定期予約 | サブスクリプションとチップ | 散歩中の写真更新 | ワンタップで再予約 |
スケルトンが何を含んでいないかに注目してください：リアルタイム追跡、レビュー、アプリ内メッセージングはなく、ウォーカーの承認は手動で行われます。しかし、オーナーは登録から完了・支払い済みの散歩までを体験できるため、見知らぬ人に犬の散歩を依頼するかどうかをテストするには十分です。
マップがMVPスコープに変換される方法
良いマップの最上位スライスがあなたのMVPスコープです。コミットする前に、以下のチェックを行ってください：
- バックボーンにあるすべてのアクティビティをカバーしていること。予約はできるが支払えない製品はMVPではなく、デモの半分です。
- 1つの主要ユーザーと1つのメインジャーニーに対応すること。セカンダリな役割（管理者、パートナーなど）は、ジャーニーを維持するために最低限の機能（スプレッドシートや手動ステップなど）で対応します。
- 特定の仮説を検証すること。そのスライスが回答する質問を隣に書き留めてください。例えば「オーナーはウォーカーと会う前に支払うか？」など。
- 裏側での手動作業は許容されます。最初のユーザーに対しては、ウォーカーの承認を手動で行ったり、サマリーを自分で送信したりしても問題ありません。これにより、自動化する価値があるものがわかります。
- 予算とスケジュールに収まっていること。収まらない場合は、各カラム内のストーリーを削除するのではなく、分割して調整してください（以下のパターンを使用）。
技術的な共同創業者を持たない創業者にとって、このマップは開発チームに渡す最も有用なドキュメントでもあります。1ページで製品全体、最初のリリース、そして切り捨ての根拠を示します。私たちのガイド 非技術的な創業者によるMVPの構築 では、その後の対応方法について説明しています。
INVESTチェックリスト
ストーリーがマップに配置されたら、最初のスライスの各ストーリーについて、Bill Wakeが2003年に提唱した INVESTによる良いストーリー、およびSMARTタスク.
| 文字 | 意味 | 確認すべき質問 | 失敗した場合 |
|---|---|---|---|
| I | Independent（独立した） | 他のストーリーを待たずに、これだけで構築・リリースできるか？ | 密接に結合されたストーリーを結合するか、それぞれが単独で価値を提供できるように異なる方法で分割する |
| N | Negotiable（交渉可能な） | 解決策はまだ議論の余地があるか？ | ストーリーから実装の詳細を削除し、ノートに記録する |
| V | Valuable（価値のある） | これをリリースしても、ユーザーやビジネス側は気づくだろうか？ | 技術的なタスクは、それが属するストーリーに統合する |
| E | Estimable（見積もり可能な） | チームはこれを見積もるために十分な知識を持っているか？ | 時間制限付きのスパイク（技術検証）を実行するか、見積もりを妨げている質問に答える |
| S | Small（小さい） | 1つのスプリントに余裕を持って収まるか？ | 以下のパターンのいずれかで分割する |
| T | Testable（テスト可能な） | 合格/不合格で判定できる受け入れ基準を書けるか？ | 曖昧な言葉（「高速」「簡単」など）を、観察可能な結果に置き換える |
独立性は完全に満たすのが最も難しい基準であり、ルールではなく目標として扱うのが一般的です。小ささとテスト可能性は、厳格に守る価値のある基準です。
ユーザーストーリーの分割方法
ストーリーは縦方向に分割します。各部分は、システムのすべての層を通じて、ユーザーが見える形で何らかの価値を提供する必要があります。レイヤーごとに分割する（「データベースを構築」「APIを構築」「画面を構築」）と、3つがすべて完了するまで何も提供できず、分割の目的が達成されません。これらのパターンは、 Humanizing Workによるユーザーストーリー分割ガイド （Richard LawrenceとPeter Green著）にまとめられており、ほとんどのケースをカバーしています。
ワークフローのステップ
複数ステップのプロセスを各ステップに分割するか、まずシンプルなエンドツーエンドのバージョンを構築し、後からステップを追加します。「散歩を予約する」は：スロットをリクエスト；ウォーカーが受諾；オーナーが確認を受け取る、となります。後で：ウォーカーが別の時間を提案する。
ビジネスルールのバリエーション
ストーリーに複数のルールがある場合、最も一般的なものを最初にリリースします。「キャンセル時の返金」は：24時間前にキャンセルされた場合は全額返金；24時間以内は一部返金；散歩開始後は返金なし、となります。
データの変種
1種類のデータから始め、他のデータを追加します。「地域で検索」は：郵便番号で検索；次に現在地で検索；次に地図上でエリアを描いて検索、となります。
まずハッピーパス、次にアンハッピーパス
まずメインの成功パスを構築し、失敗ケースは発生頻度と影響度順に個別のストーリーとして処理します。「カードで支払う」は：支払い成功；カード拒否；支払いプロバイダーが利用不可、となります。
オペレーション
「犬を管理する」には、作成、表示、編集、削除が含まれます。最初のリリースでは、作成と表示のみで十分なことが多いです。
インターフェースまたはプラットフォームの変種
まず1つのプラットフォームまたは1つの入力方法でリリースします。最初のユーザーが許容する場合は、モバイルよりWeb、他の言語より英語を優先します。
まずシンプルなバージョン、パフォーマンスは後回し
まず動作させ、次に高速化します。50人のウォーカーに対して3秒で読み込まれるウォーカーリストは、パイロット都市としては十分です。数値がそれを正当化するようになったら、個別のストーリーとして最適化します。
スパイク
未知の要素（「両方の電話プラットフォームでバックグラウンドでライブ位置情報を取得できるか？」など）によりストーリーが見積もれない場合、短い時間制限付きの調査を切り離します。スパイクの成果物は知識と、より適切にサイズ調整されたストーリーであり、リリースされる機能ではありません。
SPIDR：覚えるための短いバージョン
Mike Cohnは、主な分割テクニックをSPIDRという頭文字で分類しています：Spikes（スパイク）、Paths（パス）、Interfaces（インターフェース）、Data（データ）、Rules（ルール）（ユーザーストーリーを分割する5つのシンプルで強力な方法）。ストーリーが大きすぎてどこから始めればよいかわからない場合は、この5つをこの順序で検討してください。
| テクニック | 分割基準 | 例 |
|---|---|---|
| スパイク | まず未知の要素を調査する | ライブ追跡の見積もり前に、バックグラウンド位置情報について2日間のスパイクを行う |
| パス | ストーリーを通る代替パス | まずカードで支払い、後でウォレットで支払い |
| インターフェース | デバイス、ブラウザ、またはインターフェースの種類 | オーナーはまずWebで予約、次にモバイルアプリで予約 |
| データ | データのタイプまたは範囲 | 最初は1予約あたり1匹の犬、後で複数匹の犬 |
| ルール | ビジネスルール、最初は緩く設定 | パイロット段階ではキャンセルルールなし、返金ポリシーは別のストーリーとして扱う |
ストーリーマッピングでよくあるミス
- ユーザーの活動ではなく機能をマッピングすること。「ログイン、ダッシュボード、設定」というバックボーンは画面を記述しており、ジャーニーを記述していません。
- 最初のスライスを1列の深さで構築すること。予約機能が存在する前にサインアップを磨き上げると、テストできるものが何も残りません。
- マップを詳細にしすぎること。壁に受け入れ基準を書き始めているなら、マッピングからリファインメントに移行しています。
- 開発者を部屋に招かずにマッピングすること。彼らを交えずに描いたスライスには、上部にコストの高いストーリーが隠れていることが多いです。
- マップを完成品として扱うこと。各リリース後、学んだことをマップに反映し、次のスライスを再カットしてください。
ご自身のマップに適応できる、よく形成されたストーリーについては、弊社の ユーザー・ストーリーの例.
ストーリーマッピングのツール
全員が1つの部屋にいる最初のセッションでは、壁と付箋が依然として最も効果的です。リモートチームには、MiroやFigJamなどの一般的なホワイトボードにストーリーマップのテンプレートがあり、StoriesOnBoardなどの専用ツールはマップをバックログトラッカーと同期します。Jiraなどのトラッカーはエピックごとにストーリーをグループ化して表示でき、これによりバックボーンが見えますが、リリーススライスを見るには通常プラグインやホワイトボードが必要です。チームが使い続けるツールを選びましょう。誰も更新しないマップは、1、2スプリントで有用性を失います。
よくある質問
ユーザーストーリーマッピングとは何ですか？
Jeff Pattonが提唱した、ユーザーが取るジャーニー（左から右へのバックボーン）と優先度（上から下）に沿ってユーザーストーリーを配置する技術です。水平線がマップをリリーススライスに分割し、チームがエンドツーエンドで機能するリリースを計画できるようにします。
ストーリーマップとプロダクトバックログの違いは何ですか？
バックログは優先度順に並べられた単一のリストです。ストーリーマップは同じストーリーをユーザー活動と優先度の2次元で表示し、それらがどのように組み合わさっているか、リリースがジャーニー全体をカバーしているかを確認できます。
ウォーキングスケルトンとは何ですか？
ジャーニーの各ステップに1つの本質的なストーリーを含め、開始から終了まで機能する製品の最も薄いバージョンです。この用語はAlistair Cockburnに由来し、ストーリーマップでは通常、最初のリリーススライスです。
INVESTとは何を意味しますか？
Independent（独立した）、Negotiable（交渉可能な）、Valuable（価値のある）、Estimable（見積もり可能な）、Small（小さい）、Testable（テスト可能な）の頭文字です。Bill Wakeが2003年に、良いユーザーストーリーのためのチェックリストとして提案しました。
ユーザーストーリーはどれくらい小さくすべきですか？
チームが1スプリント、理想を言えば数日以内に完了、テスト、デモできる程度に小さくすべきです。ストーリーが定期的に1スプリント全体を要する場合は、分割してください。
SPIDRとは何ですか？
Mike Cohnが記述した5つのストーリー分割テクニックのセットです：Spikes（スパイク）、Paths（パス）、Interfaces（インターフェース）、Data（データ）、Rules（ルール）。
ストーリーマッピングセッションには誰が参加すべきですか？
スコープを決定する人と、それを構築する人です：プロダクトオーナーまたは創業者、デザイナー、少なくとも1人の開発者、そして理想を言えば顧客と話す人（サポートや営業など）です。
マップを持っているか、アイデアだけを持っているか、最初のスライスを構築する必要がありますか？エンドツーエンドで機能するMVPスコープを切り出し、短いスプリントでリリースするお手伝いをします。詳しくは 月額開発プラン.