2004年押さえておくべきキーワード:「EA」〜企業システム構築におけるEAの効用情報マネジメント トレンド解説(2)

2003年半ばからIT業界で盛んに使われるようになったキーワードに「Enterprise Architecture(EA)」がある。EAが目指しているのは、業務プロセスにのっとってシステムを最適化するというフレームワークだ。情報マネージャにとって、EAはどのような意味を持つのか

» 2003年12月09日 12時00分 公開
[アットマーク・アイティ編集局,ITmedia]

EAとは何か?

 夏ごろからIT誌やセミナーなどで盛んに「EA(Enterprise Architecture)」というキーワードが頻出するようになった。電子政府実現のためのガイドラインとして引用されることも多いため、「ウチの会社には関係ない」と思われる情報マネージャも多いだろう。しかしEAが実現しようとしているコンセプトは、組織形態を超えてあらゆるシステム開発のガイドラインになると思われる。

 EAが形として見えるようになってきたのは、1996年。米国政府において「全体最適の観点でIT資産/調達管理を行い、効率的なIT企画立案・開発を実現する」ために、連邦政府機関に、(1)CIOの設置と(2)EA策定を義務付ける法律を制定したことから始まる。

 これまで米国に限らず、政府のIT調達に関しては、1つの組織内であっても業務ごとにバラバラに構築されていたため整合性が取れないばかりか、同じような業務システムを部署ごとに個別に導入し、開発・運用コストがかさむという課題を抱えていた。これを解決するために、「業務・システム最適化計画」として検討されたのがEAだ。そして1999年、「連邦政府エンタープライズ・アーキテクチャ・フレームワーク(FEAF:Federal

Enterprise Architecture Framework)」を作成し、2002年から「エンタープライズ・アーキテクチャ・プログラム管理局(FEAPMO:The

FEA Program Management Office)」を設立し、FEA開発を本格展開し始めている。

 “アーキテクチャ”という語感から、「システム基盤を構築すること」と誤解されがちだが、EAの概念はもっと広い。ベンダやコンサルタント、識者の間ではさまざまなとらえ方があるようだが、米国の「Chief Information Officers Council」によると、むしろシステムのライフサイクルと整合性を考慮した「IT化計画推進ガイドライン」に近い。

 FEAFにおけるEAは次の4つの階層で成り立っている。

  1. 政策・業務体系(Business Architecture)
    業務を分析し、各業務の構造やパターンを認識すること
  2. データ体系(Data Architecture)
    XMLなどの標準技術を使い、業務システムで使うデータの統合・標準化を進めること
  3. 適用処理体系(Application Architecture)
    モデル化したビジネスプロセスと、システムモデルとの懸け橋になる部分。概念モデルやプロセスモデル、ビジネスリファレンスモデルなどを使い、個別ソリューションや業務の相互接続性を確認し、コアアプリケーションを定めていくこと
  4. 術体系(Technology Architecture)
    電子政府ソリューションのコア・コンポーネントに適合した標準技術とその開発ガイダンスをまとめること

 要約すると、(1)統一された手法を使って業務プロセスを分析・可視化すること、(2)各業務で使うデータ形式を標準化すること、(3)洗い出した業務プロセスをモデル化し、おのおのの相互接続性を確認すること、(4)標準技術と開発手順に従い効率的に開発を進めること、という流れになる。「業務・システムの全体像をとらえ、互いの関係性を整理して必要な部分から効率的にITを導入していこう」というわけだ。こうした活動を指揮する専門家として、各省にCIOを設置することが義務付けられた。

 国内では2003年7月に発表した「電子政府構築計画」の中で、2006年3月までに各省庁でEAを推進する旨を明言している。各官公庁や市町村にCIO/CIO補佐官の設置を義務付け、EAを推進することとした。これを受け、ITベンダもEAをキーワードにした製品やコンサルティングサービス、方法論を打ち出しはじめた。

