知識エリア【ソリューション評価】
この知識エリアも大幅な変更です。バージョン2ではビジネスアナリシスはプロジェクト開始前とプロジェクト中のアクティビティに主眼が置かれていて、プロジェクト終結後のアクティビティはわずかしかありませんでした。このバージョン3ではプロジェクト終結後もプロジェクトの開始前、プロジェクト中と同様の重みをもつようになりました。それはソリューションの価値の実現に責任を持つ、と言う新しいビジネスアナリシスの役割(定義)からくるものだと思います。
それでは、まずこの知識エリアの概要です。筆者の試訳をご覧ください。
- 知識エリア「ソリューション評価」は、ビジネス・アナリストが行なう複数のタスクについて記述する。それらはソリューションの実行と提供される価値についてアセスメントする、またエンタープライズでの実運用のソリューションにたいして、価値の十分な実現を妨げている障壁または制約の除去を推奨する。
- 知識エリア「ストラテジーアナリシス」は、経営目標を識別し、実際の価値と潜在的価値の両方を決定する活動を含む。知識エリア「要求アナリシスとデザイン定義」は、ビジネスニーズとソリューションの、定義とモデリングにフォーカスしている。また「要求アナリシスとデザイン定義」はそれらのモデル、および提供されるかもしれない潜在的価値を分析する。「ソリューション評価」と「要求アナリシスとデザイン定義」の主要な相違は、実際のソリューションの存在である。それは単に部分的なソリューションかもしれない、しかし、ソリューションかソリューション・コンポーネントは既に実行されており、ある形式ではすでに開始している。「ソリューション評価」のタスクは変革が開始される前に、現在価値をアセスメントするために実行される場合もあれば、ソリューションの実装後に便益の実現を支援するために実行される場合もある。
- 「ストラテジーアナリシス」のタスクはニーズとソリューションスコープを決定する。「要求アナリシスとデザイン定義」のタスクは必要な変革、およびそれらの変革が提供することができる潜在的な価値について記述する。「ソリューション評価」のタスクは、提供された実際の価値をアセスメントして妥当性確認する。これらのタスクはすべて周期的であり、すべて進行中であるが、必ずしも順序に沿って完成する必要はない。
- 「ソリューション評価」のタスクは、異なる開発ステージにおけるソリューション・コンポーネント上で行なうことができる:
・プロトタイプまたは概念実証: 動作し価値をデモンストレートするが、実用に十分でない、ソリューションの制限付きバージョン。
・パイロットまたはベータリリース: ソリューションの制限付きバージョンで問題に対処するために使用されて、どれくらい実際に価値を提供できるかを理解できる。
・運用上のリリース:ソリューションの完全版もしくは部分的完成品でビジネス目標を達成するために使用され、プロセスを実行する、あるいは望ましい結果を満足する。 - 「ソリューション評価」は、提供される実際の価値を分析するタスク、価値が実現されるのを妨げているかもしれない制限を識別するタスク、そしてソリューションの価値を向上させる方法を推奨するタスクを記述する。それは、パフォーマンス・アセスメント、テストおよび実験のどんなコンビネーションも含んでいるかもしれないし、また価値のある客観的・主観的な評価を組み合わせるかもしれない。「ソリューション評価」は、一般にエンタープライズ全体ではなくエンタープライズのコンポーネントにフォーカスする。知識エリア「ソリューション評価」は次のタスクで構成される:
大幅に変更になっています。バージョン2の4つのタスクは、他のタスクと統合されてしまい、この知識エリアにはありません。「ソリューションを妥当性確認する」「ソリューションのパフォーマンスを評価する」の2つのタスクが詳細化され、5つのタスクに分割されたようです(まだパブリックレビュー版なので断定はできませんが)。
[図のクリックで拡大表示]
ソリューションの「価値」の実現に責任を持つ、という新しいビジネスアナリシスの役割に応じたタスクの変更だと理解してください。バージョン2ではプロジェクト終了後、ソリューション運用中のタスクは一つしかありませんでしたが、V3では受け入れを含めて合計5つのタスク全てが受け入れと運用中におけるアクティビティとなったことは、非常に大きな変化ではないでしょうか。考えてみると、ソリューションが組織に価値をもたらすのはプロジェクトの最中ではありません。プロジェクト終了後の運用において主たる価値を発揮するわけです(ウォーターフォール開発の場合)。ですからビジネスアナリシスがステークホルダーに価値を提供することに責任を持つためには、運用中のビジネス環境の変化に応じたソリューションのチューニングまたは組織変革の活動にまで踏み込むことは、ある意味当然のことと言えると思います。
それでは、各タスクの概要です。筆者の試訳をご覧ください。
ソリューション・パフォーマンスを測定する:
- ソリューションをアセスメントする最も適切な方法を決定する。エンタープライズゴールおよび目標とどのようにアライメントするか、そしてソリューションの振る舞いについての情報を収集することを含む。
パフォーマンス測定を分析する:
- このタスクは、企業とステークホルダーに提供する価値を理解するためにソリューションの実行に関する情報を検討し、パフォーマンスが現在のビジネス・ニーズを満たしているかどうか判断する。
ソリューション制限をアセスメントする:
- 現在のビジネス・ニーズを満たすのを妨げているソリューションスコープ内の問題を調査する。
エンタープライズ制限をアセスメントする:
- ソリューションがエンタープライズに提供できるトータル価値の実現を妨げているかもしれない、ソリューション・スコープの外側の問題を調査する。
ソリューションの価値を向上させるためにアクションを推奨する:
- ソリューションによって提供できる価値を向上させるために、エンタープライズが講ずることができるアクションを識別し定義する。
つづいてこの知識エリアのデータフロー図です。
知識エリア「ストラテジーアナリシス」のデータフロー図と並べてご覧ください。
[図のクリックで拡大表示]
「ソリューション評価」でのアウトプットが「ストラテジーアナリシス」の「現在の状態を分析する」タスクのインプットになっていることが分かりになると思います。
- 8.1 ソリューションパフォーマンス測定
- 8.3 ソリューション制限アセスメント
- 8.4 エンタープライズ制限アセスメント
これらのアウトプットが「ストラテジーアナリシス」のインプットになることにより、運用中のソリューションのチューニング、改修プロジェクト、または廃棄し新たなソリューションの開発が始まるのです。ビジネスアナリシス全体としてPDCAが展開されているという事になります。
知識エリア【ソリューション評価】におけるBAコアコンセプトモデル
コア・コンセプト |
「ソリューション評価」においてビジネスアナリストは; |
変革(Change):組織的に制御された変革(トランスフォーメーション) |
ソリューションの潜在的価値を実現するためにソリューションかエンタープライズのいずれかへの変革を推奨する。 |
ニーズ:ステークホルダーにとって潜在的価値のある問題、機会、または制約 |
ソリューションかソリューション・コンポーネントがどのようにニーズを満たしているか評価する。 |
ソリューション:コンテキストにおいてニーズを満たす具体的な方法 |
ソリューションの実行をアセスメントして、それが潜在的価値を提供している場合は、分析して、なぜソリューションかソリューション・コンポーネントによって価値が実現されないのかを分析する。 |
価値:コンテキストにおいてステークホルダーにとって重要なもの |
ソリューションが潜在的価値を提供しているかどうか判断して、なぜ価値が実現されていないか調査する。 |
ステークホルダー:変革又はソリューションと関係を持つグループまたは個人 |
ステークホルダーから、ソリューションのパフォーマンスおよび価値デリバリに関する情報を引き出す。 |
コンテキスト:環境のなかで変革を包含する部分 |
価値実現を阻害するコンテキストにおけるソリューションのパフォーマンス測定、およびどんな制限があるのかを決定する際にコンテキストを考慮する。 |