レビュー・テスト・再リサーチループ 完全テンプレート集
Author: Manus AI
Version: 1.0
Purpose: 非エンジニアが「やりたいこと」を伝えた後、開発破綻リスクを抑えながら、リサーチ、要件定義、仕様化、ハーネス設計、テスト、レビュー、再リサーチ、再提案までを循環させるための実用テンプレート集。
0. このテンプレート集の使い方
このテンプレート集は、レビュー、テスト、再リサーチを単発作業ではなく、発見した問題を必ず要件・仕様・技術設計・テスト・リスク対策へ戻すループとして運用するためのものです。最初からすべてを完璧に埋める必要はありませんが、少なくとも Intent Sheet、Evidence Matrix、要件ID台帳、Test & Harness Plan、RYG Gate Log は導入初期から必ず使うことを推奨します。
重要原則: 根拠IDがないMust要件、テストIDがないMust要件、ハーネスがない破壊的操作はGreenにしない。
| テンプレート番号 | テンプレート名 | 主な用途 | 必須度 |
|---|---|---|---|
| 1 | Intent Intake Sheet | 素人の希望を整理する | 必須 |
| 2 | Assumption & Unknowns Log | 前提・不明点を管理する | 必須 |
| 3 | Research Brief | 調査指示を作る | 必須 |
| 4 | Evidence Matrix | 根拠を分類する | 必須 |
| 5 | Requirement ID Ledger | 要件・根拠・テストを接続する | 必須 |
| 6 | Acceptance Criteria Sheet | 受入基準を明確化する | 必須 |
| 7 | Technical Requirement Sheet | 技術要件を整理する | 必須 |
| 8 | Harness Design Sheet | 壊さず試す仕組みを設計する | 必須 |
| 9 | Test Plan Matrix | テスト計画を作る | 必須 |
| 10 | CI Quality Gate Sheet | CI/CD判定条件を定義する | 推奨 |
| 11 | Risk Register | リスクを台帳化する | 必須 |
| 12 | Codex Review Request | 実装・テストレビューを依頼する | 必須 |
| 13 | Opus Review Request | 要件・運用レビューを依頼する | 必須 |
| 14 | Review Finding Log | レビュー指摘を記録する | 必須 |
| 15 | RYG Gate Decision Log | 赤黄緑で次工程を判定する | 必須 |
| 16 | Re-Research Brief | 発見事項を再調査へ戻す | 必須 |
| 17 | Re-Proposal Sheet | 代替案・改善案を提示する | 必須 |
| 18 | Change Impact Matrix | 変更影響範囲を確認する | 推奨 |
| 19 | Loop Completion Checklist | ループ停止条件を確認する | 必須 |
| 20 | Project Learning Log | 学習を次回へ残す | 推奨 |
1. Intent Intake Sheet
目的
非エンジニアの「やりたいこと」を、すぐ仕様にせず、目的、成功状態、制約、避けたい失敗として整理します。この段階では、確定仕様ではなく仮説として扱います。
テンプレート
| 項目 | 記入内容 |
|---|---|
| プロジェクト名 | |
| 依頼者 | |
| 作成日 | |
| やりたいことを一文で | |
| なぜやりたいのか | |
| 誰のためのものか | |
| 成功した状態 | |
| 絶対に避けたい失敗 | |
| 使いたいサービス・ツール | |
| 使ってはいけないサービス・制約 | |
| 予算・期間 | |
| 運用者のスキル | |
| 本番で触る対象 | 例: DB、外部API、メール、SNS、決済、ファイル削除 |
| 自動化レベル | 完全自動 / 承認付き / 下書きのみ / 通知のみ |
| 個人情報・機密情報の有無 | |
| 初期判定 | Green / Yellow / Red / 未判定 |
注意点
「自動化したい」「便利にしたい」「安全にしたい」といった表現は、そのまま仕様にしてはいけません。必ず、どの操作を自動化するのか、誰が承認するのか、失敗時に何を止めるのかを後続テンプレートで具体化します。
2. Assumption & Unknowns Log
目的
プロジェクト開始時点の前提、不明点、確認待ち事項を明文化します。素人が見落としやすい前提のズレを早期に見つけるために使います。
テンプレート
| ID | 種別 | 内容 | 根拠 | 確認方法 | 担当 | 期限 | 状態 | 判定 |
|---|---|---|---|---|---|---|---|---|
| A-001 | 前提 | 未確認 / 確認済 / 破棄 | Green / Yellow / Red | |||||
| U-001 | 不明点 | 未確認 / 確認済 / 破棄 | Green / Yellow / Red |
注意点
不明点が多い状態で要件定義を確定してはいけません。特に、外部API、利用規約、料金、Rate Limit、認証、権限、データ保存、削除操作に関する不明点は、YellowまたはRedとして扱います。
3. Research Brief
目的
調査を場当たり的に行わず、何を、なぜ、どの根拠レベルで調べるのかを定義します。
テンプレート
| 項目 | 記入内容 |
|---|---|
| 調査ID | RS-001 |
| 調査テーマ | |
| 調査の目的 | |
| 判断したいこと | |
| 必ず確認する一次情報 | 公式Docs / 利用規約 / API Reference / Pricing / Security Policy |
| 確認する二次情報 | 技術ブログ / GitHub Issues / Community / Hackathon事例 / 論文 |
| 調査対象外 | |
| 成果物 | Evidence Matrix / Re-Proposal / Risk Update |
| 調査完了条件 | |
| 調査後の判定方法 | Green / Yellow / Red |
調査プロンプト
次の開発テーマについて、公式ドキュメント、利用規約、API制限、料金、セキュリティ、コミュニティ事例、失敗例を調査してください。
テーマ:
[調査テーマ]
判断したいこと:
[判断したいこと]
出力形式:
1. 公式根拠
2. 利用規約・制限
3. 実装上の注意点
4. 破綻リスク
5. 代替案
6. Green / Yellow / Red 判定
7. 要件・テスト・リスク台帳へ反映すべき項目
4. Evidence Matrix
目的
集めた情報を根拠の強さで分類し、要件化してよい情報と仮説扱いにすべき情報を分けます。
テンプレート
| Evidence ID | 情報源 | URL / 出典 | 種別 | 要約 | 根拠強度 | 関連要件ID | 関連リスクID | 採用判断 |
|---|---|---|---|---|---|---|---|---|
| EV-001 | 公式Docs / 規約 / 論文 / Blog / Community | High / Medium / Low | 採用 / 参考 / 仮説 / 不採用 |
根拠強度の基準
| 強度 | 条件 | 扱い |
|---|---|---|
| High | 公式Docs、規約、API Reference、標準文書 | Must要件の根拠にできる |
| Medium | 信頼できる技術記事、論文、実務事例 | Should要件や設計参考にできる |
| Low | SNS、個人投稿、未検証サンプル | 仮説扱いにする |
注意点
根拠がLowの情報をMust要件にしてはいけません。特に外部API、自動投稿、決済、個人情報処理、スクレイピング、自動ログインは、公式根拠がない限りGreenにしません。
5. Requirement ID Ledger
目的
すべての重要要件をID化し、根拠、受入基準、テスト、リスクに接続します。
テンプレート
| 要件ID | 種別 | 要件 | 優先度 | 根拠ID | 受入基準ID | テストID | リスクID | 状態 | 判定 |
|---|---|---|---|---|---|---|---|---|---|
| FR-001 | Functional | Must / Should / Could | EV- | AC- | T- | R- | Draft / Review / Approved / Rejected | Green / Yellow / Red | |
| NFR-001 | Non-Functional | Must / Should / Could | EV- | AC- | T- | R- | Draft / Review / Approved / Rejected | Green / Yellow / Red |
要件種別
| 種別 | 意味 |
|---|---|
| FR | 機能要件 |
| NFR | 非機能要件 |
| SEC | セキュリティ要件 |
| OPS | 運用要件 |
| DATA | データ要件 |
| API | 外部API要件 |
| UX | ユーザー体験要件 |
| COM | 法務・規約・コンプライアンス要件 |
注意点
要件IDに、根拠ID、受入基準ID、テストID、リスクIDが接続されていない場合、その要件はGreenにできません。接続できない場合は、要件が曖昧か、調査不足です。
6. Acceptance Criteria Sheet
目的
「できた」と判断する条件を、主観ではなく検証可能な条件に変換します。
テンプレート
| 受入基準ID | 関連要件ID | Given | When | Then | 測定方法 | 合格条件 | 不合格条件 | 備考 |
|---|---|---|---|---|---|---|---|---|
| AC-001 | FR-001 |
記入例
| 受入基準ID | 関連要件ID | Given | When | Then | 測定方法 | 合格条件 | 不合格条件 | 備考 |
|---|---|---|---|---|---|---|---|---|
| AC-001 | FR-001 | ユーザーが予定を登録済み | 予定開始30分前になったとき | 通知が1回だけ送信される | 通知ログ確認 | 1予定につき1通知 | 未通知、重複通知 | dry-runで先に検証 |
注意点
「使いやすい」「高速」「安全」のような言葉は、測定可能な条件へ変換します。変換できない場合、その要件はまだ確定できません。
7. Technical Requirement Sheet
目的
実装方式、技術制約、依存関係、権限、データ、非機能要件を整理します。
テンプレート
| 項目 | 記入内容 |
|---|---|
| 技術要件ID | TR-001 |
| 関連要件ID | |
| 採用技術 | |
| 採用理由 | |
| 代替候補 | |
| 外部依存 | |
| 認証・権限 | |
| データ保存場所 | |
| 秘密情報の扱い | |
| ログ方針 | |
| エラー処理方針 | |
| スケーラビリティ要件 | |
| セキュリティ要件 | |
| 運用・保守要件 | |
| 既知の制約 | |
| 判定 | Green / Yellow / Red |
注意点
技術選定は「作りやすい」だけで決めてはいけません。非専門家が運用できるか、保守できるか、障害時に止められるか、料金が予測可能かを必ず確認します。
8. Harness Design Sheet
目的
本番を壊さずに試すための安全装置を設計します。外部API、メール送信、SNS投稿、決済、ファイル削除、DB更新などを含む場合は必須です。
テンプレート
| ハーネスID | 関連要件ID | 対象操作 | 破壊リスク | 安全装置 | 検証方法 | ロールバック | 停止条件 | 判定 |
|---|---|---|---|---|---|---|---|---|
| H-001 | FR-001 | 高 / 中 / 低 | dry-run / mock / sandbox / fixture / kill switch | Green / Yellow / Red |
ハーネス部品チェックリスト
| 部品 | 必要性 | 設計内容 | 状態 |
|---|---|---|---|
| dry-run | 破壊的操作がある場合は必須 | 未 / 済 | |
| mock | 外部APIがある場合は推奨 | 未 / 済 | |
| fixture | 再現性が必要な場合は必須 | 未 / 済 | |
| sandbox | 本番分離が必要な場合は必須 | 未 / 済 | |
| kill switch | 自動実行がある場合は必須 | 未 / 済 | |
| rollback | データ更新がある場合は必須 | 未 / 済 | |
| audit log | 重要操作がある場合は必須 | 未 / 済 | |
| permission boundary | 権限操作がある場合は必須 | 未 / 済 |
注意点
本番で試してから安全策を作るのではなく、安全策があるから試せるという順序にします。dry-runがない破壊的操作はRedです。
9. Test Plan Matrix
目的
要件ごとの検証方法を明確にし、テスト不能な要件を発見します。
テンプレート
| テストID | 関連要件ID | テスト種別 | テスト内容 | 前提データ | 期待結果 | 自動化 | 実行タイミング | 合否 | 備考 |
|---|---|---|---|---|---|---|---|---|---|
| T-001 | FR-001 | Unit / Integration / E2E / Acceptance / Security / Regression / Smoke | Yes / No | PR / Release / Daily / Manual | Pass / Fail / Pending |
テスト種別の使い分け
| テスト種別 | 確認内容 |
|---|---|
| Unit | 個別関数・ロジック |
| Integration | 外部API、DB、サービス間連携 |
| E2E | ユーザー操作から完了まで |
| Acceptance | 受入基準を満たすか |
| Security | 権限、認証、秘密情報、個人情報 |
| Regression | 修正で既存機能が壊れていないか |
| Smoke | 本番反映後の最低限の動作 |
注意点
テストIDがないMust要件は実装に進めません。テスト不能な要件は、要件定義またはハーネス設計に戻します。
10. CI Quality Gate Sheet
目的
実装をマージ・リリースしてよい条件を自動・半自動で定義します。
テンプレート
| Gate ID | 対象 | 条件 | 閾値 | 失敗時アクション | 例外承認者 | 状態 |
|---|---|---|---|---|---|---|
| QG-001 | Unit Test | Stop / Yellow / Manual Review | Active / Draft | |||
| QG-002 | Security Scan | Stop / Yellow / Manual Review | Active / Draft |
推奨ゲート
| ゲート | 推奨条件 |
|---|---|
| Unit Test | 主要ロジックがPass |
| Integration Test | 外部API mockまたはsandboxでPass |
| Lint / Type Check | エラーなし |
| Secret Scan | 秘密情報の混入なし |
| Dependency Check | 重大脆弱性なし |
| Smoke Test | リリース後最低限の動作確認Pass |
注意点
CIゲートは、すべてを自動化できなくても構いません。ただし、失敗時の動きは明確にします。重大セキュリティ、秘密情報、破壊的操作のテスト失敗はRedです。
11. Risk Register
目的
開発、運用、規約、セキュリティ、費用、保守のリスクを管理します。
テンプレート
| リスクID | 関連要件ID | リスク内容 | 発生確率 | 影響度 | リスクレベル | 対策 | 残リスク | 監視方法 | 判定 |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | FR-001 | 高 / 中 / 低 | 高 / 中 / 低 | High / Medium / Low | Green / Yellow / Red |
リスク分類
| 分類 | 例 |
|---|---|
| 技術リスク | 実装困難、性能不足、依存ライブラリ不安定 |
| 外部APIリスク | Rate Limit、仕様変更、認証失敗 |
| 規約リスク | 自動化禁止、スクレイピング禁止、データ利用制限 |
| セキュリティリスク | 秘密情報漏洩、権限過大、認証不備 |
| 運用リスク | 非専門家が扱えない、復旧手順がない |
| 費用リスク | API料金増加、予算超過 |
| UXリスク | 誤操作、理解不能、通知過多 |
注意点
対策を書いて終わりにせず、残リスクと監視方法を必ず書きます。残リスクが説明できないものはGreenにしません。
12. Codex Review Request
目的
実装、テスト、CI、依存関係、エラー処理、セキュアコーディングの観点でレビューを依頼します。
テンプレート
あなたは実装・テスト・CI破綻を検出するレビュー担当です。
以下の資料とコードをレビューし、要件の採否ではなく、実装品質、テスト妥当性、CI、依存関係、例外処理、セキュリティ、破壊的操作の観点から判定してください。
対象:
- 要件ID:
- 関連仕様:
- 関連コード:
- テスト:
- ハーネス:
レビュー観点:
1. 要件IDと実装が対応しているか
2. Must要件にテストIDが接続されているか
3. 外部API失敗、Rate Limit、タイムアウトに対応しているか
4. dry-run、mock、sandbox、rollbackが設計されているか
5. 秘密情報や個人情報の扱いに問題がないか
6. CIで検出できる問題と手動確認が必要な問題は何か
7. 本番破壊リスクはないか
出力形式:
- 総合判定: Green / Yellow / Red
- 重大指摘:
- 中程度指摘:
- 軽微指摘:
- 修正案:
- 再リサーチすべき論点:
- 更新すべきテンプレート:
Codexレビュー記録表
| Review ID | 対象 | 判定 | 指摘内容 | 重大度 | 再リサーチID | 修正要否 | 状態 |
|---|---|---|---|---|---|---|---|
| CR-001 | Green / Yellow / Red | Critical / Major / Minor | RS- | Yes / No | Open / Closed |
注意点
Codexレビューは「コードを直してもらう場」ではありません。実装として破綻する条件を発見し、必要に応じて再リサーチへ戻すためのレビューです。
13. Opus Review Request
目的
要件、採否、運用、規約、保守、非専門家利用の観点でレビューを依頼します。
テンプレート
あなたは要件・採否・運用リスクを再分析するレビュー担当です。
以下のプロジェクトについて、技術的に作れるかだけでなく、作るべきか、非専門家が安全に運用できるか、規約やセキュリティ上の問題がないかを判定してください。
対象:
- Intent Sheet:
- Evidence Matrix:
- Requirement ID Ledger:
- Technical Requirement:
- Harness Design:
- Test Plan:
- Risk Register:
レビュー観点:
1. ユーザーの目的と要件が一致しているか
2. 根拠が弱いMust要件はないか
3. 規約違反・自動化禁止・データ利用制限はないか
4. 非専門家が誤操作せず運用できるか
5. 費用、保守、障害対応が現実的か
6. YellowをGreen扱いしていないか
7. 代替案や縮小案はあるか
出力形式:
- 総合判定: Green / Yellow / Red
- 採用してよい要件:
- 保留すべき要件:
- 停止すべき要件:
- 追加調査テーマ:
- 代替案:
- 更新すべきテンプレート:
Opusレビュー記録表
| Review ID | 対象 | 判定 | 採否判断 | 理由 | 再提案ID | 再リサーチID | 状態 |
|---|---|---|---|---|---|---|---|
| OR-001 | Green / Yellow / Red | 採用 / 保留 / 停止 | RP- | RS- | Open / Closed |
注意点
実装可能性と採用妥当性を混同しないことが重要です。技術的に作れても、規約違反、運用不能、費用過大、非専門家に危険な場合はRedまたはYellowです。
14. Review Finding Log
目的
レビューで見つかった指摘を、修正タスクだけでなく再リサーチ課題として記録します。
テンプレート
| Finding ID | 発見元 | 関連ID | 指摘内容 | 重大度 | 原因仮説 | 影響範囲 | 必要対応 | 再リサーチID | 状態 |
|---|---|---|---|---|---|---|---|---|---|
| F-001 | Codex / Opus / Test / User | Critical / Major / Minor | 修正 / 再調査 / 停止 / 代替案 | RS- | Open / Closed |
注意点
指摘を「修正済み」で閉じる前に、要件、仕様、テスト、ハーネス、リスク台帳へ反映したかを確認します。
15. RYG Gate Decision Log
目的
専門判断を非専門家でも扱えるGreen、Yellow、Redに変換し、次の行動を明確にします。
テンプレート
| Gate ID | 対象 | 判定 | 判定理由 | 次の行動 | 禁止事項 | 承認者 | 再確認日 | 状態 |
|---|---|---|---|---|---|---|---|---|
| G-001 | Green / Yellow / Red | Open / Closed |
判定基準
| 判定 | 意味 | 次の行動 |
|---|---|---|
| Green | 次工程へ進める | 実装、リリース、運用へ進む |
| Yellow | 条件付き検証のみ | sandbox、PoC、追加調査に限定する |
| Red | 停止 | 要件変更、代替案、撤退判断を行う |
注意点
Yellowは「ほぼGreen」ではありません。Yellowは本番禁止、隔離PoCのみ許可です。
16. Re-Research Brief
目的
レビューやテストで発見した問題を、局所修正で終わらせず、再調査テーマへ変換します。
テンプレート
| 再リサーチID | 起点Finding ID | 調査テーマ | なぜ再調査が必要か | 確認すべき情報源 | 期待する判断 | 期限 | 状態 |
|---|---|---|---|---|---|---|---|
| RRS-001 | F-001 | 公式Docs / 規約 / API制限 / 事例 / 論文 | Green / Yellow / Red | Open / Closed |
再リサーチプロンプト
次のレビュー指摘を、局所修正ではなく再リサーチ課題として扱ってください。
指摘内容:
[Finding]
現在の要件・仕様:
[関連要件・仕様]
調査してほしいこと:
1. 公式には何が推奨されているか
2. 利用規約や制限に抵触しないか
3. 類似事例では何が失敗しているか
4. 実装案を変更すべきか
5. 要件、テスト、ハーネス、リスク台帳のどこを更新すべきか
出力形式:
- 調査結果
- 根拠
- 代替案
- 更新すべき文書
- Green / Yellow / Red 判定
注意点
API制限、E2E不安定、規約リスク、誤操作リスクは、すぐ修正せず再リサーチへ戻します。
17. Re-Proposal Sheet
目的
再リサーチ結果をもとに、要件変更、代替案、縮小案、停止案を提示します。
テンプレート
| 再提案ID | 起点再リサーチID | 提案種別 | 提案内容 | メリット | デメリット | 影響範囲 | 推奨判定 | 採否 |
|---|---|---|---|---|---|---|---|---|
| RP-001 | RRS-001 | 継続 / 縮小 / 代替 / 停止 | 要件 / 仕様 / 技術 / テスト / 運用 | Green / Yellow / Red | 採用 / 保留 / 不採用 |
比較表
| 案 | 内容 | 安全性 | 実装容易性 | 運用容易性 | 費用 | 推奨度 |
|---|---|---|---|---|---|---|
| A案 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 | |
| B案 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 | 高 / 中 / 低 |
注意点
再提案は、単なる修正案ではありません。元の目的に対して、より安全で、より運用可能で、より検証可能な選択肢を提示します。
18. Change Impact Matrix
目的
要件や実装の変更が、仕様、テスト、ハーネス、リスク、運用に与える影響を確認します。
テンプレート
| 変更ID | 変更内容 | 影響要件ID | 影響テストID | 影響リスクID | 影響ドキュメント | 必要レビュー | 判定 |
|---|---|---|---|---|---|---|---|
| CH-001 | Codex / Opus / Security / User | Green / Yellow / Red |
注意点
コードだけ変更して、仕様、テスト、リスク台帳を更新しない状態を禁止します。変更は必ず文書体系へ反映します。
19. Loop Completion Checklist
目的
ループを止めてよいか、次工程へ進めてよいかを確認します。
テンプレート
| チェック項目 | 条件 | 状態 | 備考 |
|---|---|---|---|
| Intentが明確 | 目的、成功状態、避けたい失敗が記載済み | 未 / 済 | |
| 根拠が接続済み | Must要件にEvidence IDがある | 未 / 済 | |
| 受入基準が接続済み | Must要件にAC IDがある | 未 / 済 | |
| テストが接続済み | Must要件にTest IDがある | 未 / 済 | |
| ハーネスが設計済み | 破壊的操作にdry-run等がある | 未 / 済 | |
| リスク対策が記載済み | リスク、対策、残リスクがある | 未 / 済 | |
| Codexレビュー済み | 実装・CI・テスト観点の判定あり | 未 / 済 | |
| Opusレビュー済み | 要件・運用・採否観点の判定あり | 未 / 済 | |
| Yellowが隔離済み | YellowはPoCまたは追加調査に限定 | 未 / 済 | |
| Redが停止済み | Redは実装・本番進行していない | 未 / 済 | |
| 再リサーチ完了 | 指摘が再調査されている | 未 / 済 | |
| 再提案反映済み | 文書と方針が更新済み | 未 / 済 |
停止条件
| 条件 | 意味 |
|---|---|
| Green連続達成 | 主要要件が2回連続でGreenになった |
| 残リスク明文化 | 残リスクと監視方法が説明されている |
| Must要件100%接続 | 根拠、受入基準、テスト、リスクが接続済み |
| 本番破壊対策完了 | rollback、kill switch、audit logがある |
| 非専門家判断可能 | 次の行動が赤黄緑で明確 |
20. Project Learning Log
目的
今回のプロジェクトで得た知見を、次のプロジェクトのテンプレート改善へ回します。
テンプレート
| Learning ID | 発見内容 | 発生箇所 | 原因 | 今後の予防策 | 更新すべきテンプレート | 状態 |
|---|---|---|---|---|---|---|
| L-001 | 要件 / 技術 / テスト / 運用 / 規約 | Open / Closed |
注意点
学習ログは任意の反省メモではありません。次回以降、同じ失敗を防ぐために、テンプレート、チェックリスト、レビュー観点へ反映します。
21. 最小導入セット
初回導入時にすべてを使うのが難しい場合は、次の5つだけを必ず使います。
| 優先度 | テンプレート | 理由 |
|---|---|---|
| 1 | Intent Intake Sheet | 素人の希望を誤変換しないため |
| 2 | Evidence Matrix | 根拠の弱い要件を防ぐため |
| 3 | Requirement ID Ledger | 要件、根拠、テスト、リスクを接続するため |
| 4 | Harness Design Sheet / Test Plan Matrix | 壊さず検証するため |
| 5 | RYG Gate Decision Log | 非専門家でも次工程を判断するため |
22. 実務運用の黄金ルール
| ルール | 内容 |
|---|---|
| Rule 1 | 根拠IDがないMust要件は作らない |
| Rule 2 | テストIDがないMust要件は実装へ進めない |
| Rule 3 | dry-runがない破壊的操作はRedにする |
| Rule 4 | Yellowは本番禁止、隔離PoCのみ許可する |
| Rule 5 | レビュー指摘は必ず再リサーチIDへ変換する |
| Rule 6 | コード修正だけで閉じず、仕様・テスト・リスク台帳も更新する |
| Rule 7 | Redは失敗ではなく、破壊前に止められた成功として扱う |
23. 1機能に適用する場合の記入順序
| 順番 | 作業 | 使用テンプレート |
|---|---|---|
| 1 | やりたいことを整理 | Intent Intake Sheet |
| 2 | 前提と不明点を分離 | Assumption & Unknowns Log |
| 3 | 調査テーマを作成 | Research Brief |
| 4 | 根拠を収集・分類 | Evidence Matrix |
| 5 | 要件をID化 | Requirement ID Ledger |
| 6 | 受入基準を書く | Acceptance Criteria Sheet |
| 7 | 技術制約を整理 | Technical Requirement Sheet |
| 8 | 安全装置を設計 | Harness Design Sheet |
| 9 | テストを接続 | Test Plan Matrix |
| 10 | リスクを登録 | Risk Register |
| 11 | 実装レビュー | Codex Review Request |
| 12 | 採否・運用レビュー | Opus Review Request |
| 13 | 指摘を記録 | Review Finding Log |
| 14 | 赤黄緑判定 | RYG Gate Decision Log |
| 15 | 指摘を再調査 | Re-Research Brief |
| 16 | 改善案を提示 | Re-Proposal Sheet |
| 17 | 影響範囲を確認 | Change Impact Matrix |
| 18 | ループ停止判定 | Loop Completion Checklist |
| 19 | 学習を保存 | Project Learning Log |
24. 完成判定
このテンプレート体系が正しく機能している状態は、非エンジニアが専門判断を直接行わなくても、次のことが明確になっている状態です。
| 確認観点 | 完成状態 |
|---|---|
| 目的 | ユーザーのやりたいことと成功状態が明確 |
| 根拠 | 重要要件に公式または信頼できる根拠がある |
| 要件 | Must要件がID化されている |
| 受入基準 | 何をもって完了とするか検証可能 |
| 技術 | 採用技術と制約が説明されている |
| ハーネス | 本番を壊さず試せる |
| テスト | Must要件がテストIDに接続済み |
| レビュー | CodexとOpusの役割が分離されている |
| 判定 | Green、Yellow、Redで次行動が決まる |
| 再リサーチ | 指摘が学習と改善に戻る |
| 再提案 | 代替案、縮小案、停止案が提示される |
25. マスタープロンプト
以下は、このテンプレート体系全体を起動するためのマスタープロンプトです。
私は非エンジニアです。以下の「やりたいこと」を、世界最高基準の開発前準備に変換してください。
やりたいこと:
[ここに自然言語で記入]
あなたに実行してほしいこと:
1. Intent Intake Sheetを作成する
2. 前提と不明点をAssumption & Unknowns Logに分離する
3. 公式情報、規約、API制限、事例、失敗例を調査するResearch Briefを作る
4. Evidence Matrixで根拠を分類する
5. Requirement ID Ledgerで要件、根拠、受入基準、テスト、リスクを接続する
6. Acceptance CriteriaをGiven / When / Thenで書く
7. Technical Requirementを作る
8. Harness Designでdry-run、mock、sandbox、rollback、kill switchを設計する
9. Test Plan Matrixで各要件にテストIDを接続する
10. Risk Registerを作る
11. Codexレビュー依頼文を作る
12. Opusレビュー依頼文を作る
13. RYG Gate Decision LogでGreen / Yellow / Redを判定する
14. YellowまたはRedの項目はRe-Research Briefへ戻す
15. 再リサーチ結果からRe-Proposal Sheetを作る
重要ルール:
- 根拠IDがないMust要件は禁止
- テストIDがないMust要件は禁止
- dry-runがない破壊的操作は禁止
- Yellowは本番禁止、隔離PoCのみ許可
- Redは停止または設計変更
- レビュー指摘は必ず再リサーチIDへ変換する
出力は、各テンプレートを埋める形式で提示してください。
26. まとめ
このテンプレート集の本質は、文書を増やすことではありません。非エンジニアが見抜けない開発破綻リスクを、根拠、要件、仕様、ハーネス、テスト、レビュー、再リサーチ、再提案の接続によって発見し、壊れる前に止めることです。
最初は最小導入セットから始め、レビュー指摘を再リサーチへ戻す運用を定着させることで、プロジェクトごとにテンプレート自体も強化されていきます。