CONTROL2006で実証
SOAを活用した内部統制への対応

文●編集部

2006年11月30日

BPEL Process Managerでさまざまなアプリケーションを接続

　CONTROL2006は、東洋ビジネスエンジニアリングや日本オラクルなどITベンダー11社が、それぞれのパッケージをSOAの枠組みで連携させて内部統制を実現するソリューションを提示するプロジェクトである。昨年10月にプロジェクトの発足が発表され、11月9日に開催された「MCFrame Forum2006」で初披露された。

　現状多くの企業では、さまざまなアプリケーションを連携させることによって基幹システムを構築している。CONTROL2006では、こうした現状に即したソリューションを実現するために、複数のベンダーのアプリケーションを日本オラクルの「BPEL Process Manager」を使って実際にSOAによって連携させ、さらに内部統制への対応を果たした。事実、これらのアプリケーションには、データベースとしてマイクロソフトのSQL ServerやIBMのDB2、オープンソースのPostgreSQLを利用するものもあり、データベースをなかなか統一できないユーザー企業の実情が反映されている。

　実際に利用されたのは東洋ビジネスエンジニアリングのERP（生産・販売）である「MCFrame」をはじめ、エス・エス・ジェイのERP（会計）パッケージ「SuperStream」、インフォファームのCRM「InfoFarm戦略箱」など。これらをBPEL Process ManagerによってSOA連携させている（図1）。

図1●CONTROL2006においては多数のアプリケーションが利用され、それらがすべてOracle BPEL Process Managerによって連携されている（画像クリックで拡大）

アプリケーション間をSOA連携させるメリット

　従来、複数のアプリケーションを連携させるというと、連携先のアプリケーションや業務内容に合わせてアドオンなどを開発し、同期通信を行なう手法が一般的だった。こうした方法は、アプリケーション間を密接に連携させることから「密結合」と呼ばれている。

　密接にアプリケーション間が連携すると言うとよい響きに聞こえるが、実際にはそうではない。たとえば、業務ルールの変更に伴い、別のアプリケーションと連携させる必要が生じたとしよう。アドオンによって密結合させていた場合、新たなアプリケーションと連携させるたびにアドオンを開発しなければならない。また、バージョンアップやアプリケーションの入れ替えなどが行なわれると、やはりアドオンの見直しや再開発が必要となってしまう。このため、アドオン開発のコストがかさむという理由で、業務ルールの変更が実現できない、あるいはアプリケーションのバージョンアップを見送るという事例は多い。

　SOAが注目を集めているのは、こうした問題を解決できる手法であるからだ。なぜ解決できるのかというと、SOAは標準的なプロトコルを用いてアプリケーション間をつなぐことによって依存関係をできる限り減らし、両者を柔軟に連携する「疎結合」を目的としているのがその理由である。

　疎結合によるメリットは、たとえ一方が変化したとしても、もう一方には影響が及びにくいことに尽きる。この疎結合が実現できれば、業務が変わってもアプリケーションの変更を最小限に抑えることが可能となり、またアプリケーションの1つが変わっても、その他のアプリケーションをそれに合わせてカスタマイズする必要がない。

　こうした疎結合を行ない、SOAを実現するためにオラクルが提供しているのがBPEL Process Managerである。CONTROL2006では各アプリケーションはすべてこれを通じてその他のアプリケーションと連携している。

　ただ、アプリケーション間を連携させるという意味においては、EAI（Enterprise Application Integration）と呼ばれるツールがある。EAI製品には各アプリケーションを接続するためのアダプタが多数用意されており、これを利用すればWebサービスなどに未対応のアプリケーションでも連携可能だ。

　では、BPEL Process ManagerとEAIツールでは何が違うのだろうか。これについて日本オラクルのアライアンスビジネス統括本部 ISV推進部 ビジネス推進部 ディレクターの遠藤哲氏は「プロセスを記述できるのがBPEL Process Managerのメリット」だと説明する。

　そもそもEAIツールは、アプリケーション間でデータを受け渡しすることが最大の目的である。このため、データフォーマットの変換などといった処理は得意としていても、「流れているデータをチェックし、その値によって処理を変える」といったプロセスに則った処理は苦手としていることが多い。しかしBPEL Process Managerでは、あらかじめプロセスを定義し、それを軸にしてアプリケーションを連携させることができる。

BPEL Process Manager上で内部統制に必要な処理を実現

　CONTROL2006において、こうしたBPEL Process Managerの強みが発揮された場面の1つとして受注処理が挙げられる。内部統制を実現する際、ITに求められることとしてIT業務処理統制がある。受注処理のフローで言えば、「見積額と受注額に相違があれば注意を促す」などといった処理だ。こうした内部統制に必要な処理を、BPEL Process Managerが行なっているのである。

　図2が実際にCONTROL2006における受注処理の流れとなっている。ユーザーがERPであるMCFrameを使って受注内容を入力すると、BPEL Process ManagerはInfoFarm戦略箱に保存されている見積もりデータを取得し、両者を比較した結果（見積額と受注額が一致／不一致／見積申請なし）を含め、InfoFarm戦略箱の受注データベースに保存する。さらにMCFrameに保存されている、顧客ごとに割り当てられた与信データをBPEL Process Managerが取得し、受注額との比較を行なう。ここで受注額が与信額内であれば処理を続行し、超えていれば販売を停止するといった処理を行なっている。このようにBPEL Process Managerを利用すれば、内部統制に必要なコントロールをプロセスの記述によって実現できるのだ。

図2●今回のモデルにおける受注処理の流れ。BPEL Process Managerによって各データベースから情報を引き出し、受注内容との比較を行なうことで統制処理を実現している（画像クリックで拡大）

　IT業務処理統制を実現するためには、従来のアプリケーションのリプレースやカスタマイズが必要であるという説明が数多く見られる。しかしCONTROL2006の成果を見ていくと、各アプリケーションをSOAで連携させ、さらにプロセスに沿って処理することにより、アプリケーションを変えずに業務処理統制の一部を実現できることが理解できる。SOAと言うと技術面からのメリットばかりが強調されるが、内部統制の実現においても有効であると言えるのではないだろうか。ただ気をつけたいのは、SOAは手段であってそれを実現することが目的ではないということ。ユーザー企業側は、あくまでシステムを柔軟に連携させるという視点で考えるべきだ。

　一方、システムインテグレータに対してもSOAの浸透が与えるインパクトは大きい。アドオン開発やパッケージのカスタマイズは、システムインテグレータにとって大きな収益源となっているが、SOAが普及し標準インターフェイスを使った連携が広まれば、売り上げを落とすことにもつながりかねないからだ。ただ、これはそうした作業よりも付加価値を高められる、「プロセスのデザイン」に重点を置くビジネスモデルへ変革するチャンスと捉えるべきだ。

★

　内部統制は上場企業が対応すべき法制度だが、今後はそれらの企業との取引の健全性を内部統制の実現レベルで評価されることもありうる。そのため、非上場企業であっても内部統制への対応は考える必要がある。もしあなたの会社の対応が進んでいないのであれば、こうしたソリューションの活用をぜひ検討してほしい。