epic-breakdown-advisor

目的

プロダクトマネージャーが、Richard Lawrence の完全な Humanizing Work 手法を使って、エピックをユーザーストーリーに分割できるよう支援します。この手法は、9 つの分割パターンを順番に適用する、体系的なフローチャート駆動型のアプローチです。どのパターンが当てはまるかを特定し、ユーザー価値を保ちながら分割し、低価値な作業を取り除ける可能性を明らかにする観点から分割結果を評価するために活用してください。これにより、水平分割（技術レイヤーごとの分割）ではなく、垂直分割（エンドツーエンドの価値）を実現できます。

これは恣意的な分割ではありません。検証から始め、順番にパターンを確認し、結果を戦略的に評価する、実証済みの体系的なプロセスです。

入力

最適な入力： 分割したいエピックまたは大きなストーリー。バックログに記載されているとおりに貼り付けてください。 あると役立つ情報： チームの状況（スプリントの長さ、見積もりの上限）と、デリバリーを妨げている要因（見積もり、順序付け、リリースが難しいなど）。

呼び出し時に渡された内容（スキル名の後のテキスト、貼り付けられたコンテキストのダンプ、追記された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。内容を活用し、含まれている項目については再度質問しないでください。

何も用意していなくても大丈夫です。 アドバイザーがまずエピックのテキストを尋ね、その後、Humanizing Work のパターンフローチャートに沿って確認します。

呼び出し例： Break this down: 'As a finance admin, I can export any report to Excel, PDF, or CSV with custom date ranges and saved templates.'

主な概念

基本原則：垂直分割で価値を保つ

ユーザーストーリーとは、「ユーザーの視点から見た、システムの動作の変化を説明するもの」です。分割では、単一のコンポーネントだけを対象にする水平分割（例：「フロントエンドのストーリー」＋「バックエンドのストーリー」）ではなく、複数のアーキテクチャレイヤーにまたがり、ユーザーが実感できる価値を提供する垂直分割を維持する必要があります。

3 ステップのプロセス

1. 分割前の検証： ストーリーが INVEST 基準（「Small」を除く）を満たしているか確認します
2. 分割パターンの適用： 当てはまるパターンが見つかるまで、9 つのパターンを順番に確認します
3. 分割結果の評価： 低価値な作業を明らかにする分割、または同程度のサイズのストーリーを生み出す分割を選びます

9 つの分割パターン（順番）

1. ワークフローのステップ — ステップごとの分割ではなく、薄いエンドツーエンドのスライスにします
2. 操作（CRUD） — 作成、読み取り、更新、削除を個別のストーリーにします
3. ビジネスルールの違い — ルールが異なれば、ストーリーも分けます
4. データの違い — データの種類や構造が異なれば、分けます
5. データ入力方法 — まずシンプルな UI を実装し、凝った UI は後にします
6. 大きな作業 — 「まず 1 つを実装し、残りを追加」します
7. シンプル／複雑 — まず最もシンプルな基本形を実装し、バリエーションは後にします
8. パフォーマンスの改善を後回しにする — 「高速化」の前に「動作させる」ことを優先します
9. スパイクを切り出す — 不確実性によって分割が妨げられる場合は、調査期間をタイムボックス化します

メタパターン（すべてのパターンに適用）

1. 中核となる複雑さを特定します
2. すべてのバリエーションを列挙します
3. バリエーションを1 つの完全なスライスに絞ります
4. それ以外のバリエーションを別のストーリーにします

この方法が有効な理由

• 恣意的な分割を防止： 体系的なチェックリストによって、推測に頼らずに済みます
• ユーザー価値を保つ： どのストーリーも、ユーザーが実感できる価値を提供します
• 無駄を明らかにする： 適切な分割によって、優先度を下げられる低価値な作業が明らかになります
• 再現性がある： どのエピックにも一貫して適用できます

---

ファシリテーションの信頼できる情報源

このスキルのデフォルトの対話プロトコルとして、workshop-facilitation を使用してください。

以下を定義しています。

• セッションの事前案内と開始モード（ガイド付き、コンテキストのダンプ、最善の推測）
• 平易な言葉でのプロンプトを使った、一度に 1 つの質問をする進め方
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 中断への対応と一時停止／再開の動作
• 意思決定ポイントでの番号付きの提案
• 通常の質問で使う、番号付きのクイック選択肢（必要に応じて Other (specify) を含めます）

