SOA（サービス指向アーキテクチャ）に基づいたシステム構築も、普通のシステム構築と同じ。利用部門の業務を考えず、技術ありきで始めると、SOAのメリットである柔軟性は得られない――。BPM（ビジネス・プロセス・マネジメント）ツールの開発・販売に携わる独IDSシェアーのイェルグ・クルークマン氏は、技術論議が先行しがちなSOAについてこう分析する。（聞き手は島田 優子）
まず技術ありきではSOAを企業情報システムに取り入れるのは難しいというのが持論だ。
 |
| 写真●独IDSシェアーARISプロダクト・マーケティング・マネージャー イェルグ・クルークマン氏 |
SOAに基づいたシステムについて、技術先行の議論になっている点に疑問を感じる。世界各国のSOA関連のイベントに参加する機会が多いのだが、こういった会場では技術にかかわる議論が大半を占めている。
システム構築の第一歩は、利用部門の業務を理解することだ。システム部門にとっての「お客様」は社内の利用部門で働く社員。それを支援するのがシステム部門の役目である。
この点については、システム構築がSOAに基づいていようがそうでなかろうが差はない。SOAだからといって、Webサービスをどうオペレーションすべきか、再利用するサービスの数はどれくらいが適当なのか、といった議論から始めるのは本末転倒だろう。
SOAを実現するために、技術が占める重要性は高いはずだ。
技術について考慮すべきだと言っているのではない。まずビジネス・プロセスを分析すべきで、その後に実装を考えるべきだいうことだ。
SOAに基づいたシステムは5段階で構築する
SOAに基づいたシステムを構築する際には、いくつかのステップに従って実行することになる。
まずビジネス・プロセスを記述することだ。利用部門の業務を文書で可視化する。そして記述したビジネス・プロセスをより詳細化する。CRM（顧客情報管理）システムを利用した業務を例にすれば、「ユーザーの名前を読む」「購買履歴を確認する」といった粒度になる。
次に個々の業務について、システムで実行しているのか、担当者が手作業で処理しているのかを判断する。ここで初めて、新たに自動化したいビジネス・プロセスについて、どのシステムで提供しているサービスを利用するのかを考える。
SOAは、ここでメリットを発揮する。独SAPや米オラクルなどが提供する複数のパッケージ・ソフトを導入している企業の場合、新たなシステムを実現するために必要な機能を、各パッケージが提供するサービスから選ぶことができる。
SOAのメリットについてもう少し説明してほしい。
自社の業務に最適なソフトウエアを一から開発する手間が省けるということだ。技術者は、各パッケージが提供するサービスをどのように結びつけるかだけを考えればよくなる。Webサービスを介してサービスを連携させることで、柔軟なシステムが構築できるようになる。
最後に、連携したサービスとビジネス・プロセスを結びつける。ここで文書化しておいたプロセスを、ビジネス・プロセス実行言語「BPEL」を利用して、システムが連携しやすい形式に変換する。
業務と技術に精通した技術者の育成が急務
ビジネス・プロセスは誰が記述し、管理すべきか。
技術と業務の両方を理解している人が望ましい。我々はビジネス・プロセスの記述者を「プロセス・エンジニア」と呼んでいる。システムの全体像が分かるITアーキテクトでもなく、業務部門で業務を知りつくしているだけの人材でもダメだ。プロセス・エンジニアは、ビジネス・プロセスを見ながら「この業務は自動化した方がよい」と判断できる人材である。
だが技術と業務の両方に精通しているエンジニアは少ない。日本だけではなくドイツでも同じ状況だ。企業が積極的に社内で育成していくしか対処策はない。システム部門の担当者が業務部門を経験して、実際の業務を理解していくしかないだろう。
技術者には耳の痛い話が多い。
SOAの考え方は技術者には向いていない部分もある。技術者は何でも自分で作りたがるからだ。SOAのメリットの1つはサービスを再利用できるところだ。だが、技術者は再利用可能なサービスを探すよりも、自分の手で新しいサービスを開発してしまう傾向がある。ある企業で実際にこうした事例が発生した。
この企業は、技術者に対し報奨金を支払うことで問題を解決した。自分で新たなサービスを開発せずに、社内のシステムから再利用可能なサービスを発見した技術者を優遇することにしたのだ。
社内のサービスをきちんと管理すれば、サービスの内容が可視化できるので、とにかくサービスを開発しようという傾向はなくなるだろう。人材の問題は、SOAのメリットを生かすためには、技術だけを考えていてはうまくいかない例の1つだ。
業務と技術の双方に通じた人材を育てるのは簡単ではない。
当社の「ARIS Business Architect」のようなBPMツールは、図形を利用して記述したビジネス・プロセスをBPEL形式に変換する機能を持つ。こういったツールを利用することで、技術者を支援することができる。
ビジネス・プロセスとサービスを結びつけるうえで欠かせないのが、リポジトリだ。ビジネス・プロセスに変更があった場合、どのサービスに影響があるのかを特定する際に役立つ。当社はARISシリーズの製品として、サービスとビジネス・プロセスを管理するためのリポジトリも提供している。
