Skip to content
cccskills
FreePublished on GitHub

d1-business-requirement-document

ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。

新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md6.6 KB
  • template.md12.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.mdBRDテンプレート(章構成・書き方ヒント)

新規作成時の振る舞い

本書は 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・制約など、全体的に記載されている内容
ドメイン要求仕様書各ドメインごとで求められる規定
アクター一覧対象ユーザー概要

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

画面コンセプト集の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト全体の画面体験コンセプト(体験方向性・体験原則・トーン&マナー方針)と、それを体現する代表シーン2-3を、ビジネスサイドが議論・合意できるサイズに整理する文書。業界を問わず利用可能(業務アプリ・ゲーム・コンシューマー向けサービス・SaaS 等)。プロダクト要求仕様書(PRD)・アクター一覧・ユーザーストーリー一覧を上流とし、下流のワイヤーフレーム・画面遷移図・画面要件群(D2)の判断基準となる画面体験の方向性を定める。全画面の網羅は D2 画面要件群に降ろし、本書はコンセプトと代表シーンに集約する。PRD・ユーザーストーリー一覧の策定後、D2 画面要件群の作成前、もしくはデザイン会社への発注前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

See all skills by Acceler-Digital

Report a problem with this skill