ユーザーストーリーマッピングのやり方｜作り方の手順と例

ユーザーストーリーマッピングは、利用者がすることを左から右へ「話の順」に並べ、その下に細かいストーリーを上から下へ「大事な順」に並べて、横線でリリースの範囲を切る方法です。 考案者の Jeff Patton は、優先順位だけで並べた平らなバックログでは「システムが何をするのかを人に説明できない」と書き、地図（マップ）の形を勧めています。

確認環境：用語と手順は、Jeff Patton の公開資料「Story Map Concepts」（jpattonassociates.com の PDF）と、ブログ記事「The New User Story Backlog is a Map」（2008年、2023年更新）の原文で確かめました。マップからプロダクトバックログを作るスクリプトは Python 3.11.15（Linux）で動かし、マップの図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0）の block-beta 図で描画できることを確かめています（確認日 2026年10月13日）。

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

Jeff Patton が2008年のブログ記事「The New User Story Backlog is a Map」で広めた、ユーザーストーリーの並べ方です。 のちに書籍『User Story Mapping』（O'Reilly、2014年。日本語版『ユーザーストーリーマッピング』オライリー・ジャパン）にまとめられました。

Patton はブログで、作る順に並べただけのバックログを「文脈のない、袋に入った腐葉土（a bag of context-free mulch）」にたとえています。並べ替えのたびに1件ずつ「入れるか、入れないか」を決めることになり、リリース計画が面倒になる、とも書いています。

マップにすると、次のことが一目で分かります。

• 横（左→右）：利用者がどんな順で何をするか。Patton の資料では「ほかの人に利用者の話をするときの順（the order you'd tell the story about your user to someone else）」で、これをナラティブフローと呼びます。
• 縦（上→下）：同じタスクの中で、どれから作るか。上ほど先に作ります。
• 横線：どこまでを1回のリリースに入れるか。

flowchart TB
  subgraph BB["バックボーン：左→右に話の順（ナラティブフロー）"]
    direction LR
    A1["アクティビティ"] --- A2["アクティビティ"] --- A3["アクティビティ"]
  end
  subgraph R1["リリーススライス1（MVP）"]
    direction LR
    S1["ストーリー"] ~~~ S2["ストーリー"] ~~~ S3["ストーリー"]
  end
  subgraph R2["リリーススライス2"]
    direction LR
    S4["ストーリー"] ~~~ S5["ストーリー"] ~~~ S6["ストーリー"]
  end
  BB -->|"下へ：上ほど先に作る"| R1
  R1 -->|"横線でリリースを区切る"| R2

用語の一覧（原文つき）

Patton の「Story Map Concepts」の言葉です。日本語の言い方は、書籍の日本語版や国内の資料で使われている呼び方に合わせています。

大事なのは、MVP とウォーキングスケルトンが別のものだという点です。 Patton の資料では、MVP は「リリースの切り方（Slice Out Viable Releases）」の話で、ウォーキングスケルトンは「最初のリリースを作る順番（Slice Out a Development Strategy）」の最初の段階（Opening Game）として出てきます。

作り方の手順（5ステップ）

Patton の資料「Story Map Process」の5つの段階に沿って進めます。

flowchart LR
  F["1 枠を決める<br>Frame"] --> B["2 全体像を描く<br>Map the Big Picture"]
  B --> E["3 掘り下げる<br>Explore"]
  E --> V["4 リリースを切る<br>Slice Out Viable Releases"]
  V --> D["5 作る順を切る<br>Slice Out a Development Strategy"]
  D -.作りながら見直す.-> E

1. 枠を決める

最初に、マップの範囲を決める短い概要を書きます。 範囲がないと、マップは際限なく横に伸びます。書く項目の例です。

• 対象の利用者：店頭で受け取る近所のお客（最初は宅配の利用者を含めない）
• 目的：電話での注文を減らし、受け取りの待ち時間を短くする
• 測るもの：ネット経由の注文の割合、店頭での受け取りにかかる時間

プロジェクトの目的やエレベーターピッチを先に作っていれば、それをそのまま使えます。関連記事「インセプションデッキの作り方｜10の質問とシステム開発の記入例」で扱っています。

2. 全体像を描く（バックボーン）

利用者が朝から晩まで（または、始めから終わりまで）にすることを、動詞の付箋で左から右へ並べます。 細かさは気にせず、「全体の話」が端までつながることを先にします。

