dynamics 365のプロジェクトにおいて、要件定義および実施の段階では、BRD(Business Requirement Document)とSRD(Solution Requirement Document)の役割を説明します。
BRD、SRDとは
日本語に直訳すると、
BRD(Business Requirement Document)：ビジネス仕様書
SRD(Solution Requirement Document)：ソリューション仕様書
開発段階ではよく使われる基本設計書、詳細設計書に似たようなものですが、要件定義の段階では、BRDとSRDは非常に密に紐づいています。
BRD、SRD策定のメリット
- トレースバックが出来るようになる。
業務から色んな機能が欲しいという要件をヒアリングしたり聞き出したりの際に、要件と要件の関係性、ある要件を満たすために実施すべきことなど、管理しないといけません。BRDとSRDは、ロジックを整理してドキュメント化の役割を果たしています。
例えば、とあるプロジェクトにおいて、以下のObjective(目標)が実現したいと設定されます。
Objective：地域のセールスマネージャーは彼が頂いた情報を基づいて、重要な意思決定を行う。
それに対して、必要なBRDは番号付きで書いています。ObjectiveとBRDは1対多の関係を持っているケースが多い。
BRD01：地域のセールスマネージャーは先月のセールスレポートを月次レポートとして出力し、毎月の月初を頂く。
BRDに対して細分化されたSRDは付いています。BRDとSRDも1対多の関係を持っているケースが多い。
SRD01-01：先月の月次レポートをマネージャーのダッシュボードに表示する。
SRD01-02：表示する項目内容は製品名、製品カテゴリ番号、営業担当者。
このような感じで、SRD01→BRD01→Objectiveまでたどり着くようになり、PMは現場の人は何の目標のためにどこで工夫しているのかは把握できます。現場のBAおよび開発チームの人も、自分は今取り込んでいるタスクはどの課題を解決するためにやるのかも分かるようになり、疲弊する時が少なくなるでしょう。
- 業務からの要件が変更した時に、作業の証憑として業務側に提示して相談のためにもなる。
要件が策定してからずっとそのまま変わらないのではありません。ビジネス推進していく中で、例えばプロジェクト開始してから2ヶ月後、要件はA案がいいからB案がいいへ変更する場合も存在しています。
こうなった場合、BRD01が変更したとしましょう。BRD01のため、SRD01やSRD02は既に実行して完成に向かう状況ですが、BRD01を変更すると、それを実現するためにかける工数や費用を損失として見なければなりません。つまり、BRDとSRDの関係は明確であるため、業務側に予算を別途請求することができます。
プロジェクトにおけるチャレンジ
１、仕様変更：上記に書かれた通り、BRDとSRDのドキュメントが存在して管理しているため、業務側に持っていて相談できます。ただ、要件がよく変更したケースもあり、しかも予算も限られた場合、バランスが取れなくなる可能性があります。費用面だけではなく、チームが取り込んでいるSRDを何回も崩したら、メンバーのやる気がなくなり、疲弊する可能性もあります。
２、dynamics 365の限界は把握しづらい：業務側から仕様変更のお願いだけではなく、実施側はSRDまで深くやっていくと、そもそもBRDを満たせない、満たせたら余計な工数がかかるといったケースも存在しています。それは業務側の責任ではなく、実施側は提案に対してきちんと納品できないのです。dynamics 365のout of boxでカスタマイズ出来るもの、workflow出来るもの、plugin出来るものを分けて把握しないといけません。各自の難易度や工数が全く違いますから、最初見積もりや提案の際にも考慮しておいた方がいいと思います。
コメント