ビジネスとITを全体最適に導くEA（上）：ビジネスモデリング事始（2）

　従って、ビジネスモデルや（情報）システムモデルは、このEAの構成要素といえます。ある組織が経営戦略を実施するために、経営資源を使って「誰が（経営資源）」「何を（機能）」「どのように（プロセス）」実施するのかを定義しているのがビジネスモデルであり、情報システムに関してこれらを規定しているのが（情報）システムモデルです。

　もう少し分かりやすくいうと、EAは企業が新サービス／製品を提供するまでの構想や機能・構造・実装について、多様な分野／レベルの専門家が表現した設計図のことで、例えば工業製品の製造においては普通に作成されています。図面を作るに当たっては、ユーザー企業のニーズを収集・整理し、合意してから機能設計を行います。そして必要な部品に展開し、調達・製造・組み立てといった製造の各工程にかかわる担当者間の合意形成と、作業の指示書となります。

　家を建築する場合にたとえてみましょう。ビジネス・アーキテクチャは、設計者と発注者（顧客）との間で合意すべき“間取り図”に相当します。データ・アーキテクチャは設計者と材料、部品購買担当者が合意する“材料・部品展開表”であり、アプリケーション・アーキテクチャは設計者と施工者とが合意する“施工図面・手順書”です。そしてテクノロジ・アーキテクチャは施工にあたり電気、ガス、水道、基礎工事といった配線や基礎的なインフラまわりの“工事図面”になります（図1）。

図1　EAと建築の対比 　* 出所：オージス総研

　IT業界では新しい用語が出るたびに、「これは過去のものと同じですでにやっていることだ」「理想論であって現場でやれるはずがない」などといった否定的な感想が述べられます。本当に新しいものもあれば、本質的な思想は昔からあるけれど、技術や環境が変わったため装いも新たに再登場したものもあります。EAは後者でしょう。

　筆者は大学でソフトウェア工学の講義を担当していますが、EAはソフトウェア工学の本質の部分を対象としていることが分かります。ソフトウェア工学は現実の世界からコンピュータの実行可能コードへの「マッピング過程」を対象とする工学であり、そこにかかわる多数の専門家同士のコミュニケーションが重要な鍵になっています。そしてソフトウェア工学におけるコミュニケーションでは、共通表現による「可視化」、変化と複雑性に共通部品化で対応する「標準化」、そして常に改善し続けるという「継続」が埋め込まれていることが重要なのです。

なぜEAが注目されているのか？

　情報システムの開発に当たり、設計図に相当するものは昔から作成されてきました。エンドユーザーの情報化ニーズを定める「要件定義段階」では、情報システム概念図や業務フロー図が使われてきましたし、「情報システムの分析・設計段階」ではデータ中心アプローチ（DOA）や構造化技法の中心的な技法である「ERD」や「DFD」、オブジェクト指向開発であれば「UML」などが使われてきました。これらを情報システムの開発案件ごとに定義、検討してシステムの構築がなされてきたわけですが、なぜこれではいけないのでしょうか？ ここには3つの背景と3つの問題点があります。背景としては、

1. ビジネス変化のスピードアップ
2. ビジネスと情報システムの複雑度の増加
3. 情報システムとビジネスの密接な関係

という変化があり、それに対して次のような問題がクローズアップしてきたのです。

（1）「スピードの問題」

　現在の情報システムは複雑化・分散化され、誰も全体像が分かりません。その結果、組織変更や新ビジネスに対して柔軟かつ迅速な対応ができないのです。さらにいえば、外部環境の変化に対応すべく打ち出した経営戦略について、情報システムそのものがボトルネックとなって実行を妨げています。

　これは大規模かつ複雑な情報システムでは関与する利害関係者が多く、それぞれの立場と専門によって理解と合意のドキュメントやコミュニケーション法が異なるため、全体の合意形成に多くの時間が必要になっているからです。合併や組織統合に伴う情報システム変更が迅速に行えず、多くのプロジェクトで綱渡りのような開発が行われている現状が問題の深刻さを表しています。

（2）「部分最適の問題」

　単年度で現場の事業ニーズに合わせたボトムアップ型の情報化投資は重複投資を生みやすく、利用される技術もバラバラです。すなわち必要となるスキルやノウハウが多くなるため、それぞれの専門家を確保する必要性が生じてきます。

　部門ごとに割り振られた予算には限りがあり、ギリギリの生産性を追求していくと、未決定の業務ニーズを切り落とし、パフォーマンス優先になりがちです。当然、将来予想される変更に強い部品化やモジュール化などは二の次となり、大きな単位ですべての機能を一体化したプログラムを作ってしまいがちです。このように特定のビジネスや業務に特化した“部分最適”の情報システムは、ビジネスの変更や情報技術の変化を直接受けてしまい、開発直後から不良資産化への道を急速にたどることになり、陳腐化しやすいのです。

