story-splitting

ストーリーの分割

チームが小さな単位で提供、テスト、学習し、方向転換できるように作業を分割します。優れた分割では、ユーザーから見える機能をひとまとまりに保ちながら、ばらつき、不確実性、範囲、または品質レベルを抑えます。

目標は「チケットを小さくする」ことではありません。目指すのは、システム全体の100％をN％完成させることではなく、システムのN％を100％完成させ、実演できる状態にすることです。

クレジット

このスキルは、Tim Ottinger の ストーリーの分割 - リソース一覧を基にしており、Tim Ottinger、Bill Wake、Joshua Kerievsky、Gojko Adzic、Neil Killick、George Dinwiddie、Mike Cohn、Richard Lawrence、Peter Green、J. B. Rainsberger、Rachel Davies などによる、リンク先のストーリー分割に関する執筆内容をまとめています。出典ごとの来歴については、resources/source-notes.mdを読み込んでください。

詳細な資料はresources/ディレクトリにあります。必要に応じて読み込んでください。

リソース	読み込むタイミング
pattern-catalog.md	分割のための問いかけをさらに知りたいとき、SPIDR／ハンバーガー／Humanizing Work／Bill Wake のパターンの詳細や、分割が難しいストーリーの例が必要なとき
source-notes.md	出典の来歴を確認したいとき、概念を教えたいとき、または記事やリソース一覧のアイデアがこのスキルにどう反映されたか説明したいとき

他のスキルとの連携

入力が大きなストーリー、エピック、機能のアイデア、ロードマップ項目、またはバックログ項目である場合は、planningより前にstory-splittingを使用してください。このスキルでは、価値のある小さな子ストーリーを見つけます。その後、planningスキルで選んだ子ストーリーを、エビデンスと提供の詳細を含む実装スライスに順序付けます。

リポジトリの実装方法やプルリクエストのワークフローにかかわらず、ストーリーの境界は垂直に保ってください。データベース、API、UI、テストを別々のバックログ項目にしてはいけません。

分割や計画ができた後で、不足している状態、受け入れ基準、エッジケース、または検証できない表現を詰める必要がある場合は、find-gapsを使用してください。find-gapsで計画が依然として水平分割されている、または大きすぎると分かった場合は、ここに戻って再度分割してください。

未解決のプロダクトや設計上の意思決定には、インストールされている場合はgrill-meを使用し、分割の手法には使用しないでください。利用できない場合は、specificationを使用して、このスキルがスライスを提案する前後に、焦点を絞った質問を一度に1つずつ行ってください。

作業が複数のUXサーフェスやモック状態にまたがる場合は、storyboardを使用してください。ストーリーボードによって、子ストーリーとなる不足画面やフロー上の抜けが見つかることがあります。shape、critique、polishなどのデザインスキルは、モック自体を改善するために使用し、プロダクトのスライスの代わりにはしないでください。

このスキルの範囲は、プロダクトの分割までです。実装ワークフロー、TDD、ミューテーションを行うタイミング、フィーチャーフラグの方針、PR前のゲート、ブランチ構成、提供の仕組みについては、プロジェクトの指示と関連するインストール済みスキルに委ねてください。ストーリーの分割は、ローカルでのミューテーション実行やフィーチャーフラグを必須にも禁止にもしていません。ドメインやアーキテクチャのスキルは、選択したストーリーが実装段階に入ったときにのみ使用してください。こうした技術レイヤーごとにストーリーを分割してはいけません。

要件の洗練パイプライン

不確実性に合致する最も早い段階のスキルを使用します。

