日本版SOX法・徹底解析

日本企業の間には、まだ十分に普及していないとされるSOA（Service-Oriented Architecture：サービス指向アーキテクチャ）。だが、それをもって、SOAに対するユーザーの熱意が薄れたと断ずるのは早計である。現に、来るべき“SOA時代”を見据えて、着々と準備を進めている企業も確かに存在する。そんな企業の1社である住友信託銀行は、全社を挙げてEA（Enterprise Architecture）の構築を進めるという、“トップダウン”のアプローチでIT基盤刷新への道筋を立てるとともに、システム構築の現実的な方法論としてSOAに熱い視線を送っている。同社がSOAに期待するものとは何なのか。また、現時点で本格的な導入に踏み込めない理由はどこにあるのか──その本音を直撃した。

http://www.ciojp.com/contents/?id=00003679;t=45

CIO Magazine 編集部 ● text by CIO magazine

金融業界が待望する次世代のIT基盤

住友信託銀行の業務部副部長で、EAに基づく次世代IT基盤構想のリーダーとして活動する渡部信之氏。氏は、「金融ビジネスを取り巻く環境を見れば、近い将来、SOAのような技術を採用しなければならなくなることは明らかだ」と主張する　photo by Keiji Kaneda

　今や、「激動の」という枕詞が必ずと言っていいほど付いて回るようになった日本の金融業界。自由化の流れを受けて競争が激化しているのに加えて、昨今ではリスク・マネジメントにかかわる分野での規制強化も進んでいる。2008年4月以降の適用が予定されている金融商品取引法（通称：日本版SOX法）ももちろんその1つだが、それに先立ち、2007年1月には、金融機関の自己資本比率を規制する新BIS（国際決済銀行）規制（通称：バーゼルII）の適用もいよいよスタートした。つまり、現在の金融機関は、ビジネスを拡大するための“攻め”と、市場での信用を維持するための“守り”とを、同時に進めなければならないという難しい立場に立たされているわけである。

　むろん、こうした“変化”は、各社のIT戦略にも確実に影響を及ぼしている。M&A（企業の合併・買収）に伴う三菱東京UFJ銀行のシステム統合、民営化を目前に控えた日本郵政公社におけるシステム刷新、さらには、大規模なシステム障害により信用を大きく損なった東京証券取引所の次世代システム構築プロジェクト──こうした大規模プロジェクトの相次ぐ実施も、同業界の“激動ぶり”を端的に示す現象だと言えよう。

　だが、いかにIT化で先行してきた金融機関といえども、“変化”が起こるたびに大規模なITプロジェクトを実施していたのでは、負担が大きすぎる。そのため、業界内では、迅速に、かつ低コストで市場のニーズに対応できる新しいIT基盤を望む声が日増しに高まっている。言ってみれば、変化に柔軟に対応できることを“売り”にしているSOA（Service-Oriented Architecture）にとって、これほど格好の活躍の場はないとも言えるわけだ。

　信託業務と銀行業務の両方を展開する住友信託銀行も、まさに、そんな金融機関の1社である。同社においてIT戦略の遂行とビジネス・プロセスの管理に責任を持つ業務管理部の副部長、渡部信之氏は、これからのビジネスの動向を考えれば、近い将来、IT基盤のあり方を根底から考え直す必要があることは明らかだと力説する。

　「これからの金融市場では、新しい商品を次々に提供していかなければ顧客からそっぽを向かれてしまう。そのうえ、他社との連携や協業などをしながらビジネスを展開するケースもどんどん増えている。現在の鈍重なIT基盤のままでは、そうした時代のニーズに対応できなくなってしまうだろう。その意味で、近い将来、SOAのような技術を採用しなければならなくなることは明らかだ」（渡部氏）

　SOAに基づくシステム環境では、ソフトウェア機能を一定の粒度で独立した「サービス」として開発し、その疎結合によってアプリケーションが構成される。このため、複数の部門や企業でサービスを共用したり、一度作ったサービスを別の用途に再利用したりといったことが可能になるとされる。もちろん、業務に何らかの変化が生じれば、関係するサービスに手を加えるだけで対応させることが可能だ。

