Story Generation Plan — continuum

Project: continuum Phase: INCEPTION — User Stories (Part 1: Planning) Date: 2026-05-08

目的

要件定義書（aidlc-docs/inception/requirements/requirements.md）の内容を、ユーザー中心のストーリーと受入基準（Acceptance Criteria）に変換する。Phase 2 MVP（5/30 予選会）と Phase 3 決勝（6/26 AWS Summit Japan）のスコープを明確に区別する。

Story Generation Methodology Options

ストーリー分解アプローチを以下から選択していただきます。

Option A: User Journey-Based（ユーザー行動フローに沿う）

• ユーザーが Onboarding → 初回利用 → Maturity Phase 進行 → 決勝シナリオ（MACP）まで、時系列の利用フローでストーリーを構成
• メリット: ハッカソンデモのストーリーボード作成が直結する、デモ動画の流れと同期
• デメリット: 同一機能でも複数ジャーニーで再登場

Option B: Feature-Based（機能単位でストーリーをグループ化）

• FR-1 〜 FR-9 の機能単位でストーリーを束ねる（Inbound 機能群 / Outbound 機能群 / Maturity 機能群 / MACP 機能群 / Dashboard 機能群）
• メリット: requirements.md と 1対1 対応、Application Design への橋渡しが容易
• デメリット: ユーザー体験の流れが分散

Option C: Persona-Based（ペルソナ別にストーリーを整理）

• Primary ユーザー / 観察者（審査員） / コンタクト（モック）/ MACP 相手ユーザーの視点でストーリーを分類
• メリット: 各ペルソナの動機・期待値が明確化される
• デメリット: 実装単位での粒度が見えにくい

Option D: Hybrid (User Journey + Maturity Phase)

• メインアクシスはユーザージャーニー、サブアクシスは Maturity Phase（Lv1 → Lv5）の進行
• Phase ごとに変化するユーザー体験（同じ「応答」アクションでも Lv によって体験が違う）を立体的に表現
• メリット: 5フェーズ × 機能の組み合わせを系統的にカバー、ハッカソンデモとも整合
• デメリット: ストーリー数が多くなる

Option E: Epic-Based（階層化された Epic + Sub-stories）

• 大 Epic（例: "Inbound Communication Delegation"）配下に複数の sub-stories
• メリット: スコープの粗⇄細を切り替えやすい、MVP / Stretch の判別容易
• デメリット: 階層管理の手間

Mandatory Story Artifacts（必須生成物）

• aidlc-docs/inception/user-stories/stories.md — INVEST 基準準拠のユーザーストーリー集（38件 = 34 implementation + 4 Demo Set Piece）
• aidlc-docs/inception/user-stories/personas.md — ペルソナ集（7名: P1 Hiroki / P2 Asuka / M1〜M4 / F1 Sasaki）
• 各ストーリーは Independent / Negotiable / Valuable / Estimable / Small / Testable（INVEST 準拠チェックを stories.md 末尾に明記）
• 各ストーリーに受入基準を記載（Q4=A 採用: Gherkin Given-When-Then 形式）
• 各ストーリーに 5区分スコープラベル を付与（Q7=B 採用: Phase 1 / Phase 2 Must / Phase 2 Should / Phase 3 Must / Phase 3 Stretch）
• ペルソナとストーリーのマッピング（stories.md 内に Persona × Story Mapping 表）

Step-by-Step Execution Plan（Part 2 で実行）

• Step 1: Personas の生成（personas.md）— 7名（P1, P2, M1〜M4, F1）
• Step 2: ストーリー分解アプローチの適用（Feature-Based 7グループ + Demo Set Piece）
• Step 3: 全 FR（FR-1〜9）に対応する 34 implementation stories + 4 Demo stories = 38 stories 生成
• Step 4: 全ストーリーに Gherkin Given-When-Then 受入基準付与
• Step 5: 5区分スコープラベル付与（Phase 2 Must=18 / Phase 2 Should=3 / Phase 3 Must=13 / Phase 3 Stretch=4 / Phase 1=未使用）
• Step 6: Persona × Story Mapping 表生成
• Step 7: MACP デモ用 Demo Set Piece を独立セクション（DS-1〜DS-4）として記載
• Step 8: ハッカソン審査ペルソナは Q6 で除外、本ステップはスキップ
• Step 9: stories.md と personas.md の最終出力完了

質問（Embedded Questions）

以下の質問にお答えください。各質問の [Answer]: タグの後に該当する選択肢の文字を記入してください。

Question 1: ストーリー分解アプローチ

要件をストーリーに変換する際の分類軸を選択してください。

A) User Journey-Based — ユーザー利用フローに沿う B) Feature-Based — FR 単位でグループ化 C) Persona-Based — ペルソナ別に整理 D) Hybrid (User Journey + Maturity Phase) — メイン: ジャーニー × サブ: Maturity Phase 進行 E) Epic-Based — 階層化 Epic + Sub-stories F) Other (please describe after Answer: tag below)

Question 2: ストーリー粒度

ストーリーの粒度をどの程度にしますか？

A) 大粒度（Epic レベル） — 1ストーリー = 1機能領域（FR-2 全体 / FR-8 全体 等）。Application Design で詳細化 B) 中粒度（Feature レベル） — 1ストーリー = 1独立した機能単位（"Inbound 応答3案生成"、"Strategic Outreach Window 検出" 等）。バランス重視 C) 細粒度（Task レベル） — 1ストーリー = 1ユーザー操作（"3案から1案選択"、"案を編集" 等）。実装直結 D) Other (please describe after Answer: tag below)

