連載
» 2004年01月31日 12時00分 公開

ビジネスモデリング事始(3):ビジネスとITを全体最適に導くEA(下)

競争が激しく、再編が進む業種・業界ではすでにEAの適用プロジェクトが進められ、成果を挙げている。実例とともに、EAの運営体制のポイントについて解説しよう。

[明神知,オージス総研]

EAの適用が進む一般企業

 筆者が昨年11月に参加したアリゾナのフェニックスで開催されたEAC(Enterprise Architecture Conference)における事例発表を中心に、トレンドをまとめてみます。この会議の参加者は305人、うち3割がアーキテクトで、組織の名称から約2割にEA担当組織があるとされました。

 米国以外は日本、韓国、カナダなどの参加者が多く、ヨーロッパやオーストラリアなどからの参加もあり、国際的なユーザー中心の会議でした。参加者の企業は化学、製薬、自動車、航空機、金融、公共機関が多く、ほかには物流、半導体・コンピュータメーカー、テレコム関連からでした。

 日本では政府が中心になって推進していることもあり、官公庁の事例が多いと思われるかもしれませんが、競争が激しい製造業や、合併・統合の続く金融、製薬会社ではすでに大型のEAプロジェクトがスタートしており、情報交換をしている姿は真剣かつ具体的でした。

 EAに取り組む目的は、おおむね以下の4項目に分けられます。

  • 組織内の情報に関するガバナンス
  • IT投資の合理的で透明な根拠の獲得
  • 経営/ビジネスとITとの整合性確保
  • 変化への迅速対応と複雑性への対処


 EAに対する取り組みの範囲とレベルはさまざまで、まさに「Just enough architecture, just in time」というスローガンのとおり、ザックマン・フレームワーク(Zachman framework)に忠実に全項目にわたって取り組んでいる企業から、情報システムに関する部分に焦点を当てている企業、ビジネスプロセスを中心に行っている企業など、目的と企業レベルに応じてアーキテクチャを整備しています(ザックマン・フレームワークについては第2回参照)。

 ここでは、次の2つの事例を紹介します。1つはザックマン・フレームワークのほとんどすべてを整備している化学会社です。情報システム部門の役割としてはEAの整備と維持に専念し、開発そのものはアウトソーシングしています。もう1社は、TO-BEのアーキテクチャとしてサービス指向アーキテクチャを目指している半導体メーカーの事例です。

1. 化学会社の事例

▼EAの目的

アプリケーション/情報の統合、知識獲得、レガシー・マイグレーション、コスト削減、ビジネスの全体把握、データ共有、全社プロジェクト支援などを目的として挙げています。

 

▼取り組みの概要

3年前にはバラバラなITソリューションの導入で一貫性がなく、例えばSAPの導入でも既存のCRMシステムとの間でグローバルな顧客データの統合が不十分なため、データの不整合が生じていました。そこで情報システムと、ビジネス戦略/活動を密接に連携させるためにザックマン・フレームワーク全項目を作成し、個別案件のRFPに活用、レビューに利用しています。

 

▼効果

適用対象は、最初の1事業部門から4事業部門に広げ、以下のような成果を挙げました。

 

  1. 重複アプリケーションの削減
  2. データ標準化
  3. SAP/CRMインターフェイス開発の100時間を超える工数削減
  4. ミスとやり直しの削減
  5. ビジネスプロセスの合理化で重要な領域を認識できたこと
  6. 現状調査工数の削減可能性の確認

また「EA導入により、将来のIT投資の方向性が明確になり、ガイドラインとなったことも大きい」とのことです。

 

▼体制

CIO直下に5人程度の「EAオフィス」を設け、EAオフィスがビジネスプロセス、データ、アプリケーション/テクノロジ、組織レディネス/コンテンツマネジメントに関する統合化リーダーの役割を担いました。必要な能力は、強力なプロジェクトマネジメント力とプロセス能力です。EAチームの目標は、全体図の作成、標準/ガイドライン、ツール―プロセス―インターフェイス整備、新しいIT導入メカニズムとレガシー・マイグレーション、シックスシグマと連携した経営マネジメントの確立でした。

 

▼特徴

EAに関する開発/投資/強化の正しい決定ができる能力(EAガバナンス)を持てるように、ポリシー制定、標準EAプロセス制定、EAパフォーマンスモニタ定義、EA能力/関係力/組織内への浸透力に注力しました。



2. 半導体メーカーの事例

▼EAの目的

サービスベース・アーキテクチャ(SBA)によるアジャイル企業へと変革し、SBAによって費用削減(再利用、必然性のある開発のみ)、生産性向上、ビジネス駆動によるシステムの柔軟性向上などを目的に掲げました。

 

▼取り組みの概要

2001年1月CIOが取り組みを開始して、EA第1版は同年8月完成、現実の組織に依存しないSBA第1版は2002年1月に完成しました。EAは、全社横断のデータ保護とプライバシー、デジタル・シックスシグマ、顧客サービス・配送、サプライチェーン最適化などのプロジェクトに適用されました。

 

