yodogawa 1.0.0

package/.windsurf/templates/documentation-rules.md

@@ -0,0 +1,143 @@
+### Documents
+
+ドキュメンテーション構造
+
+---
+
+## プロジェクト単位
+
+#### 1. 要件（何を作るか）
+
+- **要件定義**
+  - システム概要：背景（解決する課題）と目的（提供する価値、解決策）
+  - 実装済み機能一覧：既に実装されている機能
+  - 未実装機能一覧：今後実装予定の機能
+  - 非機能要件一覧：性能、セキュリティ、可用性、スケーラビリティなど
+- **ユーザーストーリー**
+  - ユーザーストーリー一覧：各ユーザーストーリー
+
+#### 2. 振る舞い（どう動くか）
+
+- **振る舞い**
+  - Gherkinシナリオ一覧：Given-When-Then形式の理想的な動作シナリオ
+
+#### 3. ドメイン（ドメインモデルと用語）
+
+- **ドメインモデル**
+  - Event Storming形式のドメインモデル：Bounded Context、Actors、Commands、Events、Policies、Aggregatesなど
+  - Context Map：Bounded Context間の関係性
+- **ユビキタス言語**
+  - ユビキタス言語一覧：プロジェクト共通の用語定義、Bounded Contextごとの用語
+
+#### 4. 設計（どう作るか）
+
+- **テックスタック**
+  - 技術スタック一覧：使用する言語、フレームワーク、ライブラリ、ツール
+- **リポジトリ構造**
+  - ディレクトリ構造：プロジェクトのフォルダとファイルの整理方法
+- **画面設計**
+  - 画面遷移図：画面間の遷移フローと条件
+  - 各画面の役割：各画面の目的と主要な機能
+- **データモデル**
+  - ERD（Entity Relationship Diagram）：エンティティ、属性、関係性
+- **API仕様**
+  - API仕様書：エンドポイント、リクエスト/レスポンス形式、認証方式
+- **アーキテクチャ設計**
+  - システムアーキテクチャ図：システム全体の構成とコンポーネントの関係
+- **インフラ設計**
+  - インフラ構成図：サーバー構成、ネットワーク、環境設定
+
+---
+
+## タスク単位
+
+作成順序：A → B → C
+
+### A. タスク定義ドキュメント
+
+#### 1. 目的
+
+- 解決する問題：具体的な課題や不便
+- 提供する価値：ユーザーやシステムが得られる利益
+
+#### 2. ユーザーストーリー一覧
+
+- [役割]として、[目的]がしたい、なぜなら[理由]
+
+#### 3. 変更内容一覧
+
+- 画面：追加・変更する画面とUIコンポーネント
+- データモデル：エンティティ、テーブル、フィールドの追加・変更
+- API：エンドポイント、リクエスト/レスポンス形式の追加・変更
+- その他：環境設定、インフラ、ツール設定
+
+#### 4. 受け入れ基準
+
+- タスク完了の判断条件（例：画面表示の確認、APIの応答確認、Gherkinシナリオ）
+
+### B. リサーチドキュメント
+
+#### 1. ベストプラクティス
+
+- 技術的なベストプラクティス
+- 設計パターンとアーキテクチャの妥当性
+
+#### 2. 既存コードの調査
+
+- 類似機能の実装箇所と実装パターン
+- 再利用可能なコンポーネントや関数
+- 参考にすべきコード構造
+
+### C. 実装タスクリスト
+
+#### フェーズとステップ
+
+テスト可能なフェーズに分割し、各フェーズ内にチェック可能なステップを配置
+
+- **フェーズ 1**：[フェーズ名]（例：データモデルの実装）
+  - [ ] ステップ 1：[タスク内容]
+    - 成果物：[生成されるもの]
+  - [ ] ステップ 2：[タスク内容]
+    - 成果物：[生成されるもの]
+- **フェーズ 2**：[フェーズ名]（例：API実装とテスト）
+  - [ ] ステップ 1：[タスク内容]
+    - 成果物：[生成されるもの]
+
+---
+
+## ディレクトリ構造
+
+```
+docs/
+├── README.md                           # ドキュメント構造の説明
+├── project/                            # プロジェクト単位
+│   ├── 01-requirements/                # 要件
+│   │   ├── 01-system-overview.md       # システム概要
+│   │   ├── 02-features-implemented.md  # 実装済み機能一覧
+│   │   ├── 03-features-planned.md      # 未実装機能一覧
+│   │   ├── 04-non-functional-requirements.md  # 非機能要件
+│   │   └── 05-user-stories.md          # ユーザーストーリー
+│   ├── 02-behavior/                    # 振る舞い
+│   │   └── 01-scenarios.md             # Gherkinシナリオ一覧
+│   ├── 03-domain/                      # ドメイン
+│   │   ├── 01-domain-model.md          # ドメインモデル（Event Storming形式）
+│   │   └── 02-ubiquitous-language.md   # ユビキタス言語
+│   └── 04-design/                      # 設計
+│       ├── 01-tech-stack.md            # テックスタック
+│       ├── 02-repository-structure.md  # リポジトリ構造
+│       ├── 03-ui-design.md             # 画面設計
+│       ├── 04-data-model.md            # データモデル（ERD）
+│       ├── 05-api-spec.md              # API仕様
+│       ├── 06-architecture.md          # アーキテクチャ設計
+│       └── 07-infrastructure.md        # インフラ設計
+└── tasks/                              # タスク単位
+    ├── TASK-001-feature-name/
+    │   ├── a-definition.md             # タスク定義ドキュメント
+    │   ├── b-research.md               # リサーチドキュメント
+    │   └── c-implementation.md         # 実装タスクリスト
+    ├── TASK-002-another-feature/
+    │   ├── a-definition.md
+    │   ├── b-research.md
+    │   └── c-implementation.md
+    └── ...
+```

