汎用プロジェクト成果物テンプレート集

作成者: Manus AI
用途: Webアプリ、モバイルアプリ、API、業務システム、AIツール、SaaS、社内自動化、データ基盤、PoCなど、幅広いプロジェクトで使える成果物テンプレート集。
想定成果物: 要件定義書、受入基準、テスト計画書、実装計画書、リスク台帳、レビュー指摘台帳、変更管理台帳、最終判定書。

0. 共通ルール

本テンプレートでは、すべての要件、テスト、実装タスク、レビュー指摘にIDを付与する。IDを付けることで、要件、受入基準、テスト、実装計画、レビュー指摘の対応関係を追跡できる。

1. 要件定義書テンプレート

1.1 文書情報

1.2 エグゼクティブサマリー

本プロジェクトは、[誰] の [どの課題] を解決するために、[何を作るか] を構築するものである。初期版では、[MVPの範囲] に集中し、[成功指標] を満たすことを目指す。

1.3 背景と課題

現在、[現状] により、[問題] が発生している。この問題により、[影響] が生じているため、本プロジェクトでは [解決方針] を実現する。

1.4 目的と成功指標

1.5 利用者と権限

1.6 スコープ

1.7 業務フロー・ユーザーフロー

flowchart TD
  A[開始] --> B[操作または処理]
  B --> C{条件分岐}
  C -->|成功| D[完了]
  C -->|失敗| E[エラー対応]

1.8 機能要件

1.9 データ要件

1.10 外部連携・API要件

1.11 非機能要件

1.12 セキュリティ・プライバシー要件

1.13 制約条件

1.14 未決事項

2. 受入基準テンプレート

受入基準は、機能が完成したかどうかを判断する条件である。可能な限り、Given / When / Then 形式で記述する。

2.1 受入基準チェックリスト

3. テスト計画書テンプレート

3.1 文書情報

3.2 テスト方針

本テスト計画では、要件定義書に記載された機能要件、非機能要件、セキュリティ要件、受入基準が満たされていることを確認する。特に、MVPの成立に必要なMust要件、データ破壊や権限不備につながるBlocker、主要業務フローを優先して検証する。

3.3 要件・受入基準・テスト対応表

3.4 テストケース一覧

3.5 テスト完了条件

4. 実装計画書テンプレート

4.1 文書情報

4.2 実装方針

本実装計画では、すべてを一度に作るのではなく、MVPの成立に必要なMust要件から段階的に実装する。各フェーズにはExit Criteriaを設定し、未達の場合は次フェーズへ進まない。

4.3 フェーズ計画

4.4 タスク一覧

4.5 Exit Criteria

5. リスク台帳テンプレート

6. レビュー指摘台帳テンプレート

Codexレビュー、Opus再分析、人間レビューの結果は、必ず同じ指摘台帳に集約する。

7. 変更管理台帳テンプレート

8. Codexレビュー依頼テンプレート

あなたは、要件定義、テスト計画、実装計画を独立レビューする上級レビュー担当者です。

以下の成果物をレビューし、次工程へ進んでよいかを判定してください。

# 入力ファイル
- 要件定義書: requirements.md
- 受入基準: acceptance_criteria.md
- テスト計画書: test_plan.md
- 実装計画書: implementation_plan.md
- リスク台帳: risk_register.md

# レビュー観点
1. 目的、利用者、MVP、成功指標が明確か。
2. In Scope / Out of Scope / Laterが分離されているか。
3. 機能要件と受入基準が対応しているか。
4. 要件とテストが対応しているか。
5. 非機能要件、セキュリティ要件、運用要件に重大な抜けがないか。
6. 実装計画が現実的で、依存関係とExit Criteriaが明確か。
7. Blocker、Must、Should、Laterの分類が妥当か。
8. 過剰設計や、今決めなくてよい論点がMust化されていないか。
9. 未決事項が次工程を止めるものか、後で判断できるものか。
10. GO / CONDITIONAL GO / NO-GO / ESCALATE のどれが妥当か。

# 出力形式
## 1. 全体判定
GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれか。

## 2. 判定理由

## 3. 指摘一覧
| No | 区分 | 指摘内容 | 根拠 | 影響 | 推奨対応 | 対象ファイル |
|---:|---|---|---|---|---|---|

## 4. Blocker一覧

## 5. Must / Should / Later一覧

## 6. テスト計画への指摘

## 7. 実装計画への指摘

## 8. 人間判断が必要な事項

# 制約
一般論だけでNO-GOにしないでください。NO-GOにする場合は、具体的なBlockerと根拠を示してください。

9. Opus再分析テンプレート

あなたは、Codexレビュー結果を再分析する上級レビュー担当者です。

Codexの回答は鵜呑みにせず、要件定義書、受入基準、テスト計画、実装計画、リスク台帳、実ファイル、一次ソース、プロジェクト目的を確認したうえで、各指摘に対して ACCEPT / MODIFY / REJECT / HOLD / ESCALATE を判定してください。

# 入力ファイル
- Codexレビュー結果: _reviews/round1_codex_result.md
- 要件定義書: requirements.md
- 受入基準: acceptance_criteria.md
- テスト計画書: test_plan.md
- 実装計画書: implementation_plan.md
- リスク台帳: risk_register.md

# 出力形式
## 1. ラウンド判定
GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれか。

## 2. Codex指摘ごとの判定表
| No | Codex指摘 | Opus判定 | 重要度 | 根拠 | 反映方針 | 備考 |
|---:|---|---|---|---|---|---|

## 3. Blocker / Must / Should / Later / Reject / Escalate一覧
| 区分 | 論点 | 対応方針 | 対象ファイル | 次アクション |
|---|---|---|---|---|

## 4. 過剰設計リスクの評価

## 5. 要件定義書・テスト計画・実装計画への修正文案

## 6. 次ラウンドが必要か
必要 / 不要 / 人間判断へ移行 のいずれか。

# 反復レビュー終了条件
CodexとOpusの判断が一致しない場合でも、最大3ラウンドで終了してください。3ラウンドでも収束しない場合は、人間判断へエスカレーションしてください。

10. 最終判定書テンプレート

10.1 判定サマリー

10.2 判定理由

本判定では、要件定義、受入基準、テスト計画、実装計画、リスク、レビュー指摘の状態を確認した。結論として、[GO/CONDITIONAL GO/NO-GO/ESCALATE] と判断する。

10.3 残課題

10.4 最終アクション

11. 成果物チェックリスト

12. 推奨ファイル構成

project-root/
  requirements.md
  acceptance_criteria.md
  test_plan.md
  implementation_plan.md
  risk_register.md
  change_log.md
  _reviews/
    round1_codex_prompt.md
    round1_codex_result.md
    round1_opus_prompt.md
    round1_opus_result.md
    review_issue_register.md
    final_decision.md

この構成により、要件、テスト、実装、レビュー、最終判定を分離しつつ、IDで相互追跡できる。