　こうしたSOAの特徴が、変化の激しい金融市場でビジネスを展開していくうえで、重要な武器になると期待されているわけである。

“広く薄い”システム環境

　渡部氏がSOAに期待をかける背景には、住友信託銀行のビジネス形態がメガ・バンクなど、他の銀行とは少々異なっているという事情がある。

　ここ数年、好業績を保っている同社だが、それを支えているのは、コンサルティングを重視したきめ細かな商品の提案活動である。そう口で言うのは簡単だが、信託と銀行の両方の事業を展開しながら、かつ個々の顧客のニーズにきめ細かくこたえていくというのは、IT戦略を遂行する立場からすれば、非常に厳しい条件である。取り扱う商品の数が膨大になるため、当然、それを支えるアプリケーション環境も間口を広くとらざるをえない。そのうえ、多くの顧客を抱えるメガ・バンクのように、1つの商品やプロセスの“厚み”で勝負するわけにはいかない。言ってみれば、システム化がきわめて困難だというのが、同社のビジネス形態の特徴なのである。

　渡部氏は、次のように説明する。

　「昨今ではお客様も投資リスクを考慮して資産を分散化させる傾向にあるため、金融機関はさまざまなサービスをワンストップで提供できる体制を築いておかなければならなくなっている。また、他社が開発した商品を店頭で販売するといったケースも増えている。当然、システムに対する改善要求のサイクルがどんどん短くなっているため、従来のようにメインフレーム一辺倒で対応することができなくなってきている」

　こうした状況に対応すべく、住友信託銀行では、コスト効率も考えて、法人向けサービス、新規で開発した個人向けサービスを提供するシステムについては、すでにほぼオープン化を完了した。だが、それによって、システム環境が細分化され、利用しているデータ資産も分散してしまうという、新たな問題が発生しているという。

EAの採用でビジネス起点のIT基盤を

SOAの導入を阻む要因の1つとして相互運用性を挙げる渡部氏は、「ベンダー各社には、まずは基本的な相互運用性を確保する努力を行ったうえで差別化を図るという姿勢を持ってもらいたい」と注文をつける　photo by Keiji Kaneda

　幅広のアプリケーション環境を迅速に、かつ低コストで整備するというのは、本来、SOAの強みとするところである。だが、問題は、そうしたSOAの利点を生かした次世代IT基盤への移行をどのような手順で実施していくかだ。SOAは、ITに従事する人にとってはよく知られたキーワードだが、そのメリットをビジネス・サイド、さらには経営者に対して理解させるとなると、そう簡単にはいかない。下手をすれば、説明が専門用語の羅列に終わってしまい、むしろ敬遠されてしまうことにもなりかねない。これは、SOAの導入を検討している多くのCIOが、おそらく最初にぶつかる壁だと言えよう。

　「残念ながら、単にIT基盤をつくり変えるということだけのために、大きな投資はできない。具体的なビジネス上のメリットを経営者や現場に対して示してみせなければならない」（渡部氏）

　そこで、渡部氏が着目したのがEA（Enterprise Architecture）であった。これは、ご承知のとおり、トップダウンの視点で経営戦略から業務計画、業務プロセス、組織体制、そしてIT環境まで包含するかたちで全社的なアーキテクチャを描き、それを共有するところからスタートするという、IT基盤刷新の“王道”とも言うべきアプローチである。

　「ビジネス・メリットにつながるようなIT基盤を構築するためには、それが現場の業務、ひいては経営の“カイゼン”に直結しなければならない。とすれば、経営トップの強いリーダーシップ、事業部門の支援が不可欠だと考えた」（渡部氏）

