エンタプライズ・アーキテクチャ（ＥＡ）について

T-Epoch Consulting

　　エンタープライズ・アーキテクチャ（Enterprise Architecture：ＥＡ）は、一昨年くらいから頻繁
に取り上げられるようになっていますので、既にその内容をご存知の方も多いかと思います。
　　ここでは、ＥＡを先進的に推進しているアメリカでの考え方について少し整理してみたいと思
います。

　　アメリカにおいては、Clinger-Cohen法やその他複数の大統領令などによって、政府組織
（各省庁）のＥＡ構築が義務付けられています。
　　なぜ、ＥＡを義務付けたのでしょうか。
　　2001年8月の「大統領マネジメント･アジェンダ」では以下のようなＩＴ投資にに関する問題点
が指摘されています。
　　　●ITシステムを、国民のニーズではなく自らのニーズに役立つかどうかで評価している。
　　　●ITを新しく効率的なソリューションの創出のためではなく、既存のプロセスの自動化の
　　　　た
めに使用している。
　　　●縦割り組織を壊すためにITを利用せず、既存の指揮系統を維持するために無駄で重
　　　　複した投資を行っている。
　　　●多くの政府機関はITシステムの相互運用性の確保に配慮していない。
　　これらの問題を解決するために、「電子政府」が推進されることになり、そのインフラとして
ＥＡを構築するということが方向付けられたのでした。
　　また、米国では内部統制の重要性が注目され、SOX法（企業改革法）が策定されました。
内部統制の整備はＥＡと表裏一体であると考えられ、今後さらにＥＡが重要視されることにな
ると思われます。
　　ＥＡは外部環境に対応するための基盤となるだけでなく、内部環境を改善する効果もあり
ますが、そういう意味では内部統制の整備と共通するところがあると言うことです。

　　さて、ＥＡについてお話する前に、まず“Enterprise”とは何かを確認しましょう。
　　米国政府では、Enterprise という言葉を以下のように認識し、ＥＡ構築を行うことを考えて
います。
　　　●“Enterprise”は、定められたビジネス・スコープおよびミッションを有する組織。
　　　●“Enterprise”は、人・体制および技術のような互いに依存したリソースで構成される。
　　　●これらリソースは、お互いの機能を調整し、共通ミッションあるいは関連するミッション
　　　　をサポートする情報を共有している。
　　“Enterprise Architecture” における “Enterprise” とは、単純に「企業全体」を意味す
　るものではないということです。

　　では、米国政府が考えるＥＡとはどのようなものでしょうか。
　　“Federal Enterprise Architecture Framework(v1.1)”によると次のように定義されていま
す。
　　　●ＥＡは、組織の目標とミッション、ビジネス、それを支える情報、ビジネスアプリケーショ
　　　　ンシステムとテクノロジを定義する戦略的知識資産ベースである。
　　　●ＥＡは、府省の事業目的、その事業目的を果たすために必要な業務プロセスとそれを
　　　　支える情報および技術、業務プロセスと情報などの各要素間の相互関係を示すもので
　　　　ある。
　　　●ＥＡは、現在のアーキテクチャ、目標となるアーキテクチャおよび目標へと展開するた
　　　　めの移行プロセスを包含するものであり、情報システムの設計、管理、運用するため
　　　　の基本体系として使用される。
　　少し簡単に言えば、ＥＡとは、ビジネス・ライン、情報、人、組織、ITシステムなど企業を構成
する全ての構成要素にわたって、それぞれの構造（Architecture）とお互いの関連を明確にす
るものであり、組織のミッション、目標、ビジネスを遂行する上でのナレッジ・ベースのインフラ
であり、さらには、変革の基盤として用いられる体系である、ということになると思います。
　　言葉で示すのは容易ですが、実際に上記のような体系をモデル化することは非常に難しい
と言えます。
　　実際に様々なフレームワークが検討され、使用されてきました。以下にアメリカにおけるフ
レームワークの変遷を示します。

　

　　日本でも一番ポピュラーなフレームワークはＦＥＡＦ（“Federal Enterprise Architecture
Framework”でしょう。そのイメージ図を以下に示します。

　

　　さて、ＥＡをどのように構築・利用していくか、そのステップはどのように考えられているので
しょうか。“A Practical Guide to Federal Enterprise Architecture Version 1.0”によると以下の
ようなプロセスを示しています。
　（１）エグゼクティブの賛同と支援を取り付ける。
　（２）マネジメント構造およびコントロールを確立する。
　（３）アーキテクチャ構築のプロセスとアプローチを定義する。
　（４）エンタープライズ・アーキテクチャを開発する。
　（５）展開計画を策定する。
　（６）エンタープライズ・アーキテクチャを使用する。
　（７）エンタープライズ・アーキテクチャを維持する。

　　ＥＡ構築と言うと、いきなり全組織的に構築しなければならないとお考えの方が多いのでは
ないでしょうか。確かに最終的には全組織が一つのＥＡで示されることが望ましいですが、実は
組織が持つ情報量は膨大です。一度に組織全部の情報を洗い出してＥＡを構築しようとすると
かなりの労力と時間がかかります。
　　従って、ある“組織”において、あるいはある戦略テーマに関連する組織間を統合する形で、
その構成要素の構造（Architecture）を明確にすることから始めることが現実的でしょう。
　　よく言われる言葉ですが「小さく作って、大きく育てる」、これが将来全組織に広げることを考
えると重要なアプローチになると思います。

　

◆この件に関するご意見・ご感想・お問合せはこちらまで◆
　　どのような些細な事でも結構です。また、ご相談にもお乗りします。