「全体最適」、「ITガバナンス」、といった言葉をよく耳にする。これらの解としてEA（Enterprise Architecture）が提唱されていることは、読者の皆さんもご存知のことと思う。個別のシステムの最適化が、企業全体としての最適化とは一致しない場合が多いことから、これを打開するための「ITガバナンス（ITを統治する）」の仕組みとして登場したものである。

　一方、企業システムの中で、J2EEは重要性を増している。今やITを語る場合、J2EEは避けては通れない。では、EAの導入を真剣に考えている人は、ITについて、特にJ2EEについて、どのように考えていけばいいのだろうか。

ビジネスとITとの距離を埋める

　「ビジネス戦略を変更したら、システムもすぐに追随してほしい」と経営者は言い続けてきた。これに応えてシステム部門も、ビジネス要件の変化へ柔軟に対応できるシステム環境を作ろうと努力し続けてきた。しかし現実には、変化に柔軟に対応できるシステム作りへの道のりは遠い。ましてや、長期間にわたってすべてのシステムの共通基盤となるフレームワークを作り上げたり、全社システムの全体最適化を実現するのはむずかしい。ビジネス戦略とITとの間には、まだまだ隔たりがあるからだ。

　そこで注目が集まっているのがEA（Enterprise Architecture）である。

経営戦略とIT戦略を長期的に合致させるEA

　EA（Enterprise Architecture）は、直訳すると、「企業全体の設計思想」である。企業システムの全体最適化を実現するための体系的な取り組みを意味している。

　EAは、開発方法論ではない。5年後、10年後の企業全体のあるべき姿から、システムのあるべき姿（To Be）を明確にして、そこへ向かって日々の努力を重ねていくという活動である。このように説明すると、「フレームワークや開発手順書なら、ずいぶん前に作っているのだが」と考えるシステム部門も多いだろう。

　EAは、個別のルールを定める開発手順書の領域にとどまらない。手順書で言えば、表記の順番、使う用語、図示のルールなど詳細が決まっている。しかも、それらは企業システム全体のあるべき姿（To Be）からブレイクダウンして導き出されたルールであるため、ルールを守って手順書を書く行動を5年、10年と続けていると、次第にTo Beモデルへ近づいていく。またEAでは、ルールを守っているかどうかを監査する組織を設けるため、チェックし、評価し、必要に応じてルールを手直ししていくというサイクルを組織的に回していくことができる。

　EA導入の効果としては、中長期的な経営戦略とIT戦略を合致させ、全体最適を実現できることが挙げられる。企業のTo Be モデルと同期をとって企業システムのTo Beモデルを引き出しているため、長期間にわたってEAを実践することによって、経営とITの乖離がなくなり、経営の視点からITを使いこなすことが可能になる。

オンデマンドに対応するビジネスにもEAは不可欠

　システム単位での「個別最適」ではなく、経営戦略と合致した「全体最適」を追求する。この当たり前のことを実行する枠組みが、従来は確立されていなかった。結果として、ビジネスの変化にシステムを対応させることが難しくなっていた。

　「需要に合わせたオンデマンドな生産、購買意欲の急激な変動に対応できるオンデマンドなバリューチェーンなど、ビジネスの変化に機敏に対応するには、個別最適化されたシステムはむしろ障害になります。EAをベースに全体最適を実現してこそ、オンデマンドなビジネス要求に対応できるシステム基盤が構築できるのです」と、日本アイ・ビー・エム株式会社 ソフトウェア事業部 サポート＆サービス ディスティングイッシュト・エンジニア ITアーキテクト 長島哲也氏は強調した（11/14に開催されたEnterprise Software Conferenceにて）。

EA早わかり－－4つのアーキテクチャ・モデルでシステムの理想像を明確にする

　EAは、単一の概念ではなく、A社流EA、B社流EAがあっていいのだが、典型的なEAのおおまかな流れは以下のようなものとなる。

　まず、アーキテクチャ・モデルを使って、システムの現状（As Is）と理想像（To Be）を描き、そのギャップを明確にする。次に、ギャップを埋めて理想像に近づくにはどうしたら良いかを考えて計画を立てる。さらに、新規開発や再構築時はもちろん、日々のドキュメント作成などにもEAを遵守し、チェック組織が絶えず評価し、見直しを図っていく。

　To Beモデルを明確にするうえで重要な役割を果たすアーキテクチャ・モデルは、よく4階層のピラミッドで表現される。上から順に、(1)ビジネス・アーキテクチャ、(2)データ・アーキテクチャ、(3)アプリケーション・アーキテクチャ、(4)テクノロジー・アーキテクチャである。

　(1)のビジネス・アーキテクチャでは、業務の手順や情報の流れをモデル化する。

　(2)のデータ・アーキテクチャでは、業務に必要なデータの構造や相互関係を表す。

　(3)のアプリケーション・アーキテクチャでは、アプリケーションの実現方式やデータ処理の形態などを定義する。

　(4)のテクノロジー・アーキテクチャでは、ビジネス・モデル、データ・モデル、アプリケーション・モデルを実現するうえで必要なインフラを定義する。

　「モデル化の際には、データフロー図、UMLのアクティビティ図、ER図など、標準的な記述方法を使うことがポイント。モデル図は、あとで、経営者とIT部門がコミュニケー ションするための共通言語としても役立ちます」（長島氏）。

　前編では、EAの基本を紹介した。後編では、EAの成果物と、EAを実現するうえでJ2EEが果たす役割について紹介したい。