このファイルでは、ドメイン固有の評価内容を定義しています。競合する場合は、このファイルのドメインロジックに従ってください。

適用

ステップ 0：エピックのコンテキストを提示する

エージェントが質問します：

エピックを共有してください：

• エピックのタイトル／ID
• 説明または仮説
• 受け入れ条件（特に複数の「When/Then」ペア）
• 対象ペルソナ
• おおよその見積もり

Jira、Linear から貼り付けるか、簡単に説明してください。

---

ステップ 1：分割前の検証（INVEST チェック）

分割する前に、「Small」以外の INVEST 基準をストーリーが満たしていることを確認します：

エージェントが順番に質問します：

1. 独立しているか？ 「このストーリーは、他のストーリーに技術的に強く依存せずに、優先順位付けや開発ができますか？」

選択肢：

• はい — ブロックする依存関係はありません
• いいえ — 先に別の作業が必要です（その旨を示してください）

---

2. 交渉可能か？ 「正確な解決策を指定するのではなく、チームが協力して実装の詳細を見つけられる余地がありますか？」

選択肢：

• はい — 仕様ではなく、話し合いのきっかけです
• いいえ — 指示が細かすぎます（見直しが必要な場合があります）

---

3. 価値があるか？ 「このストーリーは、ユーザーに目に見える価値を提供しますか？（そうでない場合は、分割せず、関連する作業とまとめてください。）」

選択肢：

• はい — ユーザーが何かの違いを目にする、または体験します
• いいえ — 技術的なタスクです（ユーザーストーリーではありません。分割せず、見直してください）

⚠️ 重要な確認： ストーリーが「価値がある」を満たさない場合は、そこで中止してください。分割してはいけません。代わりに、他の作業とまとめて意味のある単位を作成してください。

---

4. 見積もり可能か？ 「チームはこのストーリーの規模を（おおよそでも）見積もれますか？」

選択肢：

• はい — チームが日数／ポイントで見積もれます
• いいえ — 不確実性が高すぎます（先にスパイクが必要な場合があります）

---

5. テスト可能か？ 「QA が検証できる具体的な受け入れ条件がありますか？」

選択肢：

• はい — 合否条件が明確です
• いいえ — 受け入れ条件をもっと明確にする必要があります（分割前に詳細化してください）

---

ストーリーがすべてのチェックに合格した場合 → ステップ 2（分割パターン）に進みます いずれかのチェックに不合格の場合 → 分割する前に問題を解決してください

---

ステップ 2：分割パターンを順番に適用する

パターンを順番に確認します。各パターンについて、「当てはまりますか？」と尋ねてください。

---

パターン 1：ワークフローのステップ

重要なポイント： ステップごとに分けるのではなく、薄いエンドツーエンドのスライスに分割します。ワークフロー全体を網羅する単純なケースから始め、後から中間ステップを別のストーリーとして追加します。

エージェントが質問します： 「エピックには、まず単純なケースを提供し、後から中間ステップを追加できるような複数ステップのワークフローが含まれていますか？」

例：

• 元のストーリー：「コンテンツを公開する（編集レビュー、法務承認、ステージングが必要）」
• ❌ 誤った分割（ステップごと）： ストーリー 1 = 編集レビュー、ストーリー 2 = 法務承認、ストーリー 3 = 公開
• ✅ 正しい分割（薄いエンドツーエンド）：
  • ストーリー 1：コンテンツを公開する（シンプルな経路：作成者がアップロードすると、レビューなしですぐに公開される）
  • ストーリー 2：編集レビューのステップを追加する（コンテンツは編集者の承認を受けてから公開される）
  • ストーリー 3：法務承認のステップを追加する（コンテンツは法務部門と編集者の承認を受けてから公開される）

各ストーリーがワークフロー全体を提供し、段階的に機能を充実させます。

選択肢：

1. はい、複数ステップのワークフローです → 「ワークフローのステップを説明してください」
2. いいえ、単一のステップです → パターン 2 に進みます

「はい」の場合： エージェントが薄いエンドツーエンドのスライスに分割します。

---

パターン 2：操作（CRUD）

重要なポイント：「管理する」という言葉は、複数の操作を示唆します。作成、読み取り、更新、削除に分割します。

エージェントが質問します： 「エピックに『管理する』『処理する』『保守する』などの言葉が使われていますか？その場合、複数の操作（CRUD）がまとめられている可能性があります。」

例：

