EA導入を考え始めている組織も少なくないだろう。では、EA実践のためには、何が必要となるのだろうか。導入規模によってそれなりの予算やスタッフを確保する必要があるし、プロジェクト実施体制の整備も重要な課題である。これが成否を決める最大の要因といってもよい。とはいえ、これらが重要になるのは、EAに限った話ではない。ここでは、通常のプロジェクトと異なるEA固有の要素を取り上げることにしよう。すなわち、作業全体を支える手法の面ではEAフレームワーク、作業を補助するソフトウェアとしてはEAツール、そして人材の面ではエンタープライズアーキテクトの3点である。
一から作る困難を避ける 〜EAフレームワーク〜
EAは組織ごとに異なるものであり、ある組織向けに作られたものを他の組織でそのまま使っても役に立たない。適用される組織ごとにそれぞれ独自に開発を行なう必要がある。
もちろん、ゼロからあらゆるものを作る必要はない。先駆者の得た知恵やノウハウのうち、使えるものは使うべきであろう。このような視点からEA作成作業を支援する道具の１つが「EAフレームワーク」である。基本的な考え方や成果物のフォーマット、作業の進め方などをまとめたガイドラインやマニュアルのようなものである。日本政府や米国政府によるものをはじめとして、数多くのフレームワークが作成され、公表されている。国内で最も知られているのは、政府による「業務・システム最適化計画策定指針（ガイドライン）」であろう。
EAの作成にはビジネスやITについての知識だけでなく、アーキテクチャ構築のスキルやノウハウも必要である。EA構築経験のないユーザーが、完全な独自開発でEAを導入するのは難しい。フレームワークは、不足しがちなノウハウやベストプラクティスを提供する役割を果たす。また、組織内でEAについてのコミュニケーションを行なう際の共通語彙を提供し、作業の進め方や考え方の標準としても機能する。
図をどうやって描くのか 〜EAツール〜
実際のEA作成作業の中では、多くのモデルや図表を作成する必要が出てくる。作業が小規模なうちは、ExcelやVisioなどのOffice製品でこれを行なうことが可能であるし、コストの面などからもそれが有利な手段である。
しかし、EAが成功するにつれて、プロジェクトの規模は大きくなる。ある程度作業が大規模なものになってくれば、モデル間の関連を人間が理解するのは難しい。また、蓄積された既存ドキュメントのメンテナンス、すなわち成果物の継続的な管理が必要になると、これも人手だけで行なうのは非常に効率が悪い。一部の変更がどこまで影響するのかを把握するのが難しいためである。したがって、単なる図表作成機能だけではなく、あるモデルの変化を他のモデルに自動で反映させる機能、多人数で作業するためのアクセス管理機能などが必要となってくる。
これを行なうのがEAツールと呼ばれるソフトウェアである。国内ではポプキン社の「System Architect」など限られた製品しか販売されていないが、欧米では多数の製品が登場しており、機能の強化や使い勝手の向上を続けている。
やはり経験者が重要 〜エンタープライズアーキテクト〜
フレームワークやツールがあっても、これを使うのは人である。EA構築のスキルやノウハウを持った熟練者が作業に加わることが望ましいのはいうまでもない。こうした人々はエンタープライズアーキテクトと呼ばれる。米国では重要な職種として認知されつつあり、肩書きとして見かけることも増えてきた。
実際のEA作業では、特に導入初期には、社内にはエンタープライズアーキテクトがいない、あるいはエンタープライズアーキテクトが十分な経験を有していないことが少なくない。このため、EAコンサルタントなどの外部の専門家に助力を仰ぐケースが多い。作業を進める中で社内にノウハウを蓄積し、次第に自力でEAの構築や運営を行なうことができるようになっていくのが一般的なパターンである。
EAフレームワークは有用ではあるが、そのまま実行すれば誰にでもEAが実現できるといった即効性のあるマニュアルではない。EAツールも、何を図表にするのか、その内容について特に示唆を与えてくれるわけではない。これらの道具を使いこなせるかどうかは、エンタープライズアーキテクトの力量しだいである。
（みずほ情報総研 EAソリューションセンター 相原 慎哉）
※本稿は、みずほ情報総研が2004年11月16日に発表したものです。
