SOAで市場競争を勝ち抜け！──「システム開発の迅速化」のメリットを究める

（2006年09月22日）

　SOAに基づくシステムの開発は、今や、企業にとって“当たり前”のことになりつつある。しかしながら、実際にSOAプロジェクトを進めるにあたっては、ITマネジャーはさまざまな課題に直面するものだ。本稿では、6カ月という短期間でSOAベースのシステム開発に成功した企業の事例を紹介する中で、開発現場におけるSOAプロジェクトの課題と、その解決法を探りたい。

ギャレン・グルマン
InfoWorld 米国版

　自動車の購買に関する顧客からの引き合いや問い合わせを自動車ディーラーに配信するJava対応プラットフォームの開発──新興企業「ザッグ」のCTOとして招聘されたオデオ・ノイ氏は、CTO就任後間もない2005年9月に、その大変な仕事を引き受けることになる。

　ノイ氏は、それまでにもさまざまな課題に立ち向かい、十分な実績を積んできたベテランだ。アプリケーション管理会社を共同で起業したこともあるし、イスラエル空軍の戦争ゲーム・シミュレーション開発に参加したこともある。

　しかし、ザッグでの課題は、それらとは完全に性質を異にしていた。自動車販売および自動車ローン向けのオンライン・システムを、なんと「6カ月以内」に、拡張性の高いプラットフォームに移行させよ、というのが、彼にそのとき与えられた使命だったのである。

　しかも、ザッグのパートナーだった自動車ローン大手のキャピタル・ワンは、さらに条件を積み増してきた。顧客が新車ならびに中古車の価格や在庫情報を簡単に調べることができ、オプションの発注や支払いもオンラインで済ませることができるようなシステムにしてほしいというのが、その条件だった。

　そうした条件を満たすためには、在庫管理、価格、コールセンター、CRMなどに関するアプリケーションを新たに用意しなければならなかった。それに、ノイ氏のチームが開発することになるシステムは、キャピタル・ワンの新しいWebサイト「DriveOne.com」の基盤になるものだったが、将来的には他のパートナーからの要求にも対応できるようにフレキシブルなものにしておく必要があった。

　ノイ氏はこうした複雑な条件の解決策をSOA（Service-Oriented Architecture）に求めた。SOAのモジュラ型アプローチによって、新しいビジネスの拡張性と適応性を実現することにしたのである。「このフレームワークによって、アーキテクチャを変更せずに未知のものにも対応できる、結合力に優れたプラットフォームを実現しようと考えた」（同氏）わけだ。

　しかしながら、（SOAに限らず）何を解決手段にしようと、ザッグが必要なアプリケーションを、6カ月という短い期間内に、すべて自前で開発することはほぼ不可能であった。

　そこで同社は、コールセンター・システムや自動車産業向けのCRMアプリケーション、バックエンドのトランザクション処理技術などを社内に抱えていた自動車購買クレジット・サービス会社「オートランド」を買収することにした。

　ただ、ザッグの技術はJavaをベースとしていたが、オートランドの技術は主にCOM（Common Object Model）とVisual Basicをベースとしており、一部では.NETやMicrosoft SQL Serverコンポーネントも用いていた。

　つまり、言いかえれば、ザッグは突然、レガシー技術を抱えることになったわけだ。かといって、オートランドの技術をJavaに移行させるとなると、開発期間やコストの面で独自開発とあまり差がなくなり、買収した意味が消え失せる。しかも、SQL Serverの高速プロトタイピングやサムネール・イメージの管理など、.NETのほうにも優れた機能が少なくなかった。

　このため、アーキテクチャ・ビジョンを早急に再検討する必要が生じた。そこでの議論の流れは、それぞれのジョブに最適な技術を採用し、シンプルさを維持するために個々のモジュールの技術ベースは変更せず、それらを統合する──という方向へと向かうことになった。となれば、「SOAアプローチを採用する」という結論に達するのは、当然の帰結だった。

コンポジット・アプリケーションによる開発の迅速化

　ザッグは、DriveOne.comの基盤となるシステムを開発するにあたって、全部で10のコア・アプリケーションを開発・配備・統合する必要があった。もちろん、それらの多くは、（開発期間の短縮を図るため）ザッグかオートランドの既存のアプリケーションをベースとしていた。

　「期日を死守するために、われわれは早い段階からコンポジット・アプリケーション環境を必要としていた」と語るのは、ザッグのチーフ・ソフトウェア・アーキテクト、ニック・パーンブラッド氏だ。そのため、同氏らはまず、アプリケーションのビルディング・ブロックを構成するサービスの定義から始めた。

　SOAの基本原理は、ビジネス・プロセスのビルディング・ブロックを特定して、それらをインスタンス化するサービスを開発し、必要に応じてそれらのサービスを、厳密に定義したインタフェースによって統合するというものだ。各サービスは通常、複数のビジネス・プロセスに対応する特定の機能を提供する。例えば、“ディーラーのアドレスを検索する”や“サインオン情報を有効にする”などだ。

　多くの企業では、こうしたサービスの再利用によって経済効率が高まることが、SOAのいちばんのメリットだと見ている。だが、ザッグにとって最も重要な課題は、アプリケーションの迅速な開発であった。また自己充足型のサービスでは、サービスの内容が変更、追加されてもアプリケーションを修正する必要がないこともメリットだった。

　「在庫の表示やオプション・パーツの選択など、それほど難しくないことなら自分たちでやれる。しかし、それらを統合するとなると、巨大なアプリケーションに取り組まなければならず、手に余る」とノイ氏。

　コンポジット・アプリケーション・アプローチを採用すれば、それぞれのタスクが制御可能な範囲にとどまる。しかも、今回のザッグの場合には、買収したオートランドのアプリケーションから必要なアプリケーションを“削り出す”ことができるため、システム全体を最初から書き換えるという手間がいらない。これにより、「ビジネス・ニーズに即応できる開発環境が実現する」（同氏）わけである。

　ただし、コンポジット・アプリケーション・アプローチをとる場合には、サービスが重ならないよう注意しなければならない。ソフトウェアが外部のパートナーとやり取りする必要があるときに、双方の機能の定義が異なれば、やっかいな問題が生じる可能性があるからである。

　また、それぞれのインタフェースがさまざまな事態を考慮したうえで実装されていることも重要だ。ノイ氏も、「インタフェースでつまずくことは少なくない。その意味で、厳密に定義されたインタフェースは、リスクを軽減してくれる」と指摘する。

　ただ、インタフェースを明確に定義するのは、決して容易なことではない。例えば、ディーラー・アドレスはディーラー・モジュールの一部であることは明白だが、価格情報が価格システムに置かれているのか、在庫システムに置かれているのかは、それほど明白なわけではない。在庫を価格戦略の一環として扱っているディーラーの場合は、特にそうだ。

図1：わずか6カ月間で完成したSOAシステム