ビジネス要求文書（BRD）テンプレート

ビジネス要件定義書とは？

A ビジネス要件定義書（BRD） は、ビジネスがプロジェクトやソリューションに何を求め、なぜそれが必要で、成功をどう測るかを定める文書です。目標、スコープ、ステークホルダー、制約、そして受け入れ基準付きの優先順位を付けた要件のリストを扱います。記述するのは、 何 が必要かであり、 どのように 構築するかではありません。

BRDは通常プロジェクトの初期、アイデアが次で承認された後、 ビジネスケース または プロジェクト憲章 設計、開発、調達が始まる前に書かれます。ソリューションを構築または購入する人々に明確で合意された目標を与え、スポンサーには最後に成果を受け入れるための基礎を与えます。

BRDは通常ビジネスアナリストが書きますが、小規模なプロジェクトではプロジェクトマネージャーやプロダクトオーナーが書くことがよくあります。誰が書くにしても、内容はステークホルダーから得るものです。BRDは、確認され合意された彼らのニーズの記録です。

大まかな要件と詳細な要件の全体像については、当サイトの次をご覧ください： プロジェクト要件ガイド.

BRDテンプレートのプレビュー

最初のタブはBRDの概要です。各セクションのガイダンス列に短いヒントがあり、回答は「あなたの内容」列に記入します。

サンプル行は例です。ご自身の内容に置き換えてください。

BRDテンプレートの内容

テンプレートは、連動する2つのタブを持つスプレッドシートです。 BRDの概要 は10の短いセクションで背景を定め、 要求事項 タブは、すべての要件を体系化され絞り込み可能なログに一覧化します。

• BRDの概要：セクション、ガイダンス、記入欄
• 要求事項：ID、要件、種類、根拠、優先度（MoSCoW）、出所、受け入れ基準、ステータス

BRDの概要タブ

3つの列（セクション, ガイダンス, 記入欄）と10のセクションがあります。プロジェクト名とオーナー、エグゼクティブサマリー、ビジネス目標、背景／現状、スコープ、ステークホルダー、前提条件と制約、要件（要件タブを参照）、成功指標、承認です。

要件タブ

8つの列： ID, 要件, 種類, 根拠, 優先度（MoSCoW）, 調達元, 受け入れ基準 と ステータス。上級版とエキスパート版では、3つの列にドロップダウンがあります：

• 種類： 機能、非機能、制約、データ、レポート。
• 優先度（MoSCoW）： Must、Should、Could、Won't。
• ステータス： 草稿、レビュー中、承認、却下、延期。

顧客ポータルプロジェクトの4つのサンプル要件で、各列の記入方法を示しています。自分の内容で上書きしましょう。

どのバージョンをダウンロードすべきか？

ビジネス要件定義書に含めるべき内容

10の概要セクションは、読み手が要件そのものに至る前に必要な背景を提供します。各セクションに書く内容は次のとおりです。

公開されている多くのBRDの形式には、次も含まれています： 費用便益分析。プロジェクトにすでにビジネスケースがある場合は、数値を繰り返さずにそれにリンクしましょう。BRDはニーズに焦点を当て続けるべきです。当サイトのガイド 費用便益分析 では、必要な場合の手法を説明しています。

良いビジネス要件の書き方

要件ログはBRDの中心です。良い要件は次の条件を満たします：

• 必要である： ビジネス目標を支えている。どの目標かを言えない場合は、その要件を問い直しましょう。
• 解決策を含まない： 必要なことを述べ、構築方法は述べない。「顧客はサポートに連絡せずにパスワードをリセットできなければならない」なら、設計の余地が残ります。
• 明確である： 合理的な解釈が1つしかない。「使いやすい」「速い」「柔軟な」といった言葉は、指標なしに使わないようにしましょう。
• 検証可能である： 満たされたかどうかを誰かが確認できる。受け入れ基準の列はそのためにあります。
• 単一である： 1行に1つの要件。「と」でつながっているものは分割しましょう。
• 追跡可能である： ID、出所（人、文書、規制、データ）、根拠がある。

