世界最高基準を目指す汎用要件定義テンプレート
作成者: Manus AI
用途: Webシステム、AIシステム、業務システム、データ分析基盤、社内ツール、SaaS、モバイルアプリなど、任意のプロジェクトの要件定義に転用するためのテンプレート。
1. プロジェクト憲章
この章では、プロジェクトが何のために存在するのかを定義する。要件定義は機能一覧ではなく、以後のすべての判断を拘束する絶対ルールであるため、目的、成功指標、意思決定者、対象範囲を最初に固定する。
| 項目 |
記載内容 |
| プロジェクト名 |
正式名称、略称、内部コード名を記載する。 |
| 目的 |
このシステムが解決する問題、創出する価値、誰のためのものかを一文で定義する。 |
| 成功指標 |
売上、回収率、作業時間削減率、精度、継続率など、成否を判断する数値を定義する。 |
| 最終意思決定者 |
採用、却下、優先順位変更、リリース判断を行う人物または会議体を明記する。 |
| 判断原則 |
AI、自動化、担当者、経営判断のどれを優先するかを定義する。 |
2. スコープ定義
この章では、作るものと作らないものを明確に分ける。世界最高基準の要件定義では、実装対象だけでなく、対象外が明示されている必要がある。
| 区分 |
記載内容 |
| インスコープ |
初期開発で必ず実装する機能、データ、業務範囲、ユーザー範囲。 |
| アウトオブスコープ |
今回は実装しない機能、扱わないデータ、対象外の業務、将来検討事項。 |
| 境界条件 |
どこからどこまでをシステム責任とし、どこからを人間判断・外部サービス責任とするか。 |
| 将来拡張 |
今は作らないが、後で追加する可能性がある領域。 |
3. ステークホルダー・権限・運用体制
この章では、利用者、管理者、承認者、開発者、外部関係者を明確にする。誰が何を見るのか、誰が何を押せるのか、誰が最終判断するのかを曖昧にしない。
| 役割 |
人物・部署 |
権限 |
責任 |
使用画面 |
| オーナー |
|
採用・却下・優先順位決定 |
成果責任 |
|
| 管理者 |
|
データ取得、設定変更、実行管理 |
運用責任 |
|
| 一般利用者 |
|
閲覧、確認、任意実行 |
利用判断 |
|
| 開発者 |
|
実装、保守、調査 |
技術責任 |
|
4. システムコンセプトと運用サイクル
この章では、システムが一度作って終わりなのか、継続的に改善するものなのかを定義する。AI・データ・業務判断を含むプロジェクトでは、運用サイクルを明記することが必須である。
例: データ取得 → 分析 → 仮説生成 → 検証 → 採用判断 → 本番適用 → 実績確認 → 改善、という循環で運用する。
| 工程 |
入力 |
処理 |
出力 |
判断者 |
合格条件 |
| データ取得 |
|
|
|
|
|
| 分析・学習 |
|
|
|
|
|
| 検証 |
|
|
|
|
|
| 採用判断 |
|
|
|
|
|
| 本番運用 |
|
|
|
|
|
| 改善 |
|
|
|
|
|
5. フェーズ計画
この章では、段階的に何を実現するかを定義する。特に、初期は専門家が操作し、後期は非エンジニアがUIだけで運用できる状態にするなど、成熟度の変化を明確にする。
| フェーズ |
目的 |
到達条件 |
主担当 |
利用者 |
実装範囲 |
次フェーズ移行条件 |
| Phase 1 |
|
|
|
|
|
|
| Phase 2 |
|
|
|
|
|
|
| Phase 3 |
|
|
|
|
|
|
| Phase 4 |
|
|
|
|
|
|
6. 機能要件
機能要件は、単なる一覧ではなく、ユーザー操作、入力、処理、出力、例外、検証方法まで定義する。
| ID |
機能名 |
利用者 |
入力 |
処理 |
出力 |
例外時表示 |
優先度 |
検証方法 |
| F-001 |
|
|
|
|
|
|
Must |
Test |
7. 画面・UI要件
この章は、AI時代の要件定義で特に重要である。画面名、表示項目、操作、空状態、数値表示、レスポンシブ方針を明示しないと、実装セッションごとに画面がぶれる。
| 画面ID |
画面名 |
目的 |
表示項目 |
操作 |
遷移先 |
空状態 |
権限 |
備考 |
| UI-001 |
ホーム |
|
|
|
|
|
|
|
7.1 表示ルール
| 種別 |
ルール |
| 数値 |
小数点、桁区切り、単位、丸め方を明記する。 |
| 色 |
色だけで意味を伝えず、記号・ラベルも併用する。 |
| 空状態 |
データがない場合の文言、グラフ非表示、ボタン無効化条件を明記する。 |
| エラー |
復旧方法が分かる文言にする。 |
| モバイル |
対応有無、優先画面、折りたたみ方を定義する。 |
8. データ要件
データの取得元、形式、更新頻度、保存先、契約、利用制限、権利関係を明記する。
| データID |
データ名 |
取得元 |
形式 |
更新頻度 |
利用目的 |
保存先 |
制約 |
検証方法 |
| D-001 |
|
|
CSV/API/JSON |
|
|
|
|
|
9. 外部サービス・規約・契約制約
外部データ、API、LLM、決済、認証、通知基盤などを使う場合、規約と技術制約を要件として扱う。
| サービス |
用途 |
認証方式 |
利用時間 |
禁止事項 |
契約条件 |
障害時対応 |
|
|
|
|
|
|
|
10. AI・機械学習要件
AIプロジェクトでは、モデル名だけでは不十分である。学習データ、特徴量、検証方法、評価指標、採用基準、再学習、モデル監査を定義する。
| 項目 |
記載内容 |
| 学習データ |
期間、対象、除外条件、未来データ混入防止策。 |
| 特徴量 |
使用する変数、人間コメントの数値化方法、更新方法。 |
| モデル構成 |
基礎モデル、補助モデル、不確実性推定、アンサンブル方針。 |
| 評価指標 |
精度、利益、時間効率、安定性、最大ドローダウンなど。 |
| バックテスト |
期間、購入仮定、資金ルール、検証粒度、リーク防止。 |
| 採用基準 |
何を満たせば本番採用するか。 |
| 再学習 |
頻度、トリガー、承認者、ロールバック方針。 |
11. ロジック・ルール・バージョン管理
複数のロジックや設定を扱う場合、それぞれを独立した資産として扱う。
| ID |
名称 |
説明 |
作成日 |
採用日 |
採用者 |
現在状態 |
累積成績 |
バージョン |
変更履歴 |
| L-001 |
|
|
|
|
|
候補/採用/停止 |
|
|
|
12. 収支・評価・リスク管理
成果が数値で出るシステムでは、成果計算の前提を要件として固定する。
| 指標 |
定義 |
計算式 |
表示場所 |
更新タイミング |
合格基準 |
| 回収率 |
|
|
|
|
|
| 最大ドローダウン |
|
|
|
|
|
| 的中率 |
|
|
|
|
|
| 時間効率 |
|
|
|
|
|
13. 非機能要件
| 種別 |
要件 |
測定方法 |
目標値 |
| 可用性 |
|
|
|
| 性能 |
|
|
|
| セキュリティ |
|
|
|
| 監査性 |
|
|
|
| 保守性 |
|
|
|
| アクセシビリティ |
|
|
|
| バックアップ |
|
|
|
14. レビュー・検証・受入基準
要件定義はレビューのための基準である。したがって、各要件に対して、検証方法、受入条件、証跡を定義する。
| 要件ID |
検証方法 |
受入条件 |
証跡 |
レビュー担当 |
| F-001 |
Test / Demo / Inspection / Analysis |
|
|
|
15. 未決定事項・リスク・変更管理
| ID |
内容 |
影響 |
対応方針 |
期限 |
担当 |
状態 |
| R-001 |
|
高/中/低 |
|
|
|
Open |
16. 命名・ブランド・世界観
内部名、外部表示名、コード上の名称、配布資料上の表記がずれると混乱するため、最初に統一する。
| 種別 |
名称 |
使用場所 |
禁止表記 |
備考 |
| ブランド名 |
|
UI、資料 |
|
|
| 内部コード名 |
|
DB、コード |
|
|
| モデル名 |
|
管理画面、ログ |
|
|
17. 要件品質チェックリスト
| 観点 |
チェック項目 |
| 必要性 |
目的に直結しない機能が混ざっていないか。 |
| 明確性 |
誰が読んでも同じ意味に解釈できるか。 |
| 単一性 |
1つの要件に複数の要求が混ざっていないか。 |
| 検証可能性 |
実装後に合否判定できるか。 |
| 追跡可能性 |
目的、画面、データ、テストに接続できるか。 |
| 実現可能性 |
技術、予算、運用体制で実現できるか。 |
| 境界明確性 |
対象外、例外、制約が書かれているか。 |
| 保守性 |
担当者が変わっても同じ運用ができるか。 |