この記事は、ひとりでつくるSaaS - 設計・実装・運用の記録 Advent Calendar 2025 の24日目の記事です。
昨日の記事では「Claude Codeを使った開発の実践」について書きました。この記事では、AIエージェントと協働するための開発手法「進捗駆動開発（PDD）」を紹介します。
「進捗駆動開発（PDD）」は、この記事で紹介するために筆者が考案した言葉・考え方です。10年以上のPM・PdM経験の中で様々な進捗管理ツールや手法を試してきましたが、AIエージェントと協働する開発スタイルに合った進捗管理の方法を模索する中で、この手法にたどり着きました。
💡 進捗駆動開発とは
進捗駆動開発（PDD: Progress-Driven Development）は、開発プロセス全体を構造化し、各ステップの完了条件を明確化することで、人間とAIが協調して効率的に開発を進める手法です。
個人開発での課題
個人開発を続けていると、このような課題に直面することはないでしょうか。
- 「あの機能、どこまで作ったっけ？」と思い出せない
- 久しぶりに再開すると、次に何をすべきか分からない
- 全体の何割くらい完成しているのか、把握できていない
仕様駆動開発（SDD: Spec-Driven Development）は、仕様ドキュメントをSSoT（Single Source of Truth）として、それに基づいて設計・実装を進める手法です。テスト駆動開発（TDD: Test-Driven Development）は、失敗するテストを書き（Red）、テストを通す実装をし（Green）、リファクタリングする（Refactor）という短いサイクルを繰り返す手法です。
これらは「何を作るか」「どう作るか」に焦点を当てた手法であり、「どこまでできているか」を把握するには別の仕組みが必要です。
参考ドキュメント
PDDの位置づけ
PDDは、SDDやTDDを否定するものではありません。それらを補完し、進捗管理の視点を加えた手法です。
SDD: 仕様ドキュメントを唯一の情報源として実装を進める
TDD: テストと実装の短いサイクルでコード品質を保証
PDD: 進捗を可視化して「どこまでできているか」を把握
開発を複数のステップに分解し、それぞれの完了条件を明確にすることで、「今どこまでできているか」が一目で分かるようになります。
SDD／TDDとの比較
| 手法 | 焦点 | 成果物 | サイクル |
|---|---|---|---|
| SDD | 仕様の明確化 | 仕様ドキュメント | 仕様→設計→実装 |
| TDD | コード品質 | テストコード | テスト→実装→リファクタ |
| PDD | 進捗の可視化 | 進捗マトリクス | 確認→実装→スキャン→レビュー |
TDDが開発者のための手法であるとすれば、PDDはマネジメントのための手法といえます。これらは排他的ではなく、組み合わせて使うことができます。
チーム開発への応用
この手法は個人開発向けに考案しましたが、チーム開発にも応用できます。PDDの進捗表は、エンジニア以外のメンバーにもそのまま見せられるからです。
| 手法 | 成果物の可読性 | 進捗の可視化 | ステークホルダー共有 |
|---|---|---|---|
| SDD | 仕様書（誰でも読める） | 充足度（進捗が見えにくい） | 容易 |
| TDD | テストコード（技術者向け） | pass/fail（進捗が見えにくい） | 説明が必要 |
| PDD | 進捗表（誰でも読める） | マトリクス表示（進捗が分かりやすい） | 容易 |
🔢 機能×ステップのマトリクス
PDDの特徴は、機能（縦軸）×ステップ（横軸） のマトリクスで進捗を管理することです。
ステップの定義
私のプロジェクトでは、各機能を以下の10段階で管理しています。10段階にしているのは、進捗率を10%刻みで計算できて分かりやすいからです（10% × 10ステップ = 100%）。
| # | ステップ | 内容 | 担当 |
|---|---|---|---|
| 01 | spec | 仕様（要件定義） | AI/人間 |
| 02 | design | 設計（API設計、DB設計等） | AI/人間 |
| 03 | database | スキーマ・マイグレーション | AI |
| 04 | ui | 画面・コンポーネント | AI |
| 05 | api | APIエンドポイント | AI |
| 06 | usecase | ビジネスロジック | AI |
| 07 | repository | データアクセス層 | AI |
| 08 | unit-test | ユニットテスト | AI |
| 09 | guide | ユーザーガイド | AI |
| 10 | review | 総合レビュー | 人間 |
ステップの数や内容は、プロダクトに応じて自由に設計して構いません。私のプロダクトはユーザーガイドが必要なためguideを入れていますが、不要であれば省略できます。5段階や8段階でも問題ありません。大事なのは「何をもって完了とするか」を明確にすることです。
私の場合、01-specと02-designは人間とAIが協力して作成し、03〜09はAIが実装を担当します。最後の10-reviewは人間が最終確認を行います。
ステータスの定義
私のプロジェクトでは、各セルに5段階のステータスを設定しています。
| ステータス | 記号 | 進捗 | 意味 |
|---|---|---|---|
| none | [n] |
0% | 未着手 |
| started | [s] |
25% | 着手 |
| draft | [d] |
50% | 仮完成 |
| reviewed | [r] |
75% | レビュー済み |
| done | [x] |
100% | 完了 |
ステータスの段階数や名称も、プロジェクトに応じて自由に設計できます。シンプルに「未着手／進行中／完了」の3段階でも問題ありません。
🧩 進捗管理の仕組み
私のプロジェクトでは、進捗管理に必要なファイルをdocs/progress/に配置しています。これらはClaude Codeに相談しながら作成しました。以下のようなプロンプトで依頼できます。
プロジェクトの進捗管理の仕組みを作りたいです。
要件:
- 機能ごとにJSONファイルで進捗を管理
- 各機能は10段階のステップで構成（spec, design, database, ui, api, usecase, repository, unit-test, guide, review）
- ステータスは none/started/draft/reviewed/done の5段階
- ステップごとに関連ファイルのパス一覧をまとめたJSONも作成（ドキュメントへのクイックアクセス用）
- CLIコマンドで進捗表示と自動スキャンができる
- マトリクス形式で一覧表示、色分けあり
まずディレクトリ構成と、1つの機能のJSONファイル例を提案してください。
最初から完璧なものを作る必要はありません。使いながら改善していけば大丈夫です。以下、私が実際に使っている構成を紹介します。
ディレクトリ構成
docs/progress/
├── features/ # 機能ごとの進捗ファイル
│ ├── 01-auth/
│ │ ├── 01-register.json
│ │ ├── 02-verify-email.json
│ │ ├── 03-login.json
│ │ └── ...
│ ├── 02-home/
│ ├── 03-contents/
│ └── ...
├── steps/ # ステップごとのファイル一覧
│ ├── 01-spec.json
│ ├── 02-design.json
│ └── ...
├── checklists/ # 各ステップの完了条件
│ ├── 01-spec.md
│ ├── 02-design.md
│ ├── 03-database.md
│ └── ...
└── scripts/ # CLIツール
└── pdd.ts # pdd scan / pdd status を提供
1. 各機能の進捗管理
各機能の進捗は、JSONファイルで管理します。
{
"id": "login",
"name": "ログイン",
"description": "メール/パスワードでログイン",
"steps": {
"01-spec": {
"status": "done",
"files": [{ "path": "src/_spec.md", "reviewed": false }]
},
"02-design": {
"status": "done",
"files": [{ "path": "src/client/components/auth/login/_design.md", "reviewed": false }]
},
"03-database": { "status": "done", "files": [...] },
"04-ui": {
"status": "done",
"files": [
{ "path": "src/app/[locale]/(auth)/login/page.tsx", "reviewed": false },
{ "path": "src/client/components/auth/login/LoginPage.tsx", "reviewed": false }
]
},
"05-api": { "status": "done", "files": [...] },
"06-usecase": { "status": "na" },
"07-repository": { "status": "na" },
"08-unit-test": { "status": "done", "files": [...] },
"09-guide": { "status": "none" },
"10-review": { "status": "none", "note": "認証フローの最終確認が必要" }
}
}
ポイント:
-
files: そのステップで作成したファイルを記録（自動スキャンで更新） -
reviewed: ファイル単位でレビュー済みかどうかを追跡 -
note: 補足情報やTODOを記録 -
na: そのステップが不要な場合
2. 各ステップの成果物一覧
steps/ディレクトリには、各ステップの成果物（ファイルパス）をまとめたJSONを置いています。
私のプロジェクトでは、設計ドキュメント（_design.md）を実装ファイルの近くに配置しています。こうすることで、AIエージェントが実装時に設計を参照しやすくなります。一方、人間がレビューするときは設計ドキュメントが各所に散らばっていて探しにくくなります。そこでsteps/に一覧をまとめておくことで、人間もAIエージェントもスムーズに開発を進められます。
{
"step": "02-design",
"name": "設計",
"categories": [
{
"category": "auth",
"categoryName": "01 認証",
"subcategories": [
{
"subcategory": "01-01",
"subcategoryName": "ユーザー登録",
"files": [
{ "path": "src/client/components/auth/register/_design.md" }
]
},
{
"subcategory": "01-02",
"subcategoryName": "メール認証",
"files": [
{ "path": "src/client/components/auth/verify-email/_design.md" }
]
},
{
"subcategory": "01-03",
"subcategoryName": "ログイン",
"files": [
{ "path": "src/client/components/auth/login/_design.md" }
]
}
]
}
]
}
VS Codeの拡張機能「Open File From Path」と組み合わせると、JSONファイル内のパスにカーソルを置いてショートカットキー（alt+d）を押すだけで、該当ファイルに直接ジャンプできます。「設計ドキュメントを確認したい」「ユニットテストの一覧を見たい」といったときに便利です。
3. 完了条件チェックリスト
各ステップには、完了条件をチェックリストで定義しています。このチェックリストがあることで、AIは「次に何をすべきか」を自己判断できます。
04-ui（画面）の例:
## 完了条件
- [ ] 必要なページコンポーネントが存在する
- [ ] 必要なUIコンポーネントが存在する
- [ ] TypeScriptコンパイルが通る
- [ ] 画面が正常に表示される
## 品質判定基準
| 状態 | 基準 |
|------|------|
| done | ユーザー操作が処理される、ローディング・エラー状態が実装されている |
| draft | UIは表示されるが操作が未実装、ダミーデータを使用 |
| none | コンポーネントファイルが存在しない |
10-review（総合レビュー）の例:
## 完了条件
- [ ] コードレビューが完了している
- [ ] 動作確認が完了している
- [ ] ユーザビリティが確認されている
- [ ] セキュリティ観点の確認が完了している
## AIの役割
- AIはレビューを「実施」することはできない
- AIは「レビューが必要な状態である」ことを検出・報告できる
🎮 進捗管理用コマンド
進捗管理用にCLIツール pdd を用意しています。TypeScriptで実装し、docs/progress/scripts/pdd.ts に配置しています。
| コマンド | 役割 |
|---|---|
pdd scan |
ファイル存在に基づいてステータスを自動更新 |
pdd status |
進捗をターミナルに表示 |
CLIで管理するメリットは、進捗管理ツールなどの外部サービス連携が不要でローカル完結できることです。進捗データはJSONファイルとしてリポジトリに含まれるため、Gitで履歴管理もできます。実装はシンプルで、JSONファイルの読み書きとディレクトリ走査だけです。お好みの言語やツールで実装できます。
自動スキャン
ソースコードを走査し、進捗ファイルのステータスを自動更新します。
pdd scan
動作:
- ソースコードのディレクトリを走査
- 各機能に対応するファイルの存在を確認
- ファイルが存在すれば
done、なければnoneに自動更新 - 手動で設定したステータスは上書きしない（
draftやstartedは維持）
実装後にこのコマンドを実行することで、進捗が自動的に反映されます。
進捗表示
進捗ファイルを読み込み、進捗を表示します。
pdd status
サマリー表示:
まず全体の進捗サマリーを表示します。
全体進捗 [██████████████░░░░░░] 70%
セクション別
01 認証 [███████░░░] 68%
02 ホーム [███████░░░] 70%
03 コンテンツ [███████░░░] 74%
04 検索 [██████░░░░] 63%
ステップ別
01 spec [██████████] 100%
02 design [██████████] 100%
03 database [█████████░] 86%
08 unit-test [███░░░░░░░] 25%
10 review [░░░░░░░░░░] 0%
「全体の70%が完了」「テストが遅れている」「レビューはまだ未着手」といった状況が一目で分かります。
マトリクス表示:
続いて、機能ごとの詳細をマトリクス形式で表示します。
凡例: [n]未着手 [s]着手 [d]仮完成 [r]レビュー済 [x]完了 [-]対象外
ステップ: [1]spec [2]design [3]database [4]ui [5]api [6]usecase [7]repository [8]unit-test [9]guide [10]review
🚀 01 認証
01 ユーザー登録 [██████░░░░] 63% [x] [x] [x] [-] [-] [x] [x] [n] [n] [n]
02 メール確認 [███████░░░] 67% [x] [x] [x] [-] [-] [x] [x] [n] [-] [n]
03 ログイン [████████░░] 75% [x] [x] [x] [-] [-] [x] [x] [x] [n] [n]
🚀 02 ホーム
01 ブックマーク [█████████░] 89% [x] [x] [x] [x] [x] [x] [x] [x] [-] [n]
02 パブリック [███████░░░] 67% [x] [x] [-] [-] [-] [x] [x] [n] [-] [n]
私の環境では、ターミナルで色分けして表示するようにしています（緑＝80%以上、黄＝50%以上、赤＝50%未満）。
🚀 開発の進め方
日々のワークフロー
私の日々の開発フローは以下の通りです。
1. 進捗確認
pdd status
全体の進捗率と、どこが遅れているかを確認します。
2. AIへの指示
「ログイン機能の08-unit-testを実装してください。
チェックリストは docs/progress/checklists/08-unit-test.md を参照。」
AIはチェックリストを見て、何をすべきか自己判断できます。
3. 自動スキャン
pdd scan
新しく作成されたファイルを検出し、ステータスを自動更新します。
4. レビュー
実際に動作確認し、問題なければ 10-review を done に更新します。
この繰り返しで、「次に何をすべきか」に迷うことなく開発を継続できます。
並行開発との組み合わせ
PDDは、Git Worktreeによる並行開発と組み合わせることで、さらに効率的になります。
| Worktree | 担当ステップ | 担当範囲 |
|---|---|---|
| spec-design | 01-spec, 02-design | 仕様・設計ドキュメント |
| database | 03-database | スキーマ・マイグレーション |
| frontend | 04-ui | 画面・コンポーネント |
| backend | 05-api, 06-usecase, 07-repository | サーバーサイド実装 |
| unit-test | 08-unit-test | テストコード |
| guide | 09-guide | ガイド・シードデータ |
| develop | 10-review | 統合、最終レビュー |
各Worktreeで別々のAIエージェントが並行して作業し、developブランチで統合します。
マージ順序（依存関係を考慮）:
1. spec-design ← 他の実装の参考になる
2. database ← スキーマが先にないとrepositoryが書けない
3. frontend ← 画面のモックを先に作る
4. backend ← DBスキーマに依存
5. unit-test ← 実装に依存
6. guide ← 実装完了後
依存関係を考慮した順序でマージすることで、コンフリクトを最小限に抑えられます。
チーム開発の場合、進捗の確認は全員で行い、進捗ファイルの更新はコンフリクトを避けるために管理者がまとめて行うとよいでしょう。
✅ まとめ
進捗駆動開発（PDD）について紹介しました。
| ポイント | 内容 |
|---|---|
| 位置づけ | SDD／TDDに進捗管理の視点を追加 |
| マトリクス管理 | 機能×ステップで進捗を可視化 |
| 進捗管理の仕組み | JSON + チェックリスト + 自動スキャン |
| 役割分担 | 仕様・設計は協力、実装はAI、レビューは人間 |
| 並行開発 | Git Worktreeで複数AIが同時作業 |
PDDは、AIエージェントの能力を最大限に活用しながら、人間が最終品質を保証する手法です。進捗を可視化することで「次に何をすべきか」が明確になり、個人開発の継続を助けてくれます。チーム開発への応用も可能です。
明日は「2025年の個人開発を振り返る」について書きます。
シリーズの他の記事
- 12/23: Claude Codeで変わった個人開発の進め方：AIペアプログラミングの実践
- 12/25: 2025年の個人開発を振り返る：技術・設計・運用の学び