緊急提言：Webサービスの光と陰を考察する（3）

データ指向とサービス指向、そして約束の地へ

Webサービスは有望なテクノロジである。なのに、どうして普及が進まないのか。この問題はシステム開発が抱える根本的な問題から考察しなければ、満足のいく答えは見つからないだろう。この連載では3回にわたってWebサービスを成功に導くために必要な開発者の“意識改革”について提言を行ってみたい。（編集局）

株式会社ビーコンIT
岩本 幸男
2004/1/16
主な内容
データ指向とビジネスプロセス管理
　・ビジネスプロセス管理を成功させるには
　・「孤島システム」はなぜ生まれるのか
　・グローバルシステムと4つのハードル
サービス指向とシステムの可視化
　・サービス指向がもたらす本当のメリットとは
　・サービス指向はシステム設計を変える
システム構築におけるガバナンス
グローバルシステム実現へのアプローチ

　Webサービスの普及に何が必要かを考える本連載も、今回が最終回である。第1回「Webサービスを阻害するシステム開発の旧弊を絶つ」ではWebサービスを阻害する要因、第2回「データ標準化から目をそらす守旧派の罪と罰」ではデータ標準化について議論を展開してきた。最終回となる本稿では、データ指向とサービス指向を活用した標準部品化アプローチについて考察し、連載の締めくくりとしたい。


　

データ指向とビジネスプロセス管理

　部品化は、データ指向が基本となる考え方である。データ指向とサービス指向の組み合わせにより、システム構築における部品（サービス）供給を産業化しなければならない。

　第1回で述べた自動車産業では、組み立てラインを持つ本社工場を中心に、周辺には標準部品を供給する関連会社がまとまって産業を構成しているが、その外側には金型・鋳型工場がある。ソフトウェア産業では、ビジネスプロセスを管理する本社システムを中心に、関連会社がそれぞれの業務機能をSOA（サービス指向アーキテクチャ）としてサービスを提供し、そのサービスで利用されるデータ項目は、金型・鋳型のように標準化され一元管理されるというような、グループ企業にまたがる水平横断グローバルシステムを構成する必要がある。

　図1　自動車産業を手本としたソフトウェア産業の未来像

　このような情報基盤の上にビジネスが展開されれば、ビジネス環境の変化に合わせてプロセスを変更する、またサービスを変更することが簡単にできるようになる。

ビジネスプロセス管理を成功させるには

　コミュニケーションの基本はプロセスではなく、データである。なぜならば、コミュニケーションをつかさどるインターフェイスとはデータの加工だからである。先述のとおりビジネスプロセスの変更があっても、ERPの導入があっても、基幹業務の再構築があっても、データの論理構造に変化はない。このようなイベントでの最大の作業はデータの移行であって、物理的な箱の入れ替えにすぎない。

　そもそも、ホワイトカラーの仕事とは、データを情報へと加工しているだけである。加工された情報は、次のシステムの入力、つまりデータとなる。この繰り返しがほとんどではなかろうか。はじめから、データ中心のアプローチをしていれば、無駄な仕事はなくなる。

　環境が変化しても、データは変化しない。変わるのはプロセスだ。そのためには、データ、機能、プロセスを分離した基盤が大切である。特に論理的なデータはほとんど変化しない。変化があるとすれば、規制緩和の波に乗り、まったくの新規事業に参入するとき、例えばコンビニが金融事業に参入するようなケースぐらいである。

　Webサービスを企業内のデータ統合プラットフォームとして検討するケースがある。古くから使われてきたメインフレームと、最近構築されたERPシステムやWebシステムなどは、連携して使うことが困難になっている。これらを全体最適システムにするためには、データに関して共通認識を持ち、「疑似的な統合」ができるような、つまり個別に管理しているローカルコードからグローバルコードへの変換プラットフォームを用意すればよい。

