SOAの効果を出すためのサービス粒度・体制・人材：SOAアーキテクト塾（2）（1/2 ページ）

SOAの普及でアジアの中でも最下位とされる日本。なぜ、SOAが進まないのか？ SOAによって効果的なシステム構築・運用を実現するにはどうすべきなのか？ 「SOAアーキテクト塾」のパネルディスカッションをレポートする。

[岩崎史絵（トレッフェ），＠IT]

　2008年12月、＠IT情報マネジメント主催のセミナー「SOAアーキテクト塾」が都内で開催され、盛況のうちに幕を閉じた。本レポートは、セミナー後半のプログラム・パネルディスカッション「SOA導入の道とは？」を中心に、（1）SOAにおけるサービス粒度の設計方法、（2）プロジェクトを成功に導く体制作り、（3）SOAの効果の3点について、株式会社豆蔵 ビジネスソリューション事業部 シニアコンサルタントの岩崎浩文氏、日本オラクル SOAアーキテクト本部の岡嵜禎氏（モデレーターはブレインハーツ株式会社 谷川耕一氏）の考えをまとめていく。

サービス粒度の解は1つではない

谷川氏　サービス粒度についてですが、先ほど岡嵜さんは「なぜサービスという考え方が必要なのか」という問いから始まるとおっしゃいました。この点について、もう少し深くお願いいたします。

日本オラクル SOAアーキテクト本部 岡嵜禎氏

岡嵜氏　なぜ、サービスという概念でシステムを設計するのか？ そのメリットは3点あります。第1に、「業務との親和性」です。業務担当者が利用しやすい形、認識しやすい単位でサービスを考え、連携することで、業務プロセス全体のパフォーマンスをより向上させるというもの。第2に、「標準化・共通化」があります。これは異機種環境でも接続しやすい状態にアーキテクチャを設計するという考え方。第3に「疎結合」です。できるだけ小さい単位でサービスを設計し、再利用性を高めることが目的です。さて、こう考えたときに、サービス粒度には2つの解釈が生まれます。1つはインターフェイスに着目するものです。例えば「顧客機能を登録する」という機能が3つに分散してあるとしましょう。この時、3つの機能を統合し、共通化することで再利用性を高めると共に、インターフェイスを整備して異機種環境のシステムでも利用可能とするのです。もう1つは、機能の大きさでサービス粒度を決めるアプローチです。モジュールやシステムの大きさにもかかわってきます。

谷川氏　岩崎さんはいかがですか？

株式会社豆蔵 ビジネスソリューション事業部 シニアコンサルタント 岩崎浩文氏

岩崎氏　まず、既存システムをその物理的単位でサービスととらえる考え方は、もちろんあります。しかしここではもう少し踏み込んで、わたしたちコンサルタントが、現状のシステムや業務プロセスをどのように分析し、サービスという単位に落とし込んでいるかを説明しましょう。わたしたちは、数年前にはやった「EA」（Enterprise Architecture）という概念が、サービス分析に不可欠だと考えています。「なぜこの企業には、こういうサービスを持つ必要があるのか」を演繹的に考えていくもので、先ほど説明したトップダウン型アプローチと通ずる部分です。具体的には、業務コンサルタントの成果物であるデータモデル（概念モデル）や業務フローなどを基に、サービスの粒度を定義していく。ほとんどの業務システムには、データベースがあり、そのデータをどのように効率的に読み書きするかが命題なのですが、そこはSOAでも変わりません。つまり既存システムのER図をAs-Isとしてとらえるわけです。一方、企業側は「企業理念に基づき、最高の結果を出せる（売り上げを上げる）仕組みが必要」という理想形があるので、それをTo-Beモデルとして記述していく。この2つのモデルの差異を洗い出し、トップダウン型の判断軸に基づいて、サービスの粒度を決めていくのです。

谷川氏　その場合、As-IsとTo-Beの間でギャップが生じると思うのですが、そこをどう解消していくのでしょうか。

岩崎氏　正直に申し上げると、ケースバイケースです。一例を挙げると、あるお客さまで、「どのようにシステムを連携させればいいのか、検証したい」という案件がありました。調べてみると、ビジネスプロセスや業務単位では1つに統合してあるべきものが、3つに分かれている。もちろんマスターデータも分かれています。そこでまず、3つのシステムを仮想的に1つに統合する中間層を設計することにしました。3つのシステムをまとめて1つにし、さらにその先にある業務プロセスにつないでいくというものです。こうすることで、As-Isを尊重しつつ、To-Beを実現できるわけです。

岡嵜氏　基本的には、ギャップの解消について最終的な決断は、お客さま自身に決めていただくことが必要だと思います。ただ、その判断は、置かれている状況によって異なるでしょう。例えば新規開発であればトップダウン型がやりやすい。判断が難しい場合は、1つの解決策として、当社ではデータモデルや標準プロセスのテンプレートが入ったベストプラクティス「Application Integration Architecture」というものを提供しており、これを軸足として、トップダウン／ボトムアップのハイブリッドアプローチで進めていくという手段もあります。

谷川氏　物理的なシステムの構造は、サービスの粒度に影響を与えますか。

岩崎氏　影響はあると思います。例えば、物理的にSOAPインターフェイスで連携できない、トランザクショナルにデータを取得できないなど、物理的制限はまだまだ多いですね。

岡嵜氏　そこをわれわれのようなベンダが、どのような製品で解決しているかというと、これもさまざまなケースがあります。例えばネットワークのラウンドトリップを避けるために、キャッシュを用いるなど、製品機能を組み合わせて解決していきます。