Dynamics 365の要件定義では、業務側の「何を実現したいか」と、実施側の「システムでどう満たすか」をつなぐ必要があります。この記事ではBRDとSRDを使い、目標から実装内容まで追跡する考え方を、月次営業レポートの例で説明します。
2026年10月2日更新：用語の前提、要件の追跡例、変更時の確認事項を整理しました。
BRDとSRDとは：この記事での使い分け
ここではBRDをBusiness Requirements Document（業務要件を整理する文書）、SRDをSolution Requirements Document（ソリューションに求める要件を整理する文書）として扱います。略語の展開や成果物の名称は組織・プロジェクトで異なります。SRDがSystem Requirements Documentなどを指す場合もあるため、最初に定義を合わせます。
| 観点 | BRD | SRD |
|---|---|---|
| 中心となる問い | 誰が、何のために、どのような業務を実現したいか | 業務要件を満たすために、システムに何が必要か |
| 記載の例 | 目的、対象業務、期待する成果、優先度 | 必要な機能・データ・権限・連携・制約 |
| 確認相手 | 業務責任者、利用者、業務分析担当 | 業務分析担当、設計・開発・テスト担当 |
| つながり | 業務目標に対応付ける | 根拠となる業務要件に対応付ける |
基本設計書や詳細設計書と関連しますが、名称だけで同じ成果物とは判断しません。何をどの粒度で書き、誰が承認するかを合意しておくことが大切です。
具体例：月次営業レポートの要件を追跡する
元の記事で取り上げた、地域のセールスマネージャーが営業実績を使って意思決定する場面を整理します。以下の番号と内容は説明用の例です。
| 識別子 | 内容 |
|---|---|
| OBJ-01 | 地域のセールスマネージャーが、前月の営業実績を確認して対応を判断できる。 |
| BRD-01 | マネージャーが月初に、担当範囲の前月実績を確認できる。 |
| SRD-01-01 | マネージャー用の画面に前月の営業実績を表示する。 |
| SRD-01-02 | 製品名、製品カテゴリ、営業担当者など、合意した項目を表示する。 |
| TEST-01 | 対象のマネージャーでログインし、合意した期間・範囲・項目が表示されることを確認する。 |
TEST-01 → SRD-01-01／SRD-01-02 → BRD-01 → OBJ-01とたどれる形にします。1つの業務要件から複数のシステム要件が生まれる場合も、複数の業務要件を共通機能で満たす場合もあります。単に文書を分けるのではなく、関連する識別子を記録します。
BRDとSRDを対応付けるメリット
- 開発の目的を説明できる：担当する機能がどの業務目標につながるかを、業務側と実施側で共有できます。
- 変更の影響を探せる：要件が変わったときに、画面・データ・連携・テストなどの確認先をたどれます。
- 受入条件を具体化できる：作ったことだけでなく、利用者が期待する業務を実行できるかを確認できます。
仕様変更時に確認すること
例えば月次レポートの対象範囲が変わったら、BRD-01の変更だけでなく、集計、アクセス権、テスト条件への影響も確認します。すでに完了した作業、追加作業、優先順位、スケジュールを一覧にし、関係者と対応方針を合意します。
要件の対応表は工数や費用を相談する根拠になりますが、文書があるだけで追加請求が自動的に決まるわけではありません。変更の扱いはプロジェクトの合意事項に沿って判断します。
Dynamics 365導入で特に注意したい点
業務要件を満たす方法には、標準機能の設定、Power Platformによる拡張、追加開発など複数の選択肢があります。早い段階で実現方法と制約を確認し、検証が必要な点を残したまま「実現可能」と確定しないようにします。
要件一覧には、識別子、内容、根拠となる目標、担当者、優先度、受入条件、変更履歴など、チームが継続して管理できる項目を選んで記録しましょう。文書の量よりも、変更時にたどれる状態を保つことが重要です。
導入の進め方を整理する際は、Dynamics 365導入プロジェクトの種類と確認事項も参考にしてください。
コメント