🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、日用品カテゴリの再購入を楽にする機能「注文履歴からもう一度買う」を作ることになった。今日は 9/30（水）。次のスプリント計画は 10/5（月）、スプリントは 10/5〜10/16（10/12 はスポーツの日で稼働 9 日）。体制はバックエンド 2 名・フロントエンド 1 名・QA 1 名と PdM（鈴木）。
マーケティング部門の要望は 1 行だった。「日用品のリピート購入を楽にして、再購入率を上げたい」。現状は、注文履歴を開き、商品名を見て、商品ページへ移り、1 点ずつカートに入れる流れで、5 点買う人は 5 回これを繰り返す。
💬
リード佐藤: 「先輩の山田さんが要望をストーリーにしてくれたが、あのままでは次のスプリントに積めない。積める形に直して。何が悪いかは INVEST の観点で説明できるようにして。」
山田さんのストーリー下書き（そのまま）
| # | 下書き |
|---|---|
| D1 | ユーザーとして、再購入を便利にしたい |
| D2 | 開発者として、注文履歴 API に商品の販売状態（販売中／販売終了／在庫なし）を追加したい |
| D3 | 会員として、過去の注文を全部ワンタップでカートに入れたい。在庫切れなら代替商品を提案し、価格が変わっていたら通知し、定期おトク便にも切り替えられるようにしてほしい |
| D4 | 会員として、再購入の画面を使いやすくしたい |
| D5 | 会員として、D2 が終わった後に、履歴一覧に「もう一度買う」ボタンを表示したい |
| D6 | 会員として、販売終了の商品もきれいに扱ってほしい |
分かっている情報（設定値）
| 情報 | 値 | 出所 |
|---|---|---|
| 月間注文件数 | 9 万件 | 仮定（演習の設定） |
| 過去に買った商品を含む注文の割合 | 62% | 仮定 |
| 1 スプリントのキャパシティ | 20pt（過去 3 スプリントの完了実績 20／22／21pt の最小値） | 仮定 |
| D3 を 3 人が別々に見積もった結果 | 13 / 21 / 34pt（ばらつきが大きい） | 仮定 |
| 販売終了商品の代替先を持つマスタ | あるか未確認（データ基盤チームに聞く必要がある） | 仮定 |
| 関係者 | マーケ（要望元）、CS、データ基盤チーム、デザイナー 1 名 | 設定 |
📝 課題
あなたのタスク: 次の 3 点を作成してください。
- 下書き 6 本の診断: INVEST の 6 文字のうち、どれに反しているかを 1 本ずつ判定する
- ユーザーストーリー一覧: 書き直し・分割して「As a / I want / So that」で書く。見積もり（pt）、INVEST 判定、受け入れの要点（1〜2 行）を付ける。今回やらないものとその理由も書く
- スプリント投入案: 20pt のキャパに対して何を積み、何を積まないか。積んだ結果「顧客に価値が届くか」「効果を測れるか」を確認する
🔍 ヒント（段階的開示）
ヒント1
「ユーザーとして」の「ユーザー」は誰か。会員とゲストでは、できることが違わないか
ヒント2
「開発者として」で始まるものは、完成したとき顧客に何が変わるか。変わらないなら、それはストーリーではなくタスクではないか
ヒント3
1 つのストーリーに「そして」「また」が 3 回出てきたら、それは何を意味するか
ヒント4
分割を画面・API・DB という層で切ると何が起きるか。利用者が通る手順で切るとどうか
ヒント5
「使いやすく」「きれいに」はテストできるか。できないなら何に言い換えるか
ヒント6
見積もりが 13／21／34 に割れたのは、チームの能力ではなく何が原因か
📚 背景知識・用語解説
📖
ユーザーストーリー: 利用者の視点で「誰が・何をしたくて・なぜか」を 1〜2 文で書く、要求の最小単位。仕様書の代わりではなく、会話のきっかけを書いたカード。Ron Jeffries の Card（カード）・Conversation（会話）・Confirmation（確認＝受け入れ条件）の 3C が原型（Jeffries 2001、記憶に基づき未照合）。
As a / I want / So that: 「誰が／何をしたい／なぜ」の型。So that（目的）を書く理由は、目的が分かると、同じ目的を満たすもっと安い手段を開発者が提案できるから。型は Mike Cohn『User Stories Applied』（2004）で広まった（記憶に基づき未照合）。型自体に価値があるのではなく、目的を書かせることに価値がある。
分割の考え方: 層（API／画面／DB）で切ると、全部そろうまで何も動かない。利用者が通る手順を、粗くても端から端まで 1 本通す縦切りにすると、1 本目が出た時点で価値の検証が始まる（Cohn の「ワークフローのステップで分割」、Richard Lawrence の分割パターン。記憶に基づき未照合）。
スパイク（調査ストーリー）: 不確実性が見積もりを割らせている場合に、時間を区切って調べるだけのストーリー。成果は「分かったこと」で、機能ではない。
As a / I want / So that: 「誰が／何をしたい／なぜ」の型。So that（目的）を書く理由は、目的が分かると、同じ目的を満たすもっと安い手段を開発者が提案できるから。型は Mike Cohn『User Stories Applied』（2004）で広まった（記憶に基づき未照合）。型自体に価値があるのではなく、目的を書かせることに価値がある。
分割の考え方: 層（API／画面／DB）で切ると、全部そろうまで何も動かない。利用者が通る手順を、粗くても端から端まで 1 本通す縦切りにすると、1 本目が出た時点で価値の検証が始まる（Cohn の「ワークフローのステップで分割」、Richard Lawrence の分割パターン。記憶に基づき未照合）。
スパイク（調査ストーリー）: 不確実性が見積もりを割らせている場合に、時間を区切って調べるだけのストーリー。成果は「分かったこと」で、機能ではない。
INVEST（良いストーリーの 6 条件・Bill Wake 2003、記憶に基づき未照合）
| 文字 | 意味 | 破れたときの症状 |
|---|---|---|
| I | Independent（独立） | 順番が固定され、前が遅れると全部止まる |
| N | Negotiable（交渉可能） | 解決策まで書いてあり、より良い手段を検討できない |
| V | Valuable（価値がある） | 完成しても顧客・事業の誰も何も変わらない |
| E | Estimable（見積もり可能） | 3 人の見積もりが割れる。調べることが残っている |
| S | Small（小さい） | 1 スプリントに収まらない |
| T | Testable（検証可能） | 「できた」を誰も判定できない |
✅ 模範解答
答えを見る前に自分の診断を作ってから読み比べてください。
1. 下書き 6 本の診断（クイズ）
各下書きで破れている INVEST の文字を選んでから「答え」を押してください（複数可）。
| 下書き | あなたの判定 |
|---|---|
| D1 再購入を便利にしたい | |
| D2 開発者として API に販売状態を追加 | |
| D3 全部ワンタップ＋代替提案＋価格通知＋定期便 | |
| D4 画面を使いやすくしたい | |
| D5 D2 が終わった後にボタンを表示 | |
| D6 販売終了の商品もきれいに扱いたい |
診断の全体
| # | 破れている文字 | 理由 |
|---|---|---|
| D1 | S・V・T | 誰が（ユーザー＝会員かゲストか）も、便利の中身も無い。エピック（大きな要望）。完了を判定できない |
| D2 | V・I | 完成しても顧客の画面は変わらない（タスク）。D5 の前提として固定される |
| D3 | S・N・E | 4 つの機能の束で 13〜34pt に割れる。代替提案は「方法」まで決めており、他の手段を検討できない |
| D4 | T・V | 「使いやすい」を判定する基準が無い。何が困っているのか書かれていない |
| D5 | I | 順番を文に書いてしまっている。ボタンの目的（So that）も無い |
| D6 | E・T | 「きれい」が未定義。代替先マスタがあるか不明で見積もれない |
2. ユーザーストーリー一覧
利用者が通る手順「履歴を開く → ボタンを押す → カートに入る → 入らなかった理由を知る → 買う」をまず端から端まで 1 本通し、その後に枝（価格差・測定）を足した。
| ID | ストーリー | pt | INVEST | 受け入れの要点 |
|---|---|---|---|---|
| US1 | 会員として、注文履歴の 1 件の注文で「もう一度買う」を押すと、現在買える商品だけが前回の数量でカートに入るようにしたい。そうすれば、商品を 1 点ずつ探さずに買い物を終えられる | 5 | 縦切りで 1 本通る。他に依存しない | 5 点の注文で押すと買える商品だけが入り、カート画面に遷移する。ゲスト（未ログイン）は対象外 |
| US2 | 会員として、カートに入らなかった商品があるとき、どの商品が・なぜ（販売終了／在庫なし）入らなかったかを見たい。そうすれば、買い忘れに注文後に気づかなくて済む | 3 | US1 の後に出す（順序はあるが、US1 単独でもリリース可） | 入らなかった商品名と理由 2 種類が、カート画面上部に表示される。0 件なら何も出ない |
| US3 | 会員として、カートに入った商品のうち前回購入時と価格が違うものに、前回との差額を見たい。そうすれば、知らずに高い価格で買わなくて済む | 3 | US1 と独立（並行可） | 差額がある行にだけ「前回 ○○円」を表示。価格が同じ商品は何も出さない |
| US5 | マーケ担当として、「もう一度買う」の押下数・カート追加数・購入完了数を日別に見たい。そうすれば、4 週間後に機能を続けるか判断できる | 3 | US1 の押下ログに依存するが、集計は独立に作れる | 日別 3 指標が既存ダッシュボードの 1 画面で見える。判断基準: 購入完了が注文の 3% 未満なら見直し（仮定） |
| SP1 | （スパイク・1 日で区切る）データ基盤チームに聞き、販売終了商品の代替先マスタがあるか・更新頻度・カバー率を確認する | 2 | 成果は「あるかないか」の回答。機能ではない | 1 日後に「ある／ない／ある（ただしカバー率 ○%）」を、データ基盤チームの回答つきで記録する |
今回やらないもの（Won't this time）
| もの | 元 | やらない理由 | 拾い直す条件 |
|---|---|---|---|
| 代替商品の提案 | D3・D6 | SP1 の結果が出るまで見積もれない（E）。「提案する」は手段であり、目的は「買えない時に困らない」（N） | SP1 で代替先マスタが「ある」と分かれば、次のスプリントでストーリー化 |
| 定期おトク便への切り替え | D3 | 再購入とは別の目的（自動で届ける）。別のストーリー群 | 再購入ボタンの利用が 3% を超え、同じ商品を繰り返し買う会員が見えたら |
| 販売状態を返す API 追加 | D2 | タスクなので単独ではストーリーにしない。US1・US2 の中に含めて見積もる | 無し（US1 の作業内容） |
| 「使いやすい」画面改善 | D4 | 困りごとが特定されていない。US1 の利用後に利用者の行動（途中で離脱した箇所）を見てから書く | US5 のログで離脱箇所が見えたとき |
3. スプリント投入案（10/5〜10/16、稼働 9 日）
キャパとストーリーの pt は演習の設定値（仮定）。チェックを入れ外して、合計と「価値が届くか・測れるか」を確かめてください。
- 確認 1（価値が届くか）: US1 が入っていれば、スプリントの 3〜5 日目に「履歴→カート」の 1 本がステージングで通る。US1 が無いとスプリントを終えても顧客に変化が無い
- 確認 2（測れるか）: US5 が無いと、リリース後の 4 週間に「続けるか」の判断材料が無い
- 余力 4pt（20%）の使い道: US1 の想定外（カート側の在庫引当の仕様）を吸収する。使わなければ US2 の文言調整など小さい改善に回す
- スパイクを先頭に置く理由: SP1 は 1 日で終わり、結果が次のスプリントの中身を決める。中盤に回すと、結果が出てもすぐ動けない
💡 なぜこう作るのか
- 層ではなく手順で切った理由: D2→D5 は「API→画面」という層の順番で、API が終わるまで顧客に価値が無く、遅れると全体が止まる。US1 は API・画面・カート連携を全部含んで小さく作るので、5pt でも「押したらカートに入る」が実際に動く
- So that を全ストーリーに書いた理由: 目的が違えば手段が変わる。US2 の目的は「買い忘れに気づく」なので、表示場所はカート画面上部でも押下直後のポップアップでもよく、デザイナーと交渉できる（N）。D3 の「代替商品を提案」は手段が先に決まっていて、目的が同じ別の手段を比べられなかった
- D2（開発者として）を捨てた理由: 完成して何が変わるかを顧客に説明できない。必要な作業なら US1 の内訳（タスク）として残せば足りる
- 見積もりが割れた原因の読み方: 13／21／34 のばらつきは能力差ではなく、D3 に代替・価格・定期便という中身の決まっていない部分が混ざっていたから。分割後の US1〜US3 は同じ 3 人で試すと 4〜6pt に収まる想定（設定上の想定で、実測ではない）
- スパイクを 1 日・2pt で区切った理由: 区切らない調査は終わらないことが多い。時間を決めて「分かったこと」だけを成果にすれば、分からなかった場合でも「分からないと分かった」という結論が出る
🔀 迷った他案と採らなかった理由
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| D1〜D6 の文面を最小限だけ直して使う | S・V・T の破れが 3 本以上で、直すと元の形が残らない | D1〜D6 のうち 4 本以上が INVEST を満たしていた場合 |
| 層（API／画面）で分割して担当を分ける | 全部そろうまで顧客に価値が届かず、US5 の効果測定も遅れる | API を複数機能で共用する基盤整備で、顧客に見える変化が元々無い場合 |
| 「開発者として」のストーリーを残す | 顧客に何が変わるか説明できず、優先順位を比べられない | データ移行など、利用者視点で書くと嘘になる基盤作業が単独で大きい場合（タスクとして別枠で管理） |
| 代替商品の提案を今回 Must で入れる | 見積もれない（E）。マスタが無ければ作る作業が別に必要 | SP1 で「ある・カバー率 8 割以上」と分かった場合 |
| Job Story で書く | 今日の論点は INVEST と分割で、型の比較ではない | 「会員」とひとくくりにすると状況の違い（急ぎ／まとめ買い）が見えなくなる場合（Day038 参照） |
| 全ストーリーに Given-When-Then を書く | 今日は要点 1〜2 行まで。書式は次のテーマ（4-3） | 次のテーマ（4-3） |
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「ユーザーとして」で始める | 会員・ゲスト・マーケ担当の区別が消え、権限や対象が決まらない | 実在する役割名を使う。迷ったら「その人に実際に会えるか」で確かめる |
| So that を書かない、または「便利になる」と書く | 手段の代替案が出せず、優先順位も付けられない | 「〜しなくて済む」「〜が分かる」のように、行動か状態の変化で書く |
| 1 つのストーリーに「そして」が 3 回以上 | 実質は複数のストーリーで、見積もりが割れる | 「そして」ごとに 1 本に切り、手順の端から端を通す最小の 1 本を先に作る |
| 「前提が終わったら」と順番を書く | I が破れ、前が遅れると止まる | 順序は計画側（スプリント投入案）で扱い、ストーリー文には書かない。独立にできないなら 1 本にまとめる |
| 調査を機能と同じ 1 本として置く | 終わりが無く、見積もりも意味を持たない | 時間で区切るスパイクにし、成果を「分かったこと」にする |
🏢 実務での使いどころ
- 使う局面: PRD を書いた後のバックログ作成（4-1 の次）、スプリント計画の前の「バックログ整理（リファインメント）」。エンジニアが見積もりの前に「見積もれない」と言える根拠が INVEST の E になる
- 隣接する役割: PdM は So that（目的）の責任を負う。デザイナーは手段の候補を出す。QA は T が崩れているストーリーを早く見つけて差し戻せる。リードは S を見て 1 スプリントに積める単位かを判断する
- 個人開発・ポートフォリオへの転用: README の「作りたい機能」を、ID／ストーリー／pt／受け入れの要点の表にしておくと、後から「何のために作ったか」を残せる
➡️ 次のステップ
- テーマ 4-3「受け入れ条件の定義」で、US1・US2 の要点を Given-When-Then に書き直す。曖昧さが残る箇所（在庫なしの定義＝在庫 0 か引当済みか）を見つける
- 問い: US1 の「現在買える商品だけ」を実装すると、価格が前回より大きく上がった商品もカートに入る。US3 を US1 と同時に出さないと顧客に不利益が出ないか。出す順番を変えると何が変わるか
- 4-4「要求の優先度判断基準」で、今回 Won't にした 4 件を再度並べ、MoSCoW で仕分け直す
🧭 扱わなかった範囲・検証していない点
- 受け入れ条件の厳密な書式（Given-When-Then）、MoSCoW による全体の優先順位、ストーリーマッピング（Patton）は扱っていない（後続テーマ）
- 見積もり値（pt）、チームの実績（20／22／21pt）、割れた見積もり（13／21／34）、月間注文 9 万件、62%、判断基準 3% はすべて演習の設定値（仮定）で、実測ではない
- 参照した一次資料（Jeffries 2001、Cohn 2004、Wake 2003、Lawrence の分割パターン）は記憶に基づき、原文を照合していない。使う前に原典で確認すること
- 「分割後は同じ 3 人で 4〜6pt に収まる」は設定上の想定で、実際に見積もりを取り直した結果ではない