story-slicing

name	story-slicing
description	ユーザーストーリーを Independent / Valuable / Small / Testable で点検し、満たさないストーリーを分割または再定義するための skill。要件定義完成直後 (ユーザーストーリーを書き終えた直後) に必ず発火させる。基本設計中や実装中に「このストーリー大きすぎる」「他のストーリーに依存している」「ユーザー価値が見えない」「受け入れテストが書けない」と気付いたタイミングでも発火させる。Small は『ユーザー価値を保ったまま分割可能な最小単位』として価値ベースで判定する (技術的なサイクル数ではない)。Negotiable は意図的に落とし (要件 / 設計フェーズで固める方針)、Estimable は暗黙 (固める方針なら自動で満たされる)。

ストーリー分割 — INVEST で refine する

なぜこの skill があるか

ユーザーストーリーを大きいまま、または独立性なしで実装フェーズに渡すと:

• 並列開発できない (複数 agent / 複数日にまたがる作業を切り出せない)
• 完了判断が曖昧になる (受け入れ条件が書きにくい)
• 価値が分割でしか届かない (ストーリー全部終わるまで何も使えない)

ストーリー粒度の整理は実装の前提条件で、要件定義の延長で必ず行う。基本設計や実装の中で気付くこともあり、その場合も同じ skill で再度 refine する。

発火タイミング

場面	モード	説明
1. 要件定義完成直後	auto (必須)	define-requirements がストーリーを書き終えた直後、INVEST 4 観点で点検
2. 基本設計中 / 完成後	判断 invoke	設計フェーズで「このストーリー大きい / 独立性ない」と気付いたら invoke
3. 実装中 (slice-tdd 委譲)	判断 invoke	実装してみて「このストーリー大きすぎる」と気付いたら、slice-tdd から invoke
4. 手動	任意	user / main の明示要求

場面 1 を auto にする理由: 「skip OK」を導入すると、main が「これは明らかに大丈夫」と rationalize する余地ができる。INVEST チェック自体は 1 ストーリーなら数秒で済むので過剰にならない。

INVEST 4 観点 (このプロジェクトでの取捨)

このプロジェクトでは INVEST から N (Negotiable) を意図的に落とし、E (Estimable) は暗黙とする:

• N を落とす理由: 自走と相性悪い (詳細を要件 / 設計フェーズで固める方針)
• E を暗黙にする理由: N を落として固める = 自動で見積もれる状態になる

中核は I / V / S / T の 4 観点。

観点	失格時の対応
Independent	他のストーリーへの依存があれば、依存解消の分割 or 順序整理
Valuable	エンドユーザー価値が見えなければ、Why に戻って再定義
Small (価値ベース)	「ユーザー価値を保ったまま分割可能な最小単位」を超えるなら分割
Testable	受け入れテストが書けなければ Done を観測可能形に書き直す

Small の定義 (重要)

Small = ユーザー価値を保ったまま分割可能な最小単位

技術的なサイクル数ではなく、価値ベースで判定する。

例: 1 ストーリーとして適切

「運用管理者が注文履歴を見られる」 — これより小さくすると価値が崩れる:

• API だけ作っても画面なしじゃ届かない
• 画面だけ作ってもデータなしじゃ届かない

ストーリー内部で「フロント実装 + API モック → API 本実装」のような技術的サイクル分割が発生するが、これはストーリー分割ではなく slice-tdd の責務 (Cycle 内の刻み)。

例: 1 ストーリーとして不適切

「注文履歴 + 商品一覧」 — 2 つの独立な価値単位がまとまっている。分割可能。

判定基準

分割した片方だけ完成して、ユーザーに価値が届くか?

• YES → Story として分割可能 (例: 「注文履歴」と「商品一覧」は分割可)
• NO → Cycle として刻む (例: API モックとフロント実装は Cycle 内、ストーリー分割しない)

やること

1. ストーリーを読む

docs/working/<title>/要件定義.md の「ユーザーストーリー」セクションから、現在のストーリー一覧を読む。