要件の種類

テンプレートの種類のドロップダウンによって、ログを簡単に絞り込めます： 機能要求事項 （ソリューションが行うべきこと）、 非機能要求事項 （性能、可用性、セキュリティ、使いやすさなど、どれだけうまく行うべきか）、 制約条件 （規制、技術、予算などの制限）、 データ と 報告.

組織がIIBAのBABOKガイドに従っている場合は、より幅広い分類を目にするでしょう。ビジネス要求（目標と成果）、ステークホルダー要求（特定のグループのニーズ）、ソリューション要求（機能要求と非機能要求に分かれる）、移行要求（データ移行や研修など、現状から将来の状態へ移るために必要なもの）です。これらを種類のリストに追加の選択肢として加えられます。

MoSCoWによる優先順位付け

MoSCoWは要件を4つのグループに分類し、テンプレートの優先度の列はそれを使います：

よくある間違いは、ほとんどすべてをMustにすることです。それぞれについて「ローンチを中止するか？」と問いましょう。Won'tの項目を記録することも同じくらい有用です。同じ要望が毎月戻ってくるのを防げます。

受け入れ基準の書き方

受け入れ基準は、要件が満たされたことをどう確認するかを記述します。「リセットが2分未満で完了する」「2024年以降のすべての請求書が表示される」「ホスティング地域がEUであることを確認済み」のように、具体的で観察可能にしましょう。これらはテストの基礎となり、プロジェクトの最後にスポンサーが受け入れる基礎にもなり、次と自然につながります： 品質マネジメント のアプローチ。

BRDテンプレートの記入方法（ステップ別）

1. 憲章またはビジネスケースから始める。 目標とスコープをコピーし、BRDが承認された内容と一貫するようにします。
2. ステークホルダーを特定する。 ソリューションを使う人、運用する人、費用を負担する人、規制する人を全員列挙します。当サイトのガイド ステークホルダー・マネジメント で、その分析方法を紹介しています。
3. 現状を記述する。 現在の仕組みと、何がうまくいっていないかを記録します。問い合わせのデータやアンケート結果などの証拠が役立ちます。
4. 要件を収集する。 インタビュー、ワークショップ、観察、文書レビュー、データを使います。作業の中で各要件の出所を記録しましょう。ワークショップの 議事録 は有用な記録になります。
5. 各要件を独立した行に書く。 ID、明確な記述、種類、目標に結びついた根拠を付けます。
6. 優先順位を付け、受け入れ基準を加える。 ビジネスオーナーとMoSCoWの優先度を合意し、各要件にテストを書きます。
7. ステークホルダーとレビューする。 ログを確認し、矛盾を解消し、ステータスを草稿からレビュー中、承認へと更新します。
8. 承認を得て、ベースラインを確定する。 指名された承認者に概要への署名を依頼します。それ以降の変更は次を経ます： 変更管理 を経るべきです。使うもの： 変更要求.

ビジネス要件定義書の例

テンプレートのサンプル行は、顧客ポータルプロジェクトを記述しています。以下は提供されている要件ログで、各行がそのように書かれている理由のメモを添えています。

• BR-01 はサポートのデータから得られたもので、問い合わせ削減という目標に直接貢献するため、Mustです。
• BR-02 は顧客アンケートから得られたもので、明確な境界（24か月）があるため、際限のないデータ移行を避けられます。
• BR-03 はUXリサーチから得られた非機能要件です。2秒という目標がまだITと合意されていないため、まだ草稿です。
• BR-04 はGDPRポリシーに基づく法務からの制約です。これがなければソリューションを稼働できないため、Mustです。

各行は、目標（問い合わせの削減）、出所、根拠にさかのぼれます。この追跡可能性があるからこそ、6か月後に「なぜこれを作っているのか？」に答えられ、時間が足りなくなったときに適切な要件から削ることができます。

