# プロジェクト立ち上げフロー (Project Setup Flow)

新規プロジェクトを AI と協働で立ち上げる際の手順を定義する．
各フェーズを順番に進め，成果物を確定させてから次のフェーズに移ること．

## フェーズ一覧 (Phase Overview)

| フェーズ | やること                                       | 成果物                                                     |
| -------- | ---------------------------------------------- | ---------------------------------------------------------- |
| 方針決定 | プロジェクトの目的・スコープを決める           | `PLAN_01_要件定義書.md`                                    |
| 技術選定 | 言語・フレームワーク・インフラを決める         | `ENV_01_技術スタック.md`                                   |
| 環境構築 | 開発環境のセットアップ手順を整備する           | `ENV_02_環境構築手順.md`，`ENV_03_管理者用環境構築手順.md` |
| 仕様設計 | アーキテクチャ・データモデル・画面設計を決める | `SPEC_01_*.md`                                             |
| 規約整備 | 技術スタックに応じたコーディング規約を作る     | `GUIDE_*_*.md`                                             |
| 開発計画 | ステップを分割し，開発順序を決める             | `PLAN_02_開発ステップ.md`                                  |
| 実装開始 | 開発計画に沿って実装を進める                   | ソースコード                                               |

## 方針決定 (Direction)

プロジェクトの全体像を明確にする．

- **人間が決めること**: プロジェクトの目的，対象ユーザー，スコープ（やること・やらないこと）
- **AI に依頼できること**: 要件の整理・構造化，類似プロジェクトの調査，要件定義書のドラフト作成
- **成果物**: `PLAN_01_要件定義書.md`

## 技術選定 (Tech Stack)

要件に基づいて技術スタックを決定する．

- **人間が決めること**: 最終的な技術選定の判断，チームのスキルセットとの適合性
- **AI に依頼できること**: 要件に適した技術の候補提案，各候補のメリット・デメリット比較
- **成果物**: `ENV_01_技術スタック.md`

## 環境構築 (Environment Setup)

開発環境を構築し，手順をドキュメント化する．初回のみの管理者作業と，メンバーが繰り返し行う構築手順を分けて整備する．

- **前提条件**: 以下のツールは全プロジェクト共通で導入する．
  - `git` — バージョン管理（[GUIDE_04](GUIDE_04_Git運用ルール.md) で運用ルールを定義）
  - `gh` — GitHub CLI（PR 作成・マージ等に使用）
- **基本方針**: 環境の再現性を重視し，手順書だけに頼らず構築を自動化・コード化できる方法を優先する（例: Docker，Dev Containers，Windows Sandbox，IaC ツール等）．
- **人間が決めること**: 開発マシンの選定，クラウドサービスのアカウント作成，環境構築方法の選択
- **AI に依頼できること**: 環境構築手順書の作成，設定ファイルの生成，`.gitignore` の作成，Dockerfile や devcontainer.json 等の構築用ファイルの作成
- **成果物**:
  - `ENV_02_環境構築手順.md` — メンバーの参加時や環境の再構築時に使う手順
  - `ENV_03_管理者用環境構築手順.md` — プロジェクト作成時に一度だけ行う初期設定（リポジトリ作成，外部サービスの設定等）

## 仕様設計 (Specification)

アプリケーションの設計を行う．

- **人間が決めること**: ユーザー体験の方針，ビジネスロジックの最終判断
- **AI に依頼できること**: アーキテクチャ設計のドラフト，データモデル定義，画面遷移図の整理
- **成果物**: `SPEC_01_*.md`（プロジェクトの規模に応じて複数ファイルに分割）

## 規約整備 (Coding Standards)

技術スタックに応じたコーディング規約やプロジェクト固有のガイドを作成する．
汎用ガイド（GUIDE_01〜05）は本テンプレートに含まれている．ここではプロジェクト固有の規約を追加する．

- **基本方針**: 言語・フレームワークの公式ガイドラインや広く採用されている標準規約に則る（例: Effective Dart，PEP 8，Google Style Guide 等）．プロジェクト固有のルールは標準と異なる部分のみ定義する．
- **人間が決めること**: 標準規約でカバーされない判断（アーキテクチャパターンの選択等）
- **AI に依頼できること**: 標準規約を踏まえた規約のドラフト作成，参照元ガイドラインの調査
- **作成すべきガイド**:
  - コーディング規約 — 命名規則，フォーマット，import 順序，型の使い方，コメントの書き方，コード内ドキュメントの規則
  - ディレクトリ構造規則 — プロジェクトのディレクトリ構成とファイル配置ルール
  - テスト方針 — テストの種類，粒度，実行タイミング，カバレッジ基準
  - エラーハンドリング方針 — エラーの分類，処理方法，ログ出力の方針
  - リファクタリング方針 — リファクタリングの判断基準，実施タイミング
  - 機能実装完了フロー — コミット前のチェックリスト（フォーマット，静的解析，テスト，レビュー等）

## 開発計画 (Development Plan)

実装の順序とステップを決定する．

- **人間が決めること**: 優先度，リリース計画，マイルストーン
- **AI に依頼できること**: 仕様を元にしたステップ分割の提案，依存関係の整理
- **成果物**: `PLAN_02_開発ステップ.md`

## 実装開始 (Implementation)

開発計画に沿って AI と協働で実装を進める．

- 各ステップの完了時に [GUIDE_02_ドキュメント作成ガイド](GUIDE_02_ドキュメント作成ガイド.md) と [GUIDE_04_Git運用ルール](GUIDE_04_Git運用ルール.md) に従ってコミット・PR を作成する．
- 仕様変更が発生した場合は，先にドキュメントを更新してから実装に反映する．

### ドキュメントの書き方

- コード内ドキュメント（JSDoc・コメント）と docs/ ドキュメントの書き方は [GUIDE_06_コーディング規約](GUIDE_06_コーディング規約.md) の「ドキュメント」セクションを参照
- 仕様・設計の変更がある場合は `docs/` を先に更新してから実装に反映する

## CLAUDE.md の管理 (CLAUDE.md Management)

`CLAUDE.md` は AI が会話開始時に最初に読むファイルであり，プロジェクトの引継ぎ情報を一元管理する．
AI は毎回新しい会話で始まるため，このファイルが唯一の継続的な文脈となる．

### 記載すべき内容

- **プロジェクト概要**: プロジェクト名，目的，技術スタックの要約
- **開発進捗**: 現在のステップ，次にやること
- **必須ルール**: AI が実装時に必ず守るべきルール（コーディング規約，コミット前チェック等の要点）
- **ドキュメント一覧**: docs/ 内のファイルへの参照パス

### 更新タイミング

- ステップの完了時に開発進捗を更新する
- ドキュメントの追加・削除・リネーム時に参照パスを更新する
- 必須ルールに変更があった場合に反映する

### 運用上の注意

- CLAUDE.md は AI が毎回読み込むため，簡潔に保つ．詳細は docs/ のドキュメントに委ね，CLAUDE.md には要点と参照先のみ記載する．
- プロジェクト固有のルールが増えたら，docs/ に独立ファイルとして切り出し，CLAUDE.md からはリンクで参照する．