• 付箋は「〜する」の短い動詞句で書きます（例：「支払う」「受け取る」）
• 似たタスクの上に、まとめの付箋（アクティビティ）を置きます
• 並べ終えたら、左から右へ声に出して読みます。話がつながらないところに、抜けたタスクがあります

Patton はブログで、バックボーンのアクティビティどうしには優先順位を付けないと書いています（"it's usually not important to prioritize backbone items against each other"）。注文はできるが受け取れない、というシステムは使えないからです。

3. 掘り下げる

ユーザータスクの下に、細かいやり方・別のやり方・例外を足していきます。 「支払う」の下なら、「店頭で払う」「クレジットカードで払う」「ポイントを使う」が並びます。上ほど先に必要なもの、下ほどあとでよいものにします。

利用者の流れを、業務の出来事の側から確かめたいときは、関連記事「イベントストーミングのやり方｜付箋の色・進め方・システム開発の例」の方法と組み合わせられます。

4. リリースを切る（MVP）

横に線を引き、線より上を最初のリリースにします。 線は、バックボーンのすべての列を横切るように引きます。どこかの列に1枚もストーリーがないと、利用者は目的を最後まで果たせません。

5. 作る順を切る（ウォーキングスケルトンから）

最初のリリースの中を、さらに段階に分けます。Patton の資料の3つの段階です。

完成例：ネット注文（店頭受け取り）のストーリーマップ

地域のスーパーが、ネットで注文して店頭で受け取れるサービスを作る例です。利用者は「注文するお客」と「注文をさばく店舗のスタッフ」の2人です。

block-beta
  columns 13
  a1["1 商品を探す"]:3 a2["2 カートに入れる"]:2 a3["3 注文する"]:3 a4["4 受け取る"]:2 a5["5 注文をさばく（店舗）"]:3
  t1["カテゴリから探す"] t2["キーワードで探す"] t3["商品を確かめる"] t4["数量を決める"] t5["カートを見直す"] t6["受け取り方を選ぶ"] t7["支払う"] t8["確認する"] t9["準備を知る"] t10["店頭で受け取る"] t11["注文を見る"] t12["商品をそろえる"] t13["渡す"]
  r1["▼ リリース1（MVP：最初に出す範囲）"]:13
  s1["カテゴリの一覧を見る"] space s3["写真と価格を見る"] s4["数量を指定して入れる"] s5["中身と合計を見る"] s6["店頭受け取りの日時を選ぶ"] s7["店頭で払う"] space space s10["注文番号で受け取る"] s11["当日の注文一覧を見る"] space s13["受け取り済みにする"]
  r2["▼ リリース2"]:13
  space u2["商品名で検索する"] u3["アレルギー表示を見る"] space u5["商品を削除する"] space u7["カードで払う"] u8["確認メールを受け取る"] u9["準備完了の通知"] space space u12["ピッキングリスト"] space
  r3["▼ リリース3"]:13
  space v2["価格順に並べる"] space space space v6["宅配を選ぶ"] space space space space space space space
  classDef act fill:#1f4e79,color:#fff,stroke:#1f4e79
  classDef task fill:#dbe9f6,stroke:#1f4e79
  classDef line fill:#fff4d6,stroke:#c08a00
  class a1,a2,a3,a4,a5 act
  class t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11,t12,t13 task
  class r1,r2,r3 line

同じマップを、表にするとこうなります（行がユーザータスク、列がリリースです）。

リリース1は、5つのアクティビティすべてに1枚以上のストーリーがあります。 検索・カード払い・通知はありませんが、近所のお客が「探して、頼んで、受け取る」までを最後まで終えられます。

リリース1の作る順（開発の戦略）

ウォーキングスケルトンを最初に作ると、注文のデータが店舗側まで届くかどうかが、早い段階で分かります。 画面の作り込みから始めると、端から端までつないだときに初めて問題が見つかることがあります。

MVP の切り方

MVP の線を引くときに確かめる点です。

MVP の考え方そのものは、関連記事「MVPとは｜PoC・プロトタイプとの違いと作り方」で扱っています。優先度の付け方は「MoSCoW分析のやり方｜要件の優先順位付けの例と判定シート」も参考になります。

プロダクトバックログへのつなぎ方