EAで何ができるか

 EAがもたらす企業システム構築へのメリットについて考えてみよう。

 もともとEAには、バラバラで無駄が多かったIT調達を効率的に行っていこうという狙いがある。例えば複数の部門・機関で個別に承認システムを構築した後、ふたを開けてみたらコアとなる承認プロセスは皆同じ、ということがある。この場合個別開発より、コアプロセスを実装して横展開する方が開発期間もコストも大幅に短縮できる。あらかじめ全社内の業務を分析・可視化しておけば、効率的にシステム開発を進められるようになる。またBPRの観点からいっても、重複している業務を統合することで、組織や業務のスリム化が図れるわけだ。こう考えると、EAが決して「電子政府のためのフレームワークではない」ということに気付くだろう。

 また自社内に標準化された開発手順を持つことで、IT部門に開発スキルを蓄積できるというメリットもある。EAにおける開発手順とは、プログラミング技術や個別製品についてではなく、むしろIT調達(CMM/CMMIなど)やプロジェクトマネジメント(PMBOK)などにフォーカスしたものだ。1人の優秀なプロジェクトマネージャ頼みではなく、「誰がプロジェクトマネージャになっても、同じように円滑に進められる」ということを目指している。

 もう1つ有用な点は、長期的な観点で業務およびシステムモデルを描いていくこと。新しいビジネスを始めたり、何か問題が起きるたびに、CRMやSCM、個別業務システムをその都度開発していたのでは結局“個別最適”の輪から抜け出せない。

 もちろん「先のことは分からない」という意見もある。今後の技術動向を読むこと自体難しいし、また会社の業務やビジネスがどのように変わっていくかは分からない。EAが示しているガイドラインでは、「まず企業・組織のトップが業務改革やIT施策に対して明確な方針を打ち出し、それを組織内で共有すること」としている。また適用技術に関しても、現在は「Java(J2EE)やXMLなどの標準的なWeb技術が中心」と提示。むしろいまは、政府・企業にかかわらずレガシーやWebシステムが混在している状況なので、「EAを推進する中で、いまの標準技術を使い基盤を統一した方がいい」という見解に立っている。

 つまり企業システム構築におけるEAの効用とは、(1)経営層の意向を反映し、(2)中・長期の経営計画の中でBPR/IT策定を行い、(3)標準的なオープン技術によって効率的に開発・運用を進めていく、という3点がある。

 EAのコンセプトを眺めると、1つのことに気が付く。それは「ベンダ任せのIT化はあり得ない」ということだ。まずIT化の方針を経営者自身が方向付けする必要があるし、業務を分析し、現状を把握したら次にどうすべきかは、ユーザー側で決めなければならない。EAは、ベンダ任せでIT化を進め、使われなくなったシステムが多数あるユーザー企業にとって、1つのターニングポイントになると思われる。

ベンダのサービスは補助的なもの

 具体的にどう進めていくか。まず、先に示した4つの階層に基づき、CIOが中心となり方針を文書化していくこと。ただしその際に問題になるのは、「業務・システムの詳細をどこまで定めるか」ということだ。先述したとおり、EAでは長期的な経営計画/システムライフサイクルを考慮してIT化を進めていくため、詳細を決めるのは不可能だ。まずは経営者自身がビジョンを定め、そしていまある業務の姿(As

Is)を分析することが先決だが、その後具体的にどのような作業をしていくのか分からない方も多いはずだ。

 こうした中、ITベンダはこぞってEAの手法を取り入れたコンサルティングサービスを展開している。富士通では「行政システム最適化サービス」を開始、日立製作所もEAの潮流に乗り、電子政府・自治体事業を強化している。日本ユニシスでは、官公庁や地方自治体向けのコンサルティングサービスで、CIOやCIO補佐官に向けて「EA策定支援」や「EA評価支援」サービスを提供。いまは官公庁関連の事業の中で展開されているこれらのサービスが、識者によると「2004年から徐々に企業向けメニューの中に組み入れられてくる」という声も聞かれている。またアプリケーションサーバやデータベースを提供しているベンダも徐々に、自社製品を「EAを実現する基盤」として位置付けたマーケティング戦略を始めている。

 ただし、こうした製品やサービスを活用すればEAが実現できるわけではない。EAを推進するカギは、あくまでユーザー側にある。上記のコンサルティングサービスについても、「方針さえ決めればベンダが全部やってくれる」というものではない。ベンダがサービスするのは、あくまで「業務分析」や「議事進行」の部分。EAは「今後のIT化の方針を決め、実際にプロジェクトを動かすのはユーザー側」ということを明言するものだからだ。これまでベンダ主導で導入してきたユーザー企業にとって、EAが救いの一手となるかどうか興味深いところだ。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