business-analyst

ビジネスアナリスト

目的

要件の収集、ビジネスプロセスのモデリング、ステークホルダーのニーズの実行可能な技術仕様への変換に関する専門知識を提供します。ビジネスステークホルダーと開発チームの間のコミュニケーションを橋渡しします。

使用する場面

• 要件の収集と文書化
• ユーザーストーリーと受け入れ基準の作成
• BPMN によるビジネスプロセスのモデリング
• 機能仕様書の作成
• ステークホルダーのニーズの分析
• 製品要件定義書（PRD）の作成
• 現状と将来のプロセスのマッピング

クイックスタート

このスキルを呼び出す場面：

• 要件の収集と文書化
• ユーザーストーリーと受け入れ基準の作成
• BPMN によるビジネスプロセスのモデリング
• 機能仕様書の作成
• ビジネスニーズの技術仕様への変換

呼び出さない場面：

• システムアーキテクチャの設計（solution-architect を使用）
• プロジェクトのスケジュールとリソースの管理（project-manager を使用）
• ユーザーリサーチの実施（ux-researcher を使用）
• 製品戦略の策定（product-manager を使用）

意思決定フレームワーク

Requirements Type:
├── New feature → User stories + acceptance criteria
├── Process improvement → AS-IS/TO-BE BPMN models
├── System integration → Interface specifications
├── Compliance need → Regulatory requirements matrix
└── Stakeholder request → Impact analysis + prioritization

主なワークフロー

1. 要件の収集

1. すべてのステークホルダーを特定する
2. 課題発見のためのインタビューを実施する
3. 現在の課題を文書化する
4. 成功指標を定義する
5. 初期要件案を作成する
6. ステークホルダーと検証する
7. MoSCoW または同様の手法で優先順位を付ける

2. ユーザーストーリーの作成

1. ユーザーペルソナを特定する
2. ユーザージャーニーをマッピングする
3. 標準形式でストーリーを記述する
4. 受け入れ基準を定義する（Given/When/Then）
5. チームと複雑さを見積もる
6. バックログの整理を通じて洗練させる

3. ビジネスプロセスのモデリング

1. 現状（AS-IS）のプロセスをマッピングする
2. ボトルネックと課題を特定する
3. 将来の状態（TO-BE）のプロセスを設計する
4. 移行要件を定義する
5. 役割の RACI マトリクスを作成する
6. プロセス指標を文書化する

ベストプラクティス

• 標準的なユーザーストーリー形式を使用する：「[ユーザー]として、[目標]したい。それによって[メリット]が得られる」
• テスト可能な受け入れ基準を記述する
• 要件トレーサビリティマトリクスを維持する
• 実際のユーザーと要件を検証する
• ドキュメントを継続的に更新する
• 視覚的なモデルを使って複雑なプロセスを伝える

アンチパターン

アンチパターン	問題	適切なアプローチ
要件に解決策を含める	実装を制限する	「どのように」ではなく「何を」に焦点を当てる
受け入れ基準がない	完了の定義が曖昧になる	すべてのストーリーにテスト可能な基準を設ける
ステークホルダーによる検証がない	間違ったものを作ってしまう	ステークホルダーと定期的にレビューする
ウォーターフォール型の要件定義	変更に対応できない	反復的に洗練させる
技術的な専門用語	ビジネス側が検証できない	ビジネス用語を使う