yodogawa 2.1.1 → 2.2.0

package/templates/project/01-requirements/05-user-stories.md

@@ -1,124 +1,28 @@
-# ユーザーストーリー一覧
-
-<!--
-何を書くか: ユーザー視点での機能要求を物語形式で記述したバックログ
-
-目的:
-  - ユーザーの課題とニーズを明確化
-  - 開発チームとステークホルダーの共通理解を構築
-  - 開発優先度の判断材料を提供
-  - スプリント計画の基礎資料として活用
-
-特徴:
-  - ユーザー中心設計: 実装方法ではなく、ユーザーの「なぜ」に焦点
-  - Living Document: 継続的に追加・更新・削除される動的なドキュメント
-  - 会話のきっかけ: 詳細仕様ではなく、議論の出発点として機能
-  - INVEST原則: Independent（独立）、Negotiable（交渉可能）、Valuable（価値）、Estimable（見積可能）、Small（小さい）、Testable（テスト可能）
-
-記載粒度:
-  - 1-2週間のスプリントで完了できるサイズ
-  - 大きすぎる場合はEpicとして分割を検討
-  - 小さすぎる場合は他のストーリーと統合を検討
-
-更新頻度:
-  - バックログリファインメント時に継続的に見直し
-  - スプリント計画前に受け入れ基準を明確化
-  - 実装完了後は完了マークを付けて履歴として保持
--->
-
-<!--
-テーブル構成:
-
-【ストーリーID】
-  - 形式: US-XXX（User Story）
-  - 採番ルール: 連番、一意の識別子
-  - 用途: タスク管理ツール（Jira、Asanaなど）との紐付け、コミットメッセージでの参照
-
-【ストーリー】
-  - 標準フォーマット: 「[役割]として、[目的]がしたい、なぜなら[理由]」
-  - 英語フォーマット: "As a [role], I want [goal] so that [benefit]"
-
-  構成要素:
-    • 役割（Who）: ユーザーの種類やペルソナ
-      例: 「新入社員として」「管理者として」「エンドユーザーとして」
-
-    • 目的（What）: 実現したい機能や行動
-      例: 「プロフィールを編集したい」「売上レポートを閲覧したい」
-
-    • 理由（Why）: その機能が必要な理由、得られる価値
-      例: 「自分の情報を最新に保つため」「意思決定に活用するため」
-
-  書き方のコツ:
-    - 技術用語を避け、ユーザーの言葉で記述
-    - 実装方法（How）ではなく、目的（What/Why）に集中
-    - 1つのストーリーは1つの価値に焦点を当てる
-    - 曖昧な表現を避け、具体的に記述
-
-【受け入れ基準（Acceptance Criteria）】
-  - 目的: ストーリーが「完了」と判断できる明確な基準
-  - 特徴: 測定可能、テスト可能、Yes/Noで判定可能
-
-  推奨フォーマット1: Given-When-Then（BDD形式）
-    Given [前提条件]
-    When [アクション]
-    Then [期待される結果]
-
-    例:
-    - [ ] Given ログイン済みユーザーが自分のプロフィールページにいる時
-          When 「編集」ボタンをクリックし、名前を変更して保存すると
-          Then 変更された名前が表示される
-
-  推奨フォーマット2: チェックリスト形式
-    - [ ] 条件1が満たされている
-    - [ ] 条件2が満たされている
-
-    例:
-    - [ ] ユーザーは名前、メールアドレス、プロフィール画像を編集できる
-    - [ ] 保存時にバリデーションエラーが表示される
-    - [ ] 保存成功時に確認メッセージが表示される
-
-  書き方のベストプラクティス:
-    - 最低1つ、通常3-7個の基準を設定
-    - UIの細かい仕様ではなく、ビジネス価値の検証に焦点
-    - 「意図」を記述し、「実装方法」は記述しない
-    - 開発者とテスターが明確にテストできる内容にする
-    - スプリント計画前に明確化（遅くても開発開始前）
-
-【優先度】
-  - 目的: 開発順序の判断材料
-  - 一般的な分類:
-    • High: 必須機能、ビジネス価値が高い、依存関係が多い
-    • Medium: 重要だが緊急ではない、代替手段がある
-    • Low: あると良い機能、将来的に検討
-
-  優先度付けの考慮要素:
-    - ビジネス価値（ユーザーへのインパクト）
-    - 緊急性（リリース期限、市場動向）
-    - リスク（技術的不確実性、依存関係）
-    - 工数（開発コスト、ROI）
-    - 依存関係（他のストーリーとの関連）
-
-  注意:
-    - 優先度は変動する（定期的に見直す）
-    - すべてがHighになる状況は避ける（真の優先順位をつける）
-    - プロダクトオーナーが最終決定権を持つ
-
-ベストプラクティス:
-  - 3C原則: Card（カード）、Conversation（会話）、Confirmation（確認）
-  - ストーリーはチーム全員で作成（プロダクトオーナー、開発者、デザイナー、QA）
-  - 定期的なリファインメントで詳細化・分割・統合
-  - 完了の定義（DoD: Definition of Done）を明確にする
-  - 実装後のフィードバックを次のストーリーに反映
-  - テクニカルストーリー（リファクタリング、技術的負債解消）も含めて良い
--->
-
-| ストーリーID | ストーリー | 受け入れ基準 | 優先度 |
-|--------------|-----------|--------------|--------|
-| <!-- US-001 --> | <!-- [役割]として、[目的]がしたい、なぜなら[理由] --> | <!-- - [ ] 基準1<br>- [ ] 基準2 --> | <!-- High/Medium/Low --> |
-| <!-- US-002 --> | <!-- [役割]として、[目的]がしたい、なぜなら[理由] --> | <!-- - [ ] 基準1<br>- [ ] 基準2 --> | <!-- High/Medium/Low --> |
-
----
-
-## メモ
-
-<!-- ユーザーストーリーに関する補足情報や依存関係 -->
+# ユーザーストーリー一覧
+
+<!--
+何のドキュメントか: ユーザー視点の機能要求を物語形式で記述したバックログ。詳細仕様ではなく議論の出発点。
+使い方:
+  - 各行は「[役割]として、[目的]がしたい、なぜなら[理由]」で書く。実装方法(How)ではなく目的(What/Why)に集中。
+  - 「ペルソナ」列に 01-product-brief.md のペルソナ表の ID（P-XXX）を記入し、ストーリーの [役割] と一致させる。
+    該当するペルソナが無い場合は、勝手に役割を増やさず 01-product-brief.md のペルソナ表に追加してから参照する。
+  - 受け入れ基準は Given-When-Then かチェックリストで、テスト可能に。通常 3〜7 個。
+  - INVEST 原則・優先度付け・3C 等の詳しい考え方は skills/a-002b-define-user-stories/reference/user-stories-guide.md を参照。
+  - MVP の取捨選択（Must / Not Now / Won't）は 02-mvp-scope.md（/a-002a）が担う。本書の優先度は実装順の目安。
+-->
+
+| ストーリーID | ペルソナ | ストーリー | 受け入れ基準 | 優先度 |
+|--------------|----------|-----------|--------------|--------|
+| <!-- US-001 --> | <!-- P-001 --> | <!-- [役割]として、[目的]がしたい、なぜなら[理由] --> | <!-- - [ ] 基準1<br>- [ ] 基準2 --> | <!-- High/Medium/Low --> |
+| <!-- US-002 --> | <!-- P-001 --> | <!-- [役割]として、[目的]がしたい、なぜなら[理由] --> | <!-- - [ ] 基準1<br>- [ ] 基準2 --> | <!-- High/Medium/Low --> |
+
+**例:**
+
+| ストーリーID | ペルソナ | ストーリー | 受け入れ基準 | 優先度 |
+|--------------|----------|-----------|--------------|--------|
+| US-001 | P-001 | 新入社員として、自己紹介を作成したい、なぜなら早くチームに馴染みたいから | - [ ] 名前・経歴・趣味を入力して公開できる<br>- [ ] 公開後に一覧へ表示される | High |
+| US-002 | P-002 | 受け入れ側として、新人の自己紹介にコメントしたい、なぜなら接点を作りたいから | - [ ] 公開済みプロフィールにコメントできる<br>- [ ] 投稿者へ通知される | Medium |
+
+## メモ
+
+<!-- ユーザーストーリーに関する補足情報や依存関係。命名・優先度の運用ルールは user-stories-guide.md 参照。 -->