• 元のストーリー：「ユーザーアカウントを管理する」
• 分割：
  • ストーリー 1：ユーザーアカウントを作成する
  • ストーリー 2：ユーザーアカウントの詳細を表示する
  • ストーリー 3：ユーザーアカウント情報を編集する
  • ストーリー 4：ユーザーアカウントを削除する

選択肢：

1. はい、複数の操作が含まれています → 「操作を列挙してください（作成／読み取り／更新／削除など）」
2. いいえ、単一の操作です → パターン 3 に進みます

「はい」の場合： エージェントが操作ごとに 1 つのストーリーを生成します。

---

パターン 3：ビジネスルールのバリエーション

重要なポイント： 同じ機能でも、適用されるルールが異なる場合は、それぞれのルールを独立したストーリーにします。

エージェントの質問： 「エピックには、シナリオ（ユーザーの種類、地域、階層、条件など）によって異なるビジネスルールがありますか？」

例：

• 元の内容：「日付に柔軟性のあるフライト検索（日付範囲、特定の週末、日付のオフセット）」
• 分割後：
  • ストーリー 1：日付範囲（±N 日）で検索する
  • ストーリー 2：特定の週末のみを対象に検索する
  • ストーリー 3：日付のオフセット（N 日前／後）で検索する

選択肢：

1. はい、ルールが異なります →「ルールのバリエーションを説明してください」
2. いいえ、すべて同じルールです → パターン 4 に進みます

「はい」の場合： エージェントは、ルールのバリエーションごとに 1 つのストーリーを生成します。

---

パターン 4：データのバリエーション

重要なポイント： 異なるデータ型や構造を扱うことで複雑さが生じます。必要に応じて、必要なタイミングでバリエーションを追加します。

エージェントの質問： 「エピックでは、異なるデータ型、形式、構造（ファイルの種類、地理的な階層、ユーザー属性など）を扱いますか？」

例：

• 元の内容：「地理的な検索（郡、市／町／近隣地域、カスタムプロバイダーのエリア）」
• 分割後：
  • ストーリー 1：郡で検索する
  • ストーリー 2：市／町／近隣地域の検索を追加する
  • ストーリー 3：カスタムプロバイダーのエリア検索を追加する

選択肢：

1. はい、異なるデータ型があります →「データのバリエーションを列挙してください」
2. いいえ、データ型は 1 つです → パターン 5 に進みます

「はい」の場合： エージェントは、データのバリエーションごとに 1 つのストーリーを生成します（最もシンプルなものから提供します）。

---

パターン 5：データ入力方法

重要なポイント： UI の複雑さはコア機能とは別のものです。まず最もシンプルなインターフェースを構築し、その後、より高度な UI を追加のストーリーとして実装します。

エージェントの質問： 「エピックには、コア機能に不可欠ではない高度な UI 要素（日付ピッカー、オートコンプリート、ドラッグ＆ドロップなど）が含まれていますか？」

例：

• 元の内容：「カレンダーの日付ピッカーを使った検索」
• 分割後：
  • ストーリー 1：日付で検索する（基本的なテキスト入力：「YYYY-MM-DD」）
  • ストーリー 2：視覚的なカレンダーピッカー UI を追加する

選択肢：

1. はい、高度な UI 要素があります →「UI の拡張内容を説明してください」
2. いいえ、基本的な UI のみです → パターン 6 に進みます

「はい」の場合： エージェントは、ストーリー 1 を基本的な入力、ストーリー 2 以降を UI の拡張として生成します。

---

パターン 6：大規模な初期作業

重要なポイント： 初期実装に複雑さの大部分があり、追加分は簡単な場合です。「1 つを実装し、残りを追加する」という形にします。

エージェントの質問： 「エピックでは、最初の実装は難しいものの、追加実装は簡単なインフラを構築しますか？」

例：

• 元の内容：「クレジットカード決済（Visa、Mastercard、Amex、Discover）に対応する」
• 分割後：
  • ストーリー 1：Visa 決済に対応する（決済インフラ全体を構築する）
  • ストーリー 2：Mastercard、Amex、Discover への対応を追加する（簡単な追加作業）

⚠️ 注意： 最初のストーリーで大部分の作業（決済ゲートウェイ、セキュリティ、コンプライアンス）を行います。後続のストーリーは小規模な追加になります。

選択肢：

1. はい、大規模な初期作業のパターンです →「最初に実装するものと、追加するものを教えてください」
2. いいえ、インフラの作業はありません → パターン 7 に進みます

