story-definition

ストーリー定義

チームが、機能、エピック、要件、アイデアから、明確で実装可能なユーザーストーリーを定義できるよう支援します。接続済みのツールからプロジェクトのコンテキストを取得し、構造化されたフレームワークを適用して、プロジェクトトラッカーにストーリーを直接作成します。

ワークフロー

ステップ 1 — コンテキストを収集する

何を分解する必要があるのかを把握してから、書き始めます。

~~project tracker が接続されている場合：

• 作業するプロジェクトまたはボードをユーザーに尋ねます
• 現在のエピック、ラベル、チームメンバーを取得して、プロジェクトの構成を把握します
• 関連するストーリーや重複するストーリーがないか、既存のバックログを確認します
• コンテキストを把握するため、リンクされた要件、仕様、親エピックを取得します
• プロジェクトで使われている既存の規約（ラベルの分類、ストーリーポイントの尺度、命名パターン）を特定します

プロジェクトトラッカーが接続されていない場合：

• 機能、エピック、または要件について、ユーザーに説明を求めます
• 誰が実装するのか、技術スタック、制約など、チームの状況を尋ねます
• ストーリーの形式に関して、既存の規約があるか尋ねます

必ず尋ねること：

• この作業で達成すべき目標や成果は何ですか？
• 既知の制約（スケジュール、依存関係、技術的制限）はありますか？
• どの程度の粒度が必要ですか？（エピックレベル、スプリント対応、タスクレベル）

ステップ 2 — 分析して分解する

入力を、論理的で実装可能な単位に分解します。

分解の原則：

1. 垂直分割 — 各ストーリーは水平のレイヤーではなく、エンドツーエンドの価値を薄く切り出して提供します。ストーリーは、特定の動作に必要なすべてのレイヤー（UI、API、DB）に関わるものにします。
2. INVEST 基準 — すべてのストーリーは、以下の条件を満たす必要があります。
   • Independent（独立している）— 他のストーリーを待たずに構築して提供できる（依存関係を最小限にする）
   • Negotiable（交渉可能である）— 詳細を話し合えるものであり、厳格な仕様ではない
   • Valuable（価値がある）— ユーザー、ステークホルダー、またはシステムに明確な価値を提供する
   • Estimable（見積もり可能である）— チームが妥当に作業量を見積もれる
   • Small（小さい）— 1 つのスプリント内に収まる（大きすぎる場合は、さらに分割する）
   • Testable（テスト可能である）— 完了したことを確認できる明確な条件がある
3. 依存関係のマッピング — 他のストーリーを妨げるストーリーを特定し、循環依存に注意します
4. リスク優先の順序付け — リスクや不確実性の高いストーリーを早い段階で明らかにし、優先して取り組めるようにします

ストーリーが大きすぎる場合の分割方法：

方法	使用する場面	例
ワークフローのステップごと	複数ステップのプロセス	「ユーザーが商品をカートに追加できる」対「ユーザーがチェックアウトできる」
ビジネスルールごと	複雑なバリデーション	「基本的なバリデーション」対「エッジケースの処理」
データの種類ごと	複数のエンティティタイプ	「CSV の連絡先をインポートする」対「CSV の企業をインポートする」
インターフェースごと	複数のエントリーポイント	「フォームから作成する」対「API から作成する」
操作ごと	CRUD 全体	「一覧を表示する」対「項目を編集する」対「項目を削除する」
ペルソナごと	ユーザータイプの違い	「管理者が設定できる」対「メンバーが表示できる」
正常系／エッジケース	複雑なフロー	「支払いが成功する」対「失敗時に支払いを再試行する」

ステップ 3 — ストーリーを書く

各ストーリーに、次の形式を使用します。プロジェクトの規約と異なる場合は、フィールド名を合わせて調整します。

Title: [Action-oriented, concise — starts with a verb or "As a..."]

User story:
As a [specific persona/role],
I want to [concrete action],
so that [measurable outcome or business value].

Acceptance criteria:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] [Additional criteria using Given/When/Then or plain checkboxes]

Definition of done:
- [ ] Code implemented and passing CI
- [ ] Unit/integration tests covering acceptance criteria
- [ ] Code reviewed and approved
- [ ] [Project-specific DoD items from team conventions]

Technical notes:
- Implementation hints, API contracts, data model changes
- Links to relevant specs, designs, or documentation
- Known risks or open questions to resolve during implementation

Size: [T-shirt (XS/S/M/L/XL) or story points — match project convention]
Priority: [P0-Critical / P1-High / P2-Medium / P3-Low]
Labels: [Use existing project labels when available]
Dependencies: [List story titles or IDs this story depends on]

品質チェックリスト — すべてのストーリーに適用します：

• ボードビューでタイトルをざっと読んで把握できる（80 文字未満）
• 「その結果」には、アクションの言い換えではなく、実際の成果が記載されている
• 受け入れ条件がテスト可能であり、「適切に動作する」のような曖昧な表現がない
• 各受け入れ条件が 1 つの動作を扱っている（複合した条件は分割する）
• 実装者にとって自明でない内容には、技術的な注記がある
• サイズはコード量ではなく、実際の複雑さを反映している
• 隠れた作業がない — ストーリーにマイグレーション、設定変更、ドキュメント更新が必要な場合、それらが明記されている

