◇ エンタープライズ・アーキテクチャ ◇

当論説は、日本金融通信社 発行「FIT2003年秋季号」への寄稿論文に加筆したものです。


金融業界でも、ITアーキテクチャの重要性が認識されるようになった。米国連邦政府では、およそ10年程前からEA導入のための施策を進めている。日本政府も、eガバメント推進にあたり、各公共団体のIT推進部門に対して、エンタープライズ・アーキテクチャ(EA)の推進と導入方法の研修支援を始めたところである。今年の6月には、東京三菱FGがEA導入を発表したことから、金融界でも注目されるようになってきた。

EAの位置付け

ITの世界でアーキテクチャという言葉は頻繁に使用される。「体系」「基本構造」「設計理念」「基本設計」「枠組み」などというような意味で使われるが、議論の場で明確に定義して使うことは少ない。ITの要素を抽象化・体系化した概念に止まったり、実装技術とは関係の薄い基本設計書であるため、議論のたたき台程度としての意味しかなかったとも言える。

企業レベルでIT関連アーキテクチャを考える時には、大きく4つのレイヤーで整理できる。

(図1)

基本層は、プロセサーやメモリーなどのチップ設計や、バス・アーキテクチャ、コンピュータ・アーキテクチャなどのコンポネント・レベル、モジュール・レベルの基本構造である。

第二層は、ハードウエア、ソフトウエア、ネットワークなど情報システムを構成して、密接に関連する技術同士を体系化したものである。

第三層は、最も多く使用されるシステム・アーキテクチャである。大きくビジネス・アーキテクチャとテクニカル・アーキテクチャに分けられる。ビジネス・アーキテクチャは、アプリケーション・アーキテクチャとも呼称されるが、データ、プロセス、プロセス・フローのモデルで表現される。


最上層に、EAが位置付けられるが、これは事業分野や業務を全社的に包括・体系化したものである。

基本層と第二層は、公的標準機関やITベンダーが開発・保守・製品化するので、ユーザーが直接に関与するものではないが、自社のニーズに適したアーキテクチャを実装した製品・技術をテクニカル・アーキテクチャに配置することになる。

第三層は、銀行で言えば、勘定系、本部情報系、営業情報系、証券系、国際系等々で別々にサブシステム(系システム)として体系化されることが多い。各サブシステムを個別に追加開発していくと、データやプロセスの重複や不整合、欠落が発生することが避けられない。

第四層のEAで、サブシステム間の重複・不整合・欠落を無くしながら、全体最適と柔軟性、移植性、相互運用性等の確保を追求することになる。

EAの歴史と米銀の対応

日本でアーキテクチャの必要性が認識されだしたのは、190年代後半である。筆者も20年近くに渡ってアーキテクチャの必要性を説いてきた。誰もが肯定はするが実行しない状況が今日まで続いている。

アーキテクチャは、体系化である一方、標準化という意味を持つ。標準は、時として新しい技術、技法、手法、製品の適用を阻害したり柔軟性を犠牲にすることがある。論理モデルであれば、必要とされる業務機能を定義するだけであるが、物理レベルとなると採用技術に制約がついたり、実装段階で現場レベルでの組織・手順・権限・スキルとの不具合を引き起こすことが多い。全く新規にビジネスを展開する場合は問題ないが、既存事業に適用する場合の危険性と労力を考えると、規格化に重点をおいたアーキテクチャ導入は悪い副作用を伴う場合がある。

事業分野毎にIT部門を抱える大手米銀では、コーポレート・アーキテクチャ、ITアーキテクチャと称してエンタープライズ・アーキテクチャの導入と拡充が行なわれている。その目的と対象領域を整理すると「企業全体における情報技術のブループリントであり、各種モデル、定義、使用テクノロジーを階層化して体系化している。設計者と開発者にガイダンスを与える目的であり、物理的インプレメンテーションを指図する使い方はとらない。対象領域は、アプリケーション、データ、インタフェース、ミドルウェア、開発ツール、開発手法などである。」

重視するのはデータであり、エレメントを含まない場合でも、データの配置と管理の仕組みについては対象とすることが多い。

