user-story-splitting

目的

大規模なユーザーストーリー、エピック、機能を、個別に提供できる小さなストーリーに体系的な分割パターンを使って分解します。作業を管理しやすくし、リスクを減らし、フィードバックサイクルを速め、アジャイル開発の流れを維持するために活用してください。このスキルは、ユーザーストーリー、エピック、そして1回のスプリントで完了するには大きすぎるあらゆる作業に適用できます。

これは恣意的な切り分けではありません。ユーザー価値を維持しながら複雑さを軽減する、戦略的な分解です。

入力

最適な入力： 大きすぎるストーリーまたはエピックを、そのまま貼り付けてください。 あると役立つ情報： 大きすぎる理由（見積もれない、1回のスプリントで完了できない、個別にリリースできないなど）と、チームが扱えるサイズの上限。

スキルの呼び出し時に渡された情報（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追加された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。その情報を使い、内容が重複する質問はしないでください。

何も準備していなくても大丈夫です。 このスキルがストーリーの内容を尋ね、そのストーリーに分割パターンを順に適用していきます。

呼び出し例： Split this: 'As an admin, I can bulk-import users from CSV, Excel, or our HR system with field mapping and error handling.'

主な概念

ストーリー分割フレームワーク

Richard Lawrence と Peter Green による「Humanizing Work Guide to Splitting User Stories」に基づくこのフレームワークでは、作業を分割するための体系的な8つのパターンを提供します。

1. ワークフローのステップ： ユーザーの一連の行動に沿って分割します
2. ビジネスルールの違い： 異なるルールのシナリオ（権限、計算など）ごとに分割します
3. データの違い： データの種類や入力ごとに分割します
4. 受け入れ条件の複雑さ： 複数の「When」または「Then」の記述がある場合に分割します
5. 大きな作業： 技術的なマイルストーンや実装フェーズごとに分割します
6. 外部依存関係： 依存関係の境界（API、サードパーティなど）に沿って分割します
7. DevOps のステップ： デプロイやインフラストラクチャの要件ごとに分割します
8. 小さな発見のための実験（TAD）： 上記のいずれも当てはまらない場合、未知の要素を明らかにするために小さな実験を行います

ストーリーを分割する理由

• フィードバックの迅速化： 小さなストーリーは早くリリースでき、より早い検証が可能になります
• リスクの軽減： 作るものが少なければ、問題が起きる可能性も下がります
• 見積もりの精度向上： 小さなストーリーは、より正確に見積もりやすくなります
• 流れの維持： ボトルネックを避け、スプリント中も作業を前に進められます
• テストのしやすさ： スコープが小さければ、テストの作成と実行も容易になります

アンチパターン（これは何ではないか）

• 水平分割ではありません： 「フロントエンドのストーリー」と「バックエンドのストーリー」に分けないでください（各ストーリーでユーザー価値を提供する必要があります）
• タスクの分解ではありません： ストーリーはタスクではありません（「データベースをセットアップする」「API を作成する」など）
• 恣意的な切り分けではありません： 「ユーザー管理を追加する」を「ユーザーを追加する」と「管理」に分けないでください（意味がありません）

使用する場面

• ストーリーが1回のスプリントには大きすぎる
• 受け入れ条件に複数の「When」または「Then」の記述がある
• エピックを、提供可能な単位に分割する必要がある
• チーム内でストーリーのサイズやスコープについて合意できない
• 複数のペルソナやワークフローが1つのストーリーにまとめられている

使用しない場面

• ストーリーがすでに小さく、スコープも明確（細分化しすぎないでください）
• 分割によって依存関係が生まれ、提供が遅くなる
• ストーリーが技術的なタスクである（代わりにエンジニアリングタスクの分解を使用してください）

---

適用方法

ステップ1：元のストーリーを特定する

分割が必要なストーリー、エピック、機能から始めます。ユーザーストーリー形式で記述されていることを確認してください（skills/user-story/SKILL.md または skills/epic-hypothesis/SKILL.md を参照）。

### Original Story:
[Story formatted with use case and acceptance criteria]

---

ステップ2：分割ロジックを適用する

記入欄と出力形式の全体については、template.md を使用してください。

8つの分割パターンを順番に確認します。該当するパターンが見つかったら、そこで終了してください。

パターン 1：ワークフローの手順

確認事項： このストーリーには、複数の連続した手順が含まれていますか？

例：

