コンサルタントに聞くSOAの手触り：動き出したSOAのいま（2/2 ページ）

[谷川耕一，ITmedia]

既存資産で全体最適を実現するSOA

　SOAは新しい技術を導入することではなく、従来のシステム開発方法論に、業務とシステムを結びつける視点をより強調したものだ。前出のNECは、SOAに対応する製品をベンダー企業としてフルラインアップで提供している。個々の製品を利用することで、SOAによる問題解決や効率化を図ることができるだろう。しかし、コンサルタントである松友氏の立場からは、特定の製品に依存するのではなく、常に顧客が直面している課題をスタートポイントとして、解決方法を提供することに注力しているという。

　つまり、SOAに対応したシステムへのアプローチは、SOA対応ツールなどを用いて個々のシステムをコンポーネントとして連携させるという、システムの「形」を整えることから入るわけではない。まずはその企業が抱えている問題点を徹底的に洗い出し、ITを使った解決方法を考える。その際に、部門などの単位で問題に対応していては、従来の個別最適のシステムと同じだ。効率的な全体最適を考えると、細分化されたコンポーネントを組み合わせて、新たな仕組みを生み出すSOAが有力な方法論としておのずと浮上してくる。

　「SOAのコンサルティングには、企画と構築の2つのフェーズがあります。NECの立場はコンサルティングファームではないので、IT部門での役割を軸足とした上でプロジェクトをどう進められるか、SOAの手法を利用するとどんな効果があるのか、これらを、実際にシステムを作り始める前の段階から顧客と一緒に考えることが重要です。課題について顧客にも意識してもらわなければなりませんし、ITベンダー側ではどこまでを解決するかというスコープをきちんと設定することが大きなポイントとなります」（松友氏）

　「最初の課題は、課題を設定すること」であり、「IT部門の本来の仕事は何か」に定義から始めることすらある。方法論や技術など、SOAという概念にはかなり領域に幅がある。どんな課題を抱えていて、SOAのどういうところに課題解決を求めているのか。この部分を最初に明らかにしないと、プロジェクトはうまくいかないことが多い。

　システムの統合だけを考えるならば、EAI（Enterprise Application Integration）という選択肢もある。サブシステム同士を単につなぐことが目的であれば、EAIやハブ的な要素だけでも解決できるだろう。だが、SOAとなると、個々のインタフェースを共通化するだけでなく、全体最適化を目指し、全体で標準的なインタフェースを決めて、そこでサービスとサービスをつなぐ。サービスという単位がどう実行されるかは、サブシステムの単位から脱却した視点でみて、いかにシームレスにビジネスプロセスが連携できているかが重要になってくる。

どの単位で構造化するか

　業務フローの構造化は、業務コンサルタントがこれまでにも実施してきたことだ。システムの構造化についても、ITコンサルタントが行っている。SOAでは、双方をどう対応付けるかになる。業務の構造化とシステムの構造化にデータがそろえば、作るべきシステム全体の輪郭が描ける。

　ここで、松友氏が考える「輪郭」には、SOAにおけるサービス粒度、つまり、脱着性や流用性の単位を、方法論を用いて業務とシステムの両方の視点から明確に定義したいという思いがある。それを描けない場合は、描けないこと自体に何か問題があると考え、輪郭が描けるように改善を図るわけだ。

　まずは、業務を構造化するための業務分析から始める。業務分析の結果をシステムに落とし込む方法を考えながら、構造化の単位を決めていく。業務も構造化、アプリケーションも構造化、システムも構造化、それぞれのレイヤーでシームレスにつなげるような構造化が必要だ。これらの関係は多次元的なマトリックスとして表現できるだろう。最終的には、システムの機能まで構造化するためのシナリオを描くことが重要になる。

　現状の業務の中には、システム化されているものに加え、人の手作業だけで処理されているものもある。SOAでは、いまシステム化されていないものも含めて構造化することが重要だ。すると、手作業の処理を将来的には自動化したいという要求が出てくる可能性もある。システムで動いているフローしか見ていないと、その部分しか構造化、効率化できなくなる。SOAで全体最適を考える際には、手作業の部分も含めて可視化することが重要だ。

　また、企業の中でのポジションによって業務を見る視点は異なる。経営者やマネジャー、一般社員の間でも、部門によっても違う。このことも加味して、構造化し、可視化できるようにする。漠然と業務を細分化するのではなく、担当者ごとの視点を検討することで、精密かつ網羅的に業務をチェックできることになる。

　「導入から運用管理までトータルでサポートできるところにわれわれの強みがあります。もともと得意だったテクノロジーに加え、SOAのアプローチができるのです」と松友氏は話している。

　ユーザー企業にとってSOAに対応すること自体はシステムへの要求ではなく、ましてやシステム間を連携させることがSOAの目的でもない。何が問題かを明らかにし、そこをスタート地点にして業務やシステムを多角的に構造化する。もちろん実際のシステム構築の段階になれば、数々登場しているSOA用のツールやアプリケーションを適材適所に選択して活用することになる。

　とはいえ、先にツールやアプリケーションが来るわけではない。課題の設定から業務システムの構造化、次に、最適なツールや方法の選択というステップを順に踏むことが、結果的にSOAを実現の早道となるようだ。