問題が次の場合は…	使用するスキル…	次の状態になったら終了…
「どの意思決定の分岐が正しいのか分からない」	grill-me がインストールされていればそれを、そうでなければ specification	意思決定ツリーが解決済み、または未決事項が明示されている
「要件の範囲が広すぎる、または解決策ありきになっている」	story-splitting	それぞれ独立して価値のある子ストーリーができている
「このストーリー／仕様／計画／モックに抜けがある」	find-gaps	テスト可能な表現で成果物が更新され、確認済みである
「子ストーリーを選び、その実装が必要」	planning	スライスごとの提供形態を含む実装スライスができている
「選択した子ストーリーの実装順序を決める必要がある」	プロジェクトの計画／デリバリースキル	リポジトリの規約に準拠した実装・デリバリー計画ができている

すべての製品上の意思決定を最初から問いただすために story-splitting を使わないでください。意思決定ツリーの作成が本来の作業である場合は、任意の grill-me スキル、または代替の specification を使ってください。実装タスクを作成するために story-splitting を使わないでください。子ストーリーを選択した後に planning を使ってください。確認対象となる成果物がまだない段階で find-gaps を使わないでください。分割案、計画、受け入れ基準のセット、またはモック仕様の強化に使ってください。

基本原則

ストーリーは要件ではなく対話です

ストーリーは、課題を抱える人と解決できる人との協力のためのプレースホルダーとして扱います。完璧な文書要件や、プロダクトからエンジニアリングへの引き継ぎを目指さないでください。

ストーリーが大きすぎると思われる場合は、プロダクト、エンジニアリング、デザイン、QA、運用の視点を分割に取り入れてください。プロダクトは価値とトレードオフを把握しています。エンジニアは労力と不確実性が潜んでいる箇所を把握しています。両方の視点を取り入れずに分割すると、価値の低い断片か、技術的な依存関係が生じがちです。

次を優先します。

Buyer can pay one invoice by card and receive a confirmation.

次は避けます。

Backend exposes payment endpoint.
Frontend calls payment endpoint.
Database stores payment rows.

タスクはストーリー内に含めることができます。計画を段階的に見せるために、タスクをストーリーと呼び替えないでください。

まず課題の領域にとどまります

次のように問いかけます。

What are the simplest options for delivering value to the customer as soon as possible?

次のように始めないでください。

What is the simplest way to build this already-imagined solution?

最初の質問では、顧客に提供できる機能の選択肢が明らかになります。2つ目の質問では、チームが価値のある機能を絞り込む前に、ポータル、アプリ、サービス、ベンダー、アーキテクチャの話へ飛躍しがちです。

まず最小の全体像から始めます

洗練された部分より、小さくてもエンドツーエンドで動く全体を優先します。最初のバージョンとして有用なのは、機能を絞った垂直スライス、構造的に組み合わされていない経路、内部限定の機能、または使い捨てであることを明示したトレーサーなどです。

この最初のスライスでは、可能な限り実際の動作経路を通します。リリース上の制約を正直に記述してください。機能フラグ、別のリリース方式、または一切隠さない方式のどれを使うかは、プロジェクトのポリシー上の判断です。使い捨ての作業には、スパイクまたはトレーサー実験であることを明示してください。

お得な選択肢を探します

お得な選択肢とは、わずかなコストで高い価値が得られるものです。想定している機能の4分の1で、価値や学びの大半を得られるスライスを探してください。親ストーリーは草案として扱い、対話を通じて、より低コストで優れた方法を見つける余地を残してください。

子ストーリーの品質基準

INVEST はテンプレートではなく、品質チェックとして使います。

文字	チェック項目
I	すべての兄弟ストーリーを待たずに、十分に独立して開発、テスト、リリース、順序変更、または破棄できる
N	範囲と品質レベルについて交渉の余地があり、固定された解決順序になっていない
V	実際のユーザー、外部システム、ビジネス関係者、運用担当者、または学習目標に価値をもたらす
E	挙動、不確実な点、先送りする内容が明確で、見積もりが可能である
S	目標とする計画期間内に完了できる規模である
T	観察可能な例を通じてテストできる

