SOAに取り組む際に固定観念にとらわれなくていいからと言って、闇雲に進めるのは避けるべきだ。先進企業やベンダーが経験から得た、数々の“定石”を踏まえておきたい。余計な手間をかけずに効率的に作業を進められる。

社内外を巻き込む姿勢が大切

 マイクロソフトの萩原正義バートナーテクノロジー推進部アーキテクトは「サービス化にあたり、まず物理統合、次に論理統合を進めるのが基本」と定石を語る。物理統合とはサーバーを集約したり、異なるバージョンのパッケージを一般化すること。論理統合とは、アプリケーションの機能やマスターデータの重複を整理する作業を指す。

 「この順序が逆になるとうまくいかない」と萩原氏は指摘する。ただし「完全な論理統合はまず不可能」なため、「手近で期待できる効果が大きい部分から統合するのがよい」と語る。「論理統合がほどほどでもサービス化はできる」(同)。

 SOAに基づき開発したワークフローシステムで、IT Japan Award 2008で特別賞を受けたセガ。同社はサービスの定義を見直したり、使い勝手を向上させるなどシステムの改善を継続。8月に作業を一通り完了した。

 セガはSOAに基づくシステム開発経験から数々の定石を得た(図1)。松田雅幸 情報システム部部長がSOAに挑む企業に特に勧めたいとするのは、「社内が“乗れる”プロジェクトを目指す」と「外部の友人を増やす」の二つだ。

図1●セガがSOAプロジェクトを通じて得た“定石”の例
図5●セガがSOAプロジェクトを通じて得た“定石”の例
[画像のクリックで拡大表示]

 前者は新たな手法や技術を使い、かつ多くの部門がかかわるプロジェクトほど、周囲を巻き込むことが不可欠という意味だ。「どれだけ生産性が上がるか、といった短期的な効果を強調しないと予算も得られないし、プロジェクトの運営にも無理が出る。どう言えば周囲にアピールできるかをトコトン考えた」(松田氏)。

 後者の友人とは「技術に関して相談できる知り合い」のこと。「営業担当者を通じて質問を出しても、希望する回答が即座に得られるケースはまれ。研究会やコミュニティを通じて『この技術ならこの人』という技術者と知り合い、直接問い合わせるよう心がけた。それ以降、得られる情報の品質は格段に上がった」(同)。

方法論や既存サービスを参考にする

 各ベンダーが経験を基に作成した方法論で定石を学ぶのも手だ。例えばNECは今春、SOAに基づくシステム開発を支援する「SystemDirector Enterprise」と呼ぶツールと方法論を整備した。このなかで「サービスの粒度(大きさ)の決め方の指針も盛り込んだ」(久保田卓見 第二システムソフトウェア事業部グループマネージャー)。

 NECの方法論では「トップダウン(戦略ベース)とボトムアップ(ルールベース)双方の視点でとらえる」「トップダウンなら経営戦略とIT戦略の観点、ボトムアップなら業務と運用の観点でみる」「IT戦略の観点では『モニタリングの単位』『パッケージ化の単位』で考える」といった、サービスを決める際の指針を示している。

 SAPジャパンや日本オラクルなどのERPパッケージでSOAに基づくシステムを実現するのも手だ。利点は、サービスがすでに存在すること。SAPは自社パッケージの機能をサービス化した「エンタープライズサービス」を約2800種類用意している。サービスの連携に欠かせないが見過ごされがちな共通のデータ型も整備されている。これらを使えば、SOAの定石にのっとったシステムを開発できる。

 「本来オープンであるべきSOA環境がパッケージ・ベンダーにロックインされる」(HPのタリガプーラ氏)懸念があるのも事実だが、選択肢として考える価値はありそうだ。