レビュー・テスト・再リサーチループ 進捗管理・タスク割り当てテンプレート

作成者: Manus AI
対象: 非エンジニア起点のプロジェクト、AI支援開発、要件定義、仕様策定、ハーネス設計、テスト計画、レビュー、再リサーチ、再提案を含む開発運用

1. このテンプレートの目的

このテンプレートは、レビュー・テスト・再リサーチループを実際のプロジェクトで運用するための進捗管理とタスク割り当ての標準フォーマットである。単に「誰が何をやるか」を管理するのではなく、各タスクがどの要件、根拠、リスク、テスト、レビュー、再リサーチ課題に接続しているかを追跡することを目的とする。

重要な考え方は、タスクを作業単位ではなく、根拠・要件・リスク・検証・判定に接続された管理単位として扱うことである。

このテンプレートでは、非エンジニアが「やりたいこと」を伝えた後、調査、要件化、仕様化、実装、レビュー、テスト、再リサーチ、再提案までを漏れなく管理できるようにする。特に、開発破綻リスクを下げるため、Red / Yellow / Green判定、再リサーチ起票、ブロッカー管理、CodexレビューとOpusレビューの役割分担を明示的に組み込んでいる。

2. 全体フェーズ進捗管理テンプレート

プロジェクト全体を一枚で把握するためのテンプレートである。週次レビュー、ステアリング会議、プロジェクト開始時の初期設計、またはAIエージェントに進捗確認を依頼する際に使用する。

3. ロール定義・責任分担テンプレート

進捗管理を成功させるには、担当者の名前だけではなく、判断権限と責任範囲を明確にする必要がある。特にAI支援開発では、AIに任せる作業、人間が判断する作業、非エンジニアが確認する作業を混同しないことが重要である。

4. フェーズ別タスク割り当てテンプレート

各フェーズで発生する具体タスクを、担当、依存関係、成果物、判定基準と一緒に管理するためのテンプレートである。作業が増えた場合でも、タスクをこの表へ追加することで、どの工程に遅延やリスクがあるかを可視化できる。

5. カンバン型進捗ボードテンプレート

日次または週次で運用する場合は、詳細表だけでなく、カンバン形式で現在位置を確認するとよい。特にAI支援開発では、調査中、レビュー待ち、再リサーチ中のタスクが滞留しやすいため、状態を明確に分ける。

カンバン運用ルール

6. RACIタスク割り当てテンプレート

タスクごとに責任者、実行者、相談先、報告先を分けるためのテンプレートである。プロジェクトが小さい場合でも、判断責任を曖昧にしないために有効である。

7. 週次進捗レビュー議事録テンプレート

週次レビューでは、単なる進捗報告ではなく、リスク、ブロッカー、再リサーチ課題、ゲート判定の更新を行う。以下のテンプレートを使うことで、会議後に次アクションが曖昧になることを防ぐ。

8. 日次スタンドアップ用テンプレート

小規模チームやAI支援開発では、長い会議よりも短い日次確認のほうが効果的な場合が多い。以下の項目だけを毎日確認する。

9. ゲート判定管理テンプレート

レビュー・テスト・再リサーチループでは、各フェーズを「なんとなく完了」にしない。必ずゲート判定を記録し、Green、Yellow、Redの理由と次アクションを明示する。

ゲート判定基準

10. ブロッカー管理テンプレート

ブロッカーは「止まっている理由」だけではなく、解除条件、責任者、期限、代替案まで記録する必要がある。

11. 再リサーチ起票テンプレート

レビューやテストで見つかった問題は、その場の修正だけで終わらせない。原因が不明、根拠が不足、外部仕様が不安定、運用影響が読めない場合は、必ず再リサーチ課題として起票する。

12. 再提案・変更反映タスク管理テンプレート

再リサーチの結果は、必ず要件、仕様、テスト、ハーネス、リスク台帳のいずれかに反映する。調査しただけで終わると、同じ問題が次のループで再発する。

13. 要件・タスク・テスト・レビューのトレーサビリティテンプレート

世界最高基準の運用では、各タスクがどの要件を満たし、どのテストで検証され、どのレビューで確認されたかを追跡できる必要がある。

14. スプリント計画テンプレート

レビュー・テスト・再リサーチループを2週間または1週間のスプリントで回す場合のテンプレートである。

スプリントバックログ

15. 期限・依存関係管理テンプレート

タスクが遅れる原因の多くは、依存関係が見えていないことである。特に、調査が終わらないと要件が固まらず、要件が固まらないとテストもハーネスも設計できない。

16. リスク連動タスク管理テンプレート

リスクはリスク台帳に書くだけでは不十分である。各リスクに対して、具体的な対策タスク、担当、期限、検証方法を割り当てる。

17. AIレビュー依頼タスクテンプレート

