D1: ビジネス要件定義書 (BRD)
このスキルの位置付け
- AIDD成果物フローの最上流となる成果物であるビジネス要件定義書(BRD)を作成するスキル。この成果物はすべての下流成果物の根拠となる。
inputする成果物
| 成果物のパス | 内容 |
|---|
docs/D1.business-requirements/business-requirement-document.md | 既存BRD(更新・レビュー時のみ参照。新規作成時は未存在) |
outputする成果物
| 成果物のパス | 内容 |
|---|
docs/D1.business-requirements/business-requirement-document.md | ビジネス要件定義書本体 |
使用するテンプレート
出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。
| テンプレートのパス | 内容 |
|---|
.claude/skills/d1-business-requirement-document/template.md | BRDテンプレート(章構成・書き方ヒント) |
新規作成時の振る舞い
本書は AIDD 成果物フローの最上流で、「何を作るのか」を初めて定義する文書である。すなわち、本書より上流に「何を作るのか」が定義された成果物は存在しない。よって、新規作成時(docs/D1.business-requirements/business-requirement-document.md 未存在)は、執筆開始前に必ず以下のヒアリングを 1問ずつ順に 行う。
冒頭で以下を投げかけてからヒアリングを開始する。
「📝 以降の4つの問いに回答してください。
正確な内容であるほど修正が少ないビジネス要件定義書が生成されます。ただし、概念さえ理解できれば、実用的な成果物が生成されます。」
各問いは 記入用テンプレ(コピペで埋められるフォーム)形式 で提示する。具体的には: 見出し → 一言ガイド → fenced code block でテンプレ → 補足(各項目の意味・例)の順で出す。空欄可とし、ユーザーは値だけ書き換えて返信する。
Q1/4: 開発対象のメタ情報
以下のテンプレに記入してください。
プロジェクト名(コードネーム可):
業界(例 銀行、生命保険、SNS 等):
作りたいサービス(例 新契約システム、勘定系システム、メタバース等):
社名:
Q2/4: ビジネス目的
以下のテンプレに記入してください。
現行の課題感:
今この投資が必要な理由:
- 現行の課題感: 何が問題か
- 今この投資が必要な理由: タイミングの根拠・市場環境・経営計画上の位置付け 等
Q3/4: 扱う業務領域の輪郭
以下のテンプレに記入してください(空欄可)。
対象業務範囲(起点〜終点):
スコープ外として除外したい領域:
Q4/4: 主要な制約(分かる範囲で)
以下のテンプレに記入してください(空欄可)。
リリース時期:
予算規模:
連携する既存システム:
ユーザーが明示的に委ねた場合(「サンプルでよい」「想定で書いて」等)に限り、推測で記述して要確認マーカーを付ける。それ以外は確認なしに執筆を開始しない。
留意事項
- 業務観点に留まる: 業務観点(ビジネス言語)で記述する。機能名・画面名・テーブル名・API 名等のシステム実装語は混入させない
- 隣接成果物への振り分け: プロダクトとしての要求(対象 OS・ブラウザ・最低限求める機能/非機能 等)は PRD に、個別の業務ルール・判定条件はドメイン要求仕様書に降ろす
- KPI 粒度: 機能単位の KPI は書かず、全社/プロダクト全体の KPI のみ記載する
- Why と事業レベル What の整理: §「本書について > 概要」では「BRD が扱うのは Why + 事業レベル What」を明示する。本書の事業レベル What は下流 PRD の Why となる(Why → What → How が階層的に連鎖する)が、その詳細展開は PRD 側に委ね、本書では深掘りしない
- フェーズ2 ラベルの付与: 初期フェーズの対象外で将来追加される要件(チャネル拡張・新商品・機械学習活用・将来連携 等)は
[フェーズ2] ラベルで明示し、初期/将来の境界を読み手に分からせる。「将来のビジネスの拡張性を担保するためのシステム的要求」章のように章全体がフェーズ2以降の場合は章導入文で宣言してラベルを省略してよい。下流の PRD・ドメイン要求仕様書も同表記を継承するため、表記を一貫させる
完成時のセルフチェック
執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
- 本書だけを読んで「なぜ今このプロジェクトをやるのか」が第三者に伝わるか
- 期日・スコープ・KPI・予算・主要リスクの5点が揃っているか
- 「やらないこと(スコープ外)」が明示されているか
- 業務観点(ビジネス言語)で記述されており、機能名・画面名・テーブル名等のシステム実装語が混入していないか
- 機能単位のKPIではなく、全社/プロダクト全体のKPIに留まっているか
- 将来要件・フェーズ2以降に該当する箇所に
[フェーズ2] ラベル(または同等表記/章導入文宣言)が付与され、初期フェーズとの境界が読み手に分かるか
{{ や XXX のプレースホルダが残っていないか
下流への伝搬関係
作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | BRDから何を引く |
|---|
| ドメイン定義書 | スコープからドメイン分割の根拠 |
| プロダクト要求仕様書(PRD) | スコープ・KPI・制約など、全体的に記載されている内容 |
| ドメイン要求仕様書 | 各ドメインごとで求められる規定 |
| アクター一覧 | 対象ユーザー概要 |