「はい」の場合： エージェントは、ストーリー 1 でインフラを構築し、ストーリー 2 で残りのバリエーションを追加する形で生成します。

---

パターン 7：シンプル／複雑

重要なポイント：「最もシンプルな形は何か？」と問いかけ、ストーリーの中核を特定します。バリエーションを切り分けて、個別のストーリーにします。

エージェントの質問： 「このエピックで、価値を提供できる最もシンプルな形は何ですか？複雑さを取り除き、後から追加できますか？」

例：

• 元のストーリー：「フライト検索（最大乗り継ぎ回数、近隣空港、柔軟な日程を含む）」
• 分割後：
  • ストーリー 1：基本的なフライト検索（出発地、目的地、日付）
  • ストーリー 2：最大乗り継ぎ回数のフィルターを追加
  • ストーリー 3：近隣空港のオプションを追加
  • ストーリー 4：柔軟な日程のオプションを追加

選択肢：

1. 最もシンプルな中核を特定できる →「最もシンプルな形と、後回しにするバリエーションを説明する」
2. すでにシンプルである → パターン 8 に進む

**「はい」の場合：**エージェントは、ストーリー 1 に最もシンプルな中核、ストーリー 2 以降にバリエーションを生成します。

---

パターン 8：パフォーマンスを後回しにする

重要なポイント：「動作させること」と「高速化すること」を分けます。非機能要件（パフォーマンス、セキュリティ、スケーラビリティ）は、機能を提供した後に対応できます。

エージェントの質問： 「まず機能的な価値を提供し、その後でパフォーマンス、セキュリティ、スケーラビリティを最適化できますか？」

例：

• 元のストーリー：「応答時間 100ms 未満のリアルタイム検索」
• 分割後：
  • ストーリー 1：検索が動作する（機能要件。パフォーマンスの保証なし）
  • ストーリー 2：検索を 100ms 未満に最適化する（キャッシュとインデックスを追加）

選択肢：

1. 最適化を後回しにできる →「機能的な形と、必要な最適化を説明する」
2. パフォーマンスが不可欠である → パターン 9 に進む

**「はい」の場合：**エージェントは、ストーリー 1 に機能、ストーリー 2 に最適化を生成します。

---

パターン 9：スパイクを切り出す

重要なポイント：****不確実性によって分割できない場合の最終手段です。調査に時間枠を設けて具体的な疑問に答え、その後、理解を深めたうえで実装ストーリーを分割します。

エージェントの発言： 「パターン 1〜8 のいずれにも当てはまらないため、不確実性が高いと考えられます。分割する前に、スパイクを実施して不確実性を減らしましょう。」

スパイクとは、時間枠を設けた調査（ストーリーではありません）で、次のような疑問に答えるものです：

• これは技術的に実現可能ですか？
• どのアプローチが最も高いパフォーマンスを発揮しますか？
• API は実際に何を返しますか？

エージェントの質問： 「このエピックの分割を妨げている、最大の不明点は何ですか？」

選択肢：

1. 技術的な実現可能性 —「現在の技術スタックで構築できますか？」
2. アプローチの不確実性 —「解決方法が複数あり、どれが最適か不明です」
3. 外部依存関係 —「サードパーティ API が何を提供するか分かりません」

エージェントの推奨： →「[質問]に答えるため、1〜2 日間のスパイクを実施します。スパイクの後に戻ってきて、理解を深めたうえでエピックを分割しましょう。」

⚠️ スパイクで得られるのは学びであり、リリース可能なコードではありません。スパイクの後はパターン 1 からやり直してください。

---

ステップ 3：分割の品質を評価する

分割後、次の基準を使って評価します：

エージェントの質問：

1. この分割によって、優先度を下げるか削除できる、価値の低い作業が明らかになりますか？

• 良い分割は、80/20 の法則を明らかにします。価値の大部分は、機能の一部に集中しています。
• 例：「フライト検索」を 4 つのストーリーに分割した結果、「柔軟な日程」はほとんど使われないと分かる → 優先度を下げるか、削除する

2. この分割によって、サイズがより均等なストーリーになりますか？

• サイズが均等なストーリーにすることで、プロダクトオーナーは優先順位を柔軟に付けられます。
• 例：10 日間のエピック 1 つではなく、2 日間のストーリー 5 つにすれば、スプリントの途中でも順序を変更できます。

どちらの基準も満たさない場合は、別のパターンを試してください。

---

