最終更新: 2026/07/03 20:44
commontype: promptstatus: active
pageaudience: bothbusiness: meta

BRD (Business Requirements Document) 社内標準テンプレ

自社案件で「ビジネス要求 (WHY)」を確定させる文書の H2 12 節骨格 SSoT。JTBD-012 SaaS 事業計画整備 · 顧問税理士判定会議準備 · 社内新規事業の起案時に本テンプレを起点にする。RQ-120 3 モデル Deep Research (docs/research/rq-120-brd-rdd-standards/) の 5 標準比較 (IPA SEC BOOKS / IEEE 830 / ISO 29148 / BABOK v3 / PMBOK 第 7 版 / Volere v18) から抽出した中小企業向け mini template 12 章 · 15-20 ページ規模想定。

BRD / RDD / ADR の使い分け (ADR-0182 / ADR-0097 とのすみ分け)

  • BRD (本テンプレ): 要求 (WHY) の合意記録 · 起案動機 · ROI · スコープ確定 · 15-20 ページ
  • RDD (rdd-template.md): 要件 (WHAT) の合意記録 · 機能 / 非機能スペック · データ / インタフェース · 10-15 ページ
  • ADR (adr-draft.template.md): 意思決定 (Decision) の合意記録 · 11 節 · なぜこの選択肢を採ったかの記録 時系列: BRD → RDD → 個別 ADR。BRD で 3-5 件の Decision 論点が発生したら、それぞれを ADR として並列起案する。

想定読者

  • 決裁者: 代表取締役 · 半年後の自分含む。技術リテラシーはあるが本案件固有詳細は知らない前提
  • 実務担当: エンジニア · Jr · 業務部門。BRD を起点に RDD → 実装まで持って行く
  • 外部関係者: 顧客側 IT 部門 · 顧問税理士 · 監査法人。要点を短時間で掴む

全体設計原則 (3 モデル consensus)

  1. WHY のみを書く — 機能一覧 · 非機能スペック · 実装技術は RDD 側。書き始めたら §7 制約 / §10 Timeline を再確認して RDD に送る
  2. 各要求は 1 文 · 語尾は「〜できること」「〜であること」 — 曖昧語 (「必要に応じて」「原則として」「適切に」「一般的に」) は禁止
  3. 目標は定量 — 「工数削減」でなく「工数 20h/月 → 5h/月」「解約率 8% → 3%」等
  4. Scope In と Out を必ずペアで書く — Volere / Shape Up の No-Gos の技術。書かない = 曖昧化
  5. Appetite (時間予算) を先に決める — Shape Up 方式。「6 weeks で MVP · 超えたら scope 削減」

H2 12 節 (順序固定)

以下の順序で H2 を配置する。番号 prefix (## 1. Executive Summary) は推奨 (lint で strip して比較)。案件固有の説明は H3 サブ見出しで該当節の下に入れる。独自 H2 は禁止。

1. Executive Summary

  • 文脈:
  • 課題:
  • 対策:
  • 効果:
  • 代償:

2. Background & Problem Statement (背景と課題)

2.1 現状の業務フロー

2.2 直面している課題

2.3 このまま放置すると

3. Business Goals & Success Metrics (ビジネス目標と成功指標)

目標KPI測定タイミング

4. Scope (In / Out)

4.1 対象 (In Scope)

-

4.2 非対象 (Out of Scope)

-

5. Stakeholders & Users (関係者)

5.1 関係者一覧

役職 / 部門氏名 / 人数本案件での役割

5.2 RACI 表

活動R (実行)A (承認)C (相談)I (連絡)

6. Business Requirements (High-level)

ID要求優先度 (Must/Should/Could)根拠
BR-01
BR-02

7. Constraints (制約)

7.1 法規制 · 標準準拠

7.2 予算 · コスト上限

7.3 スケジュール制約

7.4 既存資産の縛り

8. Assumptions & Dependencies (前提と依存)

8.1 前提条件

8.2 外部依存

9. Risks (リスク)

リスクImpact (H/M/L)Probability (H/M/L)対応方針

10. Appetite / Timeline (時間予算)

  • Appetite: XX weeks / months
  • 超過時の対応: (どこから scope 削減するか)

  • 主要マイルストーン:

11. Approval / Sign-off (承認)

承認日承認者役職次工程開始条件

12. References (参考)

12.1 関連 ADR

12.2 関連 RQ · 過去調査

12.3 外部資料 · 業界標準

Fit Criteria (BRD → RDD 移行の準備 checklist)

BRD 承認後、RDD 起案前に以下を満たすことを確認する:

  • §3 の各目標に KPI と測定タイミングが定量記載されている
  • §4 In / Out がペアで記載されている
  • §5 RACI 表が全ての主要活動をカバーしている
  • §6 の各要求が「〜できること」「〜であること」の語尾で書かれ · 曖昧語がない
  • §7 法規制 · 予算 · スケジュール · 既存資産の 4 カテゴリを全て検討済
  • §10 Appetite が具体的な期間で明示されている
  • §11 承認済 (承認者印 · 日付あり)

関連

  • RQ-120 (docs/research/rq-120-brd-rdd-standards/): 本テンプレの一次調査 (3 モデル Deep Research · $6.58)
  • rdd-template.md: 本テンプレの後続 (RDD)
  • adr-draft.template.md: BRD 内の Decision 論点は本テンプレの ADR draft 経由で個別起案
  • adr-draft-style-guide.md: 用語 Tier · アンチパターンは ADR draft と共有

参考文献 (一次資料)