　このようなケースではEAIツールを導入し、データ統合を図るケースも多いが、ソリューションとして不十分である。各プラットフォームに構築済みのシステムは、プロセスの一部が機能に組み込まれてしまっている。部品化のためには、これまでアプリケーションプロセスの中に隠ぺいされてきたビジネスプロセスを、明確に分離させ、別に管理することが必要である。

「孤島システム」はなぜ生まれるのか

　データ項目の標準化がシステム間のインターフェイスの標準化につながるということを第2回で述べたが、コミュニケーションでは、主体の意識する対象物の「粒度の違い」や「見る角度」そして「所属するドメイン」などによりさまざまなギャップが生じる。設計、製造、営業、経理など職場ごとに、データのとらえ方が異なり、さまざまな偏見を生む。このギャップの生まれる部分を、「インターフェイス」と呼んでいる。標準化とはこの調整である。

　多くのシステムでは、このインターフェイスが貧弱または硬直化しており、個々のシステムが孤島化している。「孤島システム」とは、その名のとおり、周辺システムから完全に取り残されてしまったシステムを意味しており、業務ごとに現場主導で構築されたシステムは、この孤島システムになる確率が高い。

　コンピュータ機器の低価格化に伴い、各業務現場へと浸透したコンピュータは、エンドユーザー・コンピューティングとして活用が進んでいる。しかし、このコンピュータ資源の分散は、システム全体から見ると、最適化という面ではマイナスである。それぞれの利用部門による各部門業務の部分最適化のためのシステムは、縦割り組織ともあいまって、周辺システムや基幹システムとの連携が難しく、また独自技術の採用により全体最適化の流れを阻んでいることさえある。

　野放しシステムでは、部門ごとにさまざまなマスタ類が作られ、独自のコードが振られてしまい、特定の顧客に対し部門を超えたサービスを提供しようと思っても実行に移せない状態になっている。これをグローバル企業の観点でとらえると、現地法人主導で構築された、現地用に最適化されたシステムが、グローバルレベルで孤島システムとなってしまっている。

　このような孤島システムの乱立する全体システムの中で、企業経営のスピード化やグローバル化を目指す経営者は、さまざまな経営判断を下すために、「いまこの瞬間」を示す新鮮な連結データを必要としている。そして、その経営をサポートする財務担当者はリアルタイムなキャッシュフローの把握をしたがっている。ビジネス戦略遂行のためにシステムがあるにもかかわらず、孤島システム集団から得られるデータは、ビジネスのスピードについていけなくなっている。このような経営課題を解決しようとするのであれば、孤島システムをつないで、単一／部分最適化から全体最適化を考え、グローバルSCM、グローバルCRMなどの構築が必要となるのは自然な流れである。

グローバルシステムと4つのハードル

　しかし、現実にはこのグローバルシステムを構築し、効果的に運用できている企業は数えるほどである。なぜか。全体最適化をするためには、絶対に避けては通れない大きなハードルが4つある。これを知らずに、または安易に考えてしまうと悲惨な結末が待っている。

　孤島システムの拡大は、基盤設計上の問題として見ると、機能とデータ間の密結合実装により、大規模な広域データが再利用できなくなったためである。「One Fact in One Place」がデータ管理における基本であるにもかかわらず、広域データが利用できないために、システムごとに似通った冗長データが増大し、システム間の連携がますます複雑化するという悲惨な結果をもたらしている。

　さて、以下に全体最適化における4つのハードルをまとめておこう。

【インターフェイス】

　複雑にスパゲティのように絡み合いながら密結合したシステムを解きほぐし、機能を整理した後、サービス化して疎結合へと基盤を変えなければならない。またサービス同士を直接呼び出すのではなく、各サービスをプロセス制御のための「バス」へ、プラグインするような構造変更が要求される。

　このバス型構造により機能追加に伴うシステム間インターフェイスの爆発的増加を防ぐことができる。そしてこれは、機能とプロセスを分離するという作業において最も重要なことである。機能にプロセスが含まれてしまうと、ビジネスプロセスが変更されるたびにシステム全体の見直しが必要となり、臨機応変なシステムとはほど遠いものが作られてしまうことになる。

