ビジネスアナリシスの知識体系BABOKガイドとは（後編）：ビジネスとITを繋ぐビジネスアナリシスを知ろう！（1/2 ページ）

ビジネスアナリシス（BABOK）がいかにビジネスとITを結びつけることができるか、さらにデジタルトランスフォーメーションにも大きく貢献できる知識体系にもなっている。

[清水千博，ITmedia]

第1回：なぜDXにおいてビジネスアナリシスが必要なのか

第2回：ビジネスアナリシスの知識体系BABOKガイドとは（前編）

　第3回目はビジネスアナリシス知識体系（BABOKガイド）について学びましょう。今回は後編です。

知識エリアとタスク

　次の6つの知識エリアがあります。

・戦略アナリシス：プロジェクト開始以前の超上流工程での作業です。プロジェクトをなぜ開始する必要があるのか（WHY）、そしてそのスコープを決めます。

・引き出しとコラボレーション：ニーズを発見し、要求を引き出します。

・要求アナリシスとデザイン定義：引き出された要求を構造化しモデル化し、ビジネスニーズを満たすソリューション案を特定します。

・要求のライフサイクルマネジメント：要求情報を発生から廃棄までマネジメントし、維持します。

・ソリューション評価：ソリューションのパフォーマンスと、ソリューションが提供する価値を評価します。そしてその価値の実現を妨げる障壁や制約を除去します。

・ビジネスアナリシスの計画とモニタリング：ビジネスアナリストとステークホルダーの作業全体を計画します。

　6つの知識エリアの関係を表した図です。

図1：知識エリアの関係

　もう少し詳しく見ていきます。

・戦略アナリシス

図2：知識エリア：戦略アナリシス

　デジタルトランスフォーメーション（DX）と最も密接な関係がある知識エリアが「戦略アナリシス」です。DXはビジネスモデルを変革することですから、ビジネスモデルキャンバスなどを使えば、データ構造や業務プロセスなど、企業のチェンジするべき部分を特定できます。DXは大規模な変革なので企業のデータ構造（内部資産）や業務プロセスのみならず、業務のポリシー/ルール、更に組織構造・組織文化まで変える必要が出てきます。すなわち企業全体の構造（エンタープライズアーキテクチャと言います）を変革することになるでしょう。

　また、DXほど大規模でなければSWOT分析などで、弱みを克服するために特定業務を改善するために業務プロセスを分析することも可能です。そのようにDXや業務改革/改善の概要（大筋）を作り上げるのが「戦略アナリシス」という知識エリアです。

図3：戦略アナリシス：内部要因

　そして、企業全体の現状と将来像を明確にし、そのギャップを埋めるのが「チェンジ戦略を策定する」タスクです。

図4：チェンジ戦略を策定する

　このフレームワークを使うと効率的にDXの全貌を明確にすることが可能になります。もちろん組織文化は一朝一夕では変えられないことかもしれませんが、それを変革しなければいけないということが早期に明確にすることができます。また、企業を分析して、チェンジ（DX）を実施できる力があるのか、ステークホルダーの文化は変革の準備ができているのか、また変革後に将来状態を維持できるのかなどを評価することも重要です。

・引き出しとコラボレーション

　要件定義工程では「要求」を引き出すことに力点が置かれていますが、BABOKでは要求（本人が自覚しているもの）よりも、認知されていない無自覚で潜在的な「ニーズ」をより重要視します。それが前回詳述したコア・コンセプトの「ニーズ」です。潜在的でステークホルダーがまだ認知していないようなモノやコト（それがニーズ）を発見し、ソリューションにつなげると大きな価値が実現できるという考え方です。ですから豊富な引き出しのテクニックが用意されていて、例えばステークホルダー本人が認知していないニーズを発見するやり方としてデータマイニングもあります。

図5：知識エリア：引き出しとコラボレーション

・要求アナリシスとデザイン定義

　この知識エリアの作業は主にプロジェクトの中で行われます。

図6：知識エリア：要求アナリシスとデザイン定義

　モデルのカテゴリーを見てください。データと情報（What）、人と役割（Who/Where）、アクティビティ・フロー・能力（How/When）、根拠（Why）に整理されています。

図7：要求アナリシスとデザイン定義モデルのカテゴリー

　データモデルだけ作成しても、正しいシステムを作成することはできません。プロセスだけモデル化しても正しくありません。複数のモデリングテクニックを使い、上記5W1Hの視点で要求を分析することを勧めています。さらにそれらのモデル間の関係も重要です。データ構造を変えるとプロセスの一部に影響が出たり、ビジネス・ルールも変更しなければいけなくなる……、などです。複数の視点でみることにより、要求の抜けや漏れも見つかったりします。

　それは立体を正面から見ただけでは正しく表現できなく、上下左右、断面など複数の視点から見てはじめて立体の正しい姿が表現できるのと同じです。

　このような作業は、もはやワード/エクセル/パワーポイントで管理できるレベルではありません。複数のモデルを有機的に管理する専用のモデリングツールが必要になります。

　上図のピンク色の「モデリング・要求アーキテクチャ」はモデリング用のツールです。BABOKではこのようなモデリングツールの使用を強く勧めています。

図8：アーキテクチャ管理ソフトの例

　図8はアーキテクチャ管理ソフトの例です。プロセスモデル、ビジネス・ルール、データモデル、GUIなどが有機的にリポジトリに統合化されます。モデル間の関係性を可視化してくれますので影響分析に役立ちます。

　「デザイン案を定義する」タスクでは要求を次のコンポーネントに割り当てます。

• データ構造
• 組織構造。組織間の相互作用、その顧客とサプライヤー
• 職務機能と責任
• ビジネス・プロセス
• ソフトウェア・アプリケーション
• ビジネス・ポリシー/ビジネス・ルール
• ビジネス遂行上の意思決定

　IT（ソフトウェア・アプリケーション）以外のコンポーネントが多いことに注目してください。トランスフォーメーションにはIT以外の要素も重要です。

　これは戦略アナリシスで明らかにした以下の企業構造に対応します。

• 企業のデータ構造（内部資産）
• 組織構造・組織文化
• 業務プロセス（能力とプロセス）
• 業務のポリシー/ルール、

　戦略で明確にした概要レベルの変革が、より詳細なプロジェクトレベルのコンポーネントに分解されていることが分かります。これで具体的な複数のプロジェクトが発足できます。

　特にDXの場合は上記全てを変革することになります。このタスクがDXを実現するためには欠かすことができません。