business-requirements-analyst

要件のヒアリング

このスキルでは、「アプリ」や「システム」だけでなく、あらゆるビジネスレイヤーを網羅する、要件ヒアリングの専門的かつ包括的な手法を紹介します。

基本原則

要件のヒアリングは、機能の一覧を作成するだけではありません。

質の高い要件ヒアリングでは、あらゆるビジネスレイヤーを網羅します。

• 🧠 アイデアと目的
• 👥 ユーザー
• 💼 運用
• 💰 資金
• ⚙️ 技術
• ⚠️ リスク
• 📈 成長
• 🔗 トレーサビリティ（ビジネスからコードまで）
• ⚖️ 品質ゲート（検証基準）

利用できる手法

1. デザイン思考（新しいアイデア向け）

次のような場合に最適です。

• アイデアの検証がまだ続いている
• まだ不明確な点が多い
• ユーザーを深く理解したい

フェーズ：

1. 共感 - ユーザーを理解する
2. 定義 - 主要な課題を特定する
3. アイデア創出 - 解決策を生み出す
4. プロトタイプ - 初期バージョンを作成する
5. テスト - 実際のユーザーと検証する

**注：**何を構築するかを見つけるために使う手法であり、すべてを文書化するためのものではありません。

2. ビジネス分析（BABOK）

最も包括的で専門的な手法です。

対象範囲：

• ビジネス要件
• 機能要件
• 非機能要件
• ビジネスルール
• ステークホルダー
• プロセス

**注：**正式な文書を作成する際に使われます。

3. リーン／スタートアップ・キャンバス（迅速な全体像の把握）

次の用途に便利です。

• アイデアを整理する
• ビジネスとして成り立つかを確認する

**⚠️ 重要：**包括的な要件ヒアリングの代わりにはなりません。

推奨するアプローチ

次の4つの重要な要素を組み合わせます。

1. ビジネスビジョン
2. プロセス
3. システム／製品
4. トレーサビリティと検証（すべてがつながり、品質基準を満たしていることを確認する）

すべてを単一のマスター成果物、または体系化されたレイヤー構造で文書化します。

包括的な要件定義書の構成

📌 1. ビジネスビジョン

以下を記載します。

• 解決する課題 - どのような問題やニーズに対応するのか
• 価値提案 - 代替案より優れている点は何か
• ビジネス目標 - 明確で測定可能な目標
• 主な KPI - 成功を測る指標
• スコープ - 含まれるものと含まれないもの

形式の例：

## Business Vision

### Problem

[Description of the problem being solved]

### Value Proposition

[What makes this product/service unique]

### Objectives

- Objective 1: [Description]
- Objective 2: [Description]

### KPIs

- KPI 1: [Specific metric]
- KPI 2: [Specific metric]

### Scope

**Includes:**

- [Element 1]
- [Element 2]

**Does not include:**

- [Element 1]
- [Element 2]

📌 2. ステークホルダー

関係するすべての関係者を特定します。

• ビジネスオーナー - 意思決定を行う人
• エンドユーザー - システムを利用する人
• 管理者 - システムを管理する人
• サプライヤー - 外部のサービスや製品
• サードパーティ - 決済、物流、連携など

推奨する形式：

## Stakeholders

| Type  | Name/Role | Interest          | Influence         |
| ----- | --------- | ----------------- | ----------------- |
| Owner | [Name]    | [High/Medium/Low] | [High/Medium/Low] |
| User  | [Type]    | [High/Medium/Low] | [High/Medium/Low] |

📌 3. ユーザータイプ（ペルソナ）

ユーザータイプごとに、以下を文書化します。

• 必要なもの - 重要な機能
• 抱えている課題 - 現在の問題
• システムに期待すること - 期待事項

例：

## Personas

### End Customer

- **Needs:** Make fast and secure purchases
- **Pain:** Complicated checkout processes
- **Expectation:** Checkout in less than 3 clicks

### Administrator

- **Needs:** Manage inventory and orders
- **Pain:** Lack of real-time visibility
- **Expectation:** Dashboard with updated metrics

📌 4. ビジネスプロセス

⚠️ 非常に重要です。ここで多くの人が失敗します。

一連のフローをすべて文書化します。

• 顧客がどのように訪れるか
• どのように販売が成立するか
• どのように支払いを受け取るか
• 支払いに失敗した場合に何が起こるか
• 苦情にどのように対応するか

手順に沿ったフローとして表現します。

## Process: Product Purchase

1. User browses catalog
2. User adds products to cart
3. User proceeds to checkout
4. System validates availability
5. User enters payment details
6. System processes payment
   - **If success:** Confirms order and sends email
   - **If failure:** Shows error and allows retry