　図2　バス型構造によるソリューション

　プロセスを管理するバスと、個々のサービス機能間のインターフェイス設計が上手に標準化できれば、この問題は解決する。SCMを例に挙げると、購買・製造・販売・社外BtoBの各システムは、メッセージと業務プロセスを制御するバスへプラグインするようなデザインになる。この場合、例えば販売システムに変更があっても、ほかのシステムは変更不要である。

【コードとマスタ】

　機能をデータから独立した形で設計することは難しいが、データは機能から独立させて、単独で設計することができる。通常のプロジェクトでは、機能に合わせてデータを定義するので、特定機能に依存したデータ定義となってしまう。このため機能ごとに似通ったデータ定義が複数必要となり、システム間連携が複雑化する。これがまさに現在のシステム統合における問題である。

　データを機能とは独立して定義し、データの標準化、共通化がなされた広域データ基盤の上に機能を実装すれば、機能変更の要求に対しても容易に対処可能である。その結果、主マスタは「外だし」構成となる。ただし物理的な構成やパフォーマンスの問題、実装するERPツールの制約などにより、マスタの差分またはコピーをローカルシステムに持つこともある。理想は「One Fact in One Place」であり、マスタの2重管理はだれも望んではいない。

【クレンジング】

　マスタの統合にチャレンジすると、いきなりとんでもない事態に遭遇する。顧客マスタでは、お得意さまである「ABC商事」が、株式会社ABC商事、（株）ABC商事、エービーシー商事、ＡＢＣ商事……と、多分、同じ会社であるにもかかわらず、名寄せができないのである。機械的にできないのであれば、人間が数千、数万に及ぶ顧客マスタの整理を行うことになる。同様に顧客マスタの住所欄に至っては、もっと悲惨な状況が待っていることは容易に想像できよう。企業合弁による、最も重要で緊急を要する顧客の囲い込みのためのグローバルCRMは、クレンジング作業なしでは構築できない。

【維持】

　クレンジング作業でキレイになった顧客マスタや商品マスタは、野放しにすると2年でクレンジング前と同じ状態に戻ってしまう。せっかくキレイにしたマスタを維持するためには、データの登録変更に関し、ワークフローなどを活用した運用ルールの策定が必須である。

　システム統合やグローバルシステムの構築とは、プロセス統合とデータ統合を行うことである。プロセス統合は、的確な業務分析が行えれば、比較的問題なく行えるが、ビジネスルールの変更を強いるため、政治的な困難さがある。一方、データ統合は、前述した4つのポイントにあるとおり、困難で泥臭く面倒な終わることのない作業の連続であり、維持・継続が難しい。


　

サービス指向とシステムの可視化

　経営とは、企業の現状を正確に「観る」ことから始まるのであれば、グローバルシステムの目指す目標は「観える化」システムの構築にある。これが、グローバルSCMであるならば、最も重要なことは在庫の可視化ということになるであろう。バランスシートの棚卸資産として計上される部分の多くは、在庫と称されるものであるが、製品を作成するための部品在庫や原料在庫であったり、製造途中の仕掛在庫であったり、製品在庫でも、積送品、新品、中古品、展示品、貸し出し中……とさまざまな状態で存在している。

　これらの在庫が状態ごとにリアルタイムに「観える化」することが重要である。これは、各地の生産システムを、Webサービス技術によって連携し、グループ全体を「1つの仮想工場」として扱うことによって実現できる。そして在庫の圧縮はリードタイムの圧縮を導き、生産計画の単純化と正確化に最大限の効果を発揮する。これにより、工場、卸、販売店など、至るところに滞留する在庫を、世界中でリアルタイムに管理できるようになる。

サービス指向がもたらす本当のメリットとは

　サービス指向には技術的に次のような特徴がある。

【オンデマンドなダイナミック結合】