BRDとFRD、SRS、PRD、ユーザーストーリーの違い

要件文書は重なり合っており、名称は組織によって異なります。下表は一般的な区別を示しています。

ソリューションを構築するのではなく購入する場合、BRDは次の基礎になることがよくあり、 RFQ または 作業範囲記述書 、またあらゆるプロジェクトで次の基礎になります： プロジェクトスコープ記述書 。

アジャイルプロジェクトでのBRDの活用

アジャイルチームが長いBRDを事前に書くことはまれですが、その背後にある考え方は依然として有用です。目標、スコープの境界、制約、主なビジネス要件を記録した短いBRDは、 プロダクトオーナー とチームに共通の目標を与えます。

詳細はその後、次に移り、 プロダクトバックログ として記述され、 ユーザーストーリー、それぞれがビジネス要件のIDにさかのぼれるようにします。非機能要件と制約は、多くの場合チームの次の一部になります： 完了の定義。この用途には通常、テンプレートの初級版（概要タブのみ）で十分です。当サイトの次と組み合わせましょう： ユーザーストーリーテンプレート または プロダクトバックログテンプレート.

BRDでよくある間違い

• ソリューションを設計する。 画面のレイアウトや技術の選択は、BRDではなく設計に属します。
• あいまいな言葉。 「簡単」「速い」「安全」には指標が必要です。そうでないとテストできません。
• すべてがMust。 本当の優先順位がないと、時間が足りなくなったときにチームはトレードオフを判断できません。
• ステークホルダーの抜け。 法務、財務、セキュリティ、運用のチームからの要件は遅れて浮上し、手戻りを招くことがよくあります。
• 出所や根拠がない。 誰も説明できない要件は守りにくく、過剰な作り込みを招きやすくなります。
• 承認を省く。 承認がなければBRDは草稿であり、スコープは開いたままです。参考： スコープクリープ.
• 永遠に固定されたものとして扱う。 要件は変わります。承認済みのBRDをベースラインとし、こっそり編集するのではなく、変更をオープンに管理しましょう。

関連するテンプレートとガイド

BRDは一連の文書の中に位置しています。その前に ビジネスケーステンプレート と プロジェクト憲章テンプレートがあり、並行して 問題記述テンプレート と ギャップ分析テンプレート がニーズを枠づけ、その後に プロジェクトスコープのテンプレート, ユーザーストーリーテンプレート と 変更要求テンプレート が要件を提供へと引き継ぎます。 RACIマトリクステンプレート は、誰が書き、レビューし、承認するかを合意するのに役立ちます。

プロジェクトスコープ記述書テンプレート無料のプロジェクトスコープテンプレート：目標、成果物、対象範囲、対象外、受入れ…初級 · 上級 · エキスパートユーザーストーリーテンプレート無料のユーザーストーリーテンプレート：〈ユーザー〉として／〈機能〉がほしい／なぜなら〈目的〉、受け入れ基準、エピック、見積り…初級 · 上級 · エキスパートギャップ分析テンプレート現状と将来の姿を比較し、各ギャップを採点…できる無料のギャップ分析テンプレート初級 · 上級 · エキスパート問題記述テンプレート無料の問題記述テンプレート：影響を受ける人、何が・どこで・いつ、影響、根拠…初級 · 上級 · エキスパート根本原因分析（なぜなぜ5回）テンプレートなぜなぜ5回を使った無料の根本原因分析テンプレート：問題記述、なぜの連鎖、根本…初級 · 上級 · エキスパート

すべてのテンプレートを見る

• プロジェクトの要求事項：上位要求事項と技術要求事項
• プロジェクト・ステークホルダー・マネジメント：特定、分析、エンゲージメント
• プロジェクトスコープ：定義、スコープ記述書、例
• ユーザーストーリー：書き方と例

大まかな要件と詳細な要件がどう組み合わさるかを知るには、当サイトの次をお読みください： プロジェクト要件ガイド.

よくある質問