7. System generates shipping order
8. User receives confirmation

複雑なプロセスについては、references/process-mapping.md を参照してください。

📌 5. 機能要件

標準的な形式：

• **FR-01：**システムは～を可能にすること。
• **FR-02：**ユーザーは～できること。

一般的なカテゴリ：

• ユーザー登録
• 注文管理
• 支払い
• 通知
• レポート

例：

## Functional Requirements

### Authentication

- **FR-01:** The system must allow registration with email and password
- **FR-02:** The system must send a verification email
- **FR-03:** The user will be able to recover a forgotten password

### Order Management

- **FR-04:** The user will be able to view order history
- **FR-05:** The system must allow canceling orders in "pending" status

📌 6. 非機能要件

これがアマチュアとプロを分ける要素です。

主な領域：

• セキュリティ - 認証、認可、暗号化
• パフォーマンス - 応答時間、処理能力
• スケーラビリティ - 想定される成長
• 可用性 - 稼働時間、冗長性
• 法令遵守 - GDPR、データ保護
• UX／ユーザビリティ - アクセシビリティ、レスポンシブ対応

例：

## Non-Functional Requirements

### Performance

- **NFR-01:** The system must respond in < 2 seconds for 95% of requests
- **NFR-02:** The system must support 1000 concurrent users

### Security

- **NFR-03:** All passwords must be hashed with bcrypt
- **NFR-04:** Communications must use HTTPS/TLS 1.3

### Compliance

- **NFR-05:** The system must comply with GDPR for European user data

📌 7. ビジネスルール

ドメイン固有のロジック：

例：

## Business Rules

- **BR-01:** An order cannot be canceled after 30 minutes of creation
- **BR-02:** A user can only have one active plan at a time
- **BR-03:** Commissions are calculated as 5% of the total amount
- **BR-04:** Taxes are applied according to the buyer's region

📌 8. データモデル（概要）

概念的なものであり、まだ SQL ではありません。

以下を記載します。

• 主要なエンティティ - User、Order、Product など
• リレーションシップ - 1 対多、多対多
• 重要なデータ - 必須フィールド

例：

## Data Model

### Primary Entities

**User**

- id (PK)
- email (unique)
- name
- registration_date

**Order**

- id (PK)
- user_id (FK)
- status
- total
- creation_date

**Product**

- id (PK)
- name
- price
- stock

### Relationships

- A User can have many Orders (1:N)
- An Order can contain many Products (N:M)

複雑なモデルについては、references/data-modeling.md を参照してください。

📌 9. インテグレーション

必要な外部サービス：

• 決済ゲートウェイ - Stripe、PayPal など
• 外部 API - サードパーティサービス
• サードパーティサービス - メール、SMS、分析

例：

## Integrations

### Payment Gateway

- **Provider:** Stripe
- **Functionality:** Credit card processing
- **Data exchanged:** Amount, currency, card token

### Email Service

- **Provider:** SendGrid
- **Functionality:** Sending notifications
- **Data exchanged:** Recipient, subject, HTML body

📌 10. リスクと前提条件

潜在的な問題を特定します。

• 技術的リスク - 依存関係、スケーラビリティ
• 法的リスク - コンプライアンス、プライバシー
• ビジネス上の前提 - 検証が必要な前提

例：

## Risks

### Technical

- **R-01:** Dependency on external API may cause downtime
  - _Mitigation:_ Implement caching and fallback system

### Legal

- **R-02:** Changes in data protection regulation
  - _Mitigation:_ Modular design for rapid adaptation

## Assumptions

- **S-01:** Users have stable internet access
- **S-02:** Initial volume will not exceed 10,000 users

📌 11. ロードマップ／フェーズ

管理しやすい段階に分割します。

例：

## Roadmap

### MVP (Phase 1) - 3 months

- Registration and authentication
- Product catalog
- Shopping cart
- Basic payment with Stripe

### Phase 2 - 2 months

- Notifications system
- Order history
- Basic administration panel

### Phase 3 - 3 months

- Advanced reports
- Logistics integration
- Recommendations system

📌 12. アーキテクチャ決定記録（ADR）

重要な技術的決定を記録し、背景を保持します。

例：

• ADR-001： リレーショナルデータの整合性を保つため、PostgreSQL を使用します。
• ADR-002： リアルタイム通知のキャッシュに Redis を導入します。

詳細については、references/adr-template.md を参照してください。

📌 13. トレーサビリティマトリクスとタグ

要件と実装の間をつなぐ累積タグを埋め込みます。

