yodogawa 2.1.3 → 2.2.0

package/templates/project/01-requirements/01-product-brief.md

@@ -0,0 +1,186 @@
+# Product Brief
+
+<!--
+何のドキュメントか: ステークホルダーと5分で「なぜ作るのか」を合意するための軽量資料。
+                    詳細な PRD ではない。実装前に Go / No-Go を判断できる最小情報に絞る。
+
+使い方:
+  - 各セクションは数文〜小さな表で簡潔に。抽象論ではなく証拠・数値・固有名で書く。
+  - 埋まらない箇所は「未確定事項」に逃がし、空欄のまま放置しない。
+  - 成功指標・非ゴール・クリティカル制約は後続スキル（MVP Scope / PM Gate）が参照するため必須。
+-->
+
+## 背景 / 解く課題
+
+<!--
+何を書くか: 誰の・どの課題を・なぜ今解くのか。問題の証拠と規模を添える。
+必須情報:
+  - 具体的な課題（「〜できない」「〜に時間がかかる」）
+  - 問題の証拠・規模（数値・頻度・影響範囲。例: 「月◯件」「1件あたり2時間」）
+  - 放置した場合に何が起きるか
+ベストプラクティス: 抽象表現（「効率が悪い」）より具体表現（「手動で2時間かかる」）。
+-->
+
+**例:**
+新入社員が既存社員と接点を持つ機会が少なく、チームに馴染むまで平均◯週間かかる。リモート増加で雑談・自然な関係構築の場が減り、オンボーディング満足度が低下している（直近アンケートで◯%が「孤立を感じた」と回答）。
+
+## ターゲットユーザー / 主要ペルソナ
+
+<!--
+何を書くか: 主に誰のためのプロダクトか。MVP段階は主要 1〜2 ペルソナに絞る（過剰な人物像づくりはしない / YAGNI）。
+列の意味:
+  - ペルソナID: P-001 形式。05-user-stories.md の「ペルソナ」列がこの ID を参照し、ストーリーの [役割] を解決する SSoT。
+  - 種別: 主要 / 副次。
+  - 役割・ひとこと: どんな人か（職種・立場・状況を一言で）。
+  - ゴール（Job）: その人が片付けたい仕事・達成したいこと。
+  - 主な課題・ペイン: 今困っていること（「〜できない」「〜に時間がかかる」）。
+  - 利用文脈: いつ・どこで・どんな状況で使うか（タイミング・デバイス・頻度）。
+  - ニーズの強さ（任意）: 課題の切実さ（高/中/低）。MVP の優先順位判断の材料。今は仮で可。
+後続参照: 05-user-stories.md の各ストーリーは「ペルソナ」列で P-XXX を参照し、本表と紐づける。
+         a-006 レビューが「US の役割 → 本表」の trace を検証する。
+-->
+
+| ペルソナID | 種別 | 役割・ひとこと | ゴール（Job） | 主な課題・ペイン | 利用文脈 | ニーズの強さ（任意） |
+|---|---|---|---|---|---|---|
+| <!-- P-001 --> | <!-- 主要 --> | <!-- 例: 入社3ヶ月以内の新入社員 --> | <!-- 例: 早くチームに馴染みたい --> | <!-- 例: 誰に何を聞けばよいか分からない --> | <!-- 例: 入社直後・リモート・週数回 --> | <!-- 高/中/低 --> |
+
+**例:**
+
+| ペルソナID | 種別 | 役割・ひとこと | ゴール（Job） | 主な課題・ペイン | 利用文脈 | ニーズの強さ（任意） |
+|---|---|---|---|---|---|---|
+| P-001 | 主要 | 入社3ヶ月以内の新入社員 | 早くチームに馴染み、誰に何を聞けるか把握したい | 社内に知り合いが少なく孤立を感じる | 入社直後・リモート中心・PC/スマホで週数回 | 高 |
+| P-002 | 副次 | 受け入れ側のチームメンバー | 新人の人となりを早く知り接点を作りたい | 新人の興味・背景が見えず雑談の糸口がない | 新人受け入れ時・業務の合間 | 中 |
+
+## ステークホルダー / 決裁者 / 関心事
+
+<!--
+何を書くか: 誰が意思決定し、誰が影響を受け、それぞれ何を気にするか。
+-->
+
+| ステークホルダー | 役割 | 主な関心事 |
+|---|---|---|
+| <!-- 例: 人事部長 --> | <!-- 決裁者 --> | <!-- 例: 早期離職率の低減 --> |
+| <!-- 例: 情シス --> | <!-- 影響を受ける --> | <!-- 例: セキュリティ・運用負荷 --> |
+
+## 現在の代替手段・競合スキャン
+
+<!--
+何を書くか: ユーザーが今この課題をどうしのいでいるか（手作業・既存ツール・我慢）と、同じ課題を解く競合・類似プロダクト。
+なぜ重要か: 「安い代替手段で十分」なら、そもそも作らない判断につながる（MVP Scope で再検討）。各代替の「弱み」＝我々の付け入る隙。
+スコープ: MVP段階は主要な数件（2〜4件）まで。網羅・深追いはしない（YAGNI）。深いリサーチは別途。
+列の意味:
+  - 代替手段・競合: 具体名（手作業の手順 / ツール名 / プロダクト名）。
+  - 種別: 手作業/Workaround / 既製ツール / 競合プロダクト。
+  - 強み: その代替がなぜ今も使われているか。
+  - 弱み・不満（付け入る隙）: ユーザーが困っている点。ここが価値提案の起点になる。
+後続参照: 「価値提案 / 差別化」の Why us が本表の「弱み」と対応づく。
+         02-mvp-scope.md の「より安い代替手段」判定（a-002a）が本表を参照する。
+-->
+
+| 代替手段・競合 | 種別 | 強み | 弱み・不満（付け入る隙） |
+|---|---|---|---|
+| <!-- 例: Slack 自己紹介投稿 --> | <!-- 手作業/Workaround --> | <!-- 例: 全員が既に使える --> | <!-- 例: 投稿が流れて埋もれる --> |
+| <!-- 例: ◯◯（社内SNS SaaS） --> | <!-- 競合プロダクト --> | <!-- 例: プロフィール機能が充実 --> | <!-- 例: 高価・自社カルチャーに非対応 --> |
+
+**例:**
+
+| 代替手段・競合 | 種別 | 強み | 弱み・不満（付け入る隙） |
+|---|---|---|---|
+| オンライン歓迎会・Slack 自己紹介投稿 | 手作業/Workaround | 全員が既に使える・追加コスト無し | 投稿が流れて埋もれ、共通点が見つけにくい |
+| ◯◯（汎用社内SNS SaaS） | 競合プロダクト | プロフィール・タイムラインが充実 | 高価で、ライフラインによる共通点可視化に非対応 |
+
+## 価値提案 / 差別化
+
+<!--
+何を書くか:
+  1) バリュープロポジション（1文）: 誰の・どの課題を・どう解き・なぜ既存より良いか。穴埋め式で1文に凝縮する。
+  2) 差別化ポイント / Why us（最大3点）: 上の「現在の代替手段・競合スキャン」表の「弱み・不満」に対し、我々が何で勝つか。
+ベストプラクティス:
+  - 技術ではなくユーザー価値で書く（before/after が想像できる表現）。
+  - Why us は代替手段の弱みと1対1で対応づける（漠然と「使いやすい」ではなく、どの代替の何に勝つか）。
+スコープ: MVP段階は1文＋3点以内。過剰な訴求文づくりはしない（YAGNI）。
+後続参照: a-006 レビューが「価値提案 ↔ 解く課題 / 成功指標」の整合と、Domain Sketch の中核エンティティへの反映を検証する。
+-->
+
+**バリュープロポジション（1文）:**
+
+<!-- [誰] の [課題] を [解決方法] で解決する。[代替手段] と違い [なぜ良いか]。 -->
+
+**差別化ポイント / Why us:**
+
+- <!-- 例: 流れて消える投稿と違い、いつでも参照でき関係構築の起点になる -->
+- <!-- 例: 双方向コメントで関係が継続する（一方向の自己紹介で終わらない） -->
+
+**例:**
+
+> 新入社員（P-001）の「誰に何を聞けるか分からない孤立」を、ライフラインチャートによる共通点の可視化で解決する。流れて消える Slack 投稿や高価な汎用社内SNSと違い、いつでも参照でき・自社オンボーディングに最適化されている。
+
+- 共通点が一目で分かり会話のきっかけになる（Slack 投稿は流れて埋もれる）
+- 双方向コメントで関係が継続する（一方向の自己紹介投稿で終わらない）
+- 自社オンボーディング特化で安価（汎用 SaaS は高価・過剰機能）
+
+## Why now（なぜ今）
+
+<!--
+何を書くか: なぜ今このタイミングで作るのか（市場・組織・技術・コストの変化）。
+-->
+
+**例:**
+リモート比率が◯%に上昇し従来のオフライン施策が機能しなくなった。来期の大量採用前に仕組みを用意する必要がある。
+
+## 成功指標（North Star / KPI / Guardrail）
+
+<!--
+何を書くか: 成功をどう測るか。North Star は1つ。Guardrail は「悪化させてはいけない指標（失敗の許容ライン）」。
+計測方法: 各指標を「どこで・どう取れるか」（取得元・自動/手動・頻度）。今すぐ取れない指標は、測れる代理指標に置き換える。
+先行/遅行: KPI は先行（行動の早期シグナル。早く動く）/ 遅行（成果の確定値。遅れて出る）を区別すると健全。各1つずつ持つとよい。
+MVP段階: 目標値・計測方法は「仮説」で可。過剰な精緻化はしない（YAGNI）。実測が出たら更新する。
+後続参照: MVP Scope の各機能・PM Gate の Go/No-Go 判定がこの指標に紐づく。
+-->
+
+| 種別 | 指標 | 目標 | 計測方法（どこで / どう取得） |
+|---|---|---|---|
+| North Star | <!-- 例: 入社90日時点の社内つながり数 --> | <!-- 例: 平均◯人以上 --> | <!-- 例: 接点ログをDB集計・月次自動 --> |
+| KPI（先行） | <!-- 例: プロフィール作成率 --> | <!-- 例: 入社2週で◯% --> | <!-- 例: プロダクトDB・週次自動 --> |
+| KPI（遅行） | <!-- 例: 入社90日定着率 --> | <!-- 例: ◯%以上 --> | <!-- 例: 人事システム連携・四半期 --> |
+| Guardrail | <!-- 例: 個人情報に関する苦情 --> | <!-- 例: 0件を維持 --> | <!-- 例: 問い合わせ窓口の記録・随時 --> |
+
+## クリティカル制約
+
+<!--
+何を書くか: 守らねば成立しない制約のみ（網羅的な NFR ではない）。外すと作り直しになるものに絞る。
+            例: 法務・セキュリティ・個人情報・課金・固定期限・対応デバイス・外部 API・予算・運用。
+なぜ重要か: MVP の作り方を変えるほど重要な制約をここに集約する。
+            応答 200ms / 稼働率 99.9% のような定量 NFR は初期では当て推量になりやすいため、
+            ここには書かず設計フェーズ（/a-014-define-infrastructure）で詳細化する。
+後続参照: MVP Scope の Must 判定・PM Gate（a-006）が本セクションを SSoT として参照する。
+列の意味: 制約種別 / 内容 / MVP 判断への影響 / 回避策・緩和策 / 未確定時の確認先。
+-->
+
+| 制約種別 | 内容 | MVP判断への影響 | 回避策・緩和策 | 未確定時の確認先 |
+|---|---|---|---|---|
+| <!-- 例: セキュリティ --> | <!-- 例: 社内 SSO(SAML) 必須・社外公開不可 --> | <!-- 例: 認証は SSO 前提で設計 --> | <!-- 例: 初期は社内限定で回避 --> | <!-- 例: 情シス --> |
+| <!-- 例: 期限 --> | <!-- 例: 来期開始(◯月)までにリリース --> | <!-- 例: スコープを更に絞る判断材料 --> | <!-- 例: 段階リリース --> | <!-- 例: 人事部長 --> |
+
+## 非ゴール（このプロダクトが目指さないこと）
+
+<!--
+何を書くか: 明示的に「やらない」こと。スコープクリープ防止。
+後続参照: MVP Scope の Won't / PM Gate の過剰作り込みチェックの根拠になる。
+-->
+
+**例:**
+
+- 人事評価・勤怠管理は対象外（既存システムが担う）。
+- 社外向け SNS 機能は作らない。
+
+## 未確定事項（Open Questions）
+
+<!--
+何を書くか: まだ答えが出ていない論点・確認待ち事項。空欄で放置せずここに集約する。
+-->
+
+**例:**
+
+- 既存社員のプロフィール移行をどこまで行うか未定。
+- North Star の測定方法（手動集計 / 自動）を要確認。