package/templates/project/01-requirements/{02-features-implemented.md → 06-features-implemented.md}

@@ -1,73 +1,77 @@
-# 実装済み機能一覧
-
-<!--
-何を書くか: 既に実装・リリース済みの機能を体系的に整理した一覧
-
-目的:
-  - プロダクトの現在の機能範囲を明確にする
-  - 新規メンバーへのオンボーディング資料として活用
-  - 機能追加・変更時の影響範囲把握に役立てる
-  - ドキュメントと実装の同期を保つ
-
-記載粒度: ユーザーが認識できる機能単位（APIエンドポイントレベルではなく、ユーザー機能レベル）
-
-更新頻度: 機能リリース時に必ず更新（living documentとして維持）
--->
-
-<!--
-テーブル構成:
-
-【機能ID】
-  - 形式: FN-XXX（Feature Number）
-  - 採番ルール: 連番、欠番は作らない
-  - 用途: 機能の一意識別、他ドキュメントでの参照、変更履歴の追跡
-
-【Category 1】（大分類）
-  - プロダクトの主要な機能領域で分類
-  - 例: ユーザー管理、コンテンツ、決済、通知、分析
-  - 5-10個程度に収める（多すぎると管理が困難）
-
-【Category 2】（中分類）
-  - Category 1 をさらに細分化
-  - 例: ユーザー管理 → 認証、プロフィール、権限
-  - Category 1 と合わせて機能の所在が即座に分かるように
-
-【機能名】
-  - 簡潔で分かりやすい名称（2-5単語程度）
-  - ユーザー視点の表現を使う（実装用語ではなく）
-  - 例: 「ログイン」「記事作成」「パスワードリセット」
-
-【説明】
-  - 1-2文で機能の内容を記述（50-100文字程度）
-  - 何ができるか（What）を中心に、必要に応じてどう動くか（How）を補足
-  - ユーザーへの価値や利点が分かる表現を心がける
-  - 技術的詳細は避け、ユーザー機能として記述
-
-ベストプラクティス:
-  - カテゴリは一貫性を保つ（表記ゆれを避ける）
-  - 機能の粒度を揃える（ある機能だけ詳細すぎる/粗すぎるを避ける）
-  - 説明は能動態で書く（「〜できる」「〜する」）
-  - 内部実装の変更では更新せず、ユーザー体験が変わった時のみ更新
-  - 削除された機能は一覧から削除（履歴はGitで管理）
--->
-
-| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
-|--------|-----------|-----------|--------|------|
-| <!-- FN-001 --> | <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
-
----
-
-**例:**
-
-| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
-|--------|-----------|-----------|--------|------|
-| FN-001 | ユーザー管理 | 認証 | ログイン | メールアドレスとパスワードでログイン |
-| FN-002 | ユーザー管理 | 認証 | ログアウト | セッション終了 |
-| FN-003 | ユーザー管理 | 認証 | パスワードリセット | メールでリセットリンク送信 |
-| FN-004 | ユーザー管理 | プロフィール | プロフィール編集 | 名前、アバター、自己紹介の編集 |
-| FN-005 | ユーザー管理 | プロフィール | プロフィール閲覧 | 他ユーザーのプロフィール表示 |
-| FN-006 | コンテンツ | 投稿 | 記事作成 | Markdown形式での記事作成 |
-| FN-007 | コンテンツ | 投稿 | 記事編集 | 既存記事の編集 |
-| FN-008 | コンテンツ | 投稿 | 記事削除 | 記事の削除 |
-| FN-009 | コンテンツ | コメント | コメント投稿 | 記事へのコメント |
-| FN-010 | コンテンツ | コメント | コメント削除 | 自分のコメント削除 |
+# 実装済み機能一覧
+
+<!--
+何を書くか: 既に実装・リリース済みの機能を体系的に整理した一覧
+
+モード別の扱い:
+  - existing（既存プロダクト）: 必須。既存コード分析と棚卸しで埋める。
+  - greenfield（新規プロダクト）: 任意。実装済み機能が無いため、空のまま／未生成で構わない。
+
+目的:
+  - プロダクトの現在の機能範囲を明確にする
+  - 新規メンバーへのオンボーディング資料として活用
+  - 機能追加・変更時の影響範囲把握に役立てる
+  - ドキュメントと実装の同期を保つ
+
+記載粒度: ユーザーが認識できる機能単位（APIエンドポイントレベルではなく、ユーザー機能レベル）
+
+更新頻度: 機能リリース時に必ず更新（living documentとして維持）
+-->
+
+<!--
+テーブル構成:
+
+【機能ID】
+  - 形式: FN-XXX（Feature Number）
+  - 採番ルール: 連番、欠番は作らない
+  - 用途: 機能の一意識別、他ドキュメントでの参照、変更履歴の追跡
+
+【Category 1】（大分類）
+  - プロダクトの主要な機能領域で分類
+  - 例: ユーザー管理、コンテンツ、決済、通知、分析
+  - 5-10個程度に収める（多すぎると管理が困難）
+
+【Category 2】（中分類）
+  - Category 1 をさらに細分化
+  - 例: ユーザー管理 → 認証、プロフィール、権限
+  - Category 1 と合わせて機能の所在が即座に分かるように
+
+【機能名】
+  - 簡潔で分かりやすい名称（2-5単語程度）
+  - ユーザー視点の表現を使う（実装用語ではなく）
+  - 例: 「ログイン」「記事作成」「パスワードリセット」
+
+【説明】
+  - 1-2文で機能の内容を記述（50-100文字程度）
+  - 何ができるか（What）を中心に、必要に応じてどう動くか（How）を補足
+  - ユーザーへの価値や利点が分かる表現を心がける
+  - 技術的詳細は避け、ユーザー機能として記述
+
+ベストプラクティス:
+  - カテゴリは一貫性を保つ（表記ゆれを避ける）
+  - 機能の粒度を揃える（ある機能だけ詳細すぎる/粗すぎるを避ける）
+  - 説明は能動態で書く（「〜できる」「〜する」）
+  - 内部実装の変更では更新せず、ユーザー体験が変わった時のみ更新
+  - 削除された機能は一覧から削除（履歴はGitで管理）
+-->
+
+| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
+|--------|-----------|-----------|--------|------|
+| <!-- FN-001 --> | <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
+
+---
+
+**例:**
+
+| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
+|--------|-----------|-----------|--------|------|
+| FN-001 | ユーザー管理 | 認証 | ログイン | メールアドレスとパスワードでログイン |
+| FN-002 | ユーザー管理 | 認証 | ログアウト | セッション終了 |
+| FN-003 | ユーザー管理 | 認証 | パスワードリセット | メールでリセットリンク送信 |
+| FN-004 | ユーザー管理 | プロフィール | プロフィール編集 | 名前、アバター、自己紹介の編集 |
+| FN-005 | ユーザー管理 | プロフィール | プロフィール閲覧 | 他ユーザーのプロフィール表示 |
+| FN-006 | コンテンツ | 投稿 | 記事作成 | Markdown形式での記事作成 |
+| FN-007 | コンテンツ | 投稿 | 記事編集 | 既存記事の編集 |
+| FN-008 | コンテンツ | 投稿 | 記事削除 | 記事の削除 |
+| FN-009 | コンテンツ | コメント | コメント投稿 | 記事へのコメント |
+| FN-010 | コンテンツ | コメント | コメント削除 | 自分のコメント削除 |

