いよいよ、パブリックレビュー版が公開されましたので、もう少し内容についてご紹介していきます。
今週は「第1章 序論」と「第2章 主要なコンセプト」です。
【第1章 序論】
ビジネスアナリシスとは、（清水試訳）
- ニーズを定義しステークホルダーに価値あるソリューションを推奨することにより、エンタープライズにおける変革を可能にするプラクティス
- ビジネスアナリシスは様々なイニシアチブで、エンタープライズのすべてのレベル、そして多様な適用分野（パースペクティブ：IT、BPM、ビジネスインテリジェンス、ビジネスアーキテクチャ、アジャイル）において実践される
- ビジネスアナリシスはプロジェクトだけでなく、エンタープライズでの改革や継続的改善によっても生じる。ビジネスアナリシスはトップレベルの戦略から非常に小さな変更まで、エンタープライズのすべてのレベルで生じる場合がある。そして、エンタープライズの現状を理解し、かつエンタープライズの将来の状態を定義するために行なうことができる
エンタープライズという言葉が多く使われていることでお分かりのように、エンタープライズレベルをかなり意識するようになったようです。
つづいて、BABOKガイドの構造で知識エリアです。V2からの大きな変更点を主に解説します。
【ビジネスアナリシスの計画とモニタリング】
ビジネスアナリシスのアプローチおよびの活動の定義について記述しています。
知識エリアの位置づけに大きな変更はありません。詳細なタスクには変更がありますが。
他の知識エリアのタスクの実行を計画するタスクが集まっています。
【引き出しとコラボレーション】
ビジネスアナリシス情報（ニーズ、要求、デザインなど）の引き出しに関するタスクと、ステークホルダーとの協働に関するタスクです。従来の知識エリア「引き出し」に、「要求マネジメントとコミュニケーション」にあった、コミュニケーションに関するタスクが加わり、知識エリアのタイトルが「引き出しとコラボレーション」になりました。
【要求のライフサイクルマネジメント】
要求のコミュニケーションに関するタスクは知識エリア【引き出しとコラボレーション】に移動しましたので、純粋に要求をマネジメントするタスクに絞られました。さらに「要求に優先順位を付ける」タスクが加わったものです。V2の時にも、気が付いた読者も多いと思いますが、BABOKでは要求は発生した時からその状態が変化します。[表明された]、 [確認された] 、[優先順位のついた]、[検証された]などです。このように状態が変わりますから要求にはライフサイクルがあり、それをマネジメントする必要があります。そのために、知識エリアのタイトルもズバリ「要求のライフサイクルマネジメント」に変更されました。
【ストラテジー・アナリシス】
現状から将来の望ましい状態までエンタープライズのトランスフォーメーションを可能にする変革に関する戦略を定義します。この知識エリアのタスクは、エンタープライズ内の任意のレベルにおける、任意のタイプの変革を扱います。つまり、従来のV2では単一のビジネスニーズに焦点があてられていましたが、V3ではエンタープライズ全体にまで拡張されました。以前の「エンタープライズアナリシス」に比べてアクティビティがより重要になったと思います。V3の中での大きな変更点です。
ビジネスアナリシスの定義の変更がそのままこの知識エリアにあらわれています。
【要求アナリシスとデザイン定義】
ステイクホルダー・ニーズをブレークダウンし、ソリューション選択肢を作り上げ、推奨します。また、ビジネス・アナリストは要求を定義するだけでなくデザインの定義にもある程度の責任を持つことになりました。従来は要求を定義することに責任があり、デザインは他の役割の人（例えばITプロジェクトの場合はシステムアーキテクト）とされていたものです。ITでなければ問題ないかもしれません。例えば、ビジネスプロセスではAsIsのプロセスを分析すれば必ずToBeプロセスをデザインします。このデザインの定義に関しては後で解説します。
【ソリューションの評価】
実装されたソリューションによって実現された実際のビジネス価値を測定し確認します。さらに、潜在的価値がすべて実現されているのかを確認するために、ソリューションとエンタープライズの評価を行います。そして、もし、すべての潜在的価値が実現されていなければ、価値のデリバリーに影響しているかもしれない問題もしくは機会を識別します。ソリューションの運用中に継続的に行う活動です。
ソリューション実装後の活動が多くなりました。すべて、プロジェクト終結後の活動です。ビジネスアナリシスの活動がプロジェクト終結後でも多く行われることを意味しています。V2にくらべて、大きく充実した部分です。
V3における知識エリアの関係です。V2と大きな変化はありません。知識エリアの内容は上記のようにいくつか変更されています。
[図のクリックで拡大表示]
【第2章 主要なコンセプト】
【ビジネスアナリシス・コア・コンセプトモデル（BACCM）】
このBACCMについては、事前情報としてすでに解説してありますので、そちらをご覧ください。
[図のクリックでリンク]
【要求とデザイン】（清水の試訳）
- 要求は、ビジネスアナリシス活動の重要な対象でかつ、そのアウトプットとして一貫して認められている。さらに、変更イニシアチブにおいて、ビジネス・アナリストがデザインの定義にもある程度責任のあることを認識することは重要である。要求はニーズにフォーカスし、デザインはソリューションにフォーカスしている。要求とデザインの違いは必ずしも明らかだとは限らないし、もしくは重要だとも限らない。同じテクニックを使用して、要求やデザインを引き出し、モデル化し、分析する。要求は設デザインに結びつき、そのデザインは次のより多くの要求の発見および分析をドライブする。この焦点のシフトはあまり明確でないことが多い。
- 要求とデザインの分類はニーズを理解し満足するために、ビジネス・アナリストの作業として、それほど重要でなくなる。BABOKガイドの中のタスクでは、「要求をトレースする」とか「要求を仕様化しモデリングする」のように要求を指しているかもしれないが、趣旨は、要求と同様にデザインの概念も含んでいる。
-
ビジネスアナリシスは一連の決まりきった活動の単純な職業ではない。複雑で再帰的なもの。要求(あるいは要求のセット)はデザインを定義するために使用されてもよい。その後、そのデザインはより多くの詳細設計を定義するために使用される追加の要求を引き出すために使用されてもよい。ビジネス・アナリストは、さらに詳細にデザインを記述する他のステイクホルダーに要求とデザインを手渡すかもしれない。デザインを完成するのがビジネスアナリストであろうと、もしくは他の役割の人であろうとも、ビジネス・アナリストは、それが要求と整合することを保証するために最終デザインをしばしば吟味する。
要求とデザインの具体例。
|
要求 |
デザイン |
| 多数の組織を横断し単一のビューで6か月の売上高データを見る | ダッシュボードのスケッチ |
| 顧客注文を取りパックするのに必要な時間を削減する | プロセスモデル |
| 患者の病歴を記録してアクセスする | 特定のデータフィールドが見れるスクリーン上のモックアップ |
| 新規事業のビジネス戦略、目的、目標 | ビジネス・ケイパビリティ・モデル |
| 全てのテキストは英語とフランス語でなければならない | 全てのテキストを英語とフランス語にする |
（BABOK®ガイドV3パブリックレビュー版より引用）
具体例を見るとわかりやすいですね。「要求」をモデリングしたり、プロトタイプを作成して見える化したものはすでに「デザイン」という考え方のようです。これならば確かにビジネスアナリストがデザインまで作業することに違和感はないのではないでしょうか。
[図のクリックで拡大表示]