（3）「知識偏在の問題」

　システム開発においては、経営戦略、業務知識、情報システム開発技術、品質管理、ネットワーク、セキュリティなど関連要素が多く、その知識は個別の専門家に偏在しています。これらをまとめ上げた結果として情報システムが実現されますが、何がどのように関係して情報システムとして形成されているのか、全体を通して理解できる人や成果物もありません。そのため、せっかく多くの専門家の知識を結集しても、次の案件ではまたゼロから積み上げていく必要があります。

　実は、昨今のEAブームの前に類似の概念がありました。情報資源管理（IRM：Information Resources Management）です。IRMは、どちらかというとDOAや構造化技法におけるデータ・アーキテクチャや、データ項目辞書を使った用語の統制など、企業や組織におけるデータ管理に焦点が当たっていました。それがメインフレームにおける情報の一元管理からダウンサイジングによって一気に分散化し、インターネットが出てきてさらに個人レベルまで情報の偏在化が起こりました。そして現代はセキュリティの問題とも絡んで、従来以上に企業における情報資源管理のニーズは高まってきています。

EAを構成するもの

　EAの概念と背景はご理解いただけたものとして、では具体的に何をすればよいのでしょうか？ ここではEAの具体的な構成内容を紹介しましょう。

　EA=プロセス＋プロダクト（成果物）＋ツールという定義もありますが、個別のシステムではなく、企業や組織全体の構造の開発方法論といえます。本質的要素ともいえる狭義のEAでは、ミッションとビジョン、戦略立案、原則と標準、EAプロセス管理といった「プロセス」面と、EAフレームワーク、アーキテクチャモデル、参照モデルといった「成果物」を指します。広義のEAではこれらに加えて、プログラム管理やプロジェクト管理、IT投資管理、教育プログラムといった「プロセス」や知識ベース／ポータル、EA作成ツールなどの「ツール」を含めるものをいいます。

　ここで最も重要なのは、どのようなアーキテクチャモデルで、現行モデル（AS-IS）から目標モデル（TO-BE）に至る移行プロセスを考えるかです。これがすなわち、EAを考える枠組み（EAフレームワーク）です。

　日本政府が採用したのは、代表的なEAフレームワークである「ザックマン・フレームワーク」（Zachman framework）です。ザックマン・フレームワークは横軸の視点（誰が見るのか）と縦軸の焦点（何を見るのか）から成るマトリックスで構成されています。

　表1にあるように横軸の視点としては、プランナ、オーナ、デザイナ、ビルダ、サブコントラクタといった視点が挙げられています。上流ほど都市計画者のように、方針や目的、要求、指標といった全体的な事項が検討の対象となっているのに対し、下流は具体的・物理的な決定、選択、取捨、組み合わせといった上流に対して制約条件の課せられた詳細事項になっています。縦軸の焦点としては、5W1Hの特定内容が挙げられています。左から順に、データ（材料：名詞）、機能（働き：動詞）、ネットワーク（場所、配置）、人（組織）、タイミング（時間）、戦略（動機）といったように、専門的に検討しなければならないフォーカスを与えています。

　ザックマン・フレームワークは1987年に提唱された当初、左3列の情報システム中心でしたが、後に会社全体を対象とするように拡張されました。個々のマス目の中に記入されているのは、指定された視点と焦点に該当する検討結果をまとめた成果物としての設計図です。企業各層・各専門家のノウハウやナレッジを形式知にしたものともいえます。

　一般的には、いくつかの焦点について並行的に上流から下流へ設計を進めることになります。日本政府が採用した4つのアーキテクチャモデルは、上2行を合わせたビジネス・アーキテクチャと左3列のデータ・アーキテクチャ、アプリケーション・アーキテクチャ、テクノロジ・アーキテクチャです。なお、表1で黄色で示した部分は、一般的にUMLがカバーしている範囲となります。

　表2は、経済産業省EAパイロットプロジェクトのガイドラインを参考にして書いた4つのアーキテクチャごとの成果物例です。この中には特別な成果物はなく、ITコーディネータのプロセスで作成するものが網羅されています。「DMM」とはDiamond Mandara Matrixのことで、機能一覧を3×3のマトリクスにトップダウンで抽出・整理していくものです。

　また、成果物として重要なのが「参照モデル」です。参照モデルは、EA策定の効率化のためのひな型や標準というべきもので、米国の連邦EAプログラム管理オフィスでは次の5つの参照モデルを整備しています。

　特に「ビジネス参照モデル」と「技術参照モデル」については、日本政府でも第1ステップで整備すべきとしています。

　EAの概要について、ご理解いただけたでしょうか。次回は、昨年11月に開催された「EAC（Enterprise Architecture Conference）」における各国企業のEAへの取り組み事例と、実際の運用体制のポイントについて解説します。