BRD Creation について
BRD Creationは、ビジネス要件、目標、範囲、高レベル要件をまとめるBRD作成スキルです。承認準備や開発チームへの要件伝達を行うプロジェクトチームと関係者を対象とします。
主な機能
- 01BRD各セクションの構成ガイド
- 02ビジネス目標と成功基準
- 03関係者とスコープの記録
- 04高レベルの機能・非機能要件
- 05前提、制約、依存関係、リスク
- 06指標とマイルストーンの計画
活用シーン
- 01開発前のプロジェクト範囲の定義
- 02経営承認に向けたプロジェクト準備
- 03関係者のニーズとリスクの記録
- 04収集した要件のBRDへの整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/brd-creationを入力して読み込まれたか確認します。
詳細
BRD 作成スキル
目的
このスキルを使用すると、AI アシスタントは、ビジネスニーズ、目標、高レベルの要件をステークホルダーや開発チームに明確に伝える、包括的でプロフェッショナルなビジネス要件定義書（BRD）を作成できます。
このスキルを使用するタイミング
- 要件のヒアリングが完了した後
- 新しいプロジェクトや大規模な取り組みを開始するとき
- 経営陣の承認や資金調達を求めるとき
- プロジェクトのスコープと境界を定めるとき
- 詳細なFRS文書を作成する前
BRDとは？
**ビジネス要件定義書（BRD）**は、以下を記載する正式な文書です。
- ビジネス上の課題や機会を説明する
- ビジネス目標と成功基準を定める
- 高レベルのビジネス要件を概説する
- プロジェクトのスコープ（対象範囲と対象外範囲）を定める
- ステークホルダーとそのニーズを特定する
- 前提条件、制約、依存関係を文書化する
BRDとFRSの違い：
- BRD：ビジネスが何を必要としているか、そしてその理由（ビジネスの観点）
- FRS：システムがそのニーズをどのように満たすか（技術的な観点）
BRDの構成
1. エグゼクティブサマリー
目的：多忙な経営陣に向けて、簡潔な概要を提示します。
内容：
- プロジェクト名と簡単な説明
- ビジネス上の課題や機会（2～3文）
- 提案するソリューションの概要（2～3文）
- 期待されるビジネス上のメリット
- 大まかなスケジュールと予算
- 主な成功指標
分量：最大1ページ
執筆のヒント：
- このセクションは最後に書きます（BRDの残りを完成させた後）
- 技術的な専門用語ではなく、ビジネス用語を使います
- ビジネス価値とROIを重視します
- 説得力のある内容にします。経営陣が読むのはこの部分だけかもしれません
例：
プロジェクト：顧客セルフサービス向けモバイルアプリ開発
ビジネス上の課題：現在、顧客はアカウントに関する問い合わせ、注文の追跡、返品のためにサポートセンターへ電話する必要があり、月間15,000件以上のサポート電話と年間45万ドルのサポートコストが発生しています。サポートに関する顧客満足度は5点満点中3.2点です。
提案するソリューション：顧客がよくある問い合わせに自分で対応し、注文をリアルタイムで追跡し、エージェントの支援なしで返品を開始できるiOSおよびAndroid向けモバイルアプリを開発します。
期待されるメリット：サポート電話の件数を60％（月9,000件）削減し、サポートコストを年間27万ドル節約し、顧客満足度を5点満点中4.5点に向上させ、顧客維持率を15％高めます。
投資額：開発費18万ドル、期間4か月
ROI：8か月で投資を回収し、2年間で54万ドルを節約
2. ビジネス目標
目的：ビジネスが達成したいことを定義します。
内容：
- 主なビジネス目標
- 副次的な目標
- 会社の戦略との整合性
- 成功基準（測定可能なもの）
形式：SMART基準（具体的、測定可能、達成可能、関連性がある、期限が明確）を使用します。
例：
主な目標：モバイルアプリのリリースから6か月以内に、顧客サポートコストを60％削減する
副次的な目標：
- リリースから3か月以内に、顧客満足度を3.2から4.5に向上させる
- 12か月以内に、顧客維持率を15％高める
- 24時間365日利用できる顧客セルフサービス機能を提供する
戦略との整合性：会社のデジタルトランスフォーメーション施策と顧客第一の戦略を支援します。
成功基準：
- 6か月以内に、顧客の70％がアプリをダウンロードして利用を開始する
- サポート電話の件数を60％削減する
- アプリストアで4.5以上の評価を獲得する
- ユーザーの80％が、サポートに問い合わせることなくタスクを完了する
3. 背景とコンテキスト
目的：このプロジェクトが必要な理由を説明します
内容：
- 現状の説明
- 問題の経緯と変遷
- 解決に向けた過去の取り組み（該当する場合）
- 市場または競争上の要因
- 規制またはコンプライアンス上の要因（該当する場合）
例：
現在、当社のカスタマーサポートセンターでは月に15,000件の問い合わせに対応しており、その70％は人間の専門知識を必要としない定型的な問い合わせ（注文状況、口座残高、返品依頼）です。業界のベンチマークによると、セルフサービス対応のモバイルアプリを導入した企業は、顧客満足度を向上させながら、サポートコストを50～70％削減しています。
主要な競合他社（CompanyXとCompanyY）は2024年にモバイルアプリをリリースし、顧客満足度と顧客維持率を大幅に向上させています。顧客アンケートによると、当社の顧客の65％は、サポートへの電話よりもモバイルでのセルフサービスを好んでいます。
2023年にウェブポータルを通じてこの課題に取り組みましたが、モバイルでの使い勝手の悪さと注文状況を知らせるプッシュ通知の欠如により、利用率は15％にとどまりました。
4. ステークホルダー分析
目的：影響を受ける人々とそのニーズを特定します
形式：ステークホルダーの役割、関心事項、要件をまとめた表
| ステークホルダーグループ | 主な代表者 | 関心事項・懸念事項 | 主な要件 |
|---|---|---|---|
| 顧客 | エンドユーザー | アカウント情報や注文追跡への簡単なアクセス | 直感的なUI、高速なパフォーマンス、オフラインアクセス |
| カスタマーサポート | サポートマネージャー | 問い合わせ件数の削減、より優れたツール | サポートシステムとの連携、エスカレーション経路 |
| IT運用 | ITディレクター | システムの安定性、セキュリティ | 安全な認証、APIのパフォーマンス、監視 |
| マーケティング | マーケティング担当VP | 顧客エンゲージメント、顧客維持 | プッシュ通知、パーソナライズ、分析 |
| 経営陣 | CEO、CFO | ROI、戦略との整合性 | コスト削減、顧客満足度の向上 |
5. スコープの定義
5.1 対象範囲
目的：対象に含める内容を明確に定義します
形式：機能・能力を分類したリスト
Eコマースモバイルアプリの例：
アカウント管理：
- ユーザー登録とログイン
- プロフィール管理
- パスワードのリセット
- 生体認証（Face ID、Touch ID）
注文管理：
- 注文履歴の表示
- リアルタイムの注文追跡
- 注文の詳細と請求書のダウンロード
- 再注文機能
商品閲覧：
- 商品カタログの閲覧
- 商品の検索と絞り込み
- 商品の詳細と画像
- ウィッシュリストの管理
カスタマーサポート：
- FAQとヘルプセンター
- ライブチャット連携
- サポートチケットの送信
- 折り返し電話の依頼
通知：
- 注文状況のプッシュ通知
- プロモーション通知
- 配送状況の更新
5.2 対象範囲外
目的：対象に含めない内容を明示します（期待値を管理します）
例：
- アプリ内購入（フェーズ2）
- 拡張現実による商品プレビュー（フェーズ2）
- ソーシャルメディア連携（今後検討）
- ロイヤルティプログラム管理（別プロジェクト）
- 国際配送（2026年第3四半期に拡張）
6. ビジネス要件
形式：カテゴリ別に整理し、ビジネスに焦点を当てた明確な表現で記述します
6.1 機能要件（概要）
BR-001：ユーザー認証
- 要件：システムは、安全なユーザー認証を提供する必要があります
- ビジネス価値：顧客データを保護し、プライバシーを確保します
- 優先度：必須
- 成功基準：認証成功率 99.9％、ログイン時間 < 3 秒
BR-002：注文追跡
- 要件：システムは、注文状況と追跡情報をリアルタイムで提供する必要があります
- ビジネス価値：「注文した商品はどこにあるのか」という問い合わせ（現在、電話問い合わせ全体の 35％）を減らします
- 優先度：必須
- 成功基準：状況の変更から 5 分以内にリアルタイムで更新します
BR-003：プッシュ通知
- 要件：システムは、注文の更新についてプッシュ通知を送信する必要があります
- ビジネス価値：先回りしたコミュニケーションにより、顧客の不安や問い合わせを減らします
- 優先度：必須
- 成功基準：通知配信率 90％、オプトイン率 > 60％
6.2 非機能要件（概要）
BR-NFR-001：パフォーマンス
- 4G 接続でアプリが 3 秒以内に読み込まれること
- リクエストの 95％で API 応答時間 < 2 秒
- 50,000 人の同時ユーザーをサポートすること
BR-NFR-002：可用性
- 営業時間中（午前 6 時～午後 11 時）の稼働率 99.9％
- 計画メンテナンスは営業時間外に実施すること
BR-NFR-003：セキュリティ
- 決済データについて PCI DSS に準拠すること
- すべてのデータを転送中に暗号化すること（TLS 1.3）
- 生体認証をサポートすること
- 15 分間操作がない場合、セッションをタイムアウトさせること
BR-NFR-004：ユーザビリティ
- iOS 15 以降および Android 12 以降をサポートすること
- WCAG 2.1 レベル AA のアクセシビリティ基準に準拠すること
- 英語とスペイン語をサポートすること
- トレーニングなしで使える直感的な UI
BR-NFR-005：コンプライアンス
- EU の顧客について GDPR に準拠すること
- カリフォルニア州の顧客について CCPA に準拠すること
- SOC 2 Type II に準拠すること
7. 前提条件
目的：真実であると想定していることを記録します
例：
- 顧客は iOS 15 以降または Android 12 以降を搭載したスマートフォンを所有している
- 既存のバックエンド API は、軽微な機能強化によりモバイルアプリの要件に対応できる
- カスタマーサポートチームは、新しいエスカレーションプロセスについてトレーニングを受ける
- マーケティング部門は、メールやソーシャルキャンペーンを通じてアプリの利用を促進する
- IT インフラストラクチャは、予測されるユーザー負荷に対応できる
- サードパーティサービス（プッシュ通知、分析）は引き続き利用できる
8. 制約
目的：制限や制約事項を記録します
カテゴリ：
- 技術：既存の AWS インフラストラクチャを使用すること、レガシー注文管理システムと統合すること
- 予算：総予算 $180K（開発、テスト、デプロイ）
- スケジュール：季節キャンペーンに向けて 2026 年第 2 四半期までにリリースすること
- リソース：モバイル開発者 2 名、QA 1 名、BA 1 名が対応可能
- 規制：アプリストアのガイドライン（Apple、Google）に準拠すること
- ビジネス：開発中に現在のウェブ体験を中断できない
9. 依存関係
目的：このプロジェクトが依存するものを特定します
例：
| 依存関係 | 説明 | 担当者 | 状況 | リスク |
|---|---|---|---|---|
| バックエンド API の機能強化 | 注文追跡 API にリアルタイム更新が必要 | IT チーム | 進行中 | 中 |
| プッシュ通知サービス | サービス（OneSignal または Firebase）の調達が必要 | IT チーム | 未着手 | 低 |
| アプリストアアカウント | Apple Developer および Google Play アカウント | マーケティング | 保留中 | 低 |
| 顧客データの移行 | アプリへの移行に向けて顧客データを整理する | データチーム | 予定済み | 中 |
| サポートシステムとの統合 | Zendesk と統合してチケットを作成する | IT チーム | 未着手 | 高 |
10. リスクと軽減策
| リスク | 影響度 | 発生確率 | 軽減策 |
|---|---|---|---|
| アプリの導入率が低い | 高 | 中 | 包括的なマーケティングキャンペーン、アプリ内インセンティブ、メールでのプロモーション |
| バックエンド API のパフォーマンス問題 | 高 | 中 | 負荷テスト、パフォーマンスの最適化、キャッシュ戦略 |
| アプリストアでのリジェクト | 中 | 低 | ガイドラインの早期確認、コンプライアンスチェックリスト、ベータテスト |
| レガシーシステムとの統合の遅延 | 高 | 高 | 技術的な事前検証の早期実施、並行開発、代替計画 |
| セキュリティの脆弱性 | 重大 | 低 | セキュリティ監査、侵入テスト、コードレビュー |
11. 成功指標と KPI
導入指標:
- アプリのダウンロード数：6 か月以内にアクティブ顧客の 70%
- 月間アクティブユーザー数（MAU）：ダウンロード数の 60%
- 日間アクティブユーザー数（DAU）：MAU の 25%
ビジネスインパクト指標:
- サポートへの電話件数の削減：3 か月以内に 60% 減少
- コスト削減：年間 $270K
- 顧客満足度：3.2 から 4.5 に向上
- 顧客維持率：15% 改善
技術指標:
- アプリストアの評価：4.5 つ星以上
- クラッシュ率：< 1%
- アプリの読み込み時間：< 3 秒
- API の応答時間：< 2 秒（95 パーセンタイル）
エンゲージメント指標:
- 平均セッション時間：> 3 分
- 機能の利用状況：80% が注文追跡を利用し、60% がアカウント管理を利用
- プッシュ通知の受信許可率：> 60%
12. スケジュールとマイルストーン
| フェーズ | マイルストーン | 期間 | 目標日 |
|---|---|---|---|
| 計画 | BRD の承認 | 2 週間 | Feb 1, 2026 |
| デザイン | UX/UI デザイン完了 | 3 週間 | Feb 22, 2026 |
| 開発 | iOS アプリ開発 | 8 週間 | Apr 19, 2026 |
| 開発 | Android アプリ開発 | 8 週間 | Apr 19, 2026 |
| テスト | QA と UAT | 3 週間 | May 10, 2026 |
| デプロイ | アプリストアへの申請 | 1 週間 | May 17, 2026 |
| リリース | 一般公開 | - | May 24, 2026 |
13. 予算見積もり
| カテゴリ | 費用 | 備考 |
|---|---|---|
| 開発（iOS と Android） | $120,000 | 開発者 2 名 x 3 か月 |
| UX/UI デザイン | $25,000 | デザイン会社 |
| QA とテスト | $15,000 | QA エンジニア + デバイステスト |
| プロジェクト管理 | $10,000 | BA + PM の作業時間 |
| サードパーティサービス（1 年目） | $5,000 | プッシュ通知、分析 |
| アプリストア手数料 | $200 | Apple（$99）+ Google（$25）+ 予備費 |
| 予備費（10%） | $17,520 | リスク対応用の予備費 |
| 合計 | $192,720 |
14. 承認と最終承認
| 役割 | 氏名 | 署名 | 日付 |
|---|---|---|---|
| ビジネススポンサー | |||
| プロダクトオーナー | |||
| IT ディレクター | |||
| 財務 | |||
| ビジネスアナリスト |
ドメイン固有の BRD における考慮事項
E コマースの BRD
重点領域:
- 顧客のジャーニーとコンバージョンの最適化
- 決済とセキュリティの要件
- 在庫および注文管理との統合
- マルチチャネル間の一貫性
- 季節的なトラフィックとスケーラビリティ
主要指標：コンバージョン率、カート放棄率、平均注文額、顧客生涯価値
ERP の BRD
重点領域:
- ビジネスプロセスの変革
- 変更管理とトレーニング
- データ移行とクレンジング
- 既存システムとの統合
- コンプライアンスと監査要件
主要指標：プロセス効率、コスト削減、データ精度、ユーザー導入率
CRM の BRD
重点領域:
- 販売プロセスの最適化
- リード管理とコンバージョン
- 顧客の 360 度ビュー
- マーケティングと営業の連携
- レポートと分析
主要指標：リードコンバージョン率、販売サイクル期間、顧客満足度、パイプライン価値
CDP の BRD
重点領域:
- データ統合戦略
- プライバシーと同意の管理
- セグメンテーションとパーソナライゼーション
- マーケティング活用チャネル
- データガバナンス
主要指標：データ完全性、セグメント精度、キャンペーンのパフォーマンス、ROI
モバイル／Web の BRD
重点領域：
- ユーザーエクスペリエンスとエンゲージメント
- パフォーマンスと応答性
- クロスプラットフォームでの一貫性
- オフライン機能
- アプリストア最適化
主要指標：ユーザーエンゲージメント、セッション時間、リテンション率、アプリストアの評価
BRD 作成のベストプラクティス
文体
✅ 推奨事項：
- 明確で簡潔なビジネス向けの表現を使用します
- 読者（開発者ではなく経営幹部）に合わせて書きます
- ビジネス価値と成果に焦点を当てます
- 能動態を使用します
- 具体的で測定可能な内容にします
- 視覚資料（図、グラフ）を含めます
❌ 避けること：
- 説明なしに専門用語や頭字語を使用します
- 実装の詳細を含めます（FRS に記載します）
- 曖昧な表現（「効率を改善する」など）を使用します
- 読者に事前知識があると想定します
- 長すぎる文を書きます
構成と形式
- 一貫性のある書式と番号付けを使用します
- 10 ページを超える文書には目次を含めます
- 構造化された情報には表を使用します
- ページ番号とバージョン管理を含めます
- 読みやすさを高めるため、見出しと余白を使用します
コラボレーション
- 早い段階から頻繁にステークホルダーを巻き込みます
- ビジネスオーナーと草案をレビューします
- 技術的な実現可能性の検証を受けます
- フィードバックに基づいて反復します
- バージョン履歴を維持します
品質チェック
- エグゼクティブサマリーが説得力に富み、簡潔である
- ビジネス目標が SMART である
- スコープが明確に定義されている（対象と対象外）
- 要件が技術面ではなく、ビジネスに焦点を当てている
- 成功指標が測定可能である
- 前提条件と制約が文書化されている
- 依存関係とリスクが特定されている
- 予算とスケジュールが現実的である
- 文書が適切に書式設定され、プロフェッショナルな仕上がりである
- すべてのステークホルダーがレビューし、承認している
BRD 作成ツール
Lark
- 共同で BRD を作成するには Lark Docs を使用します
- ステークホルダーからのフィードバックにはコメントを使用します
- 変更を追跡するにはバージョン履歴を使用します
- レビューと承認のため、ステークホルダーと共有します
Notion
- Notion で BRD テンプレートを作成します
- メタデータ（バージョン、ステータス、オーナー）にはデータベースプロパティを使用します
- 関連する要件やユーザーストーリーにリンクします
- 図やモックアップを埋め込みます
Figma
- プロセスフロー図を作成します
- ユーザージャーニーマップを設計します
- コンセプトを示すワイヤーフレームを作成します
- BRD に Figma のリンクを埋め込みます
BRD 承認後の次のステップ
- 詳細な機能要件仕様書（FRS）を作成します。
frs-creationスキルを参照してください - ユースケースを作成します。
use-case-documentationスキルを参照してください - アジャイル開発向けのユーザーストーリーを作成します。
user-story-writingスキルを参照してください - プロセスマップを設計します。
process-mappingスキルを参照してください - UAT を計画します。
uat-planningスキルを参照してください
参考資料
- BABOK® Guide - ビジネス要件文書化の標準
- IIBA Standards - プロフェッショナルな BA 文書作成の実践
- PMI PMBOK® Guide - プロジェクト憲章とビジネスケースの策定
- IEEE 29148 - 要件エンジニアリングと文書化の標準