▼体制

CIO主導の業務、IT、戦略コンサルの混成チームがEAのコアチーム。情報システム部門はアウトソーシングによって4600人から2000人になりました。

▼効果

  • シェアードビジネス機能の理解
  • ビジネスオブジェクトの再利用促進
  • 固有の既存システムを標準ベンダ製品への移行
  • 開発期間短縮 など

▼特徴

図1にあるようにTO-BEの目標アーキテクチャとして、サービス指向アーキテクチャを目指していることが最大の特徴です。

ALT 図1 半導体メーカーの目標アーキテクチャ(SBA) * 出所:EAC Conference Proceedings

従来、個別のIT製品や情報システムは、互いのデータ関連、機能連携、情報定義といった情報に関する情報(メタ情報:情報に関する上位の抽象的な情報)の定義と管理が不十分だったために、全社に関係するプロジェクトを実施するには大きな障害となっていました。そこで全社のビジネス機能と情報を分析して、144ビジネス機能、300の主要エンティティ、26アプリケーション群と600以上のデータ交換にブレークダウンし、150の主要なビジネスシステムとデータストレージにマッピングしました。

このような体系化に基づいて、図1の上から順に業務支援の画面、ワークフロー、ワークフローで用いる再利用可能なビジネスオブジェクトと、そのビジネスオブジェクトと個別の情報システムとをEAI/EII(Enterprise Application Integration/Enterprise Information Integration)で連携してサービス指向アーキテクチャを実現しました。同社では「このようなSBAがなければ、EAはメタ情報のスパゲティになる」と忠告しています。



EAの開発・運用・体制

(1)EAの開発

 表1は、EAの開発計画例です。EAの開発においては、米国会計検査院の「EA管理成熟度フレームワーク」などを参考に、自組織の現在のEAに関するマネジメントの成熟度を診断したうえで適正な目標設定をすることが重要です。というのは、競合企業や他社事例を参考にした場合にどうしても無理な目標設定をしがちだからです。

 それから、スモールスタートでインクリメンタルな整備(運用を通して完成度を高める)を開始します。その中で、どのEAフレームワークを採用して、どのアーキテクチャモデルにフォーカスしてやるのか、EAの目的や達成イメージと評価基準を定めていきます。全社に対して「プロジェクト憲章」とでもいうような理念を明示するのもよいでしょう。完成度より、タイムリーな成果物の配布に注力して効果を早く出して継続することが重要です。

EA整備計画案作成
管理体制案策定
(既存標準とプロセスの棚卸と実行計画)
2〜3カ月後 CIO特命チーム
コンサル支援
EAプロセスに関する手続と標準の定義
ベースラインEAとターゲットEAの開発要領
EAリポジトリとしての知識ベース/ポータルの開発計画
品質保証、リスク管理、構成管理要領
システム開発およびIT調達に係る指針と利用者教育案
EA能力の評価指標の定義と評価案
ベースラインEAの作成
(一部)
2〜3カ月後 ビジネス参照モデル簡易版
業務ファンクション(UML) 業務プロセスモデル(UML)
業務を支援する情報モデルと情報の流れ
業務を支援するアプリケーションとその課題
IT資源と技術基盤
ターゲットEAの作成
(一部)
5〜6カ月後 組織の戦略上の目標
業務プロセスモデル サービスコンポーネント参照モデル
業務を支援するための情報モデル
情報を提供するアプリケーション
業務を支援する技術
IT標準 テクニカル参照モデル簡易版
セキュリティ/プライバシー保護標準
ターゲットEAへの移行計画策定
(一部)
5〜6カ月後 +コアチーム、支援チーム候補 以下を考慮してギャップ分析し移行計画を作成する
移行中の業務支援
既存の技術的な資産と契約条件
現在進行中の開発プログラム
予想されたマネジメントと組織的な変更
業務目標と業務処理の優先順位
予算の優先順位と制約条件
EA利用とフィードバック
(個別案件実施とEA整備拡充 )
半年後 EAコアチーム
プロジェクト支援チーム
情報システム化予算への反映
RFIやRFPへの活用
経営計画、経営戦略の反映
リファレンスの拡充、EA体系の拡充
表1 EA開発計画例
* 出所:オージス総研

(2)EAの運用

 EAの運用とは、EAを使って情報化資源の調達を行っていくということです。運用をしながら、一方でEAそのものを改善していくことになります。

 表2は、日本政府のEAを利用した情報システムの調達プロセスです。リファレンスとしてEAの各アーキテクチャを参照することが通常の調達と異なるところで、そのほかはITコーディネータのプロセスフローに似ています。

フェイズ アクティビティ 成果物
リファレンス 備考
戦略策定フェイズ 内外部環境分析
ミッションエリア分析
ミッション目標を実現する業務、支援能力不足確認
ミッション・ニーズ分析
確認
・SWOT分析図
・責任範囲図


・ミッション・ニーズ(短期・中期)
・ミッション・ニーズ報告


