SOA/BPMの現場から - 日本のお客様事例 -

第1回 SOAと４つのソリューションパターンとその効果

目次

• 序文
• SOAと4つのソリューションと実際のメリット
• SOAにより得られた効果
• まとめ

序文

自己紹介

日本オラクルのTechnology Architectコンサルティング部SOA/BPMチームという部署に所属しています。
私たちのチームでは1人当たり年間数件から10件程度、SOAやBPMに関連する製品を使ったお客様のシステム開発のプロジェクトに参画しています。

コンサルティング部という部署名ではありますが、上流工程だけではなく、SOA/BPMといった領域で実際にシステム設計／開発を行っています。本稿はOracle Direct Seminarで行ったセミナー「SOA最前線！！現場コンサルタントが語るSOA開発の本当のトコロ」を加筆したものであり、これまでの私の所属するSOA/BPMチームでの実績と経験から、SOAを適用したシステム開発の現場について書いておりますので、偏りがあるかも知れませんがご了承下さい。

SOAは死んだのか？

2009年の年明けは、"SOA is Dead; Long Live Services" （注）（SOAは死んだ。サービスは永遠に。）でSOA関係のブログは盛り上がりました。確かに一時期のSOAブームは去り、SOAという言葉は、バズワードの代表の様になっています。

皆さんの中にも、キーワードは良く聞くものの、実際にSOAが使われている現場はあるのか、ちゃんと効果はでているのか、と疑問をもたれている方は多いのではないでしょうか。

私は４年ほど前から、SOA技術者としてお客様のプロジェクトに参加させていただいていますが、３年前と現在のプロジェクトを比較してみて、次のようなことに気がつきました。

• 3年前
  SOAの検証プロジェクト、SOAの標準化策定を始めるお客様が多かった。
  いわゆる「SOAをやってみよう／試してみよう」というプロジェクトですね
• 現在
  「SOAやろうぜ！」もしくは「SOAでなんとかするんだ」というSOA自体を目的とするお客様は少なくなってきている

では、SOAはもう終わったのかというと、私はそうではないと考えています。

最近のプロジェクト現場での傾向

以前のようにSOAの標準化プロジェクト、全社SOAプロジェクトといったものも一定数ありますが、３年前と比較しても、顕著に増えているという印象はありません。これは、全社を挙げてSOAに取り組もうというトップの意思があり、そのような体制を取れる企業ばかりではないということかも知れません。

一方、ここ１、２年で特徴的なのは、生産管理や契約処理のような一般的なシステム開発のなかにSOAの考え方が入っているケースが多くなってきているということです。

例えば、次のようなSOAの考え方はSOA以前からも存在していたと思います。

• 標準的でオープンなインターフェイスを採用しよう
• お互いのシステムを疎な関係で連携させ、一方の変更が他方にあたえる影響が小さくなるように設計しよう

しかし、納期、コスト、設計者の経験、既存システム等の要因により、実践できていない、またはそのような考え方があることも知らなかったというシステム開発の現場も数多くあったでしょう。それが、近年のSOAの認知度の向上により、より多くのシステム開発の場でSOAの考え方が取り入れられたと考えます。

SOAは死んだのか？に対する私の意見は、「SOAというキーワードは終わったのかも知れません。しかし、Service Oriented Architectureという設計の考え方は実際システム開発の現場で使われている」ということです。

それでは、実際にどのようなプロジェクトでSOAの考え方を取り入れ、どのような効果があったのかを次の章から見て行きたいと思います。

▲ ページTOPに戻る

SOAと4つのソリューションと実際のメリット

どのような案件が多いか

これまで私たちのチームが参画したプロジェクトは様々な要件、機能を持ちますが、パターンに分類して、それぞれを考察してみたいと思います。

多くのプロジェクトは次の４つの要素を持つことが多く、パターンの概要はこのようになります。

1. システムフローパターン
   

   複数のシステムが連携し合いながら、一連の業務処理を進めるフロー型のシステム連携です。

2. ヒューマンワークフローパターン
   

   システムフローパターンと似ていますが、フローの途中に人による判断・入力などを含みながら、業務処理を進めるワークフローです。
   一般的にワークフローツールといわれるソフトウェアと似ていますが、フローの進捗に合わせて基幹システムなどと連携する点が異なります。