マップのストーリーを、「リリーススライスの順 → 左から右 → 上から下」で1列に並べると、プロダクトバックログの順番になります。 Patton はブログで、マップは計画のあとも捨てずに、見えるところに置いておく（information radiator）と書いています。バックログは「次に何を作るか」、マップは「全体のどこを作っているか」を見るもの、と使い分けます。

マップから並べ替えるスクリプト

マップを CSV（アクティビティ・ユーザータスク・ストーリー・スライス）で書き、次の2つをする Python のスクリプトです。

1. 各リリーススライスが、バックボーンのすべてのアクティビティを通っているか調べる
2. 「スライス → アクティビティ（左→右）→ マップでの上下の順」で並べ、プロダクトバックログの CSV を出す

import csv, sys
from collections import defaultdict

rows = list(csv.DictReader(open(sys.argv[1], encoding="utf-8")))
acts = sorted({r["アクティビティ"] for r in rows})            # バックボーン（左→右）
slices = sorted({r["スライス"] for r in rows})                 # R1, R2, ...

# 1) 各スライスが、バックボーンを端から端まで通っているか
covered = defaultdict(set)
for r in rows:
    for s in slices:
        if r["スライス"] <= s:                                  # そのスライスまでに入る
            covered[s].add(r["アクティビティ"])
for s in slices:
    miss = [a for a in acts if a not in covered[s]]
    print(f"{s}: {len(covered[s])}/{len(acts)} アクティビティ", "OK" if not miss else f"抜け {miss}")

# 2) プロダクトバックログに並べる（スライス → 左から右 → 上から下）
order = sorted(enumerate(rows), key=lambda x: (x[1]["スライス"], x[1]["アクティビティ"], x[0]))
w = csv.writer(open(sys.argv[2], "w", encoding="utf-8", newline=""))
w.writerow(["順位", "ID", "ストーリー", "アクティビティ", "スライス"])
for n, (i, r) in enumerate(order, 1):
    w.writerow([n, f"PBI-{i+1:03}", r["ストーリー"], r["アクティビティ"], r["スライス"]])
print(f"{len(order)} 件を {sys.argv[2]} に出力")

入力の CSV（先頭の5行）です。アクティビティの名前に「1 」「2 」と番号を付けているのは、左から右の順で並べ替えるためです。

アクティビティ,ユーザータスク,ストーリー,スライス
1 商品を探す,カテゴリから探す,カテゴリの一覧から商品を見る,R1
1 商品を探す,キーワードで探す,商品名で検索する,R2
1 商品を探す,キーワードで探す,検索結果を価格順に並べる,R3
1 商品を探す,商品を確かめる,商品の写真と価格を見る,R1

最初の版では「注文番号を伝えて受け取る」を R2 に置いていました。その版で動かした結果です。

$ python3 map2backlog.py map.csv backlog.csv
R1: 4/5 アクティビティ 抜け ['4 受け取る']
R2: 5/5 アクティビティ OK
R3: 5/5 アクティビティ OK
18 件を backlog.csv に出力

R1 に「受け取る」の列が1枚もなく、注文はできても受け取れない MVP になっていました。 「注文番号を伝えて受け取る」を R1 に上げた版では、次のようになりました。

$ python3 map2backlog.py map_fixed.csv backlog2.csv
R1: 5/5 アクティビティ OK
R2: 5/5 アクティビティ OK
R3: 5/5 アクティビティ OK
18 件を backlog2.csv に出力

出力されたプロダクトバックログの先頭10行です（R1 が9件、R2 が7件、R3 が2件）。

順位,ID,ストーリー,アクティビティ,スライス
1,PBI-001,カテゴリの一覧から商品を見る,1 商品を探す,R1
2,PBI-004,商品の写真と価格を見る,1 商品を探す,R1
3,PBI-006,数量を指定してカートに入れる,2 カートに入れる,R1
4,PBI-007,カートの中身と合計を見る,2 カートに入れる,R1
5,PBI-009,店頭受け取りの日時を選ぶ,3 注文する,R1
6,PBI-011,店頭で支払う（代金引換）,3 注文する,R1
7,PBI-015,注文番号を伝えて受け取る,4 受け取る,R1
8,PBI-016,当日の注文一覧を見る,5 注文をさばく（店舗）,R1
9,PBI-018,受け取り済みにする,5 注文をさばく（店舗）,R1
10,PBI-002,商品名で検索する,1 商品を探す,R2