メタパターンの適用

すべてのパターンで、次の順序に従います：

1. 中核となる複雑さを特定する — このエピックを難しくしているものは何ですか？
2. バリエーションを列挙する — どのような方法、ケース、ルールがありますか？
3. 完結した最小のスライスに絞る — エンドツーエンドの価値を提供できる、最もシンプルなバリエーションを選びます。
4. その他のバリエーションを個別のストーリーにする

---

Cynefin ドメインに関する考慮事項

複雑さのドメインに応じて戦略を切り替えます：

エージェントの質問： 「このエピックには、どの程度の不確実性がありますか？」

選択肢：

1. 不確実性が低い（自明／煩雑なドメイン） — 「何を作るべきかは分かっています。あとはエンジニアリング作業だけです」 → すべてのストーリーを洗い出し、価値／リスクに基づいて優先順位を付けます

2. 不確実性が高い（複雑なドメイン） — 「顧客が何を求めているのか、何がうまくいくのか分かりません」 → 学習ストーリーを1～2件特定し、網羅的な列挙は避けます（作業を通じて重要なことが分かります）

3. 混沌 — 「すべてが炎上しており、優先順位が毎日変わります」 → 安定するまで分割を延期し、まず安定化に注力します

---

出力：ストーリーの分解を生成

# Epic Breakdown Plan

**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]

---

## Story Breakdown

### Story 1: [Title] (Simplest Complete Slice)

**Summary:** [User-value-focused title]

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

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

**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]

---

### Story 2: [Title] (First Variation)

[Repeat...]

---

### Story 3: [Title] (Second Variation)

[Repeat...]

---

## Split Evaluation

✅ **Does this split reveal low-value work?**
- [Analysis: Which stories could be deprioritized/eliminated?]

✅ **Does this split produce equal-sized stories?**
- [Analysis: Are stories roughly equal in effort?]

---

## INVEST Validation (Each Story)

✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each

---

## Next Steps

1. **Review with team:** Do PM, design, engineering agree?
2. **Check for further splitting:** Are any stories still >5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.

---

**If stories are still too large, re-apply patterns starting at Pattern 1.**

---

例

例1：パターン1の適用（ワークフローのステップ — エンドツーエンドで薄く分割）

エピック：「ブログ記事を公開する（編集レビュー、法務承認、ステージングが必要）」

分割前の検証： ✅ INVEST に合格

パターン1：「ワークフローのステップがありますか？」→ はい ✅

❌ 誤った分割（ステップごと）：

1. 編集レビューのストーリー
2. 法務承認のストーリー
3. 公開のストーリー → 問題：ストーリー1では価値を提供できません（ユーザーには何も見えません）

✅ 正しい分割（エンドツーエンドで薄く分割）：

1. 記事を公開する（シンプルな経路） — 作成者がアップロードすると、すぐに記事が公開されます（レビューなし）
2. 編集レビューを追加する — 記事は公開前に編集者の承認を待つようになります
3. 法務承認を追加する — 記事は公開前に法務と編集者の両方の承認を待つようになります

これがうまくいく理由： 各ストーリーが、洗練度を段階的に高めながら、完全なワークフローを提供します。

---

例2：パターン2の適用（CRUD 操作）

エピック：「ユーザープロフィールを管理する」

パターン2：「『管理する』と書かれていますか？」→ はい ✅（CRUD を示しています）

分割：

1. ユーザープロフィールを作成する
2. ユーザープロフィールの詳細を表示する
3. ユーザープロフィール情報を編集する
4. ユーザープロフィールを削除する

分割の評価：

• ✅ 価値の低い作業が明らかになります： 分析の結果、「プロフィールの削除」はほとんど使われないことが分かりました → 優先順位を下げます
• ✅ ストーリーのサイズが均等です： それぞれ1～2日です

---

例3：パターン7の適用（シンプル／複雑）

エピック：「経由地の最大数、近隣空港、柔軟な日程に対応した航空券検索」

パターン7：「最もシンプルなバージョンは何ですか？」→ 基本検索 ✅

分割：

1. 基本的な航空券検索（出発地、目的地、日付）— 中核となる価値
2. 経由地の最大数フィルターを追加する — 機能強化
3. 近隣空港のオプションを追加する — 機能強化
4. 柔軟な日程のオプションを追加する — 機能強化

分割の評価：

