第 3 章

PRD とドキュメント駆動

ドキュメント駆動開発の核心的な考え方を習得し、AI を活用して PRD を書く方法を学び、構造化された思考法を身につけ、ドキュメントを開発の羅針盤にしましょう。

核心となる洞察：文書こそがコンテキスト

AI プログラミングの時代において、ドキュメントは負担ではなく、AI が要件を理解するための文脈です。 優れた PRD によって、AI は要件を正確に理解し、期待どおりのコードを生成できます。前章の VibeCoding ワークフローを見終えたところで、次に AI が読みやすいドキュメントの書き方を学びましょう。

PRDが必要な理由

従来の開発では、PRDはチーム内のコミュニケーションツールでした。AIコーディングの時代では、PRDはAI が要件のコンテキストを理解する。

従来の開発

  • • PRD はチーム内のコミュニケーションに使う
  • • 要件理解は人による議論に依存する
  • • ドキュメントとコードが乖離しやすい
  • • 変更は手動で同期する必要がある

AIプログラミングの時代

  • • PRD は AI のコンテキスト
  • • AI が PRD を直接読み取ってコードを生成
  • • ドキュメント即コード、バージョン同期
  • • 変更が自動的にコード更新をトリガーする

ドキュメント駆動の価値

手戻りを減らす：先にドキュメントを書き、AI が理解してからコーディングすることで、理解のずれを防ぐ
品質を向上させる：構造化ドキュメントにより、AI はより正確なコードを生成できる
トレーサビリティ：ドキュメントのバージョン管理、変更履歴が明確
チームコラボレーション：ドキュメントはチームの共通言語であり、コミュニケーションコストを削減する

構造化思考法：Sequential Thinking

PRD を書くことは一朝一夕ではなく、必要なのは構造的思考。 Sequential Thinking（順次思考）メソッドを使用して、複雑な問題を管理可能なステップに分解します。

Sequential Thinking ワークフロー

1

問題の分解

複雑な要件を複数のサブ問題に分解し、各サブ問題を独立して解決可能にする

2

段階的思考

各サブ問題ごとに段階的に深く考え、思考過程を記録する

3

仮説を検証する

各仮説を検証し、論理が正しいことを確認する

4

統合ソリューション

各サブ問題の解決策を統合して完全なソリューションにする

5

反復的な最適化

フィードバックに基づいて継続的に最適化し、ソリューションを改善する

実践例：ユーザーログイン機能

思考ステップ 1：問題の分解
• ユーザーはどのようにアカウントとパスワードを入力しますか？
• ユーザーの身元をどのように検証するか？
• ログイン成功後、状態をどのように保持するか？
• ログイン失敗をどう処理するか？
思考ステップ 2：段階的に深める
• フロントエンド：フォーム検証、エラーメッセージ、読み込み状態
• バックエンド：パスワード暗号化、トークン生成、セッション管理
• セキュリティ：総当たり攻撃対策、CSRF保護
思考ステップ 3：統合案
フロントエンド、バックエンド、セキュリティの3つの観点の方案を統合して、完全なログイン機能設計にする

AI を活用して構造化思考を支援する

Sequential Thinking MCP ツールや同様の思考法を使って、AI に次のことを手伝ってもらう:

  • •複雑な問題を分解する：AI が重要なサブ問題の特定を支援します
  • •思考過程を記録する：各ステップの思考がすべて記録され、追跡可能
  • •検証ロジック：AI がロジックの穴をチェックします
  • •反復的な最適化：フィードバックに基づいて継続的に改善する

PRD 作成ガイド

PRD（Product Requirements Document）は、製品要件の完全な説明です。AI コーディングの時代において、PRD には構造化され、実行可能で、AI が読みやすい。

PRD のコア構造

1. 製品概要

必須

製品の位置づけ、対象ユーザー、コアバリュー、一文での目標

2. 機能要件

必須

機能一覧、ユーザーストーリー、優先順位、受け入れ基準

3. 非機能要件

必須

パフォーマンス、セキュリティ、可用性、スケーラビリティの要件

4. インターフェース定義

必須

入出力、データ構造、エラー処理、API 仕様

5. 制約と仮定

必須

技術的制約、リソース制限、前提条件、非目標

6. 検収基準

必須

機能受け入れ、性能受け入れ、セキュリティ受け入れ、DoD チェックリスト

AI が読み取れる PRD の原則

❌ あいまいな説明
ユーザーログイン機能 - ユーザーはログインできる - ログイン後、システムにアクセスできる
✅ 構造化された説明
ユーザーログイン機能 目標：ユーザーがアカウントとパスワードでシステムにログインする 入力：username (string), password (string) 出力：token (string), userInfo (object) エラー：401 パスワードが間違っています、429 リクエストが多すぎます 受け入れ基準：正しいパスワードを入力すると token が返され、間違ったパスワードでは 401 が返される

PRD作成のベストプラクティス

  • 明確な目標：各機能は「なぜ必要か」と「一文の目標」に答える必要があります
  • 非目標を定義する：何をしないかを明確に示し、スコープの拡大を避ける
  • 構造化された記述：Markdown形式を使用し、明確な階層構造にする
  • テスト可能性：要件は検証・テスト可能である必要があり、受け入れ基準を含む
  • バージョン管理：PRD はコードのようにバージョン管理（Git）すべき
  • 継続的に更新：要件変更時に文書を своевに更新し、文書とコードを同期させる

Spec 駆動開発

Spec-Driven Development は強調するまず仕様を書き、それからコードを書く。規範はすなわちコンテキストであり、AI が要件をよりよく理解し、期待どおりのコードを生成するのに役立ちます。

従来の開発プロセス

1要件の議論
2直接コーディング
3問題を発見する
4手戻り修正