アーキテクチャの価値と制約

アーキテクチャ化の目的・利点は、

◇経営戦略とITを連携させるプリンシプル

◇IT資源の統一管理による効率的活用

◇柔軟なアプリケーション結合・連携

◇重複不整合データ項目の除去

◇ソフトウエア資産の再利用可能性向上

◇IT要員のスキル管理効率化

◇標準製品による低コスト化、技術安定化

◇関連要員間のコミュニケーション改善

◇外部アプリケーション・ソフト導入の容易化

◇ITプロセス・資源の集中管理

などである。要するに企業レベルでのIT資源全体最適化のツールである。逆の見方をすれば、部分最適に反することになる。

制約としては、

◇余りに多種多様なサブシステムが既に稼動中であり、新たに全体アーキテクチャを定めてもそれに準じている余裕はない

◇アーキテクチャ作成作業は、業務プロセスやデータの抽象化・体系化作業であり、膨大な労力と時間を要する割には、効果の大きさや実現時期が不透明である。

◇抽象化や体系化に適した人材・技能が絶対的に不足している。

◇IT要員の評価や達成感は、ユーザー・アプリの量と見栄えで判断されることが多い。外部から見えないアーキテクチャは、評価される機会が少ない。

◇戦略的なIT活用よりも、手作業の自動化や段階的事務改善のIT化が中心であるため、トップダウン方式のEA開発の機会がない。

要するに、日本におけるIT化が部分最適の集積であったことがEA普及が進まなかった原因である。しかしながら、昨今の金融機関を取り巻く経営環境の変化は、従来の規模・範囲・速度とは全く異なるものであり、全ITのマップとも言えるEAがないため、ITが経営の阻害要因となる事例が急増している。特に、合併や事業分割、事業提携などでの問題が多発している。

トップダウン方式・ボトムアップ方式併用による論理モデル構築が重要

アーキテクチャやそれを構成するモデルを作る場合には、トップダウン方式とボトムアップ方式のアプローチ方法がある。

トップダウン方式は、企業目標や戦略から、それを構成する広義のエンティティやプロセスを特定整理し、要素分解することで、より狭義・具体的なエンティティやプロセスに展開する方法である。この利点として、戦略的・長期的な視点を含めた網羅性が確保できる。欠点は、余りに理論的作業であるため、検証性と達成感に欠けることである。

ボトムアップ方式は、現存して使用されている帳票・画面・ファイルなどからデータ項目を抽出し、事務規定集などからプロセスを抽出した上で、それらを上位概念へと抽象化していく方法である。日常的に馴染んでいる業務手順や情報を扱うので理解し易い。欠点としては、単なる現状物理の整理であるため、その必要性判断や戦略的新規要件を反映することが難しい。

一般には、双方の手法を並行して実施し、数回のインターロックを行なうことで、両手法の欠点を補完しながら、作業効率をあげることになる。

モデリングにおいても認識しておくべき手法がある。物理モデルと論理モデルである。

論理モデルは、事業活動をプロセスとエンティティ(処理対象)の上位概念から下位概念まで要素分解によって定義する。このため、環境変化があっても極めて安定した定義が可能であり、汎用性・柔軟性・網羅性に富む。しかしながら、実装時の有効性に欠ける。

物理モデルは、帳票・ファイルなど具体的メディアに展開されている物理データを対象として、具体的組織・担当者が一定のフローで、特定のツールを使って処理する関係を体系化するものである。システムに実装するための設計書として参照できるが、組織や規定、ツールが変わると都度、修正が必要となる。

モデリングを行なう場合は、現行物理を整理し、それを抽象化することで現行論理を作成する。それに、環境の将来変化や新規要件を付加して新論理モデルを作成、それを新物理モデルに展開するステップを踏むことになる。

EA開発手順として、特段定められた手法がある訳ではないが、最も多く利用されているIBMのITアーキテクチャ設計技法を参照しながら、EA設計手順の概要を紹介する。

(図2)

第一段階 ゼネラル・プリンシプル作成(IT基本戦略)

ビジネス戦略に適合したシステム基本方針を作成する。

