doc-brd

doc-brd

目的

**ビジネス要件定義書（BRD）**を作成します。これは、SDD フローのレイヤー 1 です。 BRD には、製品や技術の詳細に入る前に、ビジネス目標、ステークホルダー、スコープ、成功基準をビジネスの言葉で記述します。

レイヤー：1（エントリーポイント。上流はありません）。 下流：PRD → EARS → BDD → ADR → SPEC → TDD → IPLAN → Code。

MVP の 1 回のイテレーションでは、焦点を絞った要件を合計 5～15 件扱います。必要に応じて、複数の BRD ドキュメントに分散させてください。1 つの BRD に含める機能要件は最大 5 件にすることを推奨します（GD-14）。そのため、1 サイクルに必要なドキュメント数は最低でも ceil(N/5) 件です。これは下限であり、上限ではありません。5 件を超える場合は、BRD-02 を作成してください。新機能にも新しい BRD を作成します。@depends: BRD-NN は、真にハードな前提条件がある場合に限って使用してください。前の BRD が上限に達したために作成したドキュメントは、依存関係のない兄弟ドキュメントとして、BRD-00 インデックスに記録します。

使用するタイミング

次のような場合に doc-brd を使用します。

• 新しいプロジェクトや機能に着手し、ビジネス要件を定義するとき。
• 戦略との整合性、市場背景、成功基準を文書化するとき。
• 実装計画をビジネス言語の要件に落とし込むとき。

リファレンスドキュメント、プロンプト、または IPLAN からエンドツーエンドで生成する場合は、../doc-brd-autopilot/SKILL.md を使用してください。新しいプロジェクトのスケルトンを作成する場合は、最初に ../project-init/SKILL.md を実行してください。

前提条件

BRD はエントリーポイントのため、検証する上流の成果物はありません。作成する前に、次を読んでください。

