pr

めざせSOA先進国！ これがSOAの成功法だ ――日本のSOAをキックオフする「SOA Insight」

　エンタープライズシステムにアジリティをもたらすシステムコンセプトとして、SOA（Service Oriented Architecture）が登場して約5年。ここへ来て、ようやく国内でもSOAの実案件が増えつつある。その効果を上げるためには、どのような進め方をするべきか。SOA案件の第一人者・日本オラクル SOAアーキテクト本部 本部長の的場大輔氏に聞いた。

――今回は、グローバルでSOAの構築・導入・コンサルティングを手がけ、本市場のけん引役ともいえる日本オラクルさんに、SOA実践におけるポイントを伺っていきたいと考えています。まず、ここ数年、SOAの案件は、どの程度広がっているのでしょうか？

日本オラクル株式会社 SOAアーキテクト本部 本部長　的場大輔氏

的場　SOAというと、まず「既存のシステムを統合する」とか「連携基盤」などをイメージする方が多いと思います。考えてみれば当たり前で、ファイル連携にしろ、EAIにしろ、こと“連携”というテーマはシステム開発の歴史において非常に大きく、その効率化に関してさまざまに論議されてきました。そのため、どうしても連携技術や基盤製品の方に目が行きがちです。

　しかし、SOAの本当の狙いは「経営に貢献する仕組みを作る」ことです。これがいわゆる真の「SOA」です。もちろん技術も大切ですが、WebサービスやBPELなどの実現にこだわりすぎて、システム連携のそもそもの目標やゴールを見失い、技術的難題に直面した時などにプロジェクトが立ち行かなくなることも少なくありません。こういう狭義のとらえ方を、小文字で「soa」と呼んでいます。

――大文字の「SOA」を実践するに当たり、必要な事柄は何ですか？

的場　2つあると考えています。1つは「ディシプリン」、もう1つは「統制役」です。

　まずディシプリンですが、いわばこれは“組織体のしつけ”です。ガバナンスの成熟度といってもいいでしょう。SOAが「経営に貢献する」という考え方に基づくものであるならば、そもそもその企業自体が、「どういう組織でありたいか」「そのために、何が必要で、どうすべきか」を真剣に考えなくてはなりません。その行動指針として、ガバナンスがきちんと確立されているかどうかが重要になります。どんな企業でも、SOAの具体的な進め方は分からないし、迷いも生じるでしょう。その際、判断基準をどこに置き、どのように進めるかは、その企業が持つガバナンスのキャパシティに左右されます。

　次に統制役――これはSOAを推進し、調整する人材です。あるCIOの方がおっしゃられた“SOA Controller”という表現が適切かもしれません。SOAは、ビジネス環境の変化に合わせ、絶えず進化し続けるものです。そこでSOA Controllerが、経営環境の微妙な変化を読み取ってサービスを定義するためには、まず自社に対する愛情がなくてはいけません。加えて、技術に対する厚い信頼を持って、SOAを継続できる人。そういう人材なり、PMO（Project/Program Management Office）あるいはSOA CoE（Center of Excellence）といった組織体なりを企業の中に育成し、SOAを推進することが必要だと考えています。

――早速核心に入りますが、「経営に貢献するSOA」を現実化するには、どのように進めていくべきなのでしょうか？

的場　いくつかポイントがありますが、まず大切なのはアセスメントですね。一口にアセスメントといっても、SOA実践においては、いくつかレイヤがあり、その中でアセスメントを取ることが必要です。順に説明しましょう。

　レイヤとは、EA（Enterprise Architecture）のように企業全体の体系の層だと考えてください。当然、それぞれのレイヤには、その分野を担当するスタッフがいます。経営に貢献するということは、各レイヤの担当者が自分の立ち位置を認識し、その視点からあるべき姿を考えていくことが必要です。SOAに関して「連携技術」だけを語られたり、逆に「トップダウンの思想が重要だ」との考えからトップ層の思いだけが重視されることもあります。現場では同時に別の種類の話を討論することが多く、論議が混然としたものになり、途中で挫折することがしばしばです。まず各レイヤをアセスメントし、「この話はどのレイヤのことを言っているのか」という認識を一致させると、その近隣のレイヤが抱える課題や、あるべき姿が見やすくなります。

