Business Analyst

BABOK Guide v3準拠のビジネス分析 – 要件定義、プロセスマッピング、ステークホルダー分析、ビジネスケース、ギャップ分析を支援します。

API不要

スキルパッケージをダウンロード (.skill) GitHubでソースを見る スクリプト

目次

• 概要
• 利用シーン
• 前提条件
• 仕組み
  • BABOK 6つの知識エリア
  • 引き出しテクニック一覧
  • business_analysis.py による財務分析
  • 要件の4層分類
  • 優先順位付けフレームワーク
• 使用例
  • 例1: ビジネスケースの作成
  • 例2: 業務プロセスのマッピング
  • 例3: 要件収集計画
  • 例4: ステークホルダー分析とエンゲージメント戦略
  • 例5: CRM移行のギャップ分析
• ヒントとベストプラクティス
• トラブルシューティング
  • ステークホルダー間で要件が合意できない
  • ビジネスケースが却下される
  • ベネフィットを定量化できない
• 関連スキル

---

概要

Business Analystは、IIBA (International Institute of Business Analysis) のBABOK Guide v3に準拠した包括的なビジネス分析スキルです。6つの知識エリア（計画とモニタリング、引き出しとコラボレーション、要件ライフサイクル管理、戦略分析、要件分析と設計定義、ソリューション評価）をすべてカバーします。

Pythonスクリプト（business_analysis.py）による財務分析（ROI、NPV、IRR）、ビジネスメトリクス算出、データプロファイリング、加重スコアリングによるオプション比較が可能です。

利用シーン

• インタビュー・ワークショップ・アンケートによるステークホルダーからの要件収集
• 新システムやプロセスのビジネス要件定義書（BRD）作成
• ROI・NPV・回収期間を含むビジネスケースの策定
• BPMN表記による業務プロセスのマッピングと非効率の特定
• パワー/関心マトリクスによるステークホルダー分析とエンゲージメント戦略
• 現状と目標状態を比較するギャップ分析
• MoSCoW・価値 vs. 複雑性・カノモデルによる要件の優先順位付け

前提条件

• business-analyst スキルがインストールされたClaude Code
• 外部APIは不要
• business_analysis.py の実行にはPython 3が必要（任意 – 財務計算の自動化に使用）

仕組み

5つのコアワークフローを提供します。

1. 要件の引き出し – アプローチの計画（インタビュー・ワークショップ・アンケート・観察・プロトタイピング）、質問準備、セッション実施、要件の分類（ビジネス・ステークホルダー・機能・非機能）、検証、BRDテンプレートによる文書化
2. 業務プロセス分析 – BPMN/スイムレーン図による現状（As-Is）プロセスのマッピング、サイクルタイムとエラー率の測定、ムダの特定（TIMWOOD）、根本原因分析（5 Whys・フィッシュボーン）、将来（To-Be）プロセスの設計、改善効果の定量化
3. ステークホルダー分析とエンゲージメント – ステークホルダーの特定、パワー/関心マトリクスによる分類、個別エンゲージメント戦略の策定、RACIマトリクスの構築
4. ビジネスケース策定 – 課題定義、3-5つのソリューションオプション策定、コスト・ベネフィット分析、ROI/NPV/回収期間/IRR算出（business_analysis.pyで自動化可能）、加重スコアリングによるオプション比較、推奨案の提示
5. ギャップ分析 – 現状の能力とメトリクスの文書化、目標状態の定義、ギャップの特定（プロセス・技術・人材・データ・ポリシー）、インパクト vs. 労力マトリクスによる優先順位付け、アクションプランの策定

BABOK 6つの知識エリア

BABOK Guide v3が定義する6つの知識エリアに基づいて構成されています。

知識エリア	焦点	主要テクニック
BA計画とモニタリング	BAアプローチの定義と実行の追跡	ステークホルダーリスト、BA計画、ガバナンスモデル
引き出しとコラボレーション	ステークホルダーからの情報収集と確認	インタビュー、ワークショップ、アンケート、観察、プロトタイピング、文書分析
要件ライフサイクル管理	要件のトレース、維持、優先順位付け	MoSCoW、価値 vs. 複雑性、トレーサビリティマトリクス、変更管理
戦略分析	ビジネスニーズの理解と投資の正当化	SWOT、PESTLE、バリューチェーン、現状/将来状態分析
要件分析と設計定義	要件の詳細化・モデリングとソリューション設計	ユースケース、ユーザーストーリー、データモデル、プロセスモデル、受け入れ基準
ソリューション評価	提供されたソリューションが目標を達成しているか評価	パフォーマンスメトリクス、KPI、ベネフィット実現追跡

引き出しテクニック一覧

状況に応じた適切なテクニックの選択基準です。

テクニック	適している場面	参加人数	アウトプット
インタビュー	特定の個人から深い理解が必要	1-3名	詳細メモ、要件
ワークショップ	部門横断で合意形成が必要	6-15名	合意済み要件、プロセスマップ
アンケート	大規模ユーザーベースや定量データが必要	50名以上	優先順位付きリスト、統計
観察	プロセスが文書化されていない、暗黙知がある	1-5セッション	As-Isプロセスマップ、ペインポイント
文書分析	既存ドキュメントやレガシーシステムがある	アナリストのみ	文書から導出された要件
プロトタイピング	要件が抽象的、UIが中心	3-8名	検証済みモックアップ、精緻化された要件

business_analysis.py による財務分析

同梱のPythonスクリプトで主要な計算を自動化できます。

