「ビジネスの変革にダイナミックに対応する」──。 SOA（サービス指向アーキテクチャ）の最大の売り口上だ。一部の先進ユーザーは、トップダウンでシステム基盤の“SOA化”に取り組み始めたが、大半のユーザー企業は、「SOAはITの理想を掲げたものに過ぎない」「自分には関係ない」と冷めた目で見ていた。

　しかし、その一方で多くのユーザー企業が、部分最適でバラバラに構築してきた情報システムにかかる膨大な運用・保守コストに耐え切れなくなっている。こんがらがった情報システムを整理し、業務の変更に柔軟に対応できるシステムにしたいと切実に考え始めている。そこに、「日本版SOX法」への対応という新たな課題が降りかかってきた。SOAに基づくシステム構築は、業務プロセスを可視化し、業務の正当性を保証するSOX法対応のための基盤になるため、SOAへの注目度はにわかに高まってきた。

　必ずしも、ビッグバン型ですべてのシステムを作り直す必要はない。新しく構築するシステムから順に、SOAをベースに作る提案こそ現実解だ。業務単位で部分的に始める“プチSOA”の提案こそが、ユーザー企業の実需に応える。


　「ユーザー企業は、コンプライアンス（法令順守）やセキュリティを前提に、企業システムを構築しなければならない。そのためには、データと業務プロセスの両方を可視化する必要がある。SOAベースのシステム構築は、システムの透明性を担保するための有力な手段になる」──。

　日本オラクルの遠藤哲グローバルアライアンス戦略本部ISV推進部ディレクターは、ユーザー企業の日本版SOX法対応の取り組みが、SOA（サービス指向アーキテクチャ）に基づくシステム構築を加速させると断言する。

　SOAは、ユーザー企業の個々の業務を「サービス」と呼ぶプログラム単位でシステムに実装し、そのサービスを組み合わせて連携することで、必要な業務プロセスを実現する開発手法だ。標準的なインタフェースでプログラム同士を接続することで、業務の変更や拡張に柔軟に対応できる。

　一方、日本版SOX法は今や、ユーザー企業が情報システムのあり方を考える際の最大の関心事だ。企業の会計や財務報告の透明性・正確性を高めるために、内部統制の実施を義務付ける法律で、早ければ2008年3月期の決算から適用される。ユーザー企業は、財務報告の信頼性を担保するために、財務処理の証拠文書の記録や承認プロセスなどの業務プロセスを整備する必要がある。

　IT関連では、会計システムや販売管理システムなどを適切に運用しているかどうかが監査の対象となる。そのためシステム運用面では、運用業務のベストプラクティスであるITIL（ITインフラストラクチャ・ライブラリ）を、SOX法対応に融合させて提案することが、ソリューションプロバイダにとっての大きなビジネスチャンスになりつつある（2005年12月15日号の特集参照）。

　一方、システム開発の面では、SOAこそが、日本版SOX法に対応する強力な手段なのだ。

　日本版SOX法では、業務アプリケーションによる統制を示す「業務処理統制」と、業務処理統制が有効に機能することをシステムのインフラによって保証する「全般統制」の大きく2つに分けられる。これは、サービス（＝業務アプリケーション）とそれを管理・実行するミドルウエアとの関係でシステムを構築するSOAの考え方にほかならない。業務を可視化し、業務遂行の正確性を担保する、内部統制実現のための仕組みを、SOAベースのシステムは備えているわけだ。

　ところで、日本版SOX法への対応以前の問題として、ユーザー企業の情報システムは、増大する保守・運用コストに耐え切れなくなっている。スクラッチで開発したシステムはもちろんのこと、ERP（統合基幹業務システム）ですら、レガシーシステム化しているケースもある。ユーザー企業が業務に合わせてカスタマイズした影響などによって、バージョンアップしようにも新規導入ほどのコストがかかったり、業務プロセスを見直そうにも、複雑に入り組んだプログラムが障害となって、簡単に修正できなかったりする。

　また、2000年問題対応時に、手直しで乗り切ったシステムの更新需要もある。これらのシステムは、実際の業務とのギャップを抱えている。レガシーシステムの技術やノウハウが継承できなくなる、いわゆる「2007年問題」も間近に迫る。ユーザー企業にとって、自社のシステムを分かりやすく整理し直し、保守・運用も簡単にしていくことが、IT投資が復活した今、いよいよ待ったなしなのだ。

ボトムアップ型で浸透へ

　これまでITベンダーはこぞって、「SOAを全社のシステム基盤とすることで、ビジネスの変化にも、“ダイナミック”にサービスを組み替えて対応できる」と喧伝してきた。だが、現実にそこまでのダイナミックな対応を必要とするユーザーは、大手を中心とした一部の先進企業に限られるだろう。それがSOAを“夢物語”にした大きな要因である。

　全社最適によってあるべき業務プロセスを定義し、そこからサービスの切り出し単位を決めてシステムを構築するという手法も、敷居が高い。様々な既存システムがあり、関連部署も多岐にわたる環境では、よほどのトップダウンの大刷新プロジェクトでもなければ、容易ではない。

　実際ユーザー企業は、一からすべてのシステムを作り直すわけにはいかない。今後新しく構築するシステムから、徐々に変更していくアプローチが必要になる。 　SOAは本来、それが可能だ。既存のシステムを部分的に活用して他のシステムと連携するときに、その機能をサービスとして切り出し、標準的なインタフェースで連携していけばよいのだ。SOAの理想型であるビッグバン導入などは、あり得ないと考えた方がよい。部門単位、業務単位でのボトムアップ型のアプローチで実現する、いわば“プチSOA”から始めることが有効になる。