• ✅ 価値の低い作業が明らかになります： ユーザー調査の結果、「柔軟な日程」はほとんど使われないことが分かりました → 削除するか、延期します
• ✅ ストーリーのサイズが均等です： ストーリー1は3日、ほかはそれぞれ1日です

---

例4：反復的な分割（複数のパターン）

エピック：「割引（会員、VIP、初回利用者）と決済（Visa、Mastercard、Amex）に対応したチェックアウトフロー」

第1段階 — パターン1（ワークフロー）： はい ✅

• ストーリー1：商品をカートに追加する
• ストーリー2：割引を適用する
• ストーリー3：決済を完了する

ストーリー2（「割引を適用する」）を確認： まだ4日かかります → 大きすぎるため、再分割します

ストーリー2をパターン3（ビジネスルール）で第2段階の分割： はい ✅

• ストーリー2a：会員割引（10%）を適用する
• ストーリー2b：VIP 割引（20%）を適用する
• ストーリー2c：初回利用者割引（5%）を適用する

ストーリー3（「決済を完了する」）を確認： まだ5日かかります → 大きすぎるため、再分割します

ストーリー3をパターン6（主要な労力）で第3段階の分割： はい ✅

• ストーリー3a：Visa 決済を受け付ける（決済インフラを構築する）
• ストーリー3b：Mastercard と Amex のサポートを追加する

最終的な分解： 6つのストーリーで、すべて1～2日です

---

よくある落とし穴

落とし穴1：分割前の検証を省略する

症状： INVEST を確認せず、すぐに分割を始めてしまいます

結果： 分割すべきでないストーリーを分割してしまいます（例：価値がない＝技術的なタスク）

対策： ステップ2（分割パターン）の前に、必ずステップ1（INVEST チェック）を実行します

---

落とし穴 2：ワークフローを段階的に分割する（パターン 1 の誤った適用）

症状： ストーリー 1 =「編集レビュー」、ストーリー 2 =「法務承認」

結果： ストーリーがエンドツーエンドの価値を提供できません

対策： 各ストーリーで、段階的に高度化させながら、ワークフロー全体（エンドツーエンドの薄いスライス）をカバーします

---

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

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

結果： どちらのストーリーもユーザー価値を提供できません

対策： 垂直分割を行います。各ストーリーにフロントエンドとバックエンドの両方を含め、ユーザーが確認できる動作を実現します

---

落とし穴 4：適合しないパターンを無理に当てはめる

症状：「順序がないのに、ワークフローで分割します」

結果： 恣意的で意味のない分割になります

対策： パターンが適用できない場合は、NO と答えて次のパターンに進みます

---

落とし穴 5：大きなストーリーを再分割しない

症状： エピックを 3 つのストーリーに分割したものの、それぞれが依然として 5 日以上かかる

結果： スプリントには大きすぎるストーリーになります

対策： すべてのストーリーが 1～5 日になるまで、大きなストーリーごとにパターン 1 から再開します

---

落とし穴 6：分割の評価を無視する（ステップ 3）

症状： 分割しても、価値の低い作業が明らかになったかを評価しない

結果： 無駄をなくす機会を逃します

対策： 分割した後、「この分割で、なくしたり先送りしたりできる作業が明らかになりましたか？」と確認します

---

実践とスキルの習得

Humanizing Work の推奨事項： チームは、複数回の練習を通じて 2.5～3 時間でスキルを習得できます。

練習方法：

1. 最近完了した機能を分析する（後から振り返ることで、パターンが明確になります）
2. 完了した作業をフローチャートに沿って確認する — どのパターンが適用できたでしょうか？
3. 各機能について、複数の分割方法を見つける
4. ドメイン固有のパターン例を共有するための共通用語を構築する

練習を省略しないでください。スキルは、今後の作業を改善するだけでなく、過去の成果物を分析することで身につきます。

---

参考資料

関連スキル

• user-story-splitting.md — 9 つのパターンの詳細
• user-story.md — ストーリーを記述するための形式
• epic-hypothesis.md — 元のエピック形式

外部フレームワーク

• Richard Lawrence、Peter Green 著、『The Humanizing Work Guide to Splitting User Stories』 — 方法論の全容
• Bill Wake 著、『INVEST in Good Stories』（2003 年）— 品質基準

出典

• https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/

---

スキルの種類： インタラクティブ 推奨ファイル名： epic-breakdown-advisor.md 推奨配置場所： /skills/interactive/ 依存関係： user-story-splitting.md、user-story.md、epic-hypothesis.md を使用