• 元のストーリー：「ユーザーとして、サインアップし、メールアドレスを確認して、オンボーディングを完了したい」
• 分割後：
  1. 「ユーザーとして、メールアドレスとパスワードでサインアップしたい」
  2. 「ユーザーとして、確認リンクからメールアドレスを確認したい」
  3. 「ユーザーとして、プロフィールに関する 3 つの質問に回答してオンボーディングを完了したい」

---

パターン 2：ビジネスルールの違い

確認事項： このストーリーには、シナリオごとに異なるルールがありますか？

例：

• 元のストーリー：「ユーザーとして、割引を適用したい（会員は 10％、VIP は 20％、初回購入者は 5％）」
• 分割後：
  1. 「会員として、チェックアウト時に 10％の割引を適用したい」
  2. 「VIP として、チェックアウト時に 20％の割引を適用したい」
  3. 「初回購入者として、チェックアウト時に 5％の割引を適用したい」

---

パターン 3：データの違い

確認事項： このストーリーでは、異なる種類のデータや入力を扱いますか？

例：

• 元のストーリー：「ユーザーとして、ファイル（画像、PDF、動画）をアップロードしたい」
• 分割後：
  1. 「ユーザーとして、画像ファイル（JPG、PNG）をアップロードしたい」
  2. 「ユーザーとして、PDF ドキュメントをアップロードしたい」
  3. 「ユーザーとして、動画ファイル（MP4、MOV）をアップロードしたい」

---

パターン 4：受け入れ条件の複雑さ

確認事項： このストーリーには、複数の「When」または「Then」の文がありますか？

例：

• 元のストーリー：「ユーザーとして、カートを管理したい」
  • アイテムを追加すると、カートに表示される
  • アイテムを削除すると、カートから消える
  • 数量を変更すると、カートの合計金額が更新される
• 分割後：
  1. 「ユーザーとして、後で購入できるようにアイテムをカートに追加したい」
  2. 「ユーザーとして、気が変わったときにアイテムを削除したい」
  3. 「ユーザーとして、適切な数量を購入できるようにアイテムの数量を変更したい」

注： これは、ストーリーを分割する必要があることを示す最も一般的な兆候です。「When/Then」の組み合わせが複数ある場合は、その境界に沿って分割してください。

---

パターン 5：大きな作業

確認事項： このストーリーには、段階的に提供できる大規模な技術作業が必要ですか？

例：

• 元のストーリー：「ユーザーとして、ドキュメント上でリアルタイムに共同作業したい」
• 分割後：
  1. 「ユーザーとして、ドキュメントを閲覧している他のユーザーを確認したい（閲覧専用のプレゼンス）」
  2. 「ユーザーとして、他の編集者のカーソル位置をリアルタイムで確認したい」
  3. 「ユーザーとして、他のユーザーによる編集内容をリアルタイムで確認したい」

---

パターン 6：外部依存関係

確認事項： このストーリーは、複数の外部システムまたは API に依存していますか？

例：

• 元のストーリー：「ユーザーとして、Google、Facebook、または Twitter でログインしたい」
• 分割後：
  1. 「ユーザーとして、Google OAuth でログインしたい」
  2. 「ユーザーとして、Facebook OAuth でログインしたい」
  3. 「ユーザーとして、Twitter OAuth でログインしたい」

---

パターン 7：DevOps の手順

確認事項： このストーリーには、複雑なデプロイ、インフラストラクチャ、または運用作業が必要ですか？

例：

• 元のストーリー：「ユーザーとして、大容量ファイルをクラウドストレージにアップロードしたい」
• 分割後：
  1. 「ユーザーとして、小さなファイル（<10MB）をクラウドストレージにアップロードしたい」
  2. 「ユーザーとして、進行状況を確認しながら大容量ファイル（10MB-1GB）をアップロードしたい」
  3. 「ユーザーとして、中断したアップロードを再開したい」

---

パターン 8：小さな発見のための実験（TAD）

確認事項： 上記のいずれにも当てはまらない場合、掘り下げる必要のある未知の要素や仮定はありますか？

例：

• 元のストーリー：「ユーザーとして、AI を活用したレコメンデーションがほしい」（曖昧すぎるうえ、未知の要素が多すぎます）
• TAD：
  1. 3 種類のレコメンデーションアルゴリズムを試作し、10 人のユーザーでテストする
  2. 成功基準（クリックスルー率、ユーザー満足度）を定義する
  3. 最もシンプルなレコメンデーションエンジン（協調フィルタリング）を構築する
  4. 効果を測定し、改善を繰り返す