技術動向分析
コスト削減分析
戦略情報化企画
(企画・調整段階)
システム・コンセプト作成 ・システム・コンセプト
・EA−データ・アプリケーション
・設計RFP
・情報技術管理改革法
・EA−ビジネス
・EA−テクノロジ
・セキュリティ要求
・相互運用性要求
・投資分析
情報資源調達
(設計段階)
システム設計 ・開発契約書
・開発RFP
・調達戦略
・EA−テクノロジ
CMMIII
ベンダ提案
情報システム開発・テスト・導入フェイズ(開発段階) ソフトウェア開発
・製造契約書
・運用RFP
・EA−テクノロジ
運用サービス・デリバリ(運用保守段階)
・ソフトウェア運用と支援
・サポートソフト導入
表2 EA による調達プロセス例
* 出所:EA策定ガイドライン

(3)EA整備体制

 個別の情報システム開発チームに対してEAチームは全体を見る立場にあります。例えば図2のように、CIOから直接任命される形でEAを整備し、原則やガイドラインを個別案件プロジェクトに提供してRFPに反映してもらいます。その後にシステム開発企画が具体化された時点で、EAとの適合度をレビューすることになります。

ALT 図2 EAの整備・運用体制  * 出所:オージス総研

 アーキテクチャ・レビュー・ボードは、EAそのもののレビューとともに、個別案件がEAに適合しているか審査します。設計・開発部門をアウトソーシングしている場合は、このレビュー・ボードが重要になります。実際の情報システム開発で、開発技術や製品知識を体得している場合は問題ありませんが、これらを外部にアウトソーシングしている場合には外部出向や研修、あるいは特別の案件を内部制作するなど戦略的に開発技術ノウハウを残す施策がなければ、技術に対する目利き力がなくなり、管理不能に陥る恐れがあります。

EAにおけるモデリングの役割

 第2回の表1で、UMLがカバーしている範囲を黄色で示しました。これを見ると、企業全体の中で情報システムに関係の深いデータ、機能、ネットワークの部分になっています。また、OMG(Object Management Group)が推進しているMDA(Model Driven Architecture:モデル駆動開発)のCIM(Computation-Independent Model)、PIM(Platform-Independent Model)、PSM(Platform-Specific Model)は、ザックマン・フレームワークにおけるビジネスモデル、システムモデル、技術モデルに対応しています。

 OMGが、モデルからコードの自動生成を狙ってUML2.0を制定しているのも、上流から下流への連携強化が目的です。UMLはJavaやC++といった言語との連携が保証されているので、UMLと上流のビジネスモデルが連携すればメリットは大きいといえます。例えば機能の軸におけるビジネスプロセスをUMLのアクティビティ図で定義し、BPEL(Business Process Execution Language)に連携し、ワークフローを自動生成させてWebサービスを作成する製品や実例が出てきています。

 経営戦略を定めるフェイズではさまざまな問題解決の手法やツールがあり、これを限定することにはあまり意味はありません。ただし、戦略をブレークダウンして組織内部にある経営資源を割り当て、「誰が」「何を」「どのように」実施するかといった構造を定義するビジネスモデリングや、情報システムを設計するシステム・モデリングの段階ではUMLがその威力を発揮するので、EAにおいても主要な役割を担うと思われます。

自組織で開発・改善し続けるのがEAの本質

 EAは定義するのが難しい用語です。というのは、事例でも述べたように各社各様の取り組みがなされているからです。しかし、実はこの「各社各様であること」が、EAの本質なのかもしれなません。

 自社にとって理想の情報システムを作り上げるための処方せんであるEAは、ほかから与えられるものでなく、自社で開発して改善し続けるべき性格のものです。ただ16年も前に提案されたザックマン・フレームワークはEAの元祖としていまも君臨しており、EACの基調講演でも大人気であったことは驚きでした。各社各様の取り組みのベースには、やはりザックマン・フレームワークが存在しており、この中から取捨選択している組織が多いようです。筆者が6年前にドイツ製のリポジトリを販売していたころ、メタデータ・スキーマとしてザックマン・フレームワークを日本で紹介したことがありますが、隔世の感があります。次回からはEAの中核部分を担うUMLビジネスモデリングについて解説していきます。

このページのポイント

▼EAの開発にあたっては、現在のEAに関するマネジメントの成熟度を診断したうえで適正な目標設定をすること

▼最初はスモールスタートで、改善を継続しながら範囲を広げていく

▼個別の情報システム開発チームを監理する立場としてEAチームを置き、開発プロジェクト全般を通じてレビューを行う



参考文献
ITアソシエイト協議会中間報告
ITアソシエイト協議会報告〜「EA策定ガイドラインVer.1.1」
EAC Conference Proceedings November 4-6,2003

profile

明神 知(みょうじん さとる)

オージス総研 ソフトウェア工学センター所属。UMLビジネスモデリング、EA、レガシー・マイグレーションのソリューション整備や顧客支援に従事している。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