この順番は出発点です。実際のバックログでは、ウォーキングスケルトンの段階に必要なものを先頭に寄せる、リスクの高いものを早めに置く、といった並べ替えをします。

バックログに移すときに足すもの

マップの付箋は「店頭で払う」のような短い言葉です。バックログの項目にするときは、次を足します。

• ユーザーストーリーの文：「店舗で受け取るお客として、店頭で支払いたい。カードを登録したくないから」
• 受け入れ基準：「注文時に支払い方法で『店頭』を選べる」「店舗の一覧に『未払い』と表示される」
• 見積もり：ストーリーポイントなど
• マップでの位置：アクティビティとスライス（あとでマップに戻れるように）

書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」「プロダクトバックログの書き方と例｜優先順位の付け方とテンプレート」「ストーリーポイントの見積もり方｜基準表とプランニングポーカー手順」で扱っています。スプリントで何を作るかの決め方は「スプリントプランニングの進め方｜アジェンダとスプリントゴール例」で扱っています。

進め方：参加者と時間の例

原典は時間割を決めていません。 以下は、5ステップを2回に分けて行う例です。

• 利用者の言葉を知っている人を入れます。 店舗のスタッフがいると、「ピッキングリストがないと棚を何度も往復する」のような、開発者が知らない作業が出てきます。
• 最初の10分は、黙って付箋を書く時間にします。 声の大きい人の意見だけでマップが埋まるのを防げます。
• 書き終えたら、左から右へ1人が読み上げます。 ナラティブフローの抜けが見つかります。

利用者像の整理は、関連記事「ジョブ理論（JTBD）とは｜ペルソナとの違い」で扱っています。司会の進め方は「会議ファシリテーションの進め方 アジェンダ設計とフレーズ集」で扱っています。

オンラインで進める場合

Miro や Lucidspark などのオンラインホワイトボードには、ストーリーマップのテンプレートが公開されています。道具を問わず、次の準備をしておくと進めやすくなります。

オンラインでは、会話より書く時間を長めに取ると、マップが埋まりやすくなります。 進行の役と、付箋を整える役を分けておくと、話が止まりにくくなります。

よくある誤り

よくある質問

Q. ユーザーストーリーマップとカスタマージャーニーマップは何が違いますか。 A. カスタマージャーニーマップは、利用者の体験や感情を時間の順に描き、課題を見つけるためのものです。ユーザーストーリーマップは、同じく横に利用者の行動を並べますが、下に作るもの（ストーリー）を並べ、リリースの範囲を決めるところまで進みます。

Q. 既にあるプロダクトに機能を足すときも使えますか。 A. 使えます。Patton はブログで、既存のプロダクトでは、機能ごとに小さなマップを作れると書いています。足す機能の前後の行動だけをバックボーンにします。

Q. どのくらいの頻度で見直しますか。 A. リリースの区切りごとが目安です。リリースで学んだこと（使われなかった機能、多かった問い合わせ）をもとに、線より下のストーリーを上げ下げします。

Q. 要件定義の資料とはどうつなげますか。 A. バックボーンは業務の流れに、ストーリーは要件や機能に対応します。要件の一覧に落とす方法は、関連記事「要件定義書の書き方｜記入例と要件ID・受け入れ基準」で扱っています。

まとめ

• ユーザーストーリーマッピングは、横に話の順（ナラティブフロー）、縦に作る順で並べ、横線でリリースを切る方法
• 上の段の バックボーン はアクティビティとユーザータスク。アクティビティどうしには優先順位を付けない
• 手順は 枠を決める → 全体像を描く → 掘り下げる → リリースを切る → 作る順を切る
• MVP は「特定の利用者が目的を果たせる最も少ないタスク」。ウォーキングスケルトン は最初のリリースで最初に作る、端から端まで動く単純な形
• MVP の線は すべての列を横切る。バックログには「スライス → 左から右 → 上から下」の順で移し、マップは見える場所に残す

参考・出典

確認日はいずれも 2026年10月13日です。

• Jeff Patton「Story Map Concepts」（Jeff Patton & Associates、PDF）：https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
• Jeff Patton「The New User Story Backlog is a Map」（2008年10月8日、2023年4月12日更新）：https://jpattonassociates.com/the-new-backlog/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。