また、フィードバックの3要素も適用します。優れたスライスは、機能し、価値をもたらし、ユーザーフィードバックを得られるものです。内部的な進捗しか生まないのであれば、おそらくタスクです。機能してもフィードバックや学びを得る可能性がない場合は、より薄いスライスや別のスライスのほうが有用ではないか検討してください。

ワークフロー

1. 親ストーリーを言い換える

分割する前に、親ストーリーを平易な言葉で記述します。

• アクター： 誰が価値を受け取るか
• ニーズまたは能力： 何ができる、または何が学べるか
• 成果： なぜそれが重要なのか
• 現在の制約： なぜ規模が大きすぎる、リスクが高い、曖昧、または不確実なのか

親ストーリーが「オンラインバンキングポータルを構築する」のようなソリューションを表す表現であれば、「顧客が請求書を支払える」「顧客が送金できる」「顧客が残高を確認できる」といった能力に言い換えます。

親ストーリーが「決済データベースを追加する」のような技術タスクであれば、それが支えるユーザーの行動を見つけます。対応する行動がない場合はタスクとして残し、重要性を示す最初のストーリーにひも付けます。

2. 具体例とバリエーションを洗い出す

チケットを考案する前に、具体例を列挙します。

• 正常系の例
• 代替経路とエラー経路
• ユーザーの役割や顧客セグメント
• データの形式、サイズ、境界条件
• ビジネスルールとポリシーのバリエーション
• インターフェース、チャネル、デバイス、連携先
• 品質特性：パフォーマンス、規模、信頼性、セキュリティ、アクセシビリティ、監査可能性
• 計画を無効にする可能性のある不明点や前提

受け入れ例は、自然な分割点となることがよくあります。関連する例を、各グループがそれぞれ独立して理解・テストできる場合は、別々のストーリーにまとめます。

3. 分割の観点を見つける

これらの観点をヒントとして使い、最も価値と選択の余地を生み出す分割方法を選びます。

観点	有用な問い
能力	より狭くても価値をもたらす、顧客の能力はどれか？
経路	単独で成り立つ正常系、代替経路、ワークフローの分岐、または操作はどれか？
インターフェース	挙動を最初に実証できるチャネル、利用者、UI レベル、デバイス、ブラウザー、または連携先はどれか？
データ	最初にサポートできるデータのサブセット、ファイル形式、エンティティの種類、フィールドのサブセット、または数量はどれか？
ルール	安全に範囲を限定できるビジネス、検証、権限、コンプライアンス、またはポリシーのルールはどれか？
品質	許容できる最もシンプルな品質レベルは何か？ 手動、バッチ、低忠実度、小規模、低速、汎用 UI など。
リスク	特定のリスクの高い不明点を解消するには、どのスパイク、トレーサーバレット、またはウォーキングスケルトンが有効か？

ストーリーを考える際にさらにヒントが必要な場合や、SPIDR、Hamburger、Humanizing Work のパターン、Bill Wake の 20 の方法など、名前の付いた手法を適用する場合は、resources/pattern-catalog.md を読み込みます。

4. チームが行き詰まったら、ハンバーガー法を使う

チームが技術的な分解に何度も流れてしまう場合は、resources/pattern-catalog.md にあるハンバーガー法を使います。技術レイヤーを列挙し、各レイヤーについてシンプルなものから機能豊富なものまでの選択肢を挙げてから、すべてのレイヤーを横断する最初の「ひと口」を作り、成果がエンドツーエンドになるようにします。特定のレイヤーだけを進めないことが目的です。

5. 最初のスライスを選ぶ

次の経験則を参考に、最初のスライスを選びます。

• チームが少なくとも1つの後続ストーリーの優先度を下げる、または削除できる分割を優先します。
• 価値が同程度なら、サイズがより均等な子ストーリーになる分割を優先します。
• 価値とコストの比率が最も高いスライスを優先します。
• 統合リスクやアーキテクチャ上のリスクを早期に減らせる、エンドツーエンドのスライスを優先します。
• 複雑な領域では、最初からバックログ全体を列挙したふりをするのではなく、役に立つ学習用スライスを1つか2つ選びます。
• 最初のスライスが誰にとっても役に立たない場合は、学習、運用、サポート、または検証に役立つものにし、そのことを明記します。