CodexやOpusなどのAIレビューに依頼する際は、目的、対象範囲、判断してほしい観点、出力形式を明確にする必要がある。

18. Codexレビュー進捗管理テンプレート

Codexレビューで必ず確認する項目

19. Opusレビュー進捗管理テンプレート

Opusレビューで必ず確認する項目

20. 完了判定チェックリスト

各ループまたはリリース前に、以下の項目を確認する。すべてを満たせない場合は、GreenではなくYellowまたはRedとして扱う。

21. 導入初期の最小セット

全テンプレートを最初から完全運用する必要はない。最初の導入では、以下の5点だけを必須にするとよい。

22. 成功させるための運用ポイント

この進捗管理とタスク割り当てを成功させる鍵は、作業量を増やすことではなく、曖昧な判断を構造化することである。特に、非エンジニアが関与するプロジェクトでは、要件、リスク、テスト、レビューが分離すると破綻しやすい。したがって、すべての重要タスクには、要件ID、根拠ID、テストID、レビューID、RYG判定のいずれかを接続する。

23. コピーして使えるタスク起票フォーマット

以下は、プロジェクト管理ツール、GitHub Issue、Notion、Google Sheets、Jiraなどへそのまま貼り付けられる形式である。

## タスク名

## タスクID
T-XXX

## 関連フェーズ
P0 / P1 / P2 / P3 / P4 / P5 / P6 / P7 / P8 / P9

## 目的
このタスクで何を明らかにし、何を完了させるかを書く。

## 背景
なぜこのタスクが必要なのか。関連する要件、根拠、リスクを書く。

## 関連ID
- 要件ID:
- 根拠ID:
- テストID:
- リスクID:
- レビューID:
- 再リサーチID:

## 担当
- Responsible:
- Accountable:
- Consulted:
- Informed:

## 完了条件
- [ ] 成果物が作成されている
- [ ] 関連IDが接続されている
- [ ] RYG判定が記録されている
- [ ] 必要なレビューが完了している
- [ ] 変更履歴が更新されている

## 期限
YYYY-MM-DD

## 依存関係
- 先行タスク:
- 後続タスク:

## RYG判定
Green / Yellow / Red

## ブロッカー

## 次アクション

24. コピーして使える再リサーチ起票フォーマット

## 再リサーチ課題名

## 再リサーチID
RR-XXX

## 起票元
Codexレビュー / Opusレビュー / テスト / ゲート判定 / 障害 / ユーザー確認

## 関連ID
- 要件ID:
- タスクID:
- テストID:
- リスクID:
- レビューID:

## 問題の内容
何が分からないのか、何が矛盾しているのか、何が危険なのかを書く。

## 再調査が必要な理由
推測で進めるとどのような破綻が起きるかを書く。

## 調査対象
- 公式ドキュメント:
- 論文:
- コミュニティ事例:
- GitHub Issues:
- 規約・法務:
- 競合・類似事例:

## 期待する判断
採用 / 保留 / 却下 / 代替案 / スコープ変更 / ハーネス強化 / テスト追加

## 担当と期限
- 担当:
- 期限:

## 完了条件
- [ ] 信頼できる根拠がある
- [ ] 代替案が比較されている
- [ ] 要件、仕様、テスト、ハーネスのどこへ反映するか決まっている
- [ ] RYG判定が更新されている

25. コピーして使えるゲート判定フォーマット

## ゲート判定名

## ゲートID
G-XXX

## 対象フェーズ
P0 / P1 / P2 / P3 / P4 / P5 / P6 / P7 / P8 / P9

## 判定日
YYYY-MM-DD

## 判定
Green / Yellow / Red

## 判定理由

## Greenにするために必要な条件

## 未解決リスク

## 必須対応

## 担当

## 対応期限

## 次回判定日
YYYY-MM-DD

## 承認者

26. 最終まとめ

このテンプレート体系は、レビュー・テスト・再リサーチループを実プロジェクトへ導入する際の運用骨格である。最も重要なのは、進捗管理を単なるスケジュール管理にしないことである。各タスクを、要件、根拠、テスト、レビュー、リスク、再リサーチに接続することで、非エンジニアが見抜けない開発破綻リスクを早期に検出し、発見事項を再提案へ戻すことができる。

この運用が定着すると、プロジェクトは「作ってから壊れる」流れではなく、壊れる条件を先に発見し、調査し、設計へ戻し、検証してから進める流れへ変わる。これが、素人の希望から世界最高基準の要件、仕様、技術要件、ハーネス、テスト計画を作るための進捗管理の中核である。

References

このテンプレートは、既に作成済みの以下の内部成果物と連動する。

外部標準としては、セキュリティ成熟度、CI/CD、SRE、AIエージェント設計、ソフトウェア品質管理に関する一般的な実務慣行を踏まえ、プロジェクト内で要件、根拠、テスト、レビュー、リスクを追跡可能にする構成として整理している。 ق