3. メッセージ連携基盤
   

   システム間をメッセージによって連携を行う基盤、いわゆるEnterprise Service Bus（ESB）といえるパターンです。

4. 画面統合
   

   ここでの画面統合とは、複数のシステムのユーザーインターフェースを１つの画面に張り合わせたものではなく、複数のデータベース、Webサービスなどのデータソースから取得した情報を統合して画面を作成したり、その逆に、ある画面からの変更、更新などの操作を複数のデータソースへ反映させたりするようなことを指しています。

次に、それぞれのパターンを持つシステムにおいて、お客様がどのような課題を解決したかったのか、活用した技術要素、システムを構築する上での注意点の３つを実際の事例で見て行きたいと思います。

システムフローパターン

この事例は、公共のお客様が顧客の受付業務をワークフロー化したシステムです。

お客様の課題

• 利用者が複数のシステムにて同じような登録処理を行っているのを解消したい
• 複数のサブシステム間にまたがる処理をプロセスとして定義し、各処理の実行制御を自動化したい
• 法改正に伴う業務プロセスの修正を柔軟に行いたい

これらの課題に対して、BPEL （注）を用いて、受付から各種個別のシステムと連携を行いながら業務処理を進めることで、利用者の登録は受付時のみで、その他の作業を自動化することができました。
また、業務プロセスとロジックを分離したことにより、業務プロセスの変更が容易になりました。ただし、サービスの呼び出しの前提となる処理があったり、データモデルの変更のような大きな変更を伴ったりする場合は、やはり注意が必要です。

技術要素

• BPELによるプロセス定義
• ESBによる個別システムとの連携

設計する上での重要な考慮点

業務プロセスからサービスを定められた順番で呼び出していくため、設計時に処理の順序保証、並行処理が可能かなど、プロセス内での各サービス実行の特性を考慮する必要があります。
これに関連しますが、複数の業務プロセスから利用できるようにするためのサービスを切り出したり、商品ごとに微妙に異なるプロセスを統合したりするなどの業務プロセスの分析を行うことも重要となります。

また、このようなフローを内包するようなシステムでは、一般的にWebアプリケーションと比較すると、１つの業務プロセスが実行され始めてから完了するまでが長期間になります。そのため、業務時間外に業務プロセスの変更を実施する場合でも、古いプロセス定義で実行中のものが大量にあるという状況が有り得、次のようなポイントを要件検討のタイミングから考慮しておく必要があります。

• プロセス定義のバージョンアップはどの業務処理から対象とするか
• 複数のプロセス定義を並行で稼動させる必要があるか
• 途中で障害が発生した場合の、異常系のフローと運用の検討（途中キャンセル、再処理など）

ヒューマンワークフローパターン

２つめの事例は、全国に支店を持つ金融業のお客様におけるワークフローのシステムです。

お客様の課題

• 支社ごとに業務プロセスが異なり、作業者の習熟度に依存している
• 紙の書類で業務が回っており、紙・人の移動によるボトルネックを排除したい
• どこで業務の滞留が発生しているのかを知りたい

このシステムでは、システムフローと人間系の承認フローを組み合わせたヒューマンワークフローをプロセスとして定義し、順序性を管理することで業務の人／支店ごとの独自ルールから全社で統制の取れた業務プロセスへと業務改革が行われました。特に、あるべき業務プロセスを検討し、業務のやり方を変えるための道具としてこのシステムが構築されたところに意味がありました。

また、ワークフローを導入することで、タスクがシステム上で管理され、紙書類の移動によるボトルネック解消と、滞留がどこで、どのくらい発生しているのかを可視化することができました。

技術要素

• EPC、BPMNによる業務プロセス定義 （注）
• BPELによるプロセス定義（EPC/BPMNからBPELへの変換・同期）
• ESBによる個別システムとの連携

設計する上での重要な考慮点

人間系の業務をシステム化する場合、案件の承認、回付に関するルールや要件（多段階承認、差し戻し、職制情報との連係など）を十分に分析し、明確化する必要があります。これはシステム構築時のみではなく、運用後の人事異動、部署の新設/廃止も含めて事前に検討しておかないと、業務の変化にシステムがついていけないということにもなりかねません。

また、現状の業務をそのままシステム化するのではなく、手順や規定などの業務プロセスの見直しと、システム化の両方を検討することが重要です。