package/templates/project/01-requirements/02-mvp-scope.md

@@ -0,0 +1,64 @@
+# MVP Scope
+
+<!--
+何のドキュメントか: 「本当に必要なものだけ作る」ための MVP スコープ確定資料。
+                    候補機能を Must / Not Now / Won't に切り分け、各 Must を課題・仮説・成功指標に紐づけて正当化する。
+
+使い方:
+  - 入力は `01-product-brief.md`（課題・ターゲット・成功指標・非ゴール）と `03-parking-lot.md`（アイデア backlog）。
+  - 「機能を並べる」ではなく「削る」ための資料。迷ったら Not Now / Won't に倒す。
+  - Must は「価値検証に不可欠なもの」だけ。1つでも仮説・指標に紐づかない Must は過剰作り込み候補。
+  - 「より安い代替手段（手作業・既存ツール・外部サービス）で足りるか」を必ず問う。足りるなら Must にしない。
+
+判定基準:
+  - Must:    この MVP の仮説検証に不可欠。これが無いと価値が成立しない。
+  - Not Now: 価値はあるが今回は不要。次以降のバックログ（→ Parking Lot）。
+  - Won't:   このプロダクトとして明示的に作らない（→ Out of Scope）。
+-->
+
+## 検証する仮説（1〜3 個）
+
+<!--
+何を書くか: この MVP で検証したい仮説を 1〜3 個に絞る。多すぎる場合は MVP が大きすぎる兆候。
+形式: 「[ターゲット] は [課題] に対して [解決策] を使う／価値を感じる」を検証可能な形で。
+-->
+
+**例:**
+
+1. 新入社員は、ライフラインチャート型の自己紹介があれば、入社2週間以内に自発的にプロフィールを作成する（作成率で検証）。
+2. 共通点が可視化されると、新入社員は既存社員へ自分から話しかける（つながり数で検証）。
+
+## MVP Scope
+
+<!--
+各行 = 候補機能。MVP判定 列は Must / Not Now / Won't のいずれか。
+「解決する課題」「検証指標」は Product Brief の課題・成功指標を参照する（同じ言葉で書く）。
+「より安い代替手段」が十分なら、その機能は Must にしない（手作業・既存ツールで代替）。
+-->
+
+| 候補機能 | 対象ユーザー / Job | 解決する課題 | 検証したい仮説 | MVP判定 | 入れる理由 | 入れない場合の影響 | より安い代替手段 | 検証指標 |
+|---|---|---|---|---|---|---|---|---|
+| <!-- 機能名 --> | <!-- 誰の何の仕事 --> | <!-- Brief の課題参照 --> | <!-- 検証する仮説 --> | <!-- Must / Not Now / Won't --> | <!-- なぜ Day 1 に必要か --> | <!-- 無いと何が壊れるか --> | <!-- 手作業/既存ツール等 --> | <!-- どの KPI/Guardrail --> |
+
+---
+
+**例:**
+
+| 候補機能 | 対象ユーザー / Job | 解決する課題 | 検証したい仮説 | MVP判定 | 入れる理由 | 入れない場合の影響 | より安い代替手段 | 検証指標 |
+|---|---|---|---|---|---|---|---|---|
+| ライフラインチャート作成 | 新入社員 / 自己紹介する | 共通点が見つけにくい | 仮説1 | Must | これ自体が検証対象の中核 | 価値検証が成立しない | なし | プロフィール作成率 |
+| 共通点ハイライト | 新入社員 / 話す相手を探す | 接点を持ちにくい | 仮説2 | Must | つながり創出の主要動線 | つながり数を検証できない | なし | 90日つながり数 |
+| コメント機能 | 双方 / 反応する | 双方向対話が起きない | 仮説2 | Not Now | 閲覧だけで仮説検証は可能 | 初期検証には影響小 | Slack スレッドで代替 | （後続） |
+| 実績バッジ | 新入社員 / 自己表現 | — | — | Won't | 課題・仮説に紐づかない | なし | — | — |
+
+## Out of Scope（やらないこと / Won't）
+
+<!--
+何を書くか: このプロダクトとして「作らない」と明示合意するもの。理由を必ず添える（スコープクリープ防止）。
+Product Brief の「非ゴール」と整合させる。
+-->
+
+| 項目 | 作らない理由 |
+|---|---|
+| <!-- 例: 人事評価機能 --> | <!-- 既存システムが担う。本プロダクトの課題に無関係 --> |
+| <!-- 例: 社外公開プロフィール --> | <!-- セキュリティ制約。非ゴールに記載済み --> |