　もう1つのポイントは、SOAのアーキテクチャモデルを早めに決めてしまうという点です。通常、この作業は非常に時間がかかるといわれており、事実コンサルティングファームなどは最低でも数カ月以上かけますが、私どもはそこを迅速化することが重要だと考えます。これは通常のコンサルティングファームとは異なる、当社独自の発想の転換ですね。そしてわれわれは、ワールドワイドで1万件以上のSOA案件の実績から導き出したSOA構築支援サービスの「Oracle SOA Insight」を提供しています。これは、SOA成功に造詣の深いコンサルタントによる、最長4週間のプリセールスのプログラムです。

――SOA Insightは、SOAの実装や推進を行う本番プロジェクトに先行するプログラムというわけですね。具体的な流れを教えてください。

的場　私たちは、ユーザー企業のビジネス戦略や制約条件、イベント、システムの状況などさまざまな項目を分析し、SOAプロジェクトを推進するための要件を作ります。具体的には、まず社員一人当たりの営業利益、資産回転率、受取勘定回転率など財務状況や業界での位置付けを分析し、どこが強みか戦略方向を見極めます。さらに現状のSOA成熟度のアセスメントを行い、認識した戦略に沿った成熟度の目標を設定します。

キックオフ ビジネス目標の確認 “SOA Insight Session”のゴール設定 参加者の役割の確認 アセスメント 現在のSOA成熟度評価 SOA成熟度のゴール設定 ディスカバリ SOA導入に適した案件の識別 選択した案件の情報分析 ロードマップ策定 ビジネスバリューの試算 SOA導入ベスト・プラクティス・ワークショップ ロードマップ策定 報告 ロードマップ報告

SOA Insightの5つのステップ

　次に、ビジネスプロセスや情報システムを分析し、サービス候補を識別します。ここではサービスの粒度、ネーミングの実例を示し、システム間でやり取りされるメッセージやそれに基づく業務オペレーションのイメージを策定します。だいたい1週間で20〜30個くらいのサービス候補を挙げることが多いですね。一口にサービスといっても、分け方は実に多様で、例えばプレゼンテーション層とビジネスロジック層に分けたり、ビジネスプロセスの中でも抽象化層とバックエンド層に分かれたりといろいろです。サービスの技術論をお客さまに説明するだけではまず理解されませんので、「具体的に、こうなります」とお客さまごとに特有の要件を踏まえて定義したサービスを提示し、イメージ共有を図ります。この部分は、私たちのような専門家集団の真価を発揮するフェイズでもあります。

成熟度アセスメント リファレンス・アーキテクチャ 導入ロードマップ ディスカッションペーパー ベネフィット分析

SOA Insightではアセスメントから分析、サービス識別などを行い、あるべき姿へのロードマップを提示する

　こうしてモデルができると、プロジェクトでどのような成果物が必要で、どんな作業に着手すべきか見えてきますし、優先度も付けられます。SOAのプロジェクトを進めるために必要な体制も提案できるようになるのです。つまり、SOA Insight自体が、SOAプロジェクトに必要な「成果物」「作業」「体制」を明確にするためのものであり、プロジェクトをスタートさせる道筋を提示するものです。プロジェクト実施の体制はお客さま自身で人材をアサインする必要がありますが、それができればすぐにプロジェクトに着手できるようになります。

――本番プロジェクトの前に先行して、サービスの識別まで行ってしまうのは大きな特徴だと思いますが、ユーザーにはどのようなメリットがあるのでしょうか？

