Day 049 — PdM-要求: ユーザーストーリーの書き方（2回目）— 大きすぎるエピックを SPIDR で割り、受け入れ条件を書きながら割り直す

🎬 シナリオ

MOps チームは、家電カテゴリに有料の延長保証（5年）をカートで付けられる機能を作ることになった。保証は保証会社「K保証」（架空）が引き受け、当社は販売窓口として保証料の40%を手数料で受け取る（仮定）。家電の年末商戦（BF 11/27）に合わせ、リリース目標は 11/16（月）。今日は 10/7（水）。

PdM 鈴木さんのエピック:

3人の見積もりは 40／55／89pt。2スプリント（34pt）を超え、倍以上に割れている。

分かっている情報（すべて演習の設定値＝仮定）

📝 課題

1. エピック分割表: E1 を SPIDR（Spike／Path／Interface／Data／Rules）の5つの切り口で割る。切り口ごとに「割った候補」「最初の1本（US1）に残すもの・後に回すもの」を書く
2. US1 の受け入れ条件を Given-When-Then で書き、書いている途中で出た疑問を表にする。1件ずつ「決めて残す／別ストーリーに切る／規則を緩めて後で／調べる」のどれで処理するか決める
3. 2スプリント（34pt）の投入案: 積まないものには「その間どうしのぐか」と「拾い直す条件」を付ける

🔍 ヒント（段階的開示）

📚 背景知識・用語解説

SPIDR（Mike Cohn）

出典: Mike Cohn "Five Simple but Powerful Ways to Split User Stories"（Mountain Goat Software、WebFetch で確認・参照日 2026-10-07、ページ表示の最終更新 2026-08-06）。Cohn は、スパイクは欠かせないが最初に試す切り口ではないとしている。

🧩 SPIDR 仕分けクイズ（10問）

それぞれの割り方がどの切り口かを選んでください。選ぶとすぐ判定します。

✅ 模範解答

自分の分割表と受け入れ条件を作ってから読み比べてください。

1. エピック分割表（SPIDR）

手作業で埋める量（緩めた規則ごと・導出）

2. US1 の受け入れ条件と、書いて出てきた論点

US1（8pt）: 会員として、Web で対象家電（税込1万〜10万円）をカートに入れたとき、1台ごとに5年延長保証を付けて注文したい。そうすれば、故障時の修理費を心配せずに高めの家電を選べる。

シナリオ1: 保証を付けると保証料が明細に加わる
  Given 会員が税込29,800円の対象冷蔵庫1台をカートに入れている
  When  カートで「5年延長保証を付ける」をオンにする
  Then  明細に「5年延長保証 1,100円」が1行加わり、合計が30,900円になる

シナリオ2: 数量に連動する
  Given 対象商品を数量2でカートに入れている
  When  保証を付ける
  Then  保証は2件・2,200円になり、1台だけに付ける選択肢は出ない

シナリオ3: 最終確認画面に表示する
  Given 保証付きの商品がカートにある
  When  最終確認画面を開く
  Then  保証の名称・期間（5年）・保証料・引受会社名・解約と返金の条件が、
        リンク先ではなくこの画面の本文に表示される

シナリオ4: 保証料はクーポン適用前の販売価格で決まる
  Given 税込31,000円の商品に3,000円引きクーポンを適用している（支払額28,000円）
  When  保証を付ける
  Then  保証料は「3万〜10万円」帯の3,300円になる

シナリオ5: 出荷前キャンセルは加入データに含めない
  Given 保証付きの注文が確定し、まだ当日分の CSV が作られていない
  When  会員が出荷前に注文をキャンセルする
  Then  その保証は当日分の CSV に含まれず、保証料は商品代金と一緒に返金される

シナリオ6: ギフト注文では付けられない
  Given 会員がギフト設定（届け先が別・明細なし）を選んでいる
  When  カートを開く
  Then  保証の欄は「ギフト注文では付けられません」と表示され、オンにできない

書いていて出た論点と処理

決めて残す別ストーリーに切る緩めて後で調べる

3. ストーリー一覧と2スプリントの投入案