2. INVEST で点検する

各ストーリーについて I / V / S / T の 4 観点で点検する。失格項目があれば次の対応:

• I 失格: 依存を解消する分割 or 順序整理
• V 失格: Why に戻って再定義
• S 失格: 価値の最小単位まで分割
• T 失格: Done を観測可能形に書き直す

3. 対話で refine する

失格があれば、依頼者と対話で refine する。1 問ずつ質問、段階的に認識合わせ、セクション単位で approval gate を取る (define-requirements / basic-design と同じ対話の型)。

4. 要件定義.md を更新する

refine 結果を 要件定義.md のユーザーストーリーセクションをインライン更新 する。新規ファイルは作らない。Refine の経緯は git 履歴で追える。

5. 順序を整理する

Independent でも順序依存はありえる (例: ストーリー A の機能の上にストーリー B が建つ)。順序があるなら明記する:

- ストーリー A: 注文履歴を見られる (順序: 1)
- ストーリー B: 注文に承認/差し戻しを付けられる (順序: 2、A の完了が前提)

振る舞いのルール

対話の型 (define-requirements / basic-design と共通)

ストーリー refine は対話駆動。以下を厳守:

• 1 問ずつ質問: 深い議論は 1 つずつ。複数を 1 メッセージに混ぜない。軽い確認なら複数 OK
• multiple choice 優先: クローズな選択肢を出すのを基本に。AskUserQuestion ツールが使える場面では使う
• 段階的な認識合わせ: 議論の節目で「ここまでの理解はこうです、合ってますか」を依頼者が確認サインを出す前に proactive に出す
• セクション単位の approval gate: 1 ストーリー refine ごとに「これで合っているか」を明示確認してから次へ。一気に全部書き直してからレビューを求めない
• 不明点を推測で埋めない: 「たぶんこういう意図」で進めない。不明点が出たら必ず確認

slice-tdd との責務境界

	story-slicing (このスキル)	slice-tdd Step 1
扱う粒度	ストーリー (= ユーザー価値の単位)	サイクル内 (= TDD 1 サイクルの単位)
主題	独立性 / 受け入れ可能性 / 価値の最小単位	実装手順の刻み
失敗時の対応	ストーリーを分割 or 再定義	1 ストーリー内を更にサイクル分割

実装中に「このストーリー大きすぎる」と気付いたら、slice-tdd から story-slicing を invoke する (場面 3)。

既存 skill との関係

define-requirements   → ユーザーストーリーの初期形を引き出す
        ↓
story-slicing (本)    → 初期形を INVEST 基準で refine
        ↓
basic-design          → refine 済みストーリーごとに How を設計
        ↓
slice-tdd             → 1 ストーリー内の刻みを TDD で実装

cross-cutting なので、basic-design や slice-tdd からも逆向きに invoke される。

依頼者に迎合しない

• 「このストーリーで進めましょう」と空虚に肯定しない。INVEST に照らして失格があれば必ず指摘
• 「依頼者が大きいストーリーを望んでいるから」と妥協しない。並列開発の前提条件として整理する
• 即同意も迎合の一種。依頼者が反論したら、自分の判断との整合性を再評価してから引き下がる

成果物

要件定義.md の「ユーザーストーリー」セクションをインライン更新。

例 (refine 前):

## 2. ユーザーストーリー

- 運用管理者が、注文のレビュー画面で要確認の注文を見て承認/差し戻しできる

例 (refine 後、Small 分割を適用):

## 2. ユーザーストーリー

- ストーリー A (順序 1): 運用管理者が、要確認の注文一覧を見られる
- ストーリー B (順序 2): 運用管理者が、注文ごとに承認/差し戻しを実行できる (A 完了が前提)

新規ファイルは作らない。Refine 履歴は git で追える。

「やらない」判断

軽微な案件 (1 ストーリーで明らかに INVEST OK、例: 「ボタンの文言を変える」) でも形式的には INVEST チェックを通す。skip OK を許すと形骸化する。チェック自体は数秒で済むので過剰にならない。