SOA普及を困難にしている要因を探る：SOAアーキテクト塾（1）（1/2 ページ）

「サイロ化したシステム群を統合しよう」という掛け声はよく聞かれるが、実際にそれを推進しようとするとさまざまな問題に直面する。システム統合プロジェクトに求められる情報システム部門の役割やスキルから考えてみよう。

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

　2008年12月、＠IT情報マネジメント主催の勉強会「SOAアーキテクト塾」が都内で開催された。年末近い日程であったが、現実に即したSOA導入の勘所、そして疑問に答えるという本セミナーに対する期待は大きく、会場はほぼ満員だった。

　勉強会は、まず株式会社豆蔵 ビジネスソリューション事業部 シニアコンサルタントの岩崎浩文氏の基調講演があり、続いて日本オラクル SOAアーキテクト本部の岡嵜禎氏を迎えてのパネルディスカッション（モデレーターはブレインハーツ株式会社 谷川耕一氏）、最後に参加者からの質問に答えるという形式で進められた。以下、セミナー内容の要点をまとめ、「SOAを実践するための解」を探っていく。

SOAプロジェクトがなぜ困難なのか

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

　基調講演は「2010年、分散システム時代の到来のエンジニアの将来」と題し、豆蔵 岩崎氏が、来るべきSOA時代に向け、ITエンジニアが直面する問題とその解決策を提示した。

　岩崎氏は、＠IT情報マネジメントで連載記事『戦う現場に贈る分散システム構築』を執筆している。ここで「分散システム」という用語を使っているのは、「SOAという言葉が、一過性のものになる可能性があるから」（岩崎氏）とのことだ。なぜなら、すでに今日の企業システムは、個別業務ごとに閉じた形態ではなくなりつつあり、今後もこの流れは加速すると思われる。つまり将来的にはすべてのシステムがSOA化することが予想され、そのときにはもはや「SOA」という概念自体が当たり前となるからだ。

　とはいえ、今日のシステム開発における要件で、「SOA化してほしい」と明示されることは、めったにない。要件を分析した結果として、「SOAにしましょう」という論に落ち着くケースがほとんどだ。岩崎氏は「経済環境が厳しくなると、まったくゼロからの新規開発は凍結し、代わりに『コスト削減』、一方で『機能拡張』という要件を突き付けられてきます。とすると、必然的に『既存システムを組み合わせ、業務パフォーマンスを最大限に引き出せるようにしてほしい』ということになる。しかし、これがなかなか簡単にはいかないのです」と語る。

　なぜ、うまくいかないのか。コストの問題もさることながら、さらに困難なのは、「既存システム統合のためには、各システムに関係する部署すべてにまたがる意見統一や調整が必要になる」という点だ。岩崎氏自身、コンサルタントとして開発現場にかかわる中で、「やはり、人の問題は最も大きい」と感じているという。

鍵は「トップダウン型アプローチ」

　確かに企業の中には、「あの担当者の意見には逆らえない」「この部署をつぶすわけにはいかない」という現実がある。これについて岩崎氏は、「全員が『自分は正しい』と思っている限り、この問題は永遠に解決しません」と断言している。

　そこで、どうするか。全員が納得するためのよりどころになるのは、企業全体の理念や目的だ。これらを明確にし、業務視点でブレイクダウンしていくことで、あるべき姿がはっきり見えてくる。つまりトップダウン型アプローチだ。豆蔵では、企業理念や目標から業務要件を整理するために、オブジェクト指向型アプローチを用いて分析していくという。

　ただし、強引にトップダウン型アプローチを進めても、プロジェクトに亀裂が入る可能性がある。岩崎氏は「現場には、『現在業務が回っている』という実績があります。そのため、意見をすべて切り捨てるというのは、現実的な解ではありません」という。

　そこで重要になるのは、プロジェクトにおける「調停」だ。ここでいう調停とは、「関係部署すべてを納得させつつ、現場視点から見た有効な意見や指摘を取り入れる」ということ。納得させるためには、前述したような企業理念や目標からの分析結果が必要であるし、一方で理想と現実の間にあるギャップを埋める努力をしなくてはならない。

　現在、こうした調停役を担っているのは、ユーザー企業の情報システム部門が一般的だ。しかし「これからSOAを指向する案件、結論としてSOAに行き着く案件が増え、SOAプロジェクトが増加していくと、この『調停』について、SI企業側も真剣に考えていかないとならない」と岩崎氏は指摘する。これは円滑なプロジェクトを実践する目的もあるが、何より「複数のシステムを連携する」という現実が出てくると、1社ですべて担当するのは、技術的にも無理が生じるからだ。

　具体的には、プロトコルやネットワークの状態を評価し、設計し直したり、.NETやJava、メインフレームなど異機種混在環境を整備したり、オンライン／バッチのどちらがふさわしいかを検討したり、いろいろな技術が絡み合ってくる。実際、ITSS Version3では、異機種混在環境にあるサービスをどうつないでいくか策定する「インテグレーションアーキテクト」という職種が定義されているが、今後こうした役割はますます重要になってくると予想できる。

　岩崎氏は「経済環境やビジネスの動きなど、さまざまな外的要因で企業システムは変革の波にさらされています。ITエンジニアも、この変革の波から逃れられないでしょう。環境変化に対応する柔軟なシステムを開発するには、ITエンジニア自身も、その変化に対応しなくてはならないのではないでしょうか」と提言し、講演を終えた。