package/.windsurf/templates/project/01-requirements/01-system-overview.md

@@ -0,0 +1,49 @@
+# システム概要
+
+## 背景
+
+<!--
+何を書くか: このシステムで解決しようとしている問題を記述
+
+文量: 2-4文程度（100-200文字）
+トーン: 客観的で事実ベース。感情的な表現は避ける
+必須情報:
+  - 現在直面している具体的な問題や課題
+  - なぜその問題が重要なのか
+  - 問題の影響を受けるステークホルダー
+
+ベストプラクティス:
+  - 具体的な数値やデータがあれば含める（例: 「3ヶ月かかる」「70%が離脱」）
+  - 「〜できない」「〜が困難」など問題を明確に表現
+  - 誰が・いつ・どこで困っているかを具体的に示す
+  - 現状の workaround や代替手段があればそれも言及
+  - 抽象的な表現（「効率が悪い」）より具体的な表現（「手動で2時間かかる作業」）を使う
+-->
+
+**例:**
+新入社員が既存社員とコミュニケーションを取る機会が限られており、チームに溶け込むまでに時間がかかる。また、リモートワークの増加により、雑談や自然な関係構築の場が減少している。
+
+---
+
+## 目的
+
+<!--
+何を書くか: このシステムが提供する価値や解決策を記述
+
+文量: 2-4文程度（100-200文字）
+トーン: ポジティブで具体的。実現可能な内容に留める
+必須情報:
+  - システムがどのように問題を解決するか
+  - ユーザーや組織が得られる具体的な価値
+  - 期待される成果や変化
+
+ベストプラクティス:
+  - 「〜を可能にする」「〜を支援する」など能動的な表現を使う
+  - 技術的な詳細（「React使用」）よりもビジネス価値（「開発速度2倍」）に焦点を当てる
+  - 測定可能な成果があれば言及する（例: 「作業時間を50%削減」「離脱率を20%改善」）
+  - どのように問題を解決するか、具体的なメカニズムを簡潔に示す
+  - ユーザーにとっての before/after が想像できる表現を使う
+-->
+
+**例:**
+社員がライフラインチャートを通じて自己紹介し、共通点を見つけやすくすることで、組織横断のコミュニケーションを活性化する。コメント機能により双方向の対話を促進し、早期の関係構築を支援する。

package/.windsurf/templates/project/01-requirements/02-features-implemented.md

@@ -0,0 +1,73 @@
+# 実装済み機能一覧
+
+<!--
+何を書くか: 既に実装・リリース済みの機能を体系的に整理した一覧
+
+目的:
+  - プロダクトの現在の機能範囲を明確にする
+  - 新規メンバーへのオンボーディング資料として活用
+  - 機能追加・変更時の影響範囲把握に役立てる
+  - ドキュメントと実装の同期を保つ
+
+記載粒度: ユーザーが認識できる機能単位（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/.windsurf/templates/project/01-requirements/03-features-planned.md

