AIとビジネスアナリシス（3）
よく見ると、「ビジネス要求」はあるのですが、「ステークホルダー要求」が抜けています。また、BRDでは通常不要な「非機能要求」が見れます。これらの点を指摘しましょう。
あなた:
ビジネス要求のみならず、ステークホルダー要求を追加してください。非機能要求はソリューション要求の一部なのでBRDには不要です。
ChatGPT:
ご指摘ありがとうございます。おっしゃる通り、BRD（Business Requirements Document）は主に「ビジネス要求」と「ステークホルダー要求」に焦点を当てる文書であり、非機能要求（例：パフォーマンス、可用性など）はソリューション要求の一部としてSRS（System Requirements Specification）に含めるのが適切です。
以下に、修正・拡張済みのBRDテンプレートをご提供いたします：
Business Requirements Document（BRD）テンプレート（最新版）
───────────────────────────────
- 表紙
- 文書タイトル：Business Requirements Document（プロジェクト名）
- バージョン：1.0（初版）／1.1（改訂）など
- 作成日：YYYY/MM/DD
- 作成者：氏名・部門
- レビュー／承認者：氏名・役職
- バージョン履歴表（任意）
- 目次
（セクション番号と見出し）
- 文書の目的と背景（Purpose and Background）
- この文書の目的
- プロジェクトの背景（ビジネス課題や契機）
- 対象読者
- ビジネスの概要（Business Context）
- ビジネス目標（例：顧客満足向上、コスト削減、法令遵守など）
- 現状の課題・機会（Opportunities / Problems）
- 関連施策・プロジェクトとの関係
- スコープ（Scope）
- 対象業務領域（In Scope）
- 非対象領域（Out of Scope）
- 想定する前提条件と制約事項（Assumptions / Constraints）
- 利害関係者の概要（Stakeholder Overview）
- 主なステークホルダーとその関心・影響範囲
- 例：経営層、部門責任者、現場ユーザー、顧客、外部委託先 など
- ステークホルダー要求（Stakeholder Requirements）
- ステークホルダーごとの要望、ニーズ、制約条件
- ビジネス要求の根拠となるニーズ群
- 優先度や影響度の分類
例：
| ID | ステークホルダー | 要求内容 | 優先度 | 関連ビジネス要求 |
| SR-001 | サポート部門 | 顧客の問い合わせ履歴を一覧表示したい | 高 | BR-002 |
| SR-002 | 財務部門 | 請求データは毎月1営業日までに取得可能にしたい | 中 | BR-004 |
- ビジネス要求（Business Requirements）
- ビジネスゴールを実現するために必要な成果・能力・ルール
- ステークホルダー要求から導出される「What / Why」の要求
例：
| ID | 要求内容 | 関連ステークホルダー | 優先度 | 受け入れ基準 |
| BR-001 | 顧客がWeb上で商品を注文できるようにする | 営業部、顧客 | 高 | 月間取引件数が20%増加すること |
| BR-002 | 問い合わせ対応の平均時間を20%短縮する | サポート部門 | 高 | 平均対応時間が5分未満になること |
- ギャップ分析（現状との比較）
- 現行業務やシステムとの比較
- 現状の問題点と新要求との差分
- 要件トレーサビリティ（任意）
- ステークホルダー要求 → ビジネス要求 → ソリューション要求への導線
- トレーサビリティマトリクス（追跡可能性）
- 承認セクション（Approval）
- 各ステークホルダーの承認欄（署名または記名）
━━━━━━━━━━━━━━━━━━━━━━━
- 非機能要求（セキュリティ、性能など）は、BRDではなくSRSやNFRD（Non-Functional Requirements Document）などに記述
- BRDは「要求のWhatとWhy」を扱い、「How」（具体的な設計・仕様）は含まない
いかがでしょうか。
だいぶ改善されましたが、これで正しいでしょうか。
「ビジネス要求」と「ステークホルダー要求」の順序が逆ですね。
ChatGPTのレベルはこの程度です。それなりに優秀ですが、「ウソ」とまでは言いませんが、鵜呑みにしてはいけない例です。
注意して活用しましょう。