具体的には、経営ビジョン、目標、戦略にもとづいて、管理対象ビジネス・エンティと企業コンピテンシーを抽出、優先付けする。それをITが具備すべき業務要件に展開する。次いで、システム要件とシステム機能要件に展開する。

注意すべき点として、IT企画担当者が「経営が戦略を決めてくれないと、自分達の作業が出来ない。」と考えることである。環境が激変する中では、経営の自由度が重要である。IT対応できないので、合併を中止などという本末転倒は許されない。戦略的選択肢は有限であり、可能性のある戦略的選択肢を満たすIT戦略を構築できる筈である。経営戦略の不在を、先送りの理由にすべきでない。今後、予想される戦略的選択肢の事例を別掲した。

次にこれら要件を満たすためのIT戦略を固めることになる。その際に考慮すべきは、企業体としてのコンピテンシー(現状と必要度)と情報技術の動向である。前者は簡単に調査できる手法があり、後者は専門家であれば保有している情報である。技術戦略においては、オープン化されたものやハードウエア・ネットワーク・パッケージソフトのように誰でも購入できるもの、導入すれば即座に先行者と同等レベルになるような技術では、持続的差別化にならないことを考慮すべきである。データベースのように、継続した努力の積み重ねで、時間という究極の差別化要素を活用する必要がある。

IT戦略とは、企業目標達成を支援するためのITケイパビリテイを、競合他社優位の水準に拡充維持することである。(ITケイパビリテイについては別掲)

これらの能力全てを一流レベルで維持することは容易ではない。そこで、第二段階で作成するアーキテクチャに基づいて、全体最適とサブシステム間の整合性をとりながら、優先付けを施した結果が、ゼネラル・プリンシパルということになる。アーキテクチャは階層構造であるが、その構築方法は階層間インタラクティブである。

第二段階 アーキテクチャ設計

ここでいうアーキテクチャは、第三層のシステム・アーキテクチャではなく、EAという概念的な企業モデルである。ただし、トップダウン方式による論理モデルだけのEAは、単なるスケッチで終わる危険性が高いので、下位層であるシステム・アーキテクチャからボットムアップ式による裏付けが必要である。当稿では、紙面の関係からシステム・アーキテクチャには触れないが、分析レベルや詳細技術の反映程度の違いを除けば、設計手法は基本的に同じである。

ビジネス・ラインとビジネス・エンティティの抽出

商品やサービスを横軸にとり、縦軸に管理対象項目(エンティティ)をおいた表を作り、関連するセルにチェックを入れる。できるだけチェックが集積するように各項目の配置をシミュレートする。結果として複数のグループを認識することができよう。ビジネス・サブエリアである。多くの場合は、それがサブ・システムとして定義できる。横軸を中心にグルーピングすれば、ビジネス・ライン別アプリケーション体系となり、縦軸中心とすればエンティティ別アプリケーション体系となる。(例:収益管理、CRM,チャネル等)

ビジネス・ラインとビジネス・プロセスの抽出

縦軸には業務プロセスをとる。(例:口座開設、本人確認、取引受付、精算等)グルーピングした結果、縦軸中心とすればプロセス別アプリケーション体系(口座開設、入金、本人確認、取引意思確認、コンプラチェック等)になる。

ビジネス・プロセスとビジネス・エンティティの関連分析

縦軸にプロセス、横軸にエンティティ(データ項目)をとって、関係を整理する。当該データを発生させるプロセスならC、照会するならR、更新(含む消去)ならUというように処理形態が判るようにすると便利である。やはり、関係の深いグループを抽出すると、それがサブシステムに適していることが整理できる。

プロセスは事業環境が変わると変化し易いが、データは安定性が高いので、データ中心に整理することが基本である。一般的に銀行業務に必要なデータ項目(三次レベル)は3千項目程度とされるが、大手銀行の2千を超えるシステムを分析すると3万以上になるケースが多い。それだけ、同名異義・異名同義のデータが多いことを意味しており、それがデータの整合性を崩しているばかりでなく、不必要なプログラムの作成に結びついている。