Spec 駆動フロー

1Spec を作成
2レビュー承認
3Specに基づくコーディング
4Spec に従って受け入れ

Spec の核心要素

1
目標 (Goals)：この機能は何の問題を解決するのか？一言でいうと何が目的か？
2
非目標 (Non-Goals)：この機能は何をしないのか？境界を明確にする
3
インターフェース定義：入出力、データ構造、エラー処理、API仕様
4
受け入れ基準 (Acceptance Criteria)：何をもって完了とするか？機能受入テスト、性能受入テストを含む

AIを使用してSpecを生成

AI に要件から Spec を生成させ、その後あなたがレビューして最適化します：

Prompt の例：
ユーザーログイン機能の Spec を生成してください。以下を含めてください： 1. 目標と非目標 2. インターフェース定義（入出力、エラー処理） 3. 受け入れ基準 4. 技術的制約

WBS 作業分解

WBS（Work Breakdown Structure）は複雑なプロジェクトを管理しやすい小さなタスクに分解します。AI プログラミング時代には、タスク分解により、AI は段階的に実行できる、成功率を高めます。

分解の原則

MECE 原則
相互に排他的で、完全に網羅的（Mutually Exclusive, Collectively Exhaustive）
適度な粒度
各タスクは1～3日で完了でき、AIによる段階的な実行に適している
提供可能
各タスクには明確な成果物があり、検証可能
依存関係が明確
タスク間の依存関係を明確にし、実行順序を決定する

例：ユーザーログイン機能

WBS 構造：
ユーザーログイン機能 ├─ フロントエンドログインページ │ ├─ UI コンポーネント開発 │ ├─ フォーム検証 │ └─ エラーメッセージ表示 ├─ バックエンド API 開発 │ ├─ ログイン API │ ├─ Token 生成 │ └─ セッション管理 └─ テスト ├─ 単体テスト └─ 統合テスト

AI を使ってタスク分解を支援する

AIにPRDを実行可能なタスクリストに分解させる：

Prompt の例：
以下のPRDをWBSタスクリストに分解してください： [PRDの内容を貼り付け] 要件： 1. 各タスクの粒度は適切にする（1〜3日で完了可能） 2. タスク間の依存関係を明確にする 3. 各タスクに明確な受け入れ基準を設ける

DoD 完了の定義

DoD（Definition of Done）は、タスク完了の受け入れ基準を定義します。 AIプログラミング時代では、DoD は自動でチェックできます、品質の一貫性を確保します。

標準 DoD チェックリスト

コードはすべてのテスト（単体テスト、統合テスト）に合格しました
コードはコードレビュー（AI レビュー + 人間レビュー）を通過済み
ドキュメントを更新しました（PRD、APIドキュメント、README）
コーディング規約に準拠する（ESLint、Prettier、TypeScript）
テスト環境にデプロイ済みで、検証に合格済み
プロダクトマネージャーが受け入れ済み（機能は PRD に適合）

AI 自動化 DoD チェック

AI ツールを使って DoD チェックリストを自動確認し、効率を向上させる：

コードレビュー
AI コードレビュー ツール（Cursor、GitHub Copilot など）を使用してコード品質を自動的にチェックする
テスト生成
AI を使ってテストケースを生成し、コードカバレッジを確保する
ドキュメント同期
AIを使用してドキュメントとコードの整合性を確認し、ドキュメントを自動更新する

DoD の価値

  • • 品質保証：すべてのタスクが統一された品質基準を満たすことを保証する
  • • 手戻りを減らす：問題を早期に発見し、後の修正を避ける
  • • チームの合意形成：全員が「完了」の意味を統一して理解している
  • • トレーサビリティ：各タスクの完了状況を明確に記録する
  • • AI に優しい：明確な受け入れ基準により、AI はいつタスクを完了すべきかを知ることができる

ドキュメント・アズ・コード

AI プログラミングの時代において、ドキュメントはコードのように管理すべきです： バージョン管理、コードレビュー、自動チェック、継続的インテグレーション。

ドキュメントのバージョン管理

Git でドキュメントを管理する
docs/prd/
├── user-login.md
├── user-profile.md
└── README.md
  • • ドキュメントの変更は PR で提出し、コードレビュー
  • • ドキュメントのバージョンとコードのバージョンを同期する
  • • 変更履歴が明確で追跡可能

ドキュメントの自動化チェック

CI/CD 統合
  • • PRD の形式が規範に合っているか確認する
  • • ドキュメントとコードの整合性を確認する
  • • API ドキュメントを自動生成
  • • 文書の完全性を確認する（必須フィールド）

ドキュメントがコンテキストになる

ドキュメントは記録であるだけでなく、AI が要件のコンテキストを理解する。 優れたドキュメントは、AI が要件を正確に理解し、期待どおりのコードを生成するのに役立ちます。ドキュメントとコードは同期して更新し、一貫性を保つ必要があります。

学習成果

この章を終えると、あなたは：

  • 1ドキュメント駆動開発の核心となる考え方を理解し、ドキュメントがコンテキストであるという理念を習得する
  • 2構造化思考法（Sequential Thinking）を習得し、複雑な問題を分解できる
  • 3完全な製品要件を含む、AI が読み取れる PRD ドキュメントを作成できる
  • 4Spec駆動開発プロセスを習得し、仕様がコンテキストであるという理念を理解する
  • 5効果的なタスク分解（WBS）を行い、プロジェクトの進捗を管理できる
  • 6DoD の重要性を理解し、明確な受け入れ基準を定義できる
  • 7ドキュメント・アズ・コードの管理方法を習得し、ドキュメントのバージョン管理プロセスを構築する
前章：AI 利用マニュアル次の章：AI ネイティブ開発モード