レビュー・テスト・再リサーチループ 統合README・運用開始チェックリスト
作成者: Manus AI
1. この成果物群で実現すること
この成果物群は、非エンジニアや開発経験の浅い人が「やりたいこと」を伝えるだけで、リサーチ、要件定義、仕様化、技術要件、ハーネス設計、テスト計画、レビュー、再リサーチ、再提案、ゲート判定までを一貫して進めるための運用体系である。
単なるテンプレート集ではなく、開発破綻リスクを早期発見し、修正だけで終わらせず、根拠調査と再提案へ戻すための実務OSとして構成している。
最重要原則は、素人に専門判断を要求しないことである。素人は目的、違和感、許容可否を判断し、技術的妥当性、リスク、テスト、ハーネス、規約、運用性はテンプレートとレビュー工程で検出する。
2. 成果物一覧
| ファイル |
目的 |
最初に読むべき人 |
review_loop_project_adoption_guide.md |
実プロジェクトへ導入する具体手順 |
PM、PdM、非エンジニア、導入責任者 |
review_test_reresearch_loop_templates_complete.md |
ループ各工程で使う基本テンプレート一式 |
全員 |
review_test_reresearch_loop_templates_examples_guide.md |
基本テンプレートの詳細記入例と判定解説 |
PM、レビュー担当、非エンジニア |
review_loop_template_field_examples_expanded.md |
項目ごとのさらに詳細な記入例・悪い例・良い例 |
実務記入者、レビュー担当 |
review_test_reresearch_loop_progress_task_templates.md |
進捗管理、担当割り当て、RACI、カンバン、週次運用 |
PM、スクラムマスター、開発リード |
review_loop_project_management_tool_setup_examples.md |
Notion、GitHub Projects、Jira等への設定例 |
PM、管理ツール担当 |
world_class_review_test_rersearch_loop_protocol.md |
レビュー、テスト、再リサーチの制度設計 |
品質責任者、技術責任者 |
review_test_loop_research_basis.md |
標準・実務根拠の整理 |
監査、品質、技術責任者 |
world_class_template_operating_guide_and_prompt_library.md |
AIに依頼するためのプロンプト集 |
AI活用担当、非エンジニア |
world_class_template_system_blueprint.md |
テンプレート体系全体の設計思想 |
経営、PMO、設計責任者 |
3. 推奨読書順
最初にすべてを読む必要はない。導入時は以下の順番で確認する。
| 順番 |
読むもの |
理由 |
| 1 |
review_loop_project_adoption_guide.md |
何から始めるべきかを理解する |
| 2 |
review_test_reresearch_loop_templates_complete.md |
実際に使うテンプレートを把握する |
| 3 |
review_loop_template_field_examples_expanded.md |
記入品質を上げる |
| 4 |
review_test_reresearch_loop_progress_task_templates.md |
担当、期限、進捗管理へ落とす |
| 5 |
review_loop_project_management_tool_setup_examples.md |
使用中の管理ツールへ設定する |
| 6 |
world_class_review_test_rersearch_loop_protocol.md |
ゲートと再リサーチループを制度化する |
4. まず作るべき5つの台帳
すべてのテンプレートを最初から運用する必要はない。実プロジェクトでは、まず以下の5つを作る。
| 優先 |
台帳 |
目的 |
最低限の必須項目 |
| 1 |
Intent台帳 |
やりたいこと、目的、成功条件を整理する |
Intent ID、目的、対象者、成功条件、不明点 |
| 2 |
Requirement台帳 |
要件をID化し、優先度と受入基準を持たせる |
Requirement ID、要件文、Priority、Acceptance Criteria |
| 3 |
Test台帳 |
要件とテストを接続する |
Test ID、Requirement ID、手順、期待結果、結果 |
| 4 |
Risk台帳 |
素人が見抜けない危険を可視化する |
Risk ID、内容、重大度、対策、RYG |
| 5 |
Gate台帳 |
進行可否をGreen/Yellow/Redで判断する |
Gate ID、判定、理由、解除条件、承認者 |
5. 運用開始チェックリスト
| チェック |
項目 |
完了条件 |
| [ ] |
対象プロジェクトを1つに限定した |
最初の対象機能または画面が明確である |
| [ ] |
使用ツールを決めた |
Notion、GitHub Projects、Jira、Sheets等から1つ選んだ |
| [ ] |
共通IDルールを決めた |
R-001、TC-001、RK-001、RR-001などの採番規則がある |
| [ ] |
RYG定義を決めた |
Green、Yellow、Redの意味と解除条件が定義されている |
| [ ] |
Must要件の条件を決めた |
Evidence IDとTest IDなしにMust化しないルールがある |
| [ ] |
レビュー担当を決めた |
Codexレビュー担当、Opusレビュー担当、最終承認者がいる |
| [ ] |
Gateを置いた |
DoneやReleaseの前にGate Decisionがある |
| [ ] |
Yellow放置防止を決めた |
Yellowには担当、期限、解除条件が必須である |
| [ ] |
Red時の停止ルールを決めた |
本番禁止、隔離PoC、再リサーチなどの扱いが明確である |
| [ ] |
週次レビューを予定した |
Red/Yellow、未レビュー、未テスト、再リサーチを確認する時間がある |
6. 初週の導入スケジュール
| 日 |
やること |
成果物 |
| Day 1 |
対象機能を決め、Intentを記入する |
Intent Sheet |
| Day 2 |
公式情報、事例、制約を調査する |
Evidence Matrix |
| Day 3 |
Must/Should/Couldで要件を分ける |
Requirement Register |
| Day 4 |
ハーネスとテストを設計する |
Harness Plan、Test Plan |
| Day 5 |
Codex/Opusレビューを実施する |
Review Report |
| Day 6 |
Red/Yellowを再リサーチへ起票する |
Re-Research Log |
| Day 7 |
再提案とGate判定を行う |
Re-Proposal、Gate Log |
7. ロール定義
| ロール |
主な責任 |
非推奨の状態 |
| Product Owner |
目的、優先度、許容可否を決める |
技術安全性まで一人で判断する |
| Research Owner |
根拠、競合、公式情報、規約を調査する |
出典なしで要件を確定する |
| Requirement Owner |
要件ID、受入基準、優先度を管理する |
曖昧な要望をそのまま実装へ渡す |
| Harness Owner |
sandbox、dry-run、rollback、ログ、権限制御を設計する |
本番で初めて試す |
| QA Owner |
テスト計画と結果を管理する |
手動確認だけで済ませる |
| Codex Reviewer |
実装、CI、テスト、破壊的変更を確認する |
要件採否や事業判断まで行う |
| Opus Reviewer |
要件、運用、リスク、採否、再提案を確認する |
コード差分だけを見る |
| Gate Owner |
Green/Yellow/Redの最終判定を管理する |
Yellowを放置して進める |
8. ゲート判定の基本定義
| 判定 |
意味 |
次アクション |
| Green |
実装、テスト、リスク、根拠が許容範囲であり進行可能 |
次フェーズへ進む |
| Yellow |
条件付きで進行可能だが、解除条件と期限が必要 |
隔離環境、追加テスト、再リサーチを行う |
| Red |
重大な破壊、規約違反、セキュリティ、運用不能、根拠不足がある |
停止し、再リサーチまたは再提案へ戻す |
9. 毎週の運用会議アジェンダ
| 順番 |
議題 |
確認するもの |
| 1 |
Red確認 |
Redの内容、停止理由、解除条件 |
| 2 |
Yellow確認 |
担当、期限、放置項目の有無 |
| 3 |
Must要件確認 |
Evidence ID、Test ID、Risk IDの接続 |
| 4 |
レビュー待ち確認 |
Codex/Opusレビュー未完了項目 |
| 5 |
再リサーチ確認 |
RR-ID、問い、結論、反映先 |
| 6 |
再提案確認 |
採用、却下、保留の判断 |
| 7 |
Gate判定 |
次フェーズへ進めるか |
10. 失敗防止ルール
| ルール |
理由 |
| 根拠IDがないMust要件を作らない |
思い込み実装を防ぐ |
| Test IDがない要件を実装へ進めない |
検証不能な開発を防ぐ |
| dry-runがない破壊的操作をRedにする |
本番破壊を防ぐ |
| Yellowは期限なしで放置しない |
リスクの常態化を防ぐ |
| レビュー指摘は必ずID化する |
指摘が口頭で消えるのを防ぐ |
| 修正で終わらせず再リサーチ要否を判断する |
同じ失敗の再発を防ぐ |
11. 完了判定
このループの完了は、単に実装が終わったことではない。以下を満たして初めて完了とする。
| 完了条件 |
判断基準 |
| Must要件の接続完了 |
すべてのMust要件にEvidence ID、Test ID、Risk IDがある |
| テスト完了 |
主要テストが成功し、失敗時の扱いが記録されている |
| ハーネス完了 |
sandbox、dry-run、rollback、ログ、権限が定義されている |
| Red解消 |
Redが0、または正式に停止・却下されている |
| Yellow管理 |
Yellowに担当、期限、解除条件がある |
| 再リサーチ反映 |
重要なRR-IDの結論が要件または仕様へ反映されている |
| Gate承認 |
Gate OwnerがGreenまたは条件付きGreenを承認している |
12. 最小運用から成熟運用への拡張
| 成熟度 |
状態 |
追加すべきもの |
| Level 1 |
テンプレートを手動で使う |
Intent、Requirement、Test、Risk、Gate |
| Level 2 |
管理ツールで進捗を追う |
RACI、Kanban、Dashboard、週次レビュー |
| Level 3 |
レビューを制度化する |
Codex/Opusレビュー、RYG基準、再リサーチ起票 |
| Level 4 |
CI・自動テストと接続する |
PRテンプレート、CI Gate、Release Checklist |
| Level 5 |
組織標準にする |
PMO運用、監査ログ、再利用可能なナレッジベース |
13. 最終結論
この成果物群は、非エンジニアが専門家のように要件定義や技術設計を行うためのものではない。むしろ、非エンジニアが専門判断を背負わなくても、やりたいことを安全に開発可能な形へ変換し、壊れる前に壊れる条件を見つけ、根拠に基づいて再提案できる状態を作るための体系である。
最初は1機能、5台帳、1週間の小さな導入で十分である。重要なのは、要件、根拠、テスト、リスク、レビュー、再リサーチ、再提案、ゲート判定を分断せず、同じID体系でつなぐことである。