1. テンプレート（信頼できる唯一の情報源）： ${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-TEMPLATE.yaml
2. レイヤーの README： ${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md
3. ID とタグの標準： ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
4. 作成スタイル： ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md

ID が重複していないことを確認してください：ls docs/01_BRD/。BRD-XXX のようなプレースホルダーを作成したり、存在しないドキュメントを参照したりしないでください。

レイヤーのガイダンス

プラットフォーム BRD と機能 BRD（最初に判断）

判断材料	種類
インフラ、テクノロジースタック、または横断的な関心事を定義する	プラットフォーム
他の BRD が、そのアーキテクチャ上の選択に依存する	プラットフォーム
ユーザー向けのワークフロー／機能を 1 つ記述する	機能
既存のプラットフォーム BRD で確立された機能を基盤とする	機能

• プラットフォーム BRD — ファイル名は BRD-NN_platform_{slug}。アーキテクチャ上の選択を検証するため、PRD より前に ADR を作成します。§8（アーキテクチャ決定トピック）には、下流の BRD が依存する選択済みカテゴリを記載します。
• 機能 BRD — ファイル名は BRD-NN_{feature_slug}。標準的なレイヤーフロー（BRD → PRD → EARS → BDD → ADR）に従います。§8 では、新たなアーキテクチャ上の決定を導入するのではなく、プラットフォーム BRD で採用されたトピックを参照します。

必須の構成（16 セクション）

document_control はセクション 1です（プロジェクト名、バージョン、日付 YYYY-MM-DD、オーナー、作成者、ステータス、改訂履歴テーブル）。続いて、次のセクションがあります。

2. エグゼクティブサマリー（任意 — 導出される項目。section_toggles で切り替え）·
3. はじめに · 4. ビジネス目標 · 5. プロジェクトのスコープ · 6. ステークホルダー ·
4. 機能要件 · 8. アーキテクチャ決定トピック（adr_topics）·
5. 品質への期待 · 10. 制約と前提条件 ·
6. 受け入れ基準と成功の検証 · 12. ビジネスリスク管理 ·
7. 承認 · 14. トレーサビリティ · 15. 用語集 ·
8. シードの処置（seed_disposition — 任意、_required: false。シードから SDD への取り込み台帳、GD-08／SEED_CONTRACT.md）。

テンプレートでは、番号付きセクションのほかに、構造ブロックとして図のレジストリ（diagrams:）とライフサイクル参照の付録（appendix:）も定義しています。必要な形式については、それぞれのテンプレートキーを確認してください。セクション番号とセクション識別子は、テンプレート独自の番号付けとトップレベルの YAML キーに基づきます。信頼できる唯一の情報源はテンプレートです。このスキルのリストはナビゲーション用であり、別個の定義ではありません。

セクションごとの内容と cross_section_rules については、BRD-TEMPLATE.yaml を参照してください。

セクション 8 — アーキテクチャ上の意思決定項目（必須）

7 つのカテゴリにわたって、意思決定が必要なアーキテクチャ上の項目を特定し、コストを重視した代替案ベースの分析を行います。ADR 番号は参照しないでください — ADR はまだ存在しません。

#	カテゴリ	該当しない場合
1	インフラストラクチャ	純粋なデータ／分析プロジェクト
2	データアーキテクチャ	永続データがない
3	インテグレーション	スタンドアロンシステム
4	セキュリティ	機密データを扱わない内部ツール
5	オブザーバビリティ	MVP／プロトタイプのみ
6	AI/ML	AI/ML コンポーネントがない
7	技術選定	既存のスタックを使用

各 Selected 項目には BRD.NN.08.xxxx の要素 ID を付与し、ステータス、ビジネス上の推進要因、ビジネス上の制約、（コスト見積もりを含む）代替案の概要テーブル、クラウドプロバイダーの比較（GCP/Azure/AWS）、推奨する選択、およびそれに伴う PRD 要件を記載します。レイヤーの分離：BRD §8 = 何を、なぜ、いくらで、PRD = 評価方法、ADR = 決定内容。

要素 ID とタグ

• 要素 ID：BRD.{doc_id}.{section_id}.{hash}。このプロンプトではハッシュを計算しないでください — ジェネレーターを呼び出してください：python -m sdd_doc_lint.rehash --compute --doc-id NN --section-id SS --title T --description D（衝突時は --length 8）。準拠先：framework/governance/ID_NAMING_STANDARDS.md。ここでアルゴリズムを再記載しないでください。
• レイヤー 1 には 上流タグ @ を付けません。下流レイヤーでタグを付与します（@brd: BRD.01.06.a7f3）。
• 廃止されたパターン：AC-XXX、FR-XXX、BO-XXX、旧形式の 3 セグメント BRD.NN.xxxx。

上流ソースの設定

ほとんどの BRD はステークホルダーの入力に基づいて作成されます — デフォルトの upstream_mode: "none" を維持してください。docs/00_REF/ のドキュメントに基づく内容がある場合に限り、upstream_mode: "ref" を設定し、upstream_ref_path（BRD ファイルからの相対パス）を記載してください。

作成プロセス

1. 種類を決定する — プラットフォームかフィーチャーか（上の表を参照）。
2. ID を予約する — 次に空いている BRD-NN（2 桁。2 桁を超える場合は先頭にゼロを付けない：BRD-01、BRD-99、BRD-102）。 レイヤーごとの独立性（CLEANUP-PR-F 項目 18）： 自分のレイヤーのインデックスで次に空いている番号を選んでください — 上流の番号は自分の番号ではありません（ドキュメント番号はレイヤーごとに連番で独立しています。framework/governance/ID_NAMING_STANDARDS.md §Cross-layer cardinality を参照）。
3. ネストされたフォルダーを作成する — サイズにかかわらず、すべての BRD は docs/01_BRD/BRD-NN_{slug}/ に配置します。モノリシック形式：フォルダー内に BRD-NN_{slug}.md を作成します。セクション形式（>25 KB）：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-00_index.TEMPLATE.md を基に、BRD-NN.S_{section}.md とインデックスを作成します。
4. ドキュメント管理（セクション 1）を最初に作成し、テンプレートに従って、残りの必須 14 セクション、図の一覧、および付録を完成させます。section_toggles に従って §2（エグゼクティブサマリー）の有効・無効を切り替えます。
5. §8（アーキテクチャ上の意思決定項目）を 7 つのカテゴリにわたって記入します。
6. 上流モードを設定する（デフォルトは none、docs/00_REF/ に基づく場合は ref）。
7. BRD インデックス docs/01_BRD/BRD-00_index.md を同じ変更内で更新します。
8. 検証する（下記参照）とともに、BRD とインデックスをまとめてコミットします。

Draft mode (saga-driven)

saga 駆動のオートパイロットサブプロセスパターン（ ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md および ../doc-brd-autopilot/SKILL.md の saga ループに従う）で呼び出された場合、このスキルは create→review→revise ループのドラフトフェーズのエントリーポイントです。呼び出しは次のようになります。

claude --plugin-dir "$PLUGIN_DIR" -p \
  "/aidoc-flow:doc-brd Draft BRD-<id> at <path>; use BRD-TEMPLATE.yaml + the source input at <seed-path>. Write to docs/01_BRD/BRD-<id>_<slug>/."

claude -p には subagent_type CLI パラメーターがないため、ペルソナの割り当て（business_analyst の視点 → ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_CREWS.yaml および ../review-team/SKILL.md の視点とエージェントの対応表に従った aidoc-flow:requirements-analyst エージェント）は、この SKILL のプロンプト内で行います。呼び出し概要に Draft という語が含まれている場合（大文字と小文字は区別しません）、つまり saga 駆動のドラフトフェーズである場合は、次の方法で作成者をディスパッチします。

1. business_analyst の視点（REVIEW_CREWS.yaml の BRD クルーにおける BRD 作成者）として動作する subagent_type=aidoc-flow:requirements-analyst を指定して、Task サブエージェントを1つディスパッチします。
2. 作成概要として、BRD-TEMPLATE.yaml、ソース入力（渡されたパスにある REF／プロンプト／IPLAN シードファイル）、および作成ルールとしてこの SKILL の ## Creation Process（上記）を渡します。
3. サブエージェントは、標準レイアウトに従って、BRD をネストされたフォルダー docs/01_BRD/BRD-<id>_<slug>/ に書き込みます。
4. サブエージェントの処理後、ドラフトの完了を記録する saga.json の遷移を書き込みます。.aidoc/review/01_BRD//saga.json に saga.json が存在する場合は、transitions[] に {"ts": "<now>", "from": "FANOUT_STARTED", "to": "BRANCH_COMPLETED", "scope": "branch:business_analyst"} を追加します。（saga.json が存在しない場合は、単独の呼び出しです。REVIEW_SAGA.md の「FRAMEWORK_SPEC_VERSION semantics」にある宣言と実装のルールに従って、saga への書き込みを省略します。）

saga ループ外で呼び出された場合（ユーザーが /aidoc-flow:doc-brd を直接実行して BRD を作成する場合）は、Task サブエージェントをディスパッチせずに、上記の ## Creation Process に従います（この場合、ユーザーが作成者です）。この2つのモードは共存します。トリガーとなるのは、概要に Draft が含まれ、かつ <path> 引数が存在することです。

Validation

バリデーターの枠組み（review_mode 対応）。 以下の構造チェックは確定的な最低基準であり、すべてのモードで実行します。team モードでは、コンテンツ品質のレビューは ../doc-brd-audit/SKILL.md が BRD クルー（architect／business_analyst／auditor／chaos_engineer／security_engineer）を並列にディスパッチして実施します。single_pass モードでは、監査においてすべての視点を1回で適用します。いずれの場合も、このスキル（作成者）は成果物を採点せず、作成します。

このスキルがバリデーターです（実行時コードはありません）。${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md および ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md に照らして適用します。

• ドキュメント管理（セクション1）が最初のセクションであること。
• 必須テンプレートセクションがすべて存在し、空でないこと：§1、§3～§15、図表一覧、および付録。§2「エグゼクティブサマリー」は section_toggles に含まれる場合のみ必要です。BRD-TEMPLATE.yaml を読み、該当セクションをすべて列挙します。
• §8 が7つすべての ADR トピックカテゴリを網羅していること。ADR 番号を参照していないこと。
• 要素 ID が BRD.NN.SS.xxxx に一致していること。廃止されたパターンがないこと。
• トレーサビリティマトリクス／インデックスが作成または更新されていること。リンク切れがないこと。
• 図表の契約：@diagram: c4-l1 と @diagram: dfd-l1 が存在すること（../charts-flow/SKILL.md を使用）。シーケンス図がある場合は、シーケンスタグを追加します。

エラーコード（すべて重大度は error）：XDOC-006 タグ形式が無効 · XDOC-008 内部リンク切れ · XDOC-009 トレーサビリティセクションがない

品質ゲート（ブロッキング）： 次に進む前に、PRD 準備完了スコアが90/100以上であること。

BRD-REF ドキュメント（../doc-ref/SKILL.md 経由）は自由形式の参照資料です。準備完了スコア、累積タグ、品質ゲートの対象外です。

Next Skill

../doc-prd/SKILL.md — PRD はこの BRD（@brd: BRD.NN.SS.xxxx）を参照し、製品の機能と KPI を定義して、§8 のアーキテクチャトピックを継承します。

適応

.aidoc/profile.yaml を読み込み、このスキルのノブ（section_toggles、glossary）のみを尊重します。 不明なキーは無視してください。プロファイルがない場合は、フレームワークのデフォルトを使用します。権限の所在： ${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md

関連リソース

• テンプレート／作成ルール：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-TEMPLATE.yaml
• レイヤーの README：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md
• インデックスのテンプレート：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-00_index.TEMPLATE.md
• ID とタグの標準：${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
• 品質ゲート：../doc-brd-audit/SKILL.md · 修正：../doc-brd-fixer/SKILL.md
• 生成パイプライン：../doc-brd-autopilot/SKILL.md

クイックリファレンス

目的	ビジネスニーズと目標を定義します
レイヤー	1（エントリーポイント）
上流タグ	なし
主な判断事項	プラットフォームか機能か
必須項目	§1 ドキュメント管理、§3～§15 の必須セクション、§8（7 カテゴリ）、図表一覧、付録
次へ	doc-prd