• 投入: S21 = SP0 1 + US1 8 + US2 2 + US7 2 = 13 / 18pt、S22 = US1b 3 + US6 3 + US5 8 = 14 / 16pt、合計 27 / 34pt（79%、予備 7pt）
• 11/16 に確実に出せる1本: S21 で US1＋US2 が通れば、Web で全価格帯の保証が付けられる（加入見込み 378件/月）。S22 が崩れてもこれは出せる
• US5 と US3 のどちらを S22 に: 同じ 8pt で失う加入が 126 vs 76。アプリ先。ストア審査で 11/12 の列車に乗れなければ 11/26 になるが、Web 分は影響を受けない
• 続けるかの基準（仮定）: リリース後4週の Web 加入率 4%以上→US3・US4 を積む／2〜4%→文言見直し／2%未満→想定6%を見直し、US3・US8 は積まない
• 試算（導出）: 全部入り 580件 × 2,860円 × 40% ≒ 66万円/月。今回の投入で 484件 → 約55万円/月（83%）を 27pt で取りにいく

投入案の試算ツール

数値はすべて演習の設定値（仮定）。積むストーリーと前提を変えて、キャパ・失う加入・手作業の量・出せるかどうかを確かめてください。

💡 なぜこう作るのか

• SPIDR の5つを全部試してから選んだ: 1つの切り口だけでは残る1本がまだ大きい。P（カート）・I（Web）・D（10万円まで）・R（自動解約なし）を重ねて、やっと US1 が 8pt（S21 の半分以下）になった
• US1 と US1b を分けても横切りにならない理由: US1b を後回しにしても、US1 単独で顧客に保証が届く（CSV は手作業で上げる）。「カートで付けられるが K保証に何も送らない」1本は、保証料を払って保証が無い状態になるので出せない。判定は「その1本だけ出して、顧客への約束が守られるか」
• 緩める規則を手作業の量で選んだ: 穴は誰かが埋める。数えずに緩めると、CS が年末商戦で想定外の手作業を抱える。月3時間なら CS 森リーダーが受けられる量として、S21 開始前に合意を取る
• スパイクを1本・1日に限った: 最初からスパイクに逃げると「全部調べてから割る」になる。P・I・D・R で割った後に残った不明点（締め時刻と高額帯の上限）だけを調べる
• 受け入れ条件を分割の前に書いた: 条件を書くと7件の論点を「残す・切る・緩める・調べる」に決めざるを得ず、その結果として割り方が決まる。分割と受け入れ条件は順番ではなく往復

🔀 迷った他案と採らなかった理由

⚠️ よくある失敗パターン

🏢 実務での使いどころ

• 使う局面: リファインメントでエピックを初めてチームに見せる場面。PdM は割り方の案を持っていくが、どの規則を緩めるかはエンジニア・CS・法務と決める
• 隣接する役割: エンジニアは「この1本は単独で出せない」と指摘できる。QA は受け入れ条件の「ただし」から分割を提案できる。法務は「緩められない規則」の線を引く。CS は穴を受けるかを決める
• 個人開発への転用: 作りたい機能を1行で書いたら、SPIDR の表（切り口／候補／最初に残す／後に回す／理由）を埋める。なぜこの順で作ったかが残る

➡️ 次のステップ

• テーマ4-3「受け入れ条件の定義」で、シナリオ3 の「解約と返金の条件」を曖昧さの無い文に。返金は全額か日割りか、手数料は差し引くか
• 問い: アプリのストア審査が 11/12 に間に合わないと 10/30 に分かったら、S22 をどう組み替えるか。US3 に差し替えたときの加入の差（126→76件）を誰にどう説明するか
• テーマ4-4 で、積まないにした US3・US4・US8 を MoSCoW で並べ直す

🧭 扱わなかった範囲・検証していない点

• 延長保証の法的な位置づけ（保険業法・少額短期保険、景品表示法）、K保証との契約、保証料の会計処理は扱っていない
• 特定商取引法第12条の6 と施行時期は記憶・未照合。返品特約の表示（第15条の3ただし書・省令第44条）は消費者庁の特定商取引法ガイドを確認（参照日 2026-10-07）
• SPIDR は Cohn の記事を WebFetch で確認（参照日 2026-10-07）。要約ツール経由で、原文の全文照合はしていない
• 注文件数・価格帯・保証料・加入率6%・返品率3%・手作業時間・キャパ・pt はすべて演習の設定値（仮定）。加入率の業界水準は調べていない
• ストーリーマッピング（Patton）、受け入れ条件の網羅性（境界値・異常系）は扱っていない

🎯 自己評価

自分の回答

所要時間・気づき・メモ