@@ -0,0 +1,75 @@
+# 未実装機能一覧
+
+<!--
+何を書くか: 今後実装を検討・予定している機能のリスト
+
+目的:
+  - プロダクトのロードマップや将来ビジョンを可視化
+  - ステークホルダーとの期待値調整
+  - 技術的負債や機能gap の把握
+  - 実装優先度の議論のベース資料
+
+特徴:
+  - 機能IDなし: まだ確定していないため識別子は不要
+  - 優先度なし: 優先度は常に変動し混乱を招くため記載しない
+  - 柔軟性重視: アイデア段階の機能も含めて良い
+
+記載粒度: 実装済み機能一覧と同程度（ユーザーが認識できる機能単位）
+
+更新頻度:
+  - 機能を実装したら「実装済み機能一覧」に移動し、こちらから削除
+  - 新しいアイデアや要望が出たら随時追加
+  - 四半期ごとなど定期的に見直し、不要な機能は削除
+-->
+
+<!--
+テーブル構成:
+
+【Category 1】（大分類）
+  - 実装済み機能一覧と同じカテゴリ体系を使用
+  - 既存カテゴリに当てはまらない場合は新カテゴリを追加
+  - 例: ユーザー管理、コンテンツ、決済、通知、分析
+
+【Category 2】（中分類）
+  - 実装済み機能一覧と同じカテゴリ体系を使用
+  - より具体的な機能領域で分類
+  - 例: ユーザー管理 → 認証、プロフィール、権限
+
+【機能名】
+  - 簡潔で分かりやすい名称（2-5単語程度）
+  - ユーザー視点の表現を使う
+  - まだ確定していなくても仮の名称で記載OK
+  - 例: 「二段階認証」「下書き保存」「AIレコメンド」
+
+【説明】
+  - 1-2文で機能の内容を記述（50-100文字程度）
+  - 何を実現したいか（目的）を中心に記述
+  - 「〜したい」「〜できるようにする」など意図が伝わる表現
+  - 実装方法が未定でもユーザー価値を記述
+
+ベストプラクティス:
+  - 実装の難易度や工数は記載しない（別途見積もりで管理）
+  - 「いつか実装したい」程度のアイデアも含めて良い（柔軟に）
+  - 競合製品の機能を参考にする場合は、自社プロダクトでの意義を明確に
+  - カテゴリ分類により、特定領域の機能が不足していないか確認できる
+  - 定期的に見直し、実装しない判断をした機能は削除（理由はGitコミットメッセージに残す）
+  - 技術的な表現（「WebSocket実装」）より価値の表現（「リアルタイム通知」）を優先
+-->
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
+
+---
+
+**例:**
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| ユーザー管理 | 認証 | 二段階認証 | SMS/アプリでの二段階認証 |
+| ユーザー管理 | 認証 | ソーシャルログイン | Google/GitHubアカウントでログイン |
+| ユーザー管理 | プロフィール | バッジシステム | 実績に応じたバッジ表示 |
+| コンテンツ | 投稿 | 下書き保存 | 記事の下書き保存機能 |
+| コンテンツ | 投稿 | 予約投稿 | 指定日時での自動投稿 |
+| コンテンツ | コメント | 返信機能 | コメントへの返信スレッド |
+| コンテンツ | コメント | いいね機能 | コメントへのいいね |

package/.windsurf/templates/project/01-requirements/04-non-functional-requirements.md