　この同氏の考えは認められ、2004年6月の経営会議において、EAを推進することが正式に承認された。そして、具体的なアプローチとして、各事業部門ごとに業務の改善計画を立案すると同時に、業務プロセスのモデル化を実践し、それに沿ったかたちでIT環境をつくり上げるという大まかな道筋が立てられたのである。事務局はもちろん、渡部氏が所属する業務管理部である。

　ちなみに、住友信託銀行では、このEAの概念に基づく社内アーキテクチャを「ビジネス・オリエンテッド・アーキテクチャ（BOA）」と呼んでいる。ここからも、IT基盤の構築をIT側の取り組みだけに終わらせるのではなく、ビジネス側のスタッフも参加する全社的なプロジェクトにしたいという、同社のビジョンが透けて見える。

3段階の業務プロセス・モデリング

　住友信託銀行が「BOA」を実践するに際して、カギを握る取り組みとされたのが、現場の事業部門の協力を得るかたちで進められる業務プロセスのモデリングであった。ここでつくられるプロセス・モデルが、業務の改善ポイントを探るうえでもシステム化の戦術を立てるうえでも、土台として利用されるからだ。

　同社では、EAの推進が社内に宣言されるとすぐにこの作業に取りかかり、2005年4月から本格的に運用を始めた。具体的には、レベル1～3の3段階で業務の構造を図式化し、その成果物を各事業部門と業務管理部との間で共有するという方法を採用した（右図参照）。

　ここで言う「レベル1」とは、全社のビジネスの中で、各事業部門がどのような位置づけにあるかということを大まかに示したモデルである。これは、同社のディスクロージャ資料などにも掲載されているほど一般的なものである。

　続いて、各事業部門ごとの業務プロセス項目をA3用紙1枚のサイズで俯瞰できるようにしたのものが「レベル2」である。これは、横軸にサービス、縦軸に計画、審査、営業などのアクティビティを配置したマトリクスによって構成されている。つまり、1マスが1つの業務プロセスということになる。

　この俯瞰図を「A3用紙1枚」と限定しているのにも、もちろん理由がある。渡部氏は言う。

　「各事業部門に業務プロセスをできるだけまとめてほしいという意図が込められている。あまりにも細かくプロセスを定義してしまうと、一覧性が損なわれるうえ、メンテナンスにも負担がかかる。そこで、あえて一定の枠を設けて、その範囲内でプロセスを定義してもらうことにした」

　最後の「レベル3」は、個々の業務プロセスごとに作成されるワークフロー図である。ここでは、顧客からのリクエストに対して、受付スタッフがどんな処理を行うか、そして店舗内、さらには他部門へとその処理がどのように引き継がれていくかが細かく記される。ここで定義される個々のノードが、業務の最小単位ということになる。

　このレベル3の記述には、標準として定着しているUML（Unified Modeling Language）を採用。立ち上がりの際には、ITベンダーの力も借りたが、各事業部門には業務管理／IT企画リーダーを選任し、彼らを中心に事業部門のスタッフが自らの手でアクティビティ図を作成するという体制をとっている。

相互運用性への不安

　EAの導入から2年半が経過した現在、すでに全社最適の視点に基づくシステム構築の重要性については十分に住友信託銀行社内に浸透している。懸案だった業務プロセスのモデリングも、現場の事業部門にすっかり定着した。渡部氏を中心とする業務管理部でも、一連のBOAの実践を通して、ITアーキテクチャの未来図をほぼ固めつつある。それは、店舗の受付業務やコールセンター、ATM、B2B（企業間）接続など、顧客との接点となる「チャネル層」、メッセージング連携やデータ連携、ユーザー管理などの制御系をまとめた「コントロール層」、業務を支援する「業務プロセス層」の3つのレイヤを構築し、それぞれを疎結合で連携させるという構想だ。

　以上のことを考え合わせると、同社ではSOA導入の素地がすでに十分整っているように思えるが、実はまだ、SOAに基づくシステム開発に本格的に着手するには至っていない。それは一体なぜなのだろうか。渡部氏は、「現段階でのSOAの導入には、“技術”と“文化”の両面でリスクがある」と指摘する。