的場　SOAの概念の核になるのは、疎結合という考え方です。一般のユーザーの方々には、これをすぐに理解していただけない場合もあります。ところがサービスを仮置きして具体的なモデルを提示すると、疎結合とはどういうものか、サービス粒度によってアーキテクチャがどのように変化するか、とても理解しやすくなるのです。いままで、難しい用語でしかなかった世界が具体性を持ち、その後の作業効率がぐっと向上します。ラーニングカーブが急上昇するんですね。SOAの命ともいえる迅速性を担保するために、先行してサービスを定義することで後工程も早くなりますし、そのスピードを体感できます。これが最大のメリットでしょう。

――一般のSOAプロジェクトでは、サービス識別は後のフェイズで行われると思いますが、SOA Insightではなぜ先行して行えるのでしょうか？

的場　やはり、ワールドワイドで1万件以上のSOAプロジェクトを行ってきた実績から得られた経験、ノウハウが大きいですね。

　具体的な進め方としては、まずシステムのソースコードを見せていただきます。なぜかといえば、最新のシステムだからSOAに最適化されているかというと、必ずしもそうではないからです。例えばCICSなどは、画面層とビジネスロジック層が分離し、トランザクションIDの概念がありコンポーネントの独立性、一貫性もしっかりしているので、ある意味SOAの教科書そのままでありとても分かりやすいんです。他方、パッケージを導入していると、サービスの粒度を「会計モジュール」などのようなモジュールで考えるか、トランザクションレベルにするか、2つを組み合わせて二重化するか、いろいろな方式が考えられます。柔軟性を保つため、多重階層にした方がいい場合もありますし、どの方式を採用するか判断が難しい。だから迷走することも多い。そうした際に立ち返る位置はどこなのか？ そこで問われるのが、設計のプリンシプル（原理・原則）であり、SOA Controllerがこれを統制します。SOA Insightで出てきた成果物を、きちんと利用するには、やはりそうした体制が備わっているか、つまり前に述べた「ディシプリン」が重要になります。

　また、サービス識別でいうと、ある程度標準化できる部分が必ず存在しているものです。例えば、いわゆる間接部門のプロセスはもちろん直接部門の多くのプロセスも、コスト削減のため「標準化」が最重要課題となります。そうした部分をいちいち定義しなくても済むように、「Oracle Application Integration Architecture」という製品も用意しており、これを使うことでその後のプロジェクトを迅速化できるような提案をしています。

――日本企業のSOA普及については、どのようにごらんになっていますか。

的場　ある調査機関によると、アジア主要国の中で、日本のSOA普及度はワーストワンとのことです。いろいろな理由が考えられますが、1つには、概念先行型で広まってきたのが要因なのではないでしょうか。

　米国の場合、1990年代にITの有効活用への戦略的な取り組みが広まり、その流れの中で「疎結合が必要」という結論に行き着きました。だからWebサービスが出てきたとき、すんなりと受け入れることができたし、SOAを実践する下地も整っていたわけです。一方、国内の場合、「失われた10年」の間、コストセンターであるIT部門の切り離しが盛んになり、経営観点からITを企画し、アーキテクチャを設計できる人材が育ちにくかったという背景があります。そこへ、SOAという新しい概念がやってきて、疎結合やWebサービスなど、用語や技術が先行してしまいました。

　SOA Insightは、確かに当社がワールドワイドで提供するサービスですが、「サービス識別を先行する」というのは日本独自の考え方です。米国と異なり、先例がほとんどない現状なので、まずユーザーの方々に「SOAはどういうものか」をきちんと理解してもらうことが重要だと考えたのです。オラクルには「Oracle Fusion Middleware」という非常に優れたSOA基盤製品群がそろっており、世界中で1万件の導入実績を誇ります。SOA Insightは、オラクルのSOA製品の真価を発揮させるためのサービスですが、私たちの使命はこのSOA Insightを通して、日本のSOAをキックオフすることだと思っています。

提供：日本オラクル株式会社
企画：アイティメディア 営業本部
制作：＠IT情報マネジメント編集部
掲載内容有効期限：2008年12月31日