レビュー・テスト・再リサーチループ 実プロジェクト導入ガイド

作成者: Manus AI
対象: 非エンジニア起点の新規開発、AI支援開発、既存プロジェクト改善、要件定義・仕様策定・ハーネス設計・テスト計画を含むプロジェクト

1. 導入ガイドの目的

この導入ガイドは、既に作成済みのテンプレート群を、実際のプロジェクトで迷わず使えるようにするための実行手順書である。目的は、非エンジニアが「やりたいこと」を伝えるだけで、調査、要件定義、仕様策定、技術要件、ハーネス設計、テスト計画、Codexレビュー、Opusレビュー、再リサーチ、再提案までを一貫して進められる状態を作ることである。

この仕組みでは、レビューを単なる指摘で終わらせない。テストを単なる動作確認で終わらせない。再リサーチを単なる調査メモで終わらせない。すべての発見事項を、要件、仕様、技術要件、ハーネス、テスト、タスク、ゲート判定へ戻すことで、開発破綻リスクを継続的に下げる。

導入の本質は、作業管理を増やすことではなく、素人が見抜けないリスクを構造的に発見し、設計へ戻すことである。

2. 導入前に決めること

導入前に、プロジェクトの規模、対象範囲、適用レベル、関係者、利用ツールを決める。ここを曖昧にすると、テンプレートが「書類」になり、実務の意思決定に使われなくなる。

3. 導入ステージ全体像

導入は、準備、初期適用、レビュー運用、再リサーチ運用、定着化の5段階で進める。最初から全テンプレートを完璧に使う必要はないが、要件、根拠、テスト、リスク、ゲート判定は最初から接続する。

4. 初回導入の最小セット

初回導入では、すべてのテンプレートを同時に運用しようとしない。最低限、以下の7種類を使えば、ループの骨格は成立する。

5. 具体的な導入手順

Step 1. プロジェクトの対象範囲を1つに絞る

最初に、ループを適用する対象を限定する。対象は「プロジェクト全体」ではなく、「1つの機能」「1つの業務フロー」「1つのリリース単位」にする。例えば、ECサイト全体ではなく、「会員登録からメール認証まで」に限定する。

Step 2. ID体系を決める

進捗管理とレビューを成功させるには、すべての要素をIDで接続する必要がある。IDがないと、レビュー指摘がどの要件に関係するのか、テストが何を検証しているのか、再リサーチ結果をどこへ戻すべきかが分からなくなる。

Step 3. ロールを割り当てる

小規模プロジェクトでは1人が複数ロールを兼任してよい。ただし、実行者と承認者を同じにしないことが望ましい。特に、本番影響、外部API、個人情報、課金、データ削除を含む場合は、最低でもProduct Owner、Tech Lead、QA/Harness Ownerの判断を分ける。

Step 4. Intent Sheetを作る

素人の要望は、そのまま要件にしない。まず、目的、対象者、成功条件、不明点、制約、やらないことへ分解する。ここで重要なのは、ユーザーが言ったことを否定せず、実装可能な仮説へ翻訳することである。

Step 5. 強化リサーチを行う

リサーチでは、単に便利そうな情報を集めるのではなく、要件化に使える根拠を集める。一次情報、公式ドキュメント、規約、論文、コミュニティ事例、失敗事例を区別する。

Step 6. 要件と受入基準へ変換する

リサーチが終わったら、希望を要件IDへ変換する。各要件には、根拠ID、優先度、受入基準、テストID、リスクIDを接続する。根拠が弱いものはMustにしない。

Step 7. ハーネス設計を先に行う

実装前に、壊れないための実行環境を定義する。特に、ファイル削除、DB更新、外部API送信、メール送信、課金、公開投稿などの破壊的操作がある場合は、dry-run、sandbox、rollback、権限制御、監査ログを必須にする。

Step 8. テスト計画を作る

テストは「動いたか」ではなく、「要件を満たし、壊れないことを示せるか」を確認する。Must要件は必ずテストIDへ接続する。接続できない要件は、曖昧すぎる可能性があるため要件へ戻す。

Step 9. Codexレビューを実施する

Codexレビューでは、実装、テスト、CI、差分、破壊的変更、セキュリティ、エラー処理、ログを確認する。ここでは事業採否ではなく、実装破綻を見つけることに集中する。

Step 10. Opusレビューを実施する

Opusレビューでは、要件、目的適合性、ユーザー価値、運用負荷、規約、倫理、長期リスク、採否を確認する。ここではコードの細部ではなく、プロジェクトとして進めるべきか、代替案が必要かを判断する。

Step 11. ゲート判定を行う

各フェーズの最後に、Green / Yellow / Redを判定する。Yellowは「条件付きで進める」、Redは「止める」である。YellowとRedには必ず担当、期限、次アクションを付ける。

Step 12. 再リサーチを起票する

レビューやテストで原因不明、根拠不足、外部仕様不明、運用リスク不明が見つかった場合は、修正だけで閉じずに再リサーチへ回す。

Step 13. 再提案へ戻す

再リサーチの結果は、必ず要件、仕様、技術要件、ハーネス、テスト、タスク、ゲート判定へ反映する。反映しない調査は、プロジェクトを安全にしない。

6. 30日導入ロードマップ

実プロジェクトで定着させるには、30日で最小運用から通常運用へ移行するのが現実的である。

7. 成功条件と失敗条件

導入が成功している状態は、ドキュメントが多い状態ではない。重要な意思決定が、根拠、要件、テスト、レビュー、リスクへ接続されている状態である。

8. 運用会議の推奨設計

会議体は短く、判断は明確にする。非エンジニアが参加する場では、技術詳細よりも、目的適合、リスク、RYG、次アクションを中心に話す。

9. すぐ使える導入チェックリスト

10. 結論

この導入ガイドに従うと、非エンジニアの漠然とした希望を、実装可能で検証可能な要件へ変換し、さらに安全に作るためのハーネス、テスト、レビュー、再リサーチ、再提案まで一体化できる。重要なのは、テンプレートを埋めること自体ではなく、発見したリスクを必ず設計と判断へ戻す運用である。

このループが機能しているプロジェクトでは、実装の速さだけで進まない。壊れる条件、失敗する条件、素人が見抜けない危険を先に発見し、調べ直し、仕様を修正し、テストで確認してから進む。これが、レビュー・テスト・再リサーチループを実プロジェクトに導入する最大の価値である。