package/templates/project/02-behavior/01-core-scenarios.md

@@ -0,0 +1,80 @@
+# Core Scenarios
+
+<!--
+何のドキュメントか: MVP の「価値提供が成立する最小行動」を定義する軽量資料。
+                    全ケース網羅（ハッピー / エラー / 境界値）の BDD ではない。
+                    Day 1 に必ず通る成功体験と、価値を壊す重大失敗だけを固定する。
+
+使い方:
+  - 対象は MVP Scope の Must 機能のみ（02-mvp-scope.md）。Not Now / Won't は扱わない。
+  - 各シナリオは「ユーザーの意図」で書く。UI 操作（ボタン名・画面遷移）の詳細には踏み込まない。
+  - 網羅したくなったら止める。MVP で対応しない行動・エラーは「Not Covered in MVP」へ逃がす。
+
+SSoT の住み分け:
+  - User Story（05-user-stories.md）= 要約レベルの受け入れ基準（AC）。
+  - Core Scenario（本書）= 実行時の主要行動（誰が・何をして・何が起きれば成功か）。
+  - 詳細な Gherkin / 境界値 / Scenario Outline / タグ戦略が必要になったら、実装直前または
+    テスト設計時に任意で `skills/a-003-create-scenarios/reference/detailed-gherkin-template.md` を使う。
+-->
+
+## 参照: MVP Scope
+
+<!-- 02-mvp-scope.md の Must 機能のうち、本書で主要行動を固定する対象を列挙する。 -->
+
+- 対象 Must 機能: <!-- 例: FN-001 プロフィール作成 / FN-002 コメント投稿 -->
+
+## Core Flow 一覧
+
+<!--
+何を書くか: MVP の中核となるユーザー行動の流れ（1〜3本）。価値が成立する最短経路。
+記法: 表で「フロー / 主アクター / 提供価値（So that）/ 対応 Must」を一覧化する。
+-->
+
+| フロー | 主アクター | 提供価値（So that） | 対応 Must |
+|---|---|---|---|
+| <!-- 例: 自己紹介を作り共通点を見つける --> | <!-- 例: 新入社員 --> | <!-- 例: 早くチームに馴染める --> | <!-- 例: FN-001 --> |
+
+## Day 1 Happy Path（1〜3本）
+
+<!--
+何を書くか: リリース初日に「必ず通る」成功シナリオ。MVP の価値検証の中心。
+記法: Given-When-Then を1〜数文で。ユーザーの意図を書き、UI 詳細は避ける。
+-->
+
+### CS-001: <!-- シナリオ名 -->
+
+- **対応フロー / Must**: <!-- 例: 自己紹介フロー / FN-001 -->
+- **Given**: <!-- 前提（例: 新入社員がログイン済み） -->
+- **When**: <!-- 行動（例: ライフラインチャートを入力して公開する） -->
+- **Then**: <!-- 成功条件（例: プロフィールが一覧に表示され、他者が閲覧できる） -->
+
+## Critical Failure（価値を壊す重大失敗）
+
+<!--
+何を書くか: 起きると MVP の価値そのものが崩れる失敗だけ。網羅ではなく「致命傷」に限定。
+            法務・課金・権限・データ消失など、外すと危険な境界条件を優先する。
+-->
+
+### CF-001: <!-- 失敗名 -->
+
+- **何が起きると価値が壊れるか**: <!-- 例: 公開範囲を誤り社外に個人情報が漏れる -->
+- **MVP での扱い**: <!-- 例: 公開範囲は社内固定（設定不可）にして発生源を断つ -->
+
+## Not Covered in MVP（MVP で対応しない行動・エラー）
+
+<!--
+何を書くか: 「今回は対応しない」行動・エラーを明示する。スコープ膨張の防止弁。
+            02-mvp-scope.md の Not Now / Won't と整合させる。
+-->
+
+- <!-- 例: 退職者プロフィールの自動アーカイブ → Not Now -->
+- <!-- 例: 多言語対応 → Won't -->
+
+## AI 実装時の振る舞い注意点
+
+<!--
+何を書くか: 実装エージェント（Vibe coding / AI）が踏みやすい落とし穴と、固定すべき振る舞い。
+-->
+
+- <!-- 例: エラーケースを勝手に網羅実装しない。Not Covered のものは作らない。 -->
+- <!-- 例: 公開範囲のような Critical Failure 対策は仕様どおり固定で実装する。 -->