これらに加えて、業務の順序性、業務が開始されてから終了するまでの時間が長い点はシステムフローと同様ですので、検討しておく必要があります。

メッセージ連携基盤

３つめの事例ですが、多くのグループ会社からなる交通・サービス業のお客様におけるメッセージ連携のシステムです。グループごとにシステムが存在するため、非常に連携する対象が多く、各システムが使用するＩＤ、コード値なども統一されていないというところがポイントでした。
Ｍ＆Ａ、決算の早期化などの要因により、それまでのシステム構築、運用の文化が異なるシステム同士がリアルタイムに近い形で連携しなければならないケースは、どの企業にでも発生し得るといえるでしょう。

お客様の課題

• 複数システム間でのデータ連携において、共通連携基盤を経由させることで個別開発を極小化し、開発の工数を軽減する
• EAIツールをリプレースし、ベンダ固有技術から標準技術への変更および保守費用を軽減する
• ファイルやDB出力のみなど、制約のある既存システムにアダプタを適用して、共通連携基盤に取り込む

技術要素

• ESBによる連携基盤の構築
• 既存システムに対する、各種アダプタ―サービスを利用してのサービス化

設計する上での重要な考慮点

このようなメッセージ連携では、連携本数がかなり多くなる傾向があります。そのため、次の２点を考慮しながら共通化を進めることで、開発生産性、メンテナンス性を高めることが重要です。

• 連携基盤で流通させるデータのデータ設計（各サブシステム固有ではなく、共通化を進める）
• データの変換要件の整理（レイアウトの変換、コード値の変換など）と、変換の実装方式の選択

また、仕分け情報や生産管理の情報の中には、メッセージの順序性が大きな意味を持つものがあります。順序性の保証は一般的にスループットの低下を伴いますので、プロジェクトの早期で確認を行う必要があります。

次にデータのサイズですが、開発生産性が高いからといって、画像、データのレプリケーションのような情報をメッセージ連携基盤上に流すことの必要性が本当にあるのかは、十分検討してみて下さい。私は、メッセージ連携基盤はメッセージを配布するためのもので、データを受け渡しするためのものではないと考えています。逆にそれが発注情報のようなメッセージであれば、実態はファイルやデータベースのレコードであっても、メッセージ連携基盤を介して他のシステムに連携されるべきだと思っています。

大きなデータはOracle Data IntegratorのようなWebサービスのインターフェイスを持つETLツールを業務プロセスの中から呼び出すことによる連携や、ファイルをシステム間で共有してアクセスできる場所に配置し、その場所・URLをメッセージとして連携することで解決可能です。

画面統合

お客様の課題

• オンライン画面を使った業務処理に対してそれぞれビジネスロジックを関連付けてサービス化し、画面処理の柔軟な変更やユーザ毎のカスタマイズを可能とする
• 画面部品を提供し、コーディングレスの画面開発で開発効率を高めたい

技術要素

• Oracle BPEL Process Manager /ESBによる画面からの要求とビジネスロジックとの関連付け
• 非同期でのリクエスト/レスポンスに対応する画面（Ajax などの活用）

設計する上での重要な考慮点

画面アプリケーションから利用効率性を考えると、画面からの処理要求の粒度を考慮した、ビジネスロジックのサービスとしての切り出しが必要となります。

また、画面統合パターンは他のパターンと異なり、参照系の画面も対象とするため、高トランザクションと高レスポンスを求められます。
そのため、使用するプロトコル、ひとつの画面を表示するためのデータ取得を並行処理する、画面アプリケーションでサービスとの連携を処理の内容も考慮しながら同期／非同期処理の選択などの方式を検討する必要があります。

▲ ページTOPに戻る

SOAにより得られた効果

これまでの４つのパターンを実装するのに、SOAの考え方はなくとも構築はできます。ここでは、SOAの考え方を取り入れることでどのような効果があったのかという点を見て行きたいと思います。

業務プロセスの可視化と制御

システムフローパターンとヒューマンワークフローパターンの事例では、BPELという言語を使用して業務上の条件分岐、例外業務も含めて複数の部門をまたがる業務プロセスを定義しました。これにより、業務プロセスを可視化することができました。

