行政機関におけるエンタープライズ・アーキテクチャ形成について

平成 15 年 1 月 27 日
行政機関におけるエンタープライズ・アーキテクチャ形成について
１．検討の背景
大阪市が 1960 年に大型コンピュータを導入して依頼、行政機関における情報化への取り
組みが開始されたが、その後、情報化が急激に進んだわけではなく、予算の制約や技術的
な実現性を踏まえて徐々に進められてきた。そのため、情報システムは整備された年代毎
に使われている技術が異なっており、従来のように個別に稼動する分には問題なかったが、
情報化の進展が進み、各情報システムの連携が行われるようになってきた頃から問題が顕
在化してきた。すなわち、情報システムの相互接続性（インターオペラビリティ）に関す
る問題である。電子政府／電子自治体を実現するためには、インターネットで手続を受け
取るフロントオフィス系の情報システムと内部のバックオフィス系情報システムを連携す
ることは不可避であり、また、行政改革の視点からは、 BPR （ Business Process
Reengineering）を進めていく上で情報システムの連携が必要である。後者に関して、分か
り易い事例を挙げると、以下のような事例がある。ある自治体では、汎用機で稼動してい
る福祉情報システムを持っているが、実際に職員は情報を柔軟に加工できる Excel で作業
するため、汎用機の福祉情報システムと Excel、双方に二重入力している。このような無駄
な労力の排除は BPR を推進する上での基本であり、そのためにもデータを一元化するよう
な包括的な情報システムの形成が望まれる。
２．エンタープライズ・アーキテクチャとは
ANSI/IEEE 規格 1471-2000 によると、アーキテクチャは「システムのコンポーネント、
コンポーネント同士と環境との間の関係、およびその設計と進化を支配する原理に体現さ
れたシステムの基本的な構造」と定義される。
つまり、エンタープライズ・アーキテクチャとは、システムの重複やシステム連携にお
けるトラブルの回避、ニーズに対する柔軟なシステム開発等を実現することを目的として、
組織全体関わるアーキテクチャを事前に設計する考え方と言える。
民間企業では情報化の進展によって、フロントオフィス系システムとバックオフィス系
システムの連携が不可欠になるとともに、KM （Knowledge Management）や ERP（Enterprise
Resource Planning）
のような組織全体的アプリケーションや SCM
（Supply Chain Management）
のような組織間で機能する情報システムが増加した。そのため、組織全体、もしく関連組
織も踏まえたアーキテクチャの重要性が高まり、このようなエンタープライズ・アーキテ
クチャ（以下、必要に応じて EA と表記）の考え方が出てきたのである。
３．米国における取り組み
米国では、情報システムの投資対効果を高めるという目的から、CIO カウンシルが 1998
年 4 月から連邦政府 EA の検討を開始しており、1999 年 9 月に『連邦政府エンタープライズ・
-1-
アーキテクチャ・フレームワーク（Federal Enterprise Architecture Framework）』を作
成した。その後、2001 年に電子政府タスクフォースにおいて、EA の欠如が電子政府構築の
主たる課題として認識され、2002 年２月には連邦政府における EA 推進を担う専門組織とし
てエンタープライズ・アーキテクチャ・プログラム管理局（FEAPMO ：The Federal Enterprise
Architecture Program Management Office）が設立された。
FEAPMO では、EA に関連した様々な文書を作成、公開している。2002 年 7 月には、CIO カ
ウンシルと行政予算管理局（OMB）が共同で作成した『電子政府エンタープライズ・アーキ
テクチャ・ガイダンス（E-Gov Enterprise Architecture Guidance (Common Reference
Model)）
』を公開している他、EA 形成に必要な参照モデル（reference model）を作成し、
公開している。
電子政府推進組織の幹事であり、FEAMPO の立ち上げにも関与している OMB は既にエンタ
ープライズ・アーキテクチャの実践に取り組んでおり、OMB 以外にも内国歳入庁（IRS）や
農務省（USDR）等も導入を進めている。
このような米国政府における EA への取り組み強化は、図１に示す調査結果からもうかが
える。米国の政府情報資源マネジメント協会（AFFIRM：The Association for Federal
Information Resources Management ）が行った米国 CIO 調査によると CIO が情報化におけ
る課題と捉えているトップ１０は表１のようになっており、
「エンタープライズ・アーキテ
クチャの形成」が最も多く挙げられている。
44
エンタープライズ・アーキテクチャの形成
34
電子政府に適合した組織文化形成
スキルを有する専門家の雇用・
保持
33
ITと組織目標の連携
33
IT事業への適切な資金確保
32
組織横断的なIT資本計画、投資マ
ネジメントの導入
32
30
業務におけるデータ統合
技術の効果を最大かするためのビジ
ネスプロセスの簡素化
29
顧客サービス向上へのIT活用
24
組織の経営陣との良好な関係形成
23
0
10
20
30
40
50
政府情報資源マネジメント協会“The Federal Chief Information Officer Seventh
Annual Top Ten Challenges Survey”
図１
米国政府 CIO の関心事
４．エンタープライズ・アーキテクチャの考え方
米国連邦政府では EA を図２に示すように４つのアーキテクチャから構成する形で捉えて
-2-
いる。最も上位に来るのは、組織のミッションを達成するための機能、プロセス、組織、
情報のフロー等を定義するビジネス・アーキテクチャであり、情報システムだけでなくシ
ステムの前提となる業務を含む形でアーキテクチャ捉えていることが大きな特徴と言える。
次に来るのが、ビジネス（業務）を支援するための主なデータのタイプ、およびその意味
やフォームを定義するデータ・アーキテクチャであり、基本的には XML の活用を前提とし
ているようである。３番目に来るのが、ビジネス（業務）や成果目標のために必要なデー
タや情報を効率的に管理するためのアプリケーションや支援機能等を定義するアプリケー
ション・アーキテクチャであり、アプリケーション間の相互接続性やシステムから利用者
までのプロセス等が主な関心事となる。最下層に位置するのはビジネス（業務）アプリケ
ーション／データ、および機能への支援を可能にするハードウェア、ソフトウェア、およ
びその物理的な配置を定義するテクノロジー・アーキテクチャであり、技術の標準化等を
踏まえることが重要になる。
組織のミッションを達成するための機
能、プロセス、組織、情報のフローを
定義
ビジネス・アーキテクチャ
データ・アーキテクチャ
ビジネス（業務）を支援するための主
なデータのタイプ、およびその意味や
フォームを定義
アプリケーション・アー
キテクチャ
ビジネス（業務）や成果目標のために
必要なデータや情報を効率的に管理す
るためのアプリケーションや支援機能
を定義
テクノロジー・アーキテクチャ
ビジネス（業務）アプリケーション／
データ、および機能への支援を可能に
するハードウェア、ソフトウェア、お
よびその物理的な配置を定義
出典：CIOカウンシル“E-GOV Enterprise Architecture Guidance”
図２
米国連邦政府エンタープライズ・アーキテクチャ
また、FEAMPO では、EA を形成するための図３に示す５つの参照モデルを提供することを
予定しており、現在、最上位のビジネス参照モデルが公開されている。ビジネス参照モデ
ルは主にビジネス・アーキテクチャ形成に際して参照するものであり、日々の業務を住民
向けサービス、支援サービス、内部業務の３つに分解して構造的に捉えることになる。パ
フォーマンス参照モデルは、共通アプリケーションの効果の測定を可能にする業績評価の
フレームワークであり、内部業務と顧客志向アウトカムのリンケージを提供するものであ
る。データ参照モデルは、全体レベルで業務を支援するデータや情報を定義するもので、
政府と外部組織との情報交換のタイプを規定すること等に役立つ。アプリケーション能力
-3-
参照モデルは、業務遂行や経営目標達成に必要なアプリケーションの機能を特定するフレ
ームワークである。技術参照モデルは、アプリケーションの機能等をどのように技術が支
援できるか、技術要素の輪郭を描くものである。
なお、各参照モデルに関して、詳しい解説は避けるが、FEAMPO では、残りの４つの参照
モデルも作成、公開することにより、先行的に取り組んでいる省庁以外の政府組織でも EA
形成に取り組むことを支援することを想定しているようだ。
出典：エンタープライズ・アーキテクチャ・プログラム管理局“THE BUSINESS REFERENCE MODEL
VERSION 1.O”
図３
EA 形成を支援する参照モデル
５．我が国の取り組み状況と今後の課題
最初に触れたが、我が国の行政機関では、これまで継ぎ接ぎ的に情報システムを増強し
てきたので、EA のような概念はほとんど形成されてこなかった。また、毎年度、総務省か
ら出されている『行政情報化基本調査結果報告書』からも新旧の情報システムが混在して
いることは明らかである。ただし、アーキテクチャの重要性が認識されていないかと言う
と、そうでもなく、ITS や CALS/EC のような特定の分野やアプリケーションに関してはアー
キテクチャの検討が行われている。今後、このようなアーキテクチャ検討の取り組みを組
織全体の情報化を対象にした EA まで発展させることが期待される。
EA に関する取り組みは、我が国でもようやく出てきており、経済産業省が 2003（平成 15）
年度予算で要求している「情報技術・市場評価基盤等構築事業」の中において、CIO をサポ
ートする IT アソシエイツ育成のために作成するものとして、
「エンタープライズ・アーキ
テクチャの作成ガイドライン」が明記されている。
この経済産業省のガイドライン作成を待っても良いが、電子政府／電子自治体への取り
組みが継続的に進んでいることを考慮すると、待つことが良い結果を生むかどうかは疑問
-4-
である。各行政機関は自らの情報化の取り組み状況を考慮し、システムやデータ連携の問
題が顕在化していたり、総合的なシステム開発が予定されていたりする場合は、必要に応
じて独自に EA の検討を進めることが望ましいと考える。
EA 自体はまだまだ新しい概念であり、その形成には難しい部分も多々あるが、内部にお
ける情報システムがある程度整った現状において、システムの効果的な更新や、既存の IT
関連資産の整理、BPR 推進等の観点からも今後、EA 形成が求められる。
現在、いくつかのベンダーからエンタープライズ・アーキテクチャに関するソリューシ
ョンが提示されているようだが、その広告を見る限り、従来のアーキテクチャの概念を脱
しておらず、米国連邦政府のように業務まで含んでいないように見受けられる。米国の EA
の概念からも明らかなように最上位に位置するのは業務であり、そこからアーキテクチャ
を検討しないと、技術中心のアプローチ（ピラミッドの下からのボトムアップ）では EA も
名ばかりのものになる可能性がある。確かに、情報システムの相互接続性ニーズに対応し
て、Message Broker、CORBA、J2EE、XML のようなデータ共有技術をはじめ、SOAP、UDDI、
WSDL に代表される Web サービス関連技術が開発されてきたのは事実ではあり、技術的な課
題をクリアすることは重要である。しかし、行政サービスの向上、業務の効率化等の本来
の目標と EA のリンケージを考慮すると、図２のピラミッドにおいてトップダウン的なアプ
ローチで推進することが妥当であろう。
-5-

Download Report