全体像・タスク
全体フロー・要件定義・タスク種別と Phase 対応。
タスク規模に応じて 3段だけ / Phase 2〜 / 要件から を選ぶ。
やること
- Phase 地図 を見る
- 自分のタスクに近い行を選ぶ
- 該当 Phase 章へ進む
完了: 今回のタスクで開く章の範囲が決まった
いつもの進め方は 3段フロー。 本章は要件定義と Phase 1〜7 の説明・タスク種別の早見表です。くわしい章へのリンク集として使います。
平易な Phase 地図
| Phase | やること（平易語） | いつ読む |
|---|---|---|
| 要件定義 | 関係者と「何を作るか」を文書で合意（PRD） | 中規模以上の新機能 |
| Phase 1 | AI に毎回守らせる Rules を置く | 新規リポ・ルールが古いとき |
| Phase 2 | タスク分解・完了条件を Plan に書く | タスク / PR ごと |
| Phase 3 | 設計 docs・DB・API の型を決める | 設計が複雑なとき |
| Phase 4–5 | コアロジック → アプリ層の実装 | 新機能の実装時 |
| Phase 6 | テスト・ログ・デプロイ等の共通作業 | 初期 + 必要に応じて |
| Phase 7 | PR 作成とレビュー | 実装完了後 |
下の表は各 Phase の役割と「いつ使うか」の早見表です。左から順に進む想定です。
| フェーズ | 内容 | 適用タイミング |
|---|---|---|
| 要件定義 | PdM / 関係者（SH）と PRD すり合わせ → Approved（承認チェック） | 中規模以上の新機能。関係者（SH）が複数いるとき |
| Phase 1 | AI ツールのルール整備（.cursor/rules/、AGENTS.md、CLAUDE.md 等） |
プロジェクト初期（1回）。ルール改訂時 |
| Phase 2 | Plan（タスク分解・成果物・リスク・影響範囲） | タスク / PR ごと |
| Phase 3 | 要件 / 設計 / DB / 技術選定 | 新規機能・大幅改修時 |
| Phase 4 | コアロジック実装（rules・設計 docs 準拠。TDD は任意） | 新規ロジック実装時 |
| Phase 5 | アプリ層実装（同上） | ユースケース追加時 |
| Phase 6 | 全体共通の機能（ログ / インフラ / IF / デプロイ） | 主に初期 + 機能追加で部分更新 |
| Phase 7 | PR 作成・レビュー対応・引き継ぎ | タスク / PR ごと |
タスク種別ごとのフェーズ適用
着手前にタスク種別を決め、「スキップ可」列で省略できる Phase を確認します。
| タスク種別 | スキップ可 | 備考 |
|---|---|---|
| 新規プロジェクト立ち上げ | なし | 要件定義 → 全 Phase実施 |
| 新規機能（中規模以上） | 0（ルール既存時） | 要件定義 必須。ルール追記が必要なら Phase 1 |
| 新規機能（小規模） | 要件定義, Phase 1, Phase 3 | 3段 + ADR + Plan で足りることが多い |
| バグ修正 | 0, 2, 5 | Phase 2 で再現条件を明確化。Phase 4 で回帰テストから |
| リファクタ | 2（要件不変時）, 4–5 | 既存テストで挙動保証してから着手 |
| 調査・PoC | 5, 6（破棄前提なら） | Phase 2 で「PoC である旨」を明示 |
要件すり合わせ — Phase 1〜7 はエンジニア向け。ここでは PdM・関係者（SH） と「何を・なぜ・誰のために」を決める。Approved PRD が Phase 2 の入力になる。
手順の正式な記録: メモ — PRD、docs/PRD-workflow.md。
いつ実施するか
下表で「実施 / スキップ」を切り分ける。迷ったら タスク種別と Phase を見る。
| 実施する | スキップ可（たたき台 / Issue で可） |
|---|---|
| 新規機能（中規模以上） | バグ修正・1行修正 |
| 複数 関係者（SH）・部門をまたぐ変更 | スコープが Issue 1枚で固定 |
| 優先度・やらないこと（やらないこと（Won't）） が争点 | 内部リファクタ（要件不変） |
複数 関係者（SH） が関与する「請求 PDF エクスポート」は PRD 必須 — 複数 関係者（SH） が関与する「請求 PDF エクスポート」は PRD 必須。1 行 typo 修正は Issue だけで Phase 2 へ直行する。
小規模は 3段のたたき台 で十分なことが多い。
PRD すり合わせ（5段階）
- 起票 — Issue / チケット URL を PRD に書く。
- ドラフト — 背景・ゴール/非ゴール・ユーザー・機能/非機能・受け入れ条件・メトリクス・リスク。
- レビュー — PdM + 開発 + 関係 関係者（SH）。コメントは PR かファイル上に残す。
- 承認 — ステータス
Approvedと承認日を更新。 - 実装連携 — Phase 2 に PRD パスを渡す。API/DB 詳細は Phase 3 の
docs/<feature>/へ。
置き場所: docs/prd/<機能スラッグ>.md。エピックは docs/prd/<名前>/README.md。
開発着手前チェック
PRD 不要とする場合は、ADR か Issue に理由を書いてチーム合意を取る。
| フェーズ | 開始条件 |
|---|---|
| Phase 1（rules 整備） | PRD Approved、または「PRD 不要」を ADR/Issue に記録 |
| Phase 2 Plan | Approved PRD（または 00_brief.md）を Plan プロンプトに添付 |
| Phase 3 設計 docs | Phase 2 完了。PRD の Must が 01_requirements.md にトレースできる |
Phase 2 への引き渡し
【タスク】に PRD パス + Issue URL（仕様書だけ貼って PRD を省略しない）。- PRD の受け入れ条件 → Plan の「完了条件」「レビュアー確認ポイント」へ落とす。
- 未決事項は Phase 2 前に 関係者（SH） 合意。Plan に「未決」と明記する。
AI の使い所
AI は下書き役。最終判断と Approved は PdM/関係者（SH） が行う。
| AI に任せてよい | 人間（PdM/関係者（SH））が決める |
|---|---|
| PRD ドラフト・観点チェックリスト・競合整理 | 優先度・スコープ外（やらないこと（やらないこと（Won't）））・承認 |
| 受け入れ条件の漏れ指摘 | ビジネス上のトレードオフ・KPI 目標値 |
| 議事メモの構造化 | 関係者（SH） 合意のファシリテーション |
開発者 A が AI に PRD ドラフトを依頼し、PdM が やらないこと（やらない… — 開発者 A が AI に PRD ドラフトを依頼し、PdM が やらないこと（やらないこと（Won't）） と KPI 目標値を確定する。Approved ステータスは PdM のみが更新する。
日常の進め方は 3段フロー で足りる。 本章は Phase 単位の時系列。大規模タスク・初回ルール整備・チーム共有向け。
- フェーズ定義 → 6 全体ワークフロー
- 手順詳細 → Phase 1〜7
図は着手前の分岐がポイント。左枝がリポ初回（新規プロジェクト）、右枝が既存リポへの機能追加。スキップ可否の一覧は タスク種別と Phase（平易語キャプション付き）。
迷ったら: 小さい → クイックスタート / 大きい → 要件定義 → Phase 2 から。
図の共通区間（Phase 2 以降）の対応表。詳細はリンク先の章を参照。
| Phase | 新規プロジェクト | 既存リポへの追加 | 詳細 |
|---|---|---|---|
| 要件すり合わせ | 実施 | 中規模以上のみ（小規模は省略可） | 要件定義 |
| Phase 1 | 実施 | 原則スキップ（ルール追記時のみ） | Phase 1 |
| Phase 2 Plan | タスク分解・下書き PR（Draft PR） | Phase 2 | |
| Phase 3 設計 | 実施 | 小規模は省略可 | Phase 3 |
| Phase 4–5 実装 | コア → アプリ（TDD はチーム方針に従う） | Phase 4 / Phase 5 | |
| Phase 6 共通作業 | 結合・ログ・マイグレーション | Phase 6 | |
| Phase 7 PR | CI green・レビューループ | Phase 7 | |
規模により、1日で完結することも、1週間を超えることもある。
タスク粒度は 1–3 日が目安。 履歴も適度なサイズに収まる。それ以上は分割を検討。