アプリケーション・アーキテクチャの設計

プロセスとエンティティ(データ項目)を定義できて、(それに判断基準としてのルールをテーブル化し、フローに展開すれば業務設計となる。)それらをサブ・エリアとしてグルーピングして関連性を整理すれば、アプリケーション体系となる。サブ・エリア(サブ・アプリケーション)の機能特性(取引件数、応答時間、処理形態、使用場所、時間帯、メディア、セキュリティ等)と処理特性(バッチ、登録、更新、検索、ディレード等)を整理した上で、再度、体系を見直せば、より実装し易い体系として設計できる。

テクニカル・アーキテクチャの設計

サブ・アプリケーションの機能特性と処理特性を参照しながら、適合するシステム・インフラ・パターンを選定する。パターンには、集中、分散という大区分があるが、プロセスとデータそれぞれの適合性を配慮する。従来は、プロセスは分散、データは集中が基本であったが、最近では、逆の組合せの方が、低コストで開発・保守が容易になる技術も出てきている。

パターンにはWeb使用の有無と単層(集中)、2層、3層とで六つのパターンが考えられる。各層にプロセスとデータをどのように配置するかが、開発・管理・保守運用の効率を左右することになる。

インフラ・パターンと並んで重要なのが、ソフトウェアをどのように分割・連携させるかの構造化である。オープン系を想定した代表的体系を例示する。

(図3)

近年、システム連携技術が高度化、普及しつつあり、従来よりも分散が容易になってきている。加えてわが国ITベンチャーが、数種類のPCベース高速処理技術を開発している。これらは、S/360アーキテクチャとは異なるが、単純業務の場合の処理性能比が汎用機の1000倍となる例もある。アーキテクチャが確立していれば、全体のバランスを崩さずに有効活用が可能となる。これも、アーキテクチャのメリットであろう。

第三段階 ITプロセス管理の仕組みにEAをロックインする

 これまで、部分的ながらアーキテクチャやモデリングを実施した金融機関は数多い。残念ながら、設計は行なったものの、その維持・拡充の努力が不足して、2、3年で使われなくなることが多い。特に、開発したグループが大幅な組織変更に巻き込まれると、その存在すらも忘れられてしまう。このことは大手米銀でも同様である。

その原因としては、アーキテクチャの重要性を理解するCIOやCEOが少ないこともあるが、根本は、標準規格であるアーキテクチャをIT全体の運営管理プロセスに組み込んでないことにある。

ITプロセス管理の手法として、1984年にIBMが主要先進国の主要ユーザーと共同開発し、米国で普及しているITPMの概略を紹介する。

IT管理プロセスを定義すると一次レベルx8,二次レベルx41、三次レベルx172に分解できる。一次レベルは、以下のプロセスから構成される。

1.ユーザーとの関係管理(ニーズ把握、支援サービス、CS管理等)

2.IT管理システムの設計、導入、評価

3.ITのビジネス価値管理(IT戦略、アーキテクチャ、システム化計画等)

4.ソリューションの開発

5.ソリューションの導入、変更管理

6.運用サービスの提供

7.保守管理(含む障害対策、パフオーマンス管理)

8.IT資産管理(資金、人材、施設、セキュリテイ、調達等)

EAは、3.のITビジネス価値管理と密接な関係にあるが、全てのプロセスの企画、運用、評価の基準と位置付けられるものである。IT全体の組織文化であり、地図であり、判断基準である。


― まとめ ―

EAを設計すること自体は難しくない。また、その必要性や重要性は増す一方である。その効果を享受するためには、EAの目的と範囲を正しく定義し、CIO(場合によってはCEO)による強力なガバナンスの下で、適切に運用管理することが必要である。経営環境も技術環境も急速に変化している。共同化やアウトソーシンなどのITガバナンスも変化している。IT投資効果や開発効率向上のためには、パッケージ利用やオフショア開発も推進する必要がある。EAは、これらの課題を解決する有力な手段の一つとなりうる。単独で設計することもあろうが、業界や友好グループで設計する考えもあろう。



<資料1

経営戦略選択肢と要件定義例