これまでシステム連携の進化の過程においては、バッチ的な連携方式から、MQ、JMSなどのメッセージング基盤による連携方式が採用されるようになり、リアルタイム性向上、メッセージ保証やルーティングの機能が基盤として用意されるようになりました。
ところが、メッセージング基盤の連携というのは基本的に、ある地点から別の地点へ１対１または１対Nの関係でメッセージを連携するためのものなので、全体の業務フローの流れを定義することはできませんでした。
そのため、この承認が却下された場合はどこに戻るのか、この業務の後はどの業務を行うのか、といったことはキューからメッセージを取得するルールと、メッセージを取得してからのプログラムのソースコードに隠蔽されてきました。

BPELは、このような業務フローを定義するために元々作られた言語であり、BPMNなどの業務フローを記述する仕様とのマッピングがある程度事前に考えられていたり、BPELで記述されたプロセスをビジュアル的に表すツール類が各社から用意されているという特徴があります。

業務フローの改善、効果の評価を繰り返すBPMプロジェクトは、実行可能なプロセスを定義できるBPELと相性が良く、効果が出やすいといえるでしょう。

業務プロセスの個別システムI/Fからの開放

同じくシステムフローパターンと、ヒューマンワークフローパターンで紹介したプロジェクトでは、アーキテクチャにESBを採用することで、業務プロセスの実装は個別システムごとのプロトコルを意識させない構成を採りました。この事例ではBPELで実装した業務プロセスは個別システムのOS、実行基盤、プロトコルが何であろうと、WebサービスまたはJMSのインターフェイスのみを対象として連携すればよく、結果として開発コスト、運用コストを下げるメリットがありました。

ワークフローは複数の部門をまたがって行われるケースが多いため、必然的に各部署に存在する様々な基幹システム、データベースなどのデータソースと連携する必要があります。

また、既存システムは定期的な改修、リプレースが行われることが想定されていたため、今後、既存システムに改修がある度に、このコストメリットが得られます。

サービス横断の機能提供による関心の分離

ESBを適用した構成では、システム間の連携がESBを介して行われます。そのため、次のような運用系制御をESBが提供することで個別システムがそれぞれに実装する必要がなく、開発工数の圧縮と、個別システムの開発チームに依存しない品質を保つことがメリットとして得られました。

1. 個別システムごとに異なる運用時間をESBにおいて一元的にオンライン／オフライン管理する
2. 段階的リリースなどにおいて、生産拠点、支店ごとに同じサービスを利用するが使用するバージョンが異なるといった場合に、サービス呼び出し側の属性を使用して適切なサービスにルーティングする

▲ ページTOPに戻る

まとめ

ここまで読んでいただいたように、これらの４つのパターンを含むシステムでは、SOAの考え方を採用することでメリットを得やすいと考えています。
実際のシステムは、これらの４つに属するということではなく、これらのパターンを要素として持っている可能性があるということです。例えば、システムフローとメッセージ連携のパターンを含むシステムという組み合わせは大いに有り得ます。

最後に、SOAプロジェクトのポイントをおさらいしたいと思います。

1. SOAというキーワードだけが需要を喚起する時期は終わったかも知れないが、SOAは設計の考え方として有効である
2. SOAを目的ではなく、普通のシステムを構築するにあたっての手段として使いましょう
   BPEL、Webサービスなど、SOAの中で新たに取り入れられた技術を検証する時期はもう終わり、必要以上に小さく始める必要もないですし、必ずしも全社で始めなくとも得られる効果は十分にあります。
3. SOAで何を実現したいのかを明確にしましょう
   SOAという言葉に含まれる範囲は現実のシステム開発に適用するには、あまりに広く、プロジェクトメンバー、関係者の中でもSOAをやろうといわれたときに考えることはまちまちです。

SOAとは特別なシステムのためにあるものではなく、今、皆様が関わっているプロジェクトにも有効でありそうということがお分かりいただけたでしょうか。

製品／技術情報

• Oracle BPEL Process Manager
  BPELプロセス実行エンジン。
• Oracle JDeveloper
  Java言語の統合開発環境に加えて、BPELをビジュアル的に設計、実装が可能。
• Oracle Business Process Analysis Suite
  EPC、BPMNを始めとするモデリングソフトウェア。

▲ ページTOPに戻る

"SOA/BPMの現場から - 日本のお客様事例 -" インデックスに戻る

十川　亮平(そごう りょうへい)
日本オラクルにて、SOA関連のコンサルタントとして
日々、お客様のプロジェクトに参画。