🎬 シナリオ
MOps チームは予約販売（発売前の商品を予約で受け、発売日に届ける）の仕組みを作る。今日は 10/14（水）。昨年度はマーチャンダイザーが通常の商品として「【予約】」と名前に付け、在庫数の欄に予約枠を入れて受けていた（34 SKU・7,800件）。
📦
第一弾: 調理家電メーカー N社（架空）の新型電気圧力鍋。39,800円、メーカー割当 1,500台、発売予定「2027年2月下旬」（日付未定）。メーカー条件「1会員2台まで」「毎週月曜に予約数を報告」。メーカー発表 11/27(金)、他店は 12/1(火) 10:00 に予約受付開始。前モデルは他店で3日で枠が埋まった。
日程の制約
| 期間 | 内容 |
|---|---|
| S21 10/19(月)〜10/30(金) | 稼働10日、キャパ 19pt（実績 20／22／19 の最小） |
| S22 11/2(月)〜11/13(金) | 稼働9日（11/3 文化の日）、キャパ 17pt |
| 11/16〜11/19(木) | 結合テスト・リリース。新しいストーリーは入れない |
| 11/20〜1/6 | 年末商戦の変更凍結（本番リリース不可） |
| S25・S26 1/12〜2/5(金) | 他案件と半々。この案件に約 24pt |
| 2/25(木)（仮置き） | 発売予定日。出荷指示は前日 |
関係者: PdM 高木、リード 宮本、BE あなた・青木、FE 上田、QA 中山。社内の利用者: バイヤー 森田、MD 小池、CS 主任 吉川、物流課 長尾、法務 伊藤。
分かっている情報（すべて演習の設定値＝仮定）
| 情報 | 値 |
|---|---|
| 昨年の発売日延期 | 9 / 34 SKU（26%）・影響 2,100件 |
| 「いつ届くのか」問い合わせ | 1,380件/年（予約100件あたり 17.7件） |
| 予約品と在庫品を同じ注文にした件数 | 410件 → 問い合わせ 290件・キャンセル 120件 |
| 予約のキャンセル率 | 14%。CS が手作業で売上取消、1件15分 |
| 支払い手段 / 注文経路 | カード 81%・代引き 11%・コンビニ 8% / Web 68%・アプリ 32% |
| 既存の注文システム | 注文の翌朝に倉庫へ出荷指示 → 在庫が引き当たらない注文は欠品 → 7日後に自動キャンセル |
| 決済 | カードは即時売上。オーソリだけにする機能もあるが有効期限は60日（当社契約） |
| 法務 伊藤さん | 「代金を先に受け取る予約は承諾等の通知（特商法13条）が要る。昨年の確認メールには引渡時期が無かった」 |
PdM 高木さんが書き出したカード（23枚・88pt）
💬
リード宮本: 「Jira の上から順に 36pt 分を取れば終わり、ではないよね。12/1 に受けて、2月に届けるまでの一本道が見える形で持ってきて」
📝 課題
- ストーリーマップ: 横に活動（バックボーン）を時間順、各活動の下にカードを置く。足りないカードは書き足す
- 各カードに「初めて必要になる日」（12/1／凍結中／2月の出荷時／その後）を書く
- リリースの線を2本: R1（11/19・36pt）と R2（2/5・24pt）。それぞれ「達成すること」を1文と測り方
- 線の下のカードごとに「しのぎ方（手作業なら何件・何時間）」と「拾い直す条件」
💡 ヒント（クリックで開く）
ヒント1
バックボーンは機能の分類ではなく「利用者がやることの順番」。MD・CS・物流課も利用者
ヒント2
最初のリリースは、全部の列に少なくとも1枚カードがある細い一本道（walking skeleton）か
ヒント3
「既存の注文システム」の行を読む。12/1 に受けた予約注文は 12/8 に何が起きるか
ヒント4
凍結中（11/20〜1/6）に要るものは「R1 に入れる」か「凍結中は手作業」の二択。手作業の量を数える
ヒント5
1,500台が数日で埋まるなら、アプリで予約できないことで失う台数はいくつか
ヒント6
特商法13条とメーカーとの契約条件は、緩められる規則か
📚 背景知識・用語解説
ストーリーマップ
Jeff Patton が 2008 年の記事「The New User Story Backlog is a Map」で示した並べ方。優先度順の1本の列を、Patton は "A bag of context-free mulch." と呼んだ。どのカードとどのカードがそろって初めて一連の作業になるかが1本の列では見えないからだ。
| 要素 | 意味 |
|---|---|
| バックボーン | 上の段。利用者の大きな活動を左→右に時間順。活動どうしは優先順位を付けない |
| カード | 各活動の下に縦に置く。上ほど必要性が高い |
| walking skeleton | 各列の上の必要なカードだけで作る、最小の端から端まで動く仕組み。最初に作る |
| リリースの線 | 横に引く線。線の上が今回、下は後。カードは上下に動かす |
Patton の書籍『User Story Mapping』（2014）は、線を機能の量でなく達成したい結果（outcome）で引くとしている（書籍・未照合）。
前回（SPIDR）との違い
| SPIDR（Day049） | ストーリーマップ（今回） | |
|---|---|---|
| 対象 | 大きすぎる1本のエピック | 一連の作業全体に散らばった多数のカード |
| 問い | どこで割れば入るか | どれがそろうと端から端まで動くか |
| 見落としやすいもの | 緩められない規則 | 列ごと抜けている活動 |
承諾等の通知（特商法13条）
消費者庁の特商法ガイド「通信販売」によると、引渡し前に代金を受け取る前払式の通信販売で、すぐに引き渡さない場合、遅滞なく（目安約1週間）書面で通知する: 承諾の有無（しない場合は返金方法）、事業者の名称・住所・電話、受領額、受領日、商品と数量、承諾する場合は引渡時期。カード払いが前払式に当たるかは、同ページに記載が無かった（→ Q1）。
🧩 「初めて必要になる日」クイズ
各カードが最初に要るのはいつか。選ぶと答えと理由が出る。
✅ 模範解答
1. ストーリーマップ（カードをクリックすると R1 → 余力枠 → R2 → 後 と移る）
★の破線カードは書き足したもの。右の判定は「全部の列に R1 のカードがあるか」「約束を破らないか」「凍結中の手作業」を自動で数える。
2. 書き足したカードと、その理由
| カード | なぜ要るか | 誰も要望しなかった理由 |
|---|---|---|
| ★F1a 予約注文を出荷指示から外して保留（2pt） | 既存のままだと 12/2 朝に出荷指示 → 在庫ゼロで欠品 → 12/8 に1,500件が自動キャンセル | 「受け取る」は2月の話と思われ、列ごと誰も見ていなかった |
| ★SP1 既存仕様を調べる（1pt） | 予約フラグで出荷指示から外すか、欠品キャンセルを止めるかを S21 冒頭で決める | 既存仕様の調査はカードになりにくい |
| ★B4′ アプリから Web へ案内（1pt） | B4 を後にしたとき、アプリの予約ボタンが普通の購入として動くと C1〜C4 の制限を通らない | 「アプリは後で」の時点で、アプリ側で何が起きるか誰も書いていなかった |
3. 各リリースで達成すること
| リリース | 達成すること | 測り方 |
|---|---|---|
| R1 11/19 24pt / 36pt（67%） | 12/1 から予約を受け、発売日まで約束（台数・2台まで・引渡時期・キャンセル条件）を守ったまま注文を持ち続けられる | ① 予約数 ≤ 1,500（H1 日次）② 12/8 以降の自動キャンセル 0件 ③ 13条記載の確認メール送信率 100% ④ 予約100件あたり問い合わせ 17.7 → 8件以下（目標・仮定） |
| R2 2/5 18pt / 24pt（75%） | 発売日に約束どおり届け、延期とキャンセルを人手なしで回せる | ① 出荷指示漏れ 0件 ② 手作業の売上取消 0件/週 ③ 延期の通知を発表当日に送れる |
E2（5pt）を R1 に入れると 29pt（81%）。約束しない余力枠とし、S22 3日目（11/4）に R1 本体が予定どおりなら取り込む。
4. 線の下のカードのしのぎ方
| カード | しのぎ方 | 手作業の量（導出） | 拾い直す条件 |
|---|---|---|---|
| E2 取り消し | CS が既存の売上取消で手作業 | 210件を80日に → 2.6件/日。凍結中37日で約97件≒24h、2/5まで続くと約176件≒44h | S22 3日目に R1 本体が予定どおりなら R1 へ |
| E3 発売日変更 | MD が日付を書き換え、CS が既存配信ツールで一斉送信 | 延期1回 約3h（延期は SKU の26%） | 凍結明けに R2 |
| F1b 一括出荷指示 | 物流課が予約注文 CSV を手動アップロード | 発売日に1回 約2h | 2/10(水) に R2 未リリースなら手動へ切替 |
| B4 アプリ | B4′ で Web へ案内 | 32%×離脱25%（仮定）＝需要の約8%。需要 1,630台以上なら失う台数0 | 3日以内に枠が埋まらなければ優先を上げる |
| C3 同梱 | 予約品は単独注文に限る | 昨年の410件・290件は起きない。在庫品 3,980円未満なら送料550円が別 | 単独注文への問い合わせ月20件超 |
| D3 出荷時決済 | 即時売上＋D2 の通知 | — | Q1 で通知以上の手当てが要ると判明 |
| D4 代引き・コンビニ | カードのみと明記 | 昨年の19%がカード以外 | 枠が埋まらない商品が出たら |
| H2 週次報告 | MD が H1 の CSV から作成 | 20分×12週≒4h | 同時受付 SKU が5超 |
| A2 発売予定の幅 | 商品説明に手書き、内部は 2/25 仮置き | 0 | 日付未定 SKU が同時に3以上 |
オープンな論点
| # | 論点 | 誰に・いつ | 答えで何が変わるか |
|---|---|---|---|
| Q1 | カード払い（即時売上）は13条の前払式に当たるか | 法務 伊藤・10/21 | 当たらなくても D2 は残す（害が無く 2pt）。追加要件があれば D2 を見直す |
| Q2 | 欠品自動キャンセルを予約だけ外せるか、出荷指示を止めるか | SP1・10/20 | F1a が 5pt を超えたら E1・H1 を手作業へ |
| Q3 | メーカー延期時に無料キャンセルを受けるか | 森田・10/28 | E2 の期限の文言、E3 の文面 |
| Q4 | 枠の超過を1台でも許すか | 森田・N社 | 許さない前提で C2 を在庫引き当てと同じ排他で作る |
なぜこう作るのか
1
列を先に並べると、誰も要望していない列が見える。1本の列では F1b（2月）が後ろにあるだけで、F 列が R1 で空だと分からない。
2
「初めて必要になる日」を書くと線が引ける。受付と出荷の間に凍結がある。凍結中に要るものは R1 か手作業かの二択なので、量を数えて E2 を余力枠にした。
3
緩められる規則と緩められない規則を分けた。13条（D2）・2台まで（C4）・枠（C2）は約束。同梱・代引き・アプリは規則を狭めて後へ。
4
後回しの損は「需要が枠を超えるか」で変わる。枠が埋まるなら B4・D4 で失う台数は0。失うのは体験なので、拾い直す条件で残した。
5
R1 を67%に抑えた。SP1 次第で F1a が膨らむ。F1a が無いと R1 は出せないので、ここに余裕を置いた。
採らなかった案
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| Jira の上から36pt | F 列が空のまま R1 が出る（上の「Jira 上から36pt」ボタンで確認できる） | — |
| 受付を凍結明け 1/7 にずらし全部入り | 他店は 12/1 開始、前モデルは3日で完売。予約の大半が他店へ | メーカーが当社割当を保証するなら検討 |
| 出荷時決済 D3 を R1 に | 13pt。12/1〜2/25 は86日でオーソリ有効期限60日を超え、再オーソリの失敗処理が要る | Q1 で即時売上の手当てが重いと分かったら第二弾で |
| 会員用と社内用でマップを分ける | 社内の作業は会員の作業の間に挟まっている。分けると F1a のような抜けがまた見えない | 社内作業だけで1リリースになる規模なら |
| 同梱 C3 を R1 に | 8pt で R1 が 32pt（89%）。単独注文の規則で昨年の痛み自体が起きない | 単独注文への問い合わせ月20件超 |
よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| バックボーンを「画面・API・DB」で並べる | どの列も単独では利用者に何も届かない | 利用者の動詞で並べる |
| 会員の活動だけでバックボーンを作る | MD・CS・物流の作業が抜け、「受けたが届けられない」穴が開く | 社内の利用者も同じ列に入れ、カードに「誰が」を書く |
| 線を pt だけで引く | 端から端まで通らない R1 ができる | 先に達成することを1文、全列にカードがあるか確認、それから pt |
| 線の下に何も書かない | 「後で」が「いつか」になる | しのぎ方・量・拾い直す条件を付ける |
| 作って終わり | R1 の結果で R2 は変わる | R1 の測り方を決め、線を引き直す日（12/4）を決める |
🏢 実務での使いどころ
- 最初のリリースを決める会議で、PdM・リード・社内の利用者（CS・物流・経理）を集めて付箋やオンラインホワイトボードで作る。社内の利用者を呼ぶと既存業務との継ぎ目のカードが出る
- 既存システムの仕様（今回の欠品7日自動キャンセル）を知っているのはエンジニアであることが多い。「この列の R1 が空だと何が起きるか」を言えるのは、エンジニアが PdM に返せる大きな価値
- リリース後もマップは捨てず、結果を書き込んで次の線を引き直す
➡️ 次のステップ
- R1 の C1〜C4・F1a の受け入れ条件を Given-When-Then で書く（取り消し後にもう1台予約できるか、など）
- 第二弾（フィギュア、年30 SKU、枠が埋まらない商品もある）では線がどう動くか（B4・D4・B3）
- 次回（10/21）は非機能要件（12/1 10:00 のアクセス集中）をストーリーにどう載せるか
🚧 扱わなかった範囲・一次資料
- アクセス集中対策・負荷試験（次回に回した）／転売対策の強化（C4 の会員単位のみ）／受け入れ条件（前回扱った）／13条の書面に電子メールで足りるか・カード払いへの適用（Q1、法令解釈は確定させていない）
参照日 2026-10-14:
・Jeff Patton, "The New User Story Backlog is a Map", 2008-10-08（更新 2023-04-12） jpattonassociates.com — WebFetch で確認
・消費者庁 特定商取引法ガイド「通信販売」 no-trouble.caa.go.jp — WebFetch で確認（カード払いの扱いは記載なし）
・Jeff Patton, User Story Mapping, O'Reilly, 2014 — 書籍・未照合
・数値はすべて演習の設定値（仮定）。導出は本文に式を示した