python scripts/business_analysis.py financial \
  --investment 10000000 \
  --annual-benefit 3000000 \
  --annual-cost 500000 \
  --years 5 \
  --sensitivity

ROI、NPV、IRR、回収期間を算出し、オプションの感度分析では仮定値を+/- 10-20%変動させた場合の結果変化を表示します。

要件の4層分類

漏れなく要件を整理するため、4つのレイヤーに分類します。

カテゴリ	答える問い	例
ビジネス要件	なぜ必要か?	「受注処理時間を50%削減する」
ステークホルダー要件	誰が何を必要としているか?	「営業担当者がモバイルで顧客データにアクセスできる」
機能要件	システムは何をするか?	「受注受付前に与信限度額を検証する」
非機能要件	どの程度の品質で動作するか?	「トランザクションの95%が2秒以内に応答する」

各要件にはIDが付与され、ビジネス目標とリンク（トレーサビリティ）され、明確性・完全性・一貫性・テスト可能性・追跡可能性・実現可能性・必要性のチェックリストで検証されます。

優先順位付けフレームワーク

3つの優先順位付けアプローチをサポートしています。

• MoSCoW – Must Have（約40%）、Should Have（約30%）、Could Have（約20%）、Won’t Have（約10%）。ステークホルダーとのスコープ交渉に最適。
• 価値 vs. 複雑性 – 要件を2x2マトリクスにプロットします。高価値+低複雑性はクイックウィン、低価値+高複雑性は除外候補。
• カノモデル – 基本品質（なくてはならない）、性能品質（あればあるほど良い）、魅力品質（予想外の喜び）に分類。プロダクト志向のプロジェクトに有用。

使用例

例1: ビジネスケースの作成

請求書処理の自動化のビジネスケースを作成してください。
初期投資: 1,000万円、年間削減見込み: 300万円、
分析期間: 5年。感度分析も含めてください。

例2: 業務プロセスのマッピング

現在の顧客オンボーディングプロセスをマッピングしてください。
現状は10日かかり、エラー率25%です。
目標は2日以内、エラー率5%未満です。
将来プロセスも設計してください。

例3: 要件収集計画

新しい顧客ポータルの要件を5部門から収集する必要があります。
引き出しアプローチの計画、手法の選定、
インタビュー質問の準備を手伝ってください。

例4: ステークホルダー分析とエンゲージメント戦略

6部門に影響するデジタルトランスフォーメーションを開始します。
想定されるステークホルダーを特定し、パワー/関心マトリクスを作成し、
チャンピオン・懐疑派・ブロッカーへのエンゲージメント戦略を
策定してください。

例5: CRM移行のギャップ分析

現在、顧客管理にスプレッドシートを使用しています
（500件、手入力、レポートなし）。1万件対応、
自動ワークフロー、リアルタイムダッシュボードを持つ
CRMに移行したいです。ギャップ分析を実施してください。

ヒントとベストプラクティス

• 複数の引き出し手法を組み合わせる。 インタビュー（深掘り）、ワークショップ（合意形成）、アンケート（広範囲）を組み合わせることで、包括的な要件を収集できます。
• まず現状を定量化する。 ビジネスケース作成の前に、取引あたりコスト・エラー率・サイクルタイムなどのベースライン指標を測定しておくと、改善効果の主張に説得力が出ます。
• ニーズとソリューションを区別する。 要件は「何が必要か」を記述し、「どう作るか」は記述しません。「Webフォームを作る」ではなく「受注処理時間を50%削減する」と記述しましょう。
• 財務計算はスクリプトを使う。 business_analysis.py financial --investment X --annual-benefit Y --years N --sensitivity で正確なROI/NPV計算ができます。
• 優先順位は厳格に。 MoSCoWを適用する際、Must Haveは要件全体の約40%を目安にします。80%がMust Haveでは優先順位付けになりません。

トラブルシューティング

ステークホルダー間で要件が合意できない

症状: 異なる部門から矛盾する要件が出され、解決の見通しが立たない。

解決策: 関係者全員を集めた構造化された要件ワークショップを開催します。MoSCoWで強制的に優先順位付けを行います（「10機能だけ選べるなら、どれを選びますか?」）。それでも合意に至らない場合は、オプションとトレードオフを明確にまとめてエグゼクティブスポンサーにエスカレーションし、判断を仰ぎます。

ビジネスケースが却下される

症状: 財務分析ではROIがプラスなのに提案が承認されない。

解決策: 具体的な反対理由を把握します。よくある原因は、他の投資案件と比較してROIが低い、回収期間が長い、リスクが高いと認識されている、戦略との整合性が弱い、などです。Phase 1パイロットへのスコープ縮小、リスク軽減策の強化、純粋なコスト削減ではなく戦略的価値としての再フレーミングを検討してください。

ベネフィットを定量化できない

症状: UX改善やモラル向上など「ソフト」なベネフィットが中心で、数値化が困難。

解決策: 概算でもよいので、現時点でベースライン測定を確立します。代理指標を使用します（例: ユーザビリティ向上の代理としてサポートチケット削減数）。単一の数値ではなく幅（保守的～楽観的）で提示します。定量分析と並べて定性的なベネフィットも明記し、ラベルを付けて区別します。

関連スキル

• Project Plan Creator – 承認された要件からWBS・ガントチャート付きのプロジェクト計画を作成
• Strategic Planner – SWOT・PEST等の戦略分析がビジネスケースのコンテキストを提供
• Vendor Estimate Creator – ビジネスケースで特定したソリューションのコスト見積を作成