6. 子ストーリーを書く

各子ストーリーには、次の内容を記載します。

• タイトル： アクター＋アクション＋限定された範囲
• 価値： 誰がどのような恩恵を受けるか
• 範囲： 含まれる内容
• 意図的な先送り事項： 現時点では含めない内容とその理由
• 受け入れ例： 具体的な事前条件 → トリガー → 観測可能な結果の例（または同等のテスト可能な例）
• リリース制約： プロジェクトの方針に応じて、リリース可能、内部専用、デモ専用、使い捨て、またはその他の制約とその理由
• 後続ストーリー： パス、インターフェース、データ、ルール、または品質を追加するストーリー

ユーザーのドメイン用語を使います。「buyer」と言われたら、「user」ではなく「buyer」と書きます。

検証チェックリスト

分割案を返す前に、各子ストーリーを確認します。

• 実在するアクターまたは外部システムが記載されていますか？
• トリガーと観測可能な結果がありますか？
• その振る舞いに必要な実際の本番経路を通っていますか？
• すべての兄弟ストーリーを待たずにテストできますか？
• リリース、デモ、または実行によって、フィードバック、学習、または目に見える意思決定につながりますか？
• 後続ストーリーが一切なくても、価値または学びを提供できますか？
• 依存関係が明確で、管理可能な規模ですか？
• 先送りするパス、データ、ルール、品質が明示されていますか？
• 安全にリリースできますか？そうでなければ、リリース制約が明示されていますか？
• 不要な実装の詳細を指定していませんか？
• 有用な後続スライスを見落とさないよう、最終的に実現する機能全体が見えていますか？

危険信号：

• デザイン、コーディング、テスト、ドキュメント作成、デプロイなど、プロセス上の作業ごとに子ストーリーを分割している
• 「データベース／API／フロントエンド／サービスとして」
• 「バックエンドを構築する」と「フロントエンドを構築する」を別々のストーリーにしている
• ユーザーに見える結果やフィードバックを生み出す結果がないまま、「データを収集する」または「統合を構築する」としている
• どの子ストーリーも、テストできるようになる前にすべての子ストーリーが完了している必要がある
• すべてのストーリーにスパイクがある
• 受け入れ基準が、観測可能な詳細を伴わず「動作する」「速い」とだけ記載している
• 解決策の詳細を指定するだけの、あまりにも細かなスライス
• 議論せずに、すべてのビジネスルールを最初のスライスに詰め込んでいる

出力形式

ストーリーの分割を求められた場合は、planning に直接取り込める簡潔な成果物を返します。

## Parent
[Reframed parent capability]

## Recommended First Slice
[One sentence story]

Why this first: [value, risk, learning, or bargain]

## Split Candidates
| Slice | Value | Includes | Defers | Acceptance Examples | Release Constraint |
|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... |

## Parking Lot
[Explicit follow-ups, questions, or intentionally unsplit tasks]

## Warnings
[Component splits, unsafe deferrals, unclear ownership, or missing examples]

## Next Step
[Use the project's planning and delivery instructions for the selected first slice, run `find-gaps` on the split when available, or ask one decision question. Do not prescribe TDD, mutation timing, feature flags, or pre-PR gates here.]

ユーザーが対話形式でのブラッシュアップを希望する場合は、質問を一度に1つだけ尋ね、質問票をまとめて提示しないでください。分割案を最も大きく左右する質問から始めます。通常は、アクター、成果、リリース制約、最も価値の高い顧客セグメント、または最大のリスクについて尋ねます。

出典情報と記事ごとの概念対応を確認するには、resources/source-notes.md を読み込みます。