Newer
Older
MiniTias / docs / 01_GUIDE / GUIDE_01_プロジェクト立ち上げフロー.md

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

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

フェーズ一覧 (Phase Overview)

フェーズやること成果物
方針決定プロジェクトの目的・スコープを決めるPLAN_01_要件定義書.md
技術選定言語・フレームワーク・インフラを決めるENV_01_技術スタック.md
環境構築開発環境のセットアップ手順を整備するENV_02_環境構築手順.mdENV_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 で運用ルールを定義)
    • 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 と協働で実装を進める.

ドキュメントの書き方

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

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

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

記載すべき内容

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

更新タイミング

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

運用上の注意

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