ある晩のこと。筆者は、取材先のA氏とこんな話をしていた。多少のアルコールが入っていたが、それもあくまで取材のためである。
A氏は、ユーザー企業のシステム部員である。「全社最適」を求めて、複数の情報システムが、共通の「オブジェクト」を利用できるような仕組みをつくるべく、心血を注いでいる。
「やっぱり、全社最適、ということを突き詰めると、行き着くところはEA（エンタープライズ・アーキテクチャ）だと思うんですよね」。
A氏は自分に言い聞かせるように言う。私は思わず聞いてしまった。
「それで、EAって結局のところ何なんですか？」
「うーん、人によって違いますねえ」と、A氏は応じた。
「IBM用語だと思っている人もいれば、日経BP用語だと思っている人もいるんじゃないですか？」
この発言は、半分は冗談だが、EAへの認識が世間ではいまだまちまちである、という重要な指摘を含んだ発言といえる。
EAって、結局のところ何なのだろう？
EAとは、1986年にIBMのZachman氏が提唱したモデルで、ごく短く要約すると、「全体最適」を実現するための仕組み、ということのようだ。米国では、政府調達の条件に「EAを策定すること」が盛り込まれたことで広がった。日本でも、e-Japan計画や、相次ぐ大規模システム・トラブルがきっかけとなって、「ITガバナンス」やEAへの認識が高まっている。
なお、最近の日経BP社の雑誌でEAへの言及が増えていることは事実である。「日経コンピュータ」誌2003年9月8日号特集などだ。
そして、EAとは、IT（情報技術）そのものではないが、ITガナバンスを確立するための方法であるらしい（この説明だと、かえって難しく聞こえるかもしれない）。
別の日、私はこんなことを取材でB氏に聞いてみた。
B氏は、大手ベンダーで高い地位にあるエンジニアである。「コンサルタントとアーキテクト」の両方が連携しあう必要がある、という考えをもって活動をしている。
そして、私はB氏に教えてもらおうと思って、こんなことを聞いた。
「開発プロセスという言葉がありますよね。あの上流の方をずーっと伸ばしていくと、経営プロセスにまでたどり着いて、EAになるんじゃないですか？」
あまりの突飛な質問に戸惑ったのか、B氏はこう回答してくれた。
「うーん、それは一面、そう・・・ですね」。
ここで、「ずっと伸ばしていく」という表現は不適当だった。EAとITは「直交している（＝独立している）」訳だから、「ずっと行って、直角に曲がったところ」という表現の方が正しいはずだ。
EAはITそのものではないとは言っても、ITに携わる人間に等しく降りかかってくる。
全体最適－－会社の偉い人に響きがいい言葉でいえば、コスト最適化、あるいは情報化投資の最適化のための手法がEAである。経営に携わる人にとっては、経営上の問題意識と情報システムを結びつけるための有効な手段となることが期待されているものだ。そしてITに関わる人間にも、EAは「様々な決まり事」という形で直接影響してくる。プロジェクト管理の体系、開発プロセス標準などと同様に・・・。
今までの話の中には冗談が含まれているが、もちろん冗談を紹介することがこのコラムの目的ではない。
情報システムに携わる人間が真剣に仕事をしていくとき、その先にはEAが待ちかまえているようなのだ。それが、A氏やB氏との会話の中で、感じられたのである。
EAを策定する過程で、EAで定める「スタンダード」の一部という形で、実装技術も選択することになる。
そしてJ2EEは、当然ながら実装技術の最有力候補として登場する。今の段階で、大規模システムにまで適用可能な開発環境を探すと、結局の所J2EEに登場してもらうほかないからだ。
EAは、情報システムに携わる人にとって、遅かれ早かれ関わりを持つようになるものらしい。そして、EAに適切に対応できる情報技術として、最も有力なのがJ2EEである－－このことは共通の認識となりつつある。
さて、A氏、B氏は実在の人物である。筆者のいささかトンチンカンな質問にもきちんと答えていただけたことからその片鱗が分かるように、深い見識の持ち主なのである。
筆者は2週間後の11月14日開催のイベント「エンタープライズ・ソフトウエア・コンファレンス」で、A氏、B氏のお二人と一緒にパネル・ディスカッションに出席することになった。EAとJ2EEというと、なにやら難しげに聞こえるかもしれないが、このパネルでは現場の目線から話を聞いていきたい、と思っている。
やがて来るEAとJ2EEの関わりについて、そして来るべきJ2EEの最新技術をお知りになりたい方は、ぜひともこのイベントに足を運んでいただきたい。