形式： @brd: BRD.01.01 @req: REQ-001

references/traceability-guide.md を参照してください。

📌 14. 品質ゲートとスコア

次の段階に進む前に、ドキュメントの成熟度を評価します。

• 成熟度レベル： [0-100%]
• ステータス： [Draft | Ready for Dev | Approved]
• 不足項目： 補完が必要な項目の一覧。

情報収集プロセス（ステップごと）

0. プロセスの開始とロードマップ

指示： 対話の開始時に、必ず次のことを行ってください。

1. 自己紹介： 専門的な手法を用いるビジネス要件アナリストであることを簡潔に説明します。
2. ロードマップの提示： 進める 6 つのフェーズ（ディスカバリー → ビジョン → プロセス → 機能／非機能 → データモデル → ロードマップ）を説明し、ユーザーが今後の流れを把握できるようにします。
3. ドキュメントの確認： ユーザーがファイルや以前のコンテキストを提供している場合は、すでに提供された情報について質問しないよう、まずそれらを分析することを伝えます。

1. ディスカバリーとコンテキスト分析（スマートディスカバリー）

指示：

• まず分析する： 質問をする前に、提供されたすべてのファイル（画像、テキスト、ドキュメント）を確認します。
• 不足点を見つける： コンテキストから可能な限りの情報（ステークホルダー、問題、目標）を抽出します。
• 重複質問をしない： ドキュメントにすでに記載されている問題について、「問題は何ですか？」と決して尋ねないでください。代わりに、「ドキュメントを分析し、問題を [X] と理解しました。これで正しいですか？」のように確認します。

2. インタビューと詳細な調査

指示： 不足している情報だけに焦点を当てます。たとえあなた自身がステークホルダーであっても、次の質問に答える取り組みを行います。

• どのような問題を解決しますか？
• 誰が使用しますか？
• どのように使用しますか？
• どのような代替手段がありますか？
• なぜこちらのほうが優れているのですか？

2. 答えにくい質問

エッジケースを見つけるうえで重要です。

• 決済に失敗した場合、どうなりますか？
• ユーザーの接続が切れた場合、どうなりますか？
• データが重複している場合、どうなりますか？
• 外部サービスが停止している場合、どうなりますか？

3. フロー図の作成

次の視覚的な図を作成します。

• ユーザーフロー
• ビジネスプロセス
• システムアーキテクチャ

4. 作成 → 検証 → 調整

反復プロセス：

1. ドキュメントの初版を作成します
2. ステークホルダーとレビューします
3. 不足点や曖昧な点を特定します
4. 調整して改善します
5. 合意に達するまで繰り返します

5. エンティティとデータモデルの統合（自動ERD）

指示：

• 積極的な抽出： プロセス全体を通じて、言及されたすべての主要なエンティティ（例：注文、ユーザー、在庫品目）を特定します。
• 自動生成： 分析の最後に、エンティティが検出されていれば、データモデルのセクションを自動生成します。
• ビジュアル図： わかりやすくするため、Mermaid.js 構文を使ったビジュアルなエンティティ関係図を必ず含めてください。

6. 常に最新のドキュメント

最新の状態を保つ：

• バージョン管理にはMarkdown形式を使用します
• ツール：Notion、Confluence、GitHub Wiki
• 要件が変更されたら更新します

完全版テンプレート

すぐに使えるテンプレートについては、assets/requirements-template.md をご覧ください。

最終成果物

情報をすべて収集し終えると、次のものが得られます。

• ✅ 開発用ドキュメント - 明確な仕様
• ✅ 見積もりの基準 - 定義された範囲
• ✅ 委任用ガイド - 完全な指示
• ✅ 提示用資料 - パートナーや投資家向け

重要なヒント

1. 要件の記述から始めないでください - ビジネスがすでに存在しているかのように理解することから始めます
2. 具体的に記述してください - 「速い」は要件ではなく、「2秒未満」は要件です
3. 「なぜ」を含めてください - 「何を」だけでなく、その理由も記載します
4. 決定事項を記録してください - 特定の技術やアプローチを選んだ理由を記録します
5. 最新の状態を保ってください - 古くなったドキュメントは、ドキュメントがないよりも悪い状態です

参考資料

高度な手法や具体例については、次をご覧ください。

• 複雑なプロセスのマッピング： references/process-mapping.md
• 高度なデータモデリング： references/data-modeling.md
• 詳細なユースケース： references/use-cases.md
• EARS手法： references/ears-methodology.md
• ADRテンプレート： references/adr-template.md
• トレーサビリティガイド： references/traceability-guide.md