ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。
新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/business-requirement-document.md | 既存BRD(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
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 でテンプレ → 補足(各項目の意味・例)の順で出す。空欄可とし、ユーザーは値だけ書き換えて返信する。
以下のテンプレに記入してください。
プロジェクト名(コードネーム可):
業界(例 銀行、生命保険、SNS 等):
作りたいサービス(例 新契約システム、勘定系システム、メタバース等):
社名:
以下のテンプレに記入してください。
現行の課題感:
今この投資が必要な理由:
以下のテンプレに記入してください(空欄可)。
対象業務範囲(起点〜終点):
スコープ外として除外したい領域:
以下のテンプレに記入してください(空欄可)。
リリース時期:
予算規模:
連携する既存システム:
ユーザーが明示的に委ねた場合(「サンプルでよい」「想定で書いて」等)に限り、推測で記述して要確認マーカーを付ける。それ以外は確認なしに執筆を開始しない。
[フェーズ2] ラベルで明示し、初期/将来の境界を読み手に分からせる。「将来のビジネスの拡張性を担保するためのシステム的要求」章のように章全体がフェーズ2以降の場合は章導入文で宣言してラベルを省略してよい。下流の PRD・ドメイン要求仕様書も同表記を継承するため、表記を一貫させる執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
[フェーズ2] ラベル(または同等表記/章導入文宣言)が付与され、初期フェーズとの境界が読み手に分かるか{{ や XXX のプレースホルダが残っていないか作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | BRDから何を引く |
|---|---|
| ドメイン定義書 | スコープからドメイン分割の根拠 |
| プロダクト要求仕様書(PRD) | スコープ・KPI・制約など、全体的に記載されている内容 |
| ドメイン要求仕様書 | 各ドメインごとで求められる規定 |
| アクター一覧 | 対象ユーザー概要 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。
画面コンセプト集の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト全体の画面体験コンセプト(体験方向性・体験原則・トーン&マナー方針)と、それを体現する代表シーン2-3を、ビジネスサイドが議論・合意できるサイズに整理する文書。業界を問わず利用可能(業務アプリ・ゲーム・コンシューマー向けサービス・SaaS 等)。プロダクト要求仕様書(PRD)・アクター一覧・ユーザーストーリー一覧を上流とし、下流のワイヤーフレーム・画面遷移図・画面要件群(D2)の判断基準となる画面体験の方向性を定める。全画面の網羅は D2 画面要件群に降ろし、本書はコンセプトと代表シーンに集約する。PRD・ユーザーストーリー一覧の策定後、D2 画面要件群の作成前、もしくはデザイン会社への発注前に呼び出す。