リレーションシップ・バンキング戦略を想定して考えてみる。アクション・プログラムでは、中小企業金融再生と健全性・収益性の二大目標が要求されている。それを具体的施策に展開するとすれば、

    創業・新事業支援機能強化のために、銀行外部の専門家や関連情報を銀行がアレンジして、経営相談を行なうことになる。ネットワークを介した、ナレッジマネジメントと市場調査、ネット会議などのシステム機能が有効である。ネットワーク上で連携されるノード、コンテンツ、プロセスを整理して要件定義する。Webテクノロジーを自社ITに組み込む必要がある。

    事業再生支援のためには、コア事業を活性化させるための新規施策やアライアンス戦略展開が必要であるが、一方で、不良資産のオフバランス化が必要となる。SPCやサービサー、証券化アレンジャーなどとの間で、資産の時価評価やリスク評価が必要である。

デューデリ用データ分析や統計解析、収益シミュレーションの機能はPCで十分であるが、基幹系からデータを抽出しダウンロードする機能が必要となる。

    中小企業金融への新しい取り組みは、市場型間接金融が増えるだろう。銀行としては、シンジケート・ローンやコミットメントライン融資に加えて、債権流動化を駆使した資金供給などの手数料ビジネスのウェイトが高まることになる。取扱い件数が少なければ、対面やPCレベルでの対応で充分であるが、土日夜間サービスなどを提供するなら、ネットワーク化が前提となる。データ交換用にXMLやBXML,場合によってはWebサービス機能がフロントに必要となる。一方でバックの融資・証券系システムとミドルの収益・リスク管理システムとのデータ連携も不可欠となる。

    顧客関係管理としてCRMが必要となる。現在の顧客情報管理や販売目標管理だけでは不十分である。顧客のニーズは日々変化するからである。過去データの分析により変化の契機(MOT:モーメント・オブ・トゥルース)を抽出して、顧客の取引と折衝履歴を保存・解析する必要がある。この結果は、顧客の格付けにも利用できる。

    資産査定、信用リスク管理は、時価評価が前提であり、法人保有の固定資産に関しては減損会計への対応も必要である。早晩、オペレーショナル・リスクにも対応せざるをえなくなる。個別資産の時価評価、個別作業のコスト・収益管理などが、勘定処理に付随して必要となる。既存の財務会計・管理会計に加えて、ABCなどの戦略会計が必要になる。その場合に日計表に組み込むのか、毎日の取引ログ集計に機能付加するのかが課題となる。

    収益力強化において、価格戦略が必須となる。また、市場性商品の場合は在庫管理も不可欠である。顧客、場所、時間帯によって価格を変え、販売数量を制御することになろう。流通業的システム機能が必要である。また、従来は優良中小企業と一般個人を意識した業務要件であるが、収益性を求めるのであれば、業績不振企業や低所得層個人とのビジネスも魅力的である。こうした顧客層を管理する情報や仕組みをシステム機能として包含する銀行も出現するであろう。

    法令等順守を強化する為には、各作業段階でコンプラ・チェック機能を付加する必要がある。マネロン対策に関連して、顧客から受け取る書面をイメージ管理する必要がある。更に、eジャパン計画が推進されるに伴い、法的帳票も電子化が進む。ワークフロー管理やイメージ処理など未成熟な技術をいかに適切に利用するか。

以上あげた新規ビジネス要件はあくまで一部事例であるが、経営戦略としてどのような顧客層、商品、チャネル、サービス、価格、ブランドを選択しようが考慮すべき事項である。


<資料

ITケイパビリテイの要素

ITケイパビリテイは主として、以下の能力から構成される。

◇ビジネス・ニーズ収集・理解力

◇ITガバナンス実効性

◇ITプロセス管理能力

◇アーキテクチャ有効性

◇アプリケーション設計能力(特にBPR推進力)

◇先進技術活用能力

◇プロジェクト管理能力

◇システム運用能力

◇ユーザー支援能力

◇IT要員のスキル、質、量

◇ITアライアンスのカバレッジと機動性

◇投資能力


→ 調査レポート Backnumber