　同氏が技術面での課題としてまず挙げるのは、サービスを組み合わせた場合のレスポンスである。標準的なXML形式によってデータ通信が行えるのは、確かにSOAの大きな魅力だが、同社が利用するようなトランザクション系システムでどこまでパフォーマンスが発揮されるかについてはいまだ未知数であるというのが、渡部氏の見解なのである。そしてもう1つ、同氏が懸念しているのが、ベンダー各社から提供されているSOA製品同士の相互運用性に関する問題だ。

　「例えば、あるベンダーのミドルウェア・プラットフォームを導入したとして、他社のプラットフォームとの間でサービスの互換性がどこまで保証されるのかが見えてこない。最近、部分的なSOAの適用を勧めるベンダーが増えてきたが、将来的に特定のプラットフォームに縛りつけられるのであれば、危なっかしくて導入しにくいというのが本音だ。ベンダー各社には、まずは基本的な相互運用性を確保する努力を行ったうえで、パフォーマンスの向上やアドオンによる利便性の確保といったことで差別化を図るという姿勢を持ってもらいたい」（渡部氏）

開発者とユーザーの意識を変える

　SOAの導入を阻む要因として、渡部氏がある意味で技術以上に大きいと考えているのが、開発体制、エンドユーザーの意識といった“文化”に根ざす問題だ。

　SOAを本格的に導入するとなれば、例えば、開発者には、従来とは異なるスキルが要求されることになる。

　「現在のIT市場には、個々の業務を支援するための機能を作り込むことに長けた人材はたくさんいる。だが、SOAを導入すると、UIの開発ならこの人、ロジックの設計ならこの人、というように、どうしても業務領域をまたいだ専門家が必要になる。そうした体制を整えているSI企業は決して多くない」（渡部氏）

　また、SOAの特徴の1つである疎結合は、迅速にビジネスに対応するうえでは非常に有利だが、その反面、現場の業務担当者にとっては、必ずしも“やさしい仕組み”ではない。そのトレード・オフをどのようにしてエンドユーザーに納得してもらうかも、今後の大きな課題だ。

　「疎結合は、言ってみればデータが“送りっぱなし”になるということ。つまり、細かなエラー処理は人手で補わなければならない。至れり尽くせりの従来型システムと比べれば、そのギャップはかなり大きく感じるはずだ」（渡部氏）

　同氏は、以上のような文化にまつわる障害をクリアするためにも、SOAの本格導入に際しては、経営者の理解と強いリーダーシップの有無がカギを握ることになると力説する。住友信託銀行がトップダウンによるIT基盤の刷新にこだわる理由も、まさにそこにあるのだ。

“システム貧乏”にならないために

　SOA環境の実装については慎重な立場をとっている渡部氏だが、それでも同氏は、いずれ間違いなくSOA的なアプローチが企業のシステム構築手法の標準になると予測する。SOAを巡る課題を言い募るのも、期待の大きさの裏返しであると言ってよい。

　「大規模なアプリケーション開発を行って業務効率を大きく改善するといったことが可能だった“幸せ”な時代はすでに過ぎ去った。いつまでも旧来型のシステム構築手法にこだわっていると、変更に対する要求が際限なく膨らみ、労多くして益少なしという状況に陥ることは目に見えている。かといって、リスクを考えれば、何もかもアウトソーシングしてしまうというわけにもいかない。その意味では、SOAは、ユーザーを“システム貧乏”から救ってくれるソリューションになるかもしれない」（渡部氏）

　渡部氏と同様、SOAに対して「期待」と「不安」を同時に抱く日本企業のIT責任者は少なくないだろう。また、“日本的な商習慣”とSOAとの間に一定の距離があることも確かだ。今後、SOAが日本で根を下ろすことができるかどうかは、IT市場がこうした問題に対してどのような“答え”を出すかにかかっていると言えそうだ。