注： TAD はストーリーではなく、実験です。ストーリーを書く前にリスクを軽減し、内容を明確にするために使用してください。

---

ステップ 3：分割したストーリーを書く

分割した各項目について、skills/user-story/SKILL.md の形式を使って、完全なユーザーストーリーを書きます。

### Split 1 using [Pattern Name]:

#### User Story [ID]:
- **Summary:** [Brief title]

**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]

**Acceptance Criteria:**
- **Scenario:** [Description]
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]

---

ステップ 4：分割を検証する

次の質問に答えてください。

1. 各分割でユーザーに価値を提供できますか？（「フロントエンドが完了した」だけではありません）
2. 各分割を独立して開発できますか？（強い依存関係がないこと）
3. 各分割を独立してテストできますか？（明確な受け入れ基準があること）
4. 各分割はスプリントに収まるほど小さいですか？（1〜5日分の作業）
5. 分割を組み合わせると、元の内容と一致しますか？（翻訳で失われたものがないこと）

どれか一つでも「いいえ」であれば、見直してください。

---

例

分割の詳しい例については、examples/sample.md をご覧ください。

簡単な例の抜粋：

### Original Story:
As a team admin, I want to manage team members so that I can control access.

### Suggested Splits (Acceptance Criteria Complexity):
1. Invite new team members
2. Remove team members
3. Update team member roles

---

よくある落とし穴

落とし穴 1：水平分割（技術レイヤーごとの分割）

症状：「ストーリー 1：API を構築する。ストーリー 2：UI を構築する。」

**結果：**どちらのストーリーも、単独ではユーザーに価値を提供できません。

**対処法：**垂直に分割します。各ストーリーには、ユーザー向けの機能を完成させるためのフロントエンドとバックエンドの作業を含めてください。

---

落とし穴 2：細分化しすぎる

症状：「ストーリー 1：ボタンを追加する。ストーリー 2：ボタンを API に接続する。ストーリー 3：結果を表示する。」

**結果：**不要なオーバーヘッドと依存関係が生じます。

**対処法：**ストーリーが大きすぎる場合にのみ分割してください。2 日で完了するストーリーを分割する必要はありません。

---

落とし穴 3：意味のない分割

症状：「ストーリー 1：機能の前半。ストーリー 2：機能の後半。」

**結果：**ユーザー価値やワークフローに対応しない、恣意的な分割になります。

**対処法：**8 つの分割パターンのいずれかを使います。それぞれの分割には、明確な根拠が必要です。

---

落とし穴 4：強い依存関係を作る

症状：「ストーリー 1 が 100％完了し、テストされ、デプロイされるまで、ストーリー 2 は開始できない。」

**結果：**並行作業ができず、提供が遅くなります。

**対処法：**独立して開発できるように分割してください。依存関係を避けられない場合は、ストーリー 1 を優先します。

---

落とし穴 5：「そうすれば」を無視する

**症状：**分割後のストーリーで「そうすれば」の文言が同じになっています。

**結果：**行動は分割できていますが、成果は分割されていません。ストーリーの分割ではなく、タスクの分解になっている可能性があります。

**対処法：**各分割で、ユーザーに異なる成果をもたらすようにしてください。そうなっていない場合は、分割パターンを見直します。

---

参考資料

関連スキル

• skills/user-story/SKILL.md — 分割後のストーリーを記述する形式
• skills/epic-hypothesis/SKILL.md — エピックはストーリーになる前に分割が必要なことがよくあります
• skills/jobs-to-be-done/SKILL.md — ユーザーのジョブに沿った有意義な分割を見つけるのに役立ちます

外部フレームワーク

• Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — 8 つの分割パターンの出典
• Bill Wake, INVEST in Good Stories (2003) — 適切に構成されたストーリーの基準（独立性、交渉可能性、価値、見積もり可能性、小ささ、テスト可能性）
• Mike Cohn, User Stories Applied (2004) — ストーリーを分解する手法

Dean の取り組み

• ユーザーストーリー分割プロンプトテンプレート（Humanizing Work フレームワークに基づく）

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリ内の prompts/user-story-splitting-prompt-template.md を基にしています。

---

**スキルの種類：**コンポーネント 推奨ファイル名：user-story-splitting.md 推奨配置先：/skills/components/ 依存関係：skills/user-story/SKILL.md、skills/epic-hypothesis/SKILL.md を参照します **対象：**ユーザーストーリー、エピック、1 つのスプリントで完了するには大きすぎるあらゆる作業