2009年8月18日

7月からIIBAサイトにコミュニティサイトが開始されました。

メンバーが自由にBLOGを書いたり、フォーラムを立ち上げられるものです。

とはいっても、ＩＩＢＡの中心的メンバー（President&CEOのKathleen Barrettや、BABOKを作成したKevin Brennanなど）がメインです。そのうち、筆者も投稿してみようと思っています。

これから興味のあるトピックスをかいつまんでご紹介しようと思います。翻訳権がどうこうと、硬いことを言っても始まりませんので、筆者の独断ベースで日本語化します。興味のある方は是非原文で確認してください。内容の保証（翻訳）はいたしかねます。毎日のように誰かしらが投稿し、それに対して別の人がコメントしています。生きているビジネスアナリシスを感じます。

BABOK（R）ガイドの行間を読むつもりでご覧ください。

原文サイトのURLです。

ログインにはIIBAメンバーIDとパスワードが必要です。

http://community.theiiba.org/profile.htm?mode=pvb&pid=17&op=Comment&articleId=34&blogId=1

*****************************************************************************

Kevinの７月１１日のBlogより

【テーマ：エンタープライズアーキテクチャとビジネスアナリシス】

ビジネスアナリシスとエンタープライズアーキテクチャは同じ専門（descipline）でしょうか？

この２つの違いは何でしょう？

このことを考え始めたのは、下のガートナーによるEAの定義に出会ったからです。

エンタープライズアーキテクチャとは、ビジネスのビジョンと戦略を、企業の効果的な変革に翻訳（translate）し、主な方針（principle）を、創造、伝達、改善することにより、企業の将来像をモデル化しその実現を可能にする。

一方、IIBAによるビジネスアナリシスの定義は：

ビジネスアナリシスとは、ステークホルダ間のリエイゾンとして働くのに必要なタスクとテクニックを集めたもので、組織の構造、方針（戦略）、活動を理解し、組織ゴール達成を可能にするソリューションを推奨するために使われる。

どちらの場合でも、企業の今日の状態を理解したり、明日のあるべき状態をステークホルダから(要求を)引き出す人は必要です。しかし２つ大きな違いがあります。

まず、エンタープライズアーキテクトは、具体的で実用的な変革よりも、企業全体をみます。２番目に、歴史的に技術志向が強く、ビジネスモデル、プロセスなどよりも、ITアーキテクチャを見ます。

しかし、多くの人からはBAに関しても同じことを聞きます。

一方、プロダクトマネジメントを調べてみて、BAとの本質的な違いが分かりました。一言でいえば、プロダクトマネージャは市場を分析しますが、ビジネスアナリストは組織を分析します。最初の質問に戻れば、EAとBAの違いはサブジェクト（科目）の違いというより、スコープの違いでしょうか。

意見を歓迎します。私は皆さんに質問を投げかけているのであり、結論付けるつもりはありません。念のため。

*****************************************************************************

＜Dean J Larson　のリプライ＞

ビジネスアナリシスは、エンタープライズアーキテクチャを構成している４つのアーキテクチャの一つのビジネスアーキテクチャと非常に重なります。他の３つのアーキテクチャ（アプリケーション、データ、技術）は確かに技術志向です。ビジネスアーキテクチャは他の３つと異なり、私に言わせれば、別のものです。ビジネスアーキテクチャの場合は、発表時にエンタープライズアーキテクチャの一部とされ、他の３つの技術志向のアーキテクチャ（およびEAが派生したもとのIT文化）により、単なるコンテキストとITプロジェクト要求の発生源としてその意味を萎縮、減少させてしまったのです。

それ以来、ずーっと、ビジネスアーキテクチャはこのIT作業のインプットを提供して来ましたが、実はそれ以上のものなのです。

あなたのブログへの直接的な回答として、ビジネスアナリシスはプロジェクトでビジネスアーキテクチャに関する仕事をする誰もが必要とするコアスキル（すなわちタスクとテクニックの集合）です。

なぜなら、ビジネスアーキテクチャはエンタープライズアーキテクチャの一部とみなされるし、確かにエンタープライズアーキテクチャとビジネスアナリシスはオーバーラップしています。

しかし、ビジネスアナリシスとビジネスアーキテクチャはより深い関係にあります。

********************************************************************************

＜Doug B. Goldbergのコメント＞

同意です。さらにもう少し追加。

Deanのコメントに追加します。

BAは企業要求全体を引き出すために、標準的プロジェクト同様に、全体像を支配する能力を持ちます。BAはEAが明確にするべき技術的詳細の裏表までを知る必要はありませんが、基となる要求を引き出す能力を持つ必要があります。

IIBA/BABOKではこれらのスキルセットが明確にあります。EAを遂行するBAはその全ての知識まで必要とはしませんが、適切なステークホルダに依頼して、提供してもらえばよいのです。標準的なプロジェクトと同じことです。

純粋なEAは、自分のタスクを完遂させるためにBA能力を減少させてはいけません（皆さんはやっていないと思いますが）。引き出しや要求アナリシスのコアスキルを身につけることにより、EAはKevinの言うとおりに、プロジェクトをさらなるレベル（スコープ）に引き上げることができるのです。

*****************************************************************************

このようなやり取りが、毎日のようにコミュニティ内で行われています。興味深いものもあれば、どこかの支部内での話題もありさまざまです。読者皆様の参考になれば幸いです。（清水）