package/templates/project/01-requirements/03-parking-lot.md

@@ -0,0 +1,29 @@
+# Parking Lot（後回しバックログ）
+
+<!--
+何のドキュメントか: 今は MVP に「入れない」と判断したアイデア・要望の backlog。捨てずに保持し将来に備える。
+役割分担（重要）: MVP の取捨選択（Must / Not Now / Won't と優先順位付け）は 02-mvp-scope.md（/a-002a）が正。
+                  本書は Not Now / Won't や未判断のアイデアの「置き場」で、優先度は厳密に決めない。
+使い方:
+  - 機能 ID なし。ユーザーが認識できる機能単位で、価値（〜したい）中心に 1〜2 文で書く。
+  - MVP に昇格したら 02-mvp-scope.md へ移し本書から削除。不要判断したものも削除（理由は Git に残す）。
+  - 洗い出しのヒアリングは skills/a-002-initialize-project/reference/hearing-questions.md（手順5）を参照。
+-->
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
+
+---
+
+**例:**
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| ユーザー管理 | 認証 | 二段階認証 | SMS/アプリでの二段階認証 |
+| ユーザー管理 | 認証 | ソーシャルログイン | Google/GitHubアカウントでログイン |
+| ユーザー管理 | プロフィール | バッジシステム | 実績に応じたバッジ表示 |
+| コンテンツ | 投稿 | 下書き保存 | 記事の下書き保存機能 |
+| コンテンツ | 投稿 | 予約投稿 | 指定日時での自動投稿 |
+| コンテンツ | コメント | 返信機能 | コメントへの返信スレッド |
+| コンテンツ | コメント | いいね機能 | コメントへのいいね |

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 | コンテンツ | コメント | コメント削除 | 自分のコメント削除 |