　サービス指向では、実際にサービスを利用するまで、そのサービスが「どこにあるのか」「どんなフォーマットのメッセージを使って利用するのか」「どんな通信プロトコルを使ってメッセージをやりとりするのか」などの情報を知る必要がない。サービスを利用したいときにダイナミックにサービスの場所や接続方法を取得することができる。一般的なEAIツールによる連携では、あらかじめインターフェイスの確定が必要であり、融通性に欠ける。

【環境に依存しない】

　既存の分散システム連携技術は、特定のプラットフォームや、言語、あるいはミドルウェアに依存しており相互運用が困難である。サービス指向では実装について何ら前提を置かない。つまり、トランスポートはHTTP、FTP、SMTPなどの標準的なものが使え、言語はJava、C#、オブジェクトモデルはCOM、CORBA、OSはUNIX、メインフレーム、Windowsなど何を使用してもよく、異種プラットフォーム間での相互運用性が高い。

【疎結合】

　また、既存の連携技術によるシステムが互いに強く結合されている（密結合）のに対し、サービス指向では緩く結合される（疎結合）。その結果、サービス指向では互いのサービスの独立性が高く、変更が容易であり再利用性が高くなる。既存システム、あるいはそれらが提供するサービスを、上手に組み合わせてIT資産を再活用し、顧客に対し新たなサービスを提供する基盤が「サービス指向」であり「Webサービス」である。外界の変化に臨機応変に適応可能なシステムであれば、システム変更に際し再投資を抑えることができる。

サービス指向はシステム設計を変える

　サービス指向において、サービスの粒度を決めることは非常に難しい。サービスとはそれ自身で独立して機能するぐらいの塊と考える。例えば、顧客情報サービス、在庫検索サービス、商品検索サービス、座席予約サービス、この程度である。あまり粒度を大きくすると再利用ができなくなるので注意が必要である。数回のやりとりで結果がもらえる程度と理解するのがよい。顧客情報サービスであれば、単に顧客コードや顧客名などのマスタ情報を提供するだけではなく、「顧客情報を追加する」「顧客情報を更新する」というようなデータに対する処理も含めたサービスとして共有化すべきである。

　データと処理をカプセル化し隠ぺいするという点ではオブジェクト指向と同じであるが、サービス指向ではその粒度が大きくなり、かつサービスが人間的なインターフェイスを持つことが特徴となる。個々のシステムごとに実装されていた処理を共通のサービスとして「外だし」にすることで開発生産性の向上と保守工数の改善につながり、さらには顧客マスタの一元管理が可能になる。将来、顧客情報サービスの実装プラットフォームや、物理データベースの構造が変更されても、ほかのシステムにはまったく影響を及ぼさないシステムが構築できる。

　もちろん、数百のシステムから利用されるサービスであっても、テストは1回限りでよく、複数システムの変更時にありがちな「ぬけ」が発生する余地もない。つまり外界の変化に追随してシステムの変更要求が発生しても、その変更個所を局所化し、その結果素早い対応が取れるのである。

　サービス化はそもそも個々の最適化より、システム全体としての最適化が目的であり、必ずしも開発段階での効率化に焦点を当てるものではない。いかにサービスの独立性を高め、汎用性を持たせるかという意味ではむしろ設計段階に従来以上の工数が必要となる。にもかかわらず、サービス化が重要である理由は、保守作業軽減のためである。企業を取り巻く環境変化が激しく、また複雑化する昨今、システムは変更可能であることが最も重要となる。そのとき、サービス指向のメリットが本当の意味で理解されることであろう。


　

システム構築におけるガバナンス

　コミュニケーションの問題点を述べてきたが、問題のほとんどは上流で関与する人間や組織の問題である。情報システム部門は、経営戦略部門と密接に関係した組織構造になっている必要があり、グローバルなシステム戦略立案を行えなければならない。事業部門の下請けになっているようでは、話にならない。