ステップ 4 — 検証して整理する

ストーリーを提示または作成する前に、品質チェックを行います。

検証項目：

1. 網羅性 — ストーリー全体で機能／エピックを完全に実現できますか？不足している点を特定します。
2. 重複 — 同じ作業を行うストーリーが複数ありませんか？統合するか、境界を明確にします。
3. 依存関係グラフ — ストーリーをビルド可能な順序に並べられますか？循環依存があれば指摘します。
4. スプリントへの適合性 — 各ストーリーは 1 スプリントで完了できる規模ですか？さらに分割が必要なものがあれば指摘します。
5. テスト可能性 — QA はすべての受け入れ条件を曖昧さなく検証できますか？
6. バックログの確認 — ~~project tracker が接続されている場合、既存のストーリーでこの作業がすでにカバーされていないか確認します。

出力を整理する：

• エピックまたは機能領域ごとにストーリーをグループ化します
• 推奨実装順（依存関係が先、その後に優先度）に並べます
• スプリント対応済みのストーリーと、さらに詳細化が必要なストーリーを明確に示します
• 作業範囲の合計をまとめます：ストーリー数、推定総工数、推奨スプリント配分

ステップ 5 — プロジェクト管理ツールで作成する

~~project tracker が接続されている場合：

• チケットを作成する前にユーザーの確認を取ります
• 先に概要テーブルを表示します：

#	タイトル	規模	優先度	依存関係
1	...	S	P1	—
2	...	M	P1	#1

• ユーザーの承認後、接続されたツールで各ストーリーを作成します
• 相談した内容に基づき、ラベル、担当者、スプリント、親エピックを設定します
• 対応している場合、ストーリー間の依存関係リンクを設定します
• 作成したチケットへのリンクを報告します

プロジェクト管理ツールが接続されていない場合：

• 上記の構造化された形式でストーリーを提示します
• ユーザーがツールに貼り付けられるよう、Markdown または書式付きリストでのエクスポートを提案します

ステップ 6 — チームに通知する

~~chat が接続されている場合：

• 新しいストーリーについてチームに通知するか、ユーザーに確認します
• 作成した内容、ストーリー数、推定総工数、ボード／プロジェクトへのリンクをまとめた簡潔なメッセージを作成します
• ユーザーの確認後にのみ投稿します

ストーリーの規模ガイド

プロジェクトで既存の尺度があれば、それを使用します。なければ、次のいずれかを提案します。

T シャツサイズ（見積もりに慣れていないチームにおすすめ）：

サイズ	一般的な作業範囲	例
XS	設定変更、文言の更新、1 行の修正	機能フラグの切り替え、誤字の修正
S	単一コンポーネント、明確な進め方	フォーム項目の追加、既知のパターンに沿った新しい API エンドポイント
M	複数コンポーネント、多少の不確実性	新しい CRUD 機能、ドキュメント化された API との統合
L	横断的な作業、設計上の判断が必要	新しい認証フロー、データ変換を伴うデータ移行
XL	おそらくさらに分割すべき	機能全体の再設計、新しいサービス

フィボナッチストーリーポイント（ベロシティ追跡を行うチーム向け）：

ポイント	相対的な工数
1	ごく簡単 — 数時間
2	小規模 — 1 日以内
3	中程度 — 数日
5	大きな作業 — ほぼ 1 週間
8	大規模 — 1 週間、分割を検討
13	非常に大規模 — 分割必須

優先度の基準

レベル	ラベル	基準	対応
P0	重大	リリースを妨げる、セキュリティ上の問題、データ損失のリスク	即時対応 — 現在のスプリント
P1	高	機能／エピックの目標に不可欠、ユーザーへの影響が大きい	次に空いているスプリント
P2	中	価値のある改善だが、ブロッカーではない	バックログ — キャパシティに余裕があるときに計画
P3	低	あれば便利、仕上げ、軽微な機能強化	バックログ — 計画時に再検討

避けるべきアンチパターン

アンチパターン	問題	解決策
「機能 X を実装する」	ユーザーにとっての価値が示されておらず、受け入れ基準もありません	ペルソナ、成果、テスト可能な基準を追加します
水平分割	「API を構築する」の後に「UI を構築する」では、両方が完了するまで価値を提供できません	垂直に分割し、ひとつの動作をエンドツーエンドで実現します
巨大なストーリー	「ユーザーとして、チェックアウトのフロー全体を利用したい」では、見積もりができません	ワークフローのステップ、操作、またはビジネスルールごとに分割します
曖昧な受け入れ基準	「正しく動作すること」では、テストできません	具体的な入力と出力を用いて、Given／When／Then を使用します
依存関係の不足	前提条件が特定されていないため、ストーリーが失敗します	分解の際に依存関係を明示的に整理します
ゴールドプレーティング	「あるとよい」詳細が中核要件に混在しています	必須の基準と機能強化を分けます
ペルソナの使い回し	すべてに「ユーザーとして」を使うと、文脈が失われます	管理者、メンバー、ゲスト、API 利用者など、具体的な役割を使います