@@ -0,0 +1,115 @@
+# 非機能要件一覧
+
+<!--
+何を書くか: システムが「どう動くべきか」を定義する品質要件
+
+目的:
+  - システムの性能基準、セキュリティレベル、信頼性を明確化
+  - アーキテクチャ設計の指針を提供
+  - テスト計画の基準値を設定
+  - ステークホルダーとのSLA（サービスレベル合意）の根拠
+
+特徴:
+  - 機能要件（何ができるか）に対し、非機能要件は「どれくらい良く動くか」を規定
+  - 測定可能で検証可能な基準を設定
+  - プロジェクト初期に定義し、開発全体を通じて継続的に検証
+
+記載のポイント:
+  - 具体的な数値目標を含める（「高速」ではなく「200ms以内」）
+  - 現実的で達成可能な基準を設定
+  - ビジネス要件と技術的実現可能性のバランスを取る
+
+更新頻度:
+  - プロジェクト初期に定義、要件変更時に見直し
+  - システム規模拡大時に再評価（ユーザー数増加など）
+  - 定期的な監視結果に基づいて調整
+-->
+
+<!--
+テーブル構成:
+
+【カテゴリ】
+主要なカテゴリと内容:
+
+  性能（Performance）
+    - 応答時間: ユーザー操作からレスポンスまでの時間
+    - スループット: 単位時間あたりの処理件数
+    - リソース使用率: CPU、メモリ、ディスク、ネットワーク
+    - 同時接続数: 同時にアクセス可能なユーザー数
+
+  セキュリティ（Security）
+    - 認証・認可: ログイン方式、アクセス制御
+    - 暗号化: 通信・データの暗号化方式
+    - 監査: ログ記録、アクセス履歴
+    - 脆弱性対策: OWASP Top 10対応など
+    - データ保護: GDPR、個人情報保護法などのコンプライアンス
+
+  可用性（Availability）
+    - 稼働率: システムが利用可能な時間の割合（例: 99.9%）
+    - MTBF: 平均故障間隔
+    - MTTR: 平均復旧時間
+    - バックアップ: バックアップ頻度と保持期間
+    - 障害対応: 検知から復旧までの目標時間
+
+  スケーラビリティ（Scalability）
+    - ユーザー数: 対応可能な最大ユーザー数
+    - データ量: 保存可能なデータの上限
+    - 拡張性: 水平/垂直スケーリングの方式
+    - エラスティシティ: 負荷に応じた自動スケーリング
+
+  ユーザビリティ（Usability）
+    - アクセシビリティ: WCAG準拠レベル
+    - 学習容易性: 新規ユーザーが操作を習得する時間
+    - 多言語対応: サポートする言語
+    - モバイル対応: レスポンシブデザイン、PWA
+
+  保守性（Maintainability）
+    - コード品質: テストカバレッジ、静的解析基準
+    - デプロイ頻度: リリースサイクル
+    - ロールバック時間: 問題発生時の巻き戻し時間
+
+  互換性（Compatibility）
+    - ブラウザ対応: サポートするブラウザとバージョン
+    - デバイス対応: PC、タブレット、スマートフォン
+    - API互換性: 後方互換性の保証期間
+
+【要件】
+  - カテゴリ内の具体的な要件項目名
+  - 簡潔で明確な名称（2-5単語程度）
+  - 例: 「応答時間」「認証方式」「稼働率」
+
+【説明】
+  - 要件の具体的な基準値や条件を記述
+  - 測定可能な数値を含める（必須）
+  - 測定条件や前提条件も必要に応じて記載
+  - 例: 「API応答は95パーセンタイルで200ms以内（通常負荷時）」
+
+ベストプラクティス:
+  - 「速い」「安全」など曖昧な表現を避け、具体的な数値や基準を使う
+  - テスト可能な要件にする（どう検証するか明確にする）
+  - 優先度の高い要件から記載（すべてを満たす必要はない場合もある）
+  - ビジネス影響を考慮した現実的な基準を設定（過度に厳しい基準は開発コストを増大させる）
+  - 競合他社や業界標準を参考にする
+  - システムの成長に応じて要件を見直す（初期は緩く、成熟に伴い厳格化も可）
+-->
+
+| カテゴリ | 要件 | 説明 |
+|----------|------|------|
+| <!-- カテゴリ名 --> | <!-- 要件名 --> | <!-- 要件の詳細 --> |
+
+---
+
+**例:**
+
+| カテゴリ | 要件 | 説明 |
+|----------|------|------|
+| 性能 | 応答時間 | API応答は200ms以内 |
+| 性能 | 処理能力 | 同時接続1000ユーザーまで対応 |
+| セキュリティ | 認証 | OAuth 2.0 + JWT認証 |
+| セキュリティ | 暗号化 | TLS 1.3による通信暗号化 |
+| セキュリティ | 監査 | 全API呼び出しのログ記録 |
+| 可用性 | 稼働率 | 99.9%の稼働率を維持 |
+| 可用性 | 障害対応 | 検知から復旧まで4時間以内 |
+| スケーラビリティ | ユーザー数 | 10万ユーザーまで対応可能 |
+| スケーラビリティ | データ量 | 1TBまでのデータ保存 |
+| ユーザビリティ | アクセシビリティ | WCAG 2.1 AA準拠 |

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

@@ -0,0 +1,124 @@
+# ユーザーストーリー一覧
+
+<!--
+何を書くか: ユーザー視点での機能要求を物語形式で記述したバックログ
+
+目的:
+  - ユーザーの課題とニーズを明確化
+  - 開発チームとステークホルダーの共通理解を構築
+  - 開発優先度の判断材料を提供
+  - スプリント計画の基礎資料として活用
+
+特徴:
+  - ユーザー中心設計: 実装方法ではなく、ユーザーの「なぜ」に焦点
+  - 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 --> |
+
+---
+
+## メモ
+
+<!-- ユーザーストーリーに関する補足情報や依存関係 -->