　しかし、景気低迷によるIT予算の削減は情報システム部門を弱体化させ、自社のみで巨大で複雑なシステムの構築・運用・維持管理ができなくなってしまっている。アウトソーシングされてしまった環境の下で、理想のシステムを夢見ても実現はかなり難しいのかもしれない。情報システム部門の復権を願うとともに、部品化の重要性を理解した有能なモデラーが、多くの問題を抱える現状システムを救ってくれることを切に願うものである。

　本稿で述べてきたグローバルシステムではシステムの面以上にガバナンス、つまり「統制」が成功の鍵をにぎる。コミュニケーションの言葉、手順をはじめとするルールは、統制された組織の範囲内でしか有効にならない。また、つなぐ側は「観える化」というメリットを享受できるが、つながれる側にメリットを説明することは難しく、統制の効かない相手に強要することができない。この場合、コンソーシアムなどに統制権限を委譲し、より大きな組織間でのコミュニケーションを模索することになる。


　

グローバルシステム実現へのアプローチ

　欧米でのWebサービス状況は、日本とはかなり異なるようである。WebサービスをベースとしたSOAでのサービス部品の組み合わせによるシステム構築が展開され始めている。

　米国Zapthink社やFactPoint社のレポートでも大手企業を中心に多くの事例が紹介されている。特にZapthink社のService-Oriented Architecture Consulting / Facilitating The Service-Oriented Enterprise（Doc. ID: ZTR-WS109 Released: May 22, 2003）にはビーコンITが日本の大手製造業で実装したWebサービスによるグローバル在庫管理システムがレポートされている。まだROIという点では保守の始まるこれからの効果を見守る必要があるが、サービスの部品化という面では活用が進んでいる。

　しかしオブジェクト指向の発達した米国においては、データと機能をセットで隠ぺいしている場合が多く、本稿の論点であるデータ項目に注目した部品化は行われていないようである。オブジェクト間でのインターフェイス標準化を行っているわけである。この場合、オブジェクト内部でのデータ管理が表に出ないため、「One Fact in One Place」がイメージしにくいと思われる。

　また、Webサービス活用の新たな潮流として、ポータル機能への適応が挙げられる。Webサービスが当初もくろんでいた、アプリケーション層での連携は本稿でも述べているとおり、かなり困難な状況である。しかしポータルのようなプレゼンテーション層での連携は単純な集約で実現可能な場合が多く、適応しやすいのであろう。また、Jakarta JetSpeedプロジェクトの活動がこの潮流を後押ししている。このポータル機能を実現するための規格WSRP（Web Services for Remote Portlets）やJSR-168が標準として策定されている。

　また、Webサービスの相互運用性を向上させる目的で設立されたWS-Iから、2003年8月に相互運用のガイドラインBasic Profile 1.0aが公開された。さらに相互運用ガイドラインへの適合性を検証するテストツールも併せてWS-Iから提供されているので活用することを勧める。日本語での解説も公開されているので参考にしていただきたい。

☆ ☆ ☆

　人も機械も、インターフェイスの標準化は近い将来可能になるだろう。そのときには、人と機械が一体となることができる。人は夢を大きくするためにコミュニケーションを取ろうとするのかもしれない。「Webサービスする」という言葉を、一刻も早くちまたで耳にしたいものである。

　Webサービスを有効に活用し、システム間のコミュニケーション・ギャップを埋めるために、データの管理、活用そして統合について真剣に考え、経営に貢献すべく活用を待っているデータを知識や知恵に変え、アクションを起こしていただきたい。（完）

-- Empower Your Data --
（Yukio Iwamoto）

 

■バックナンバー

　　1. Webサービスを阻害するシステム開発の旧弊を絶つ
　　2. データ標準化から目をそらす守旧派の罪と罰
　　3. データ指向とサービス指向、そして約束の地へ

緊急提言：Webサービスの光と陰を考察する


XML & SOA フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

HTML5＋UX 記事ランキング

本日月間
＠IT