Cover
世界最高基準の要件定義書を作る具体ステップ
要件ID台帳・Exit Criteria・採用停止基準・汎用テンプレート化
Manus AI
Slide 1
要件定義は「管理できる仕様」へ進化させる
- 現行要件定義の強みは、思想、判断軸、運用現実が濃いこと。
- 次に必要なのは、実装・検証・保守できる形式への変換。
- 核となる成果物は、要件ID台帳、Exit Criteria表、採用・停止基準表。
- 最後に固有語を抽象化し、他プロジェクトへ転用可能にする。
Slide 2
最優先は3つの管理表
| 成果物 | 役割 | 効果 |
|---|---|---|
| 要件ID台帳 | 要件をID単位で管理 | 実装・テスト・変更を追跡できる |
| Exit Criteria表 | フェーズ移行を判定 | 進行判断が客観化される |
| 採用・停止基準表 | ロジック判断を管理 | 人間判断が再現可能になる |
Slide 3
要件ID台帳は全要件の背骨
- 要件を「文章」ではなく「管理単位」に変える。
- 1要件1IDに分け、機能、UI、データ、AI、運用、非機能を分類する。
- 各要件に受入基準と検証方法を必ず付ける。
- AI開発でも、指示の揺れを防ぐアンカーになる。
Slide 4
要件IDは分類別に設計する
| ID | 分類 | 例 |
|---|---|---|
| F | 機能 | F-001: 外部データを取得する |
| UI | 画面 | UI-001: 推奨結果を表示する |
| D | データ | D-001: 欠損を検知する |
| ML | AI/ML | ML-001: 未来データを使わない |
| OPS | 運用 | OPS-001: 失敗時に通知する |
| NFR | 非機能 | NFR-001: 3秒以内に表示する |
| SEC | セキュリティ | SEC-001: 管理操作を制限する |
Slide 5
要件ID台帳の作成手順
- 原文要件を章ごとに分割する。
- 各文章を機能、UI、データ、AI、運用、非機能へ分類する。
- 1要件1文へ分解する。
- 要件ID、理由、優先度、フェーズを付ける。
- 受入基準、検証方法、責任者、状態を追加する。
Slide 6
要件ID台帳の完成イメージ
| 要件ID | 分類 | 要件名 | 受入基準 | 検証方法 |
|---|---|---|---|---|
| F-001 | 機能 | データ取得 | 指定期間のデータが保存される | 実行・ログ確認 |
| D-001 | データ | 欠損検知 | 欠損時にエラー記録される | 欠損投入テスト |
| ML-001 | AI/ML | 未来データ禁止 | 時系列分割が守られる | コードレビュー |
| OPS-001 | 運用 | 失敗通知 | 管理者へ通知される | 異常系テスト |
Slide 7
Exit Criteriaはフェーズの出口条件
- フェーズを「なんとなく完了」にしない。
- 次フェーズへ進む条件を成果物、数値、証跡で定義する。
- 未達の場合の対応も明記する。
- 承認者を決め、判断履歴を残す。
Slide 8
Exit Criteria表の必須項目
| 項目 | 内容 |
|---|---|
| フェーズ目的 | その段階で達成すべき状態 |
| 完了条件 | 終了に必要な条件 |
| 定量基準 | 成功率、件数、時間など |
| 必須成果物 | ログ、レポート、テスト結果 |
| 未達時対応 | 延長、修正、保留、差し戻し |
| 承認者・証跡 | 誰が何を根拠に承認したか |
Slide 9
競馬システムのExit Criteria例
| フェーズ | 目的 | 移行条件 |
|---|---|---|
| Phase 1 | データ取得安定化 | 取得・欠損検知・ログ保存が再現可能 |
| Phase 2 | ロジック検証 | 複数ロジックの成績比較が可能 |
| Phase 3 | Web UI運用化 | 非エンジニアが画面で運用可能 |
| Phase 4 | 安定運用 | 障害対応、監査、バックアップが稼働 |
Slide 10
採用・停止基準は判断を再現可能にする
- 社長判断を排除するのではなく、判断の観点を表にする。
- 採用、保留、停止、例外承認を区別する。
- 回収率だけでなく、検証件数、下振れ、説明可能性を見る。
- 停止条件を先に決めることで、悪化時に迷わない。
Slide 11
採用基準に入れるべき項目
| 項目 | 内容 |
|---|---|
| 最低検証件数 | 偶然の好成績を避ける |
| 成果KPI | 回収率、ROI、CVRなど |
| リスク指標 | 最大DD、損失幅、誤判定率 |
| 直近成績 | 劣化していないか確認 |
| 説明可能性 | なぜ採用するか説明できるか |
| 例外承認 | 基準未達時の理由付き承認 |
Slide 12
停止基準は事前に決める
| 停止区分 | 条件 | 対応 |
|---|---|---|
| 警告 | 指標が一時的に悪化 | 管理画面で警告 |
| 一時停止 | 最大DDや損失幅を超過 | 再検証まで停止 |
| 強制停止 | データ異常・重大バグ | 即時停止と原因調査 |
| 例外継続 | 未達だが理由あり | 期限付きで承認 |
Slide 13
汎用化は「構造を残し、固有語を置換」する
| 競馬システム | 抽象概念 | 他プロジェクト例 |
|---|---|---|
| JRDB | 外部データソース | CRM、POS、広告API |
| バシンの目 | 判断ロジック | 営業スコア、在庫補充ルール |
| 買い目 | 推奨アクション | 架電先、発注数、広告予算 |
| 回収率 | 成果KPI | ROI、CVR、粗利率 |
| 社長承認 | 最終承認者 | PM、事業責任者、法務 |
Slide 14
汎用テンプレートの章構成
- プロジェクト憲章、スコープ、ユーザー・権限。
- フェーズ計画、業務フロー、機能要件、画面要件。
- データ要件、AI/ロジック要件、KPI・リスク。
- 非機能、セキュリティ、受入基準、変更管理、用語集。
Slide 15
世界最高基準化は8段階で進める
| 段階 | 内容 |
|---|---|
| 1 | 原文保存 |
| 2 | 構造化 |
| 3 | ID化 |
| 4 | 基準化 |
| 5 | 図解化 |
| 6 | 検証化 |
| 7 | 運用化 |
| 8 | 汎用化 |
Slide 16
7日間ロードマップ
| 日程 | 成果物 |
|---|---|
| 1日目 | 要件ID台帳ドラフト |
| 2日目 | 受入基準付き台帳 |
| 3日目 | フェーズ別Exit Criteria表 |
| 4日目 | ロジック採用・停止基準表 |
| 5日目 | データ・AI運用要件 |
| 6日目 | UI・非機能・監査要件 |
| 7日目 | 汎用要件定義テンプレート |
Slide 17
まず作るべき順番
- 要件ID台帳を作り、要件を追跡可能にする。
- Exit Criteria表を作り、フェーズ移行を客観化する。
- 採用・停止基準表を作り、意思決定を再現可能にする。
- その後、UI、非機能、監査、汎用テンプレートへ展開する。
Slide 18
結論：強い思想を管理可能な仕様へ
- 現行要件定義の価値は、強い世界観と判断思想にある。
- 世界最高基準化の鍵は、ID、基準、証跡、図解、検証への変換。
- 3つの管理表を作れば、実装・進行・判断が安定する。
- 固有語を抽象化すれば、他プロジェクトにも転用できる。