Question 3: ストーリー記述フォーマット

ユーザーストーリーの記述形式は？

A) Connextra 形式 — "As a [persona], I want [action], so that [benefit]"（業界標準） B) Job Stories 形式 — "When [situation], I want to [motivation], so I can [outcome]"（コンテキスト重視） C) Connextra + 補足コンテキスト — Connextra を基本に Notes/Context セクションを併記（推奨） D) Other (please describe after Answer: tag below)

Question 4: 受入基準（Acceptance Criteria）の記述形式

各ストーリーの受入基準は？

A) Given-When-Then 形式（Gherkin） — 自動テストへの橋渡し容易 B) 箇条書きチェックリスト — シンプル・読みやすい C) Definition of Done（DoD）+ ふるまい例 — DoD で完了基準、ふるまい例で確認シナリオ D) Other (please describe after Answer: tag below)

Question 5: ペルソナ深度

ペルソナの記述深度は？

A) ライト（Demographic + 主要ニーズのみ） — 名前・年齢・職業・主要な動機を1段落程度 B) スタンダード（+ 心理プロファイル + 利用シナリオ） — Pain Point / Goal / Behavior / Quote を含む詳細プロファイル C) 詳細（+ ジャーニーマップ + ペルソナ間関係性） — 全フィールド + ジャーニー図 + 他ペルソナとの相互作用 D) Other (please describe after Answer: tag below)

Question 6: 含めるペルソナの範囲

どのペルソナを定義しますか？（複数選択可 — 該当する選択肢を複数記入）

A) Primary User（Continuum 利用者：社会人 SNS疲れ層） — 必須 B) Mock Contacts（ダミー友人・家族・職場関係） — Inbound/Outbound の対象として C) MACP Counterpart（もう一人の Continuum 利用者） — FR-9 の演出のため D) Hackathon Judge（ハッカソン審査員） — プロダクト観察者・遅効性ツッコミ体験者 E) Demo Video Viewer（デモ動画視聴者） — マーケティング視点 F) AI Agent（システム自身） — エージェントの "意図" を擬人化したペルソナ（実験的） G) Other (please describe after Answer: tag below)

Question 7: スコープラベルの粒度

各ストーリーへのスコープ印付けは？

A) 3区分: Phase 2 MVP / Phase 3 Stretch / Out-of-Scope B) 5区分: Phase 1 (Inception 提出物のみ) / Phase 2 Must / Phase 2 Should / Phase 3 Must / Phase 3 Stretch C) Priority + Phase: 各ストーリーに P0/P1/P2 + Phase 2/3 を併記 D) Other (please describe after Answer: tag below)

Question 8: ハッカソン Set Piece（MACP デモ）の扱い

FR-9.8 で定義した決勝デモの 6 ステップ Set Piece は、ストーリーとして？

A) 独立した "Demo Story" として記載 — 通常ストーリーと別枠で「デモ演出」セクションに集約 B) 通常ストーリーに溶け込ませる — Set Piece 各ステップを通常ストーリーに分散 C) 両方 — 通常ストーリー + 独立した Demo Story の両方で記載 D) Other (please describe after Answer: tag below)

Question 9: "真面目にバカ" のストーリー記述トーン

ストーリー記述自体（"As a 〜, I want 〜" 部分）のトーンは？

A) 完全に真面目な生産性 SaaS 体 — "As a busy professional, I want to optimize my communication overhead, so that I can reclaim cognitive resources"（プロダクト体裁を保つ） B) メタ視点を含む明示的記述 — "As a SNS疲れ社会人, I want AI に断りを丸投げしたい, so that 友人関係を表面的に維持しつつ実態は疎遠化できる"（実態を直接記述） C) 混合: 公式ストーリーは真面目、Notes/Context セクションで実態を併記（推奨：Deadpan Absurdism と整合） D) Other (please describe after Answer: tag below)

Question 10: ストーリー数の目安

全体のストーリー数の目安は？

A) コンパクト（〜20件） — Epic レベル中心、ハッカソン用に必要最小限 B) スタンダード（〜40件） — 各 FR を 3-5 ストーリーに分解、バランス重視 C) 網羅的（〜70件） — 細粒度、すべての受入基準パターンをカバー D) Other (please describe after Answer: tag below)

Question 11: 応募締切（5/10）への対応方針

応募締切まで残り2日です。User Stories ステージを：

A) 通常通り実施 — Part 1（質問→回答→承認）+ Part 2（生成→承認）を順次実行。Inception 完了は 5/15 を目指す B) 加速モード — 質問数を絞り込み、デフォルトの妥当な選択肢で進める。応募 5/10 までに必要最小限の Inception ドキュメントを揃える C) 超加速モード — 全質問を AI 推奨で進め、ユーザーレビューは生成物のみ。応募締切前に大筋を完成させる D) Other (please describe after Answer: tag below)

Approval Required

すべての質問に回答後、「完了」または「done」 とお知らせください。回答内容を分析し、矛盾・曖昧さを検出した場合はクラリフィケーション質問ファイルを作成、矛盾なしの場合は本プランの承認をお願いします。承認後、Part 2（stories.md, personas.md の生成）に進みます。