緊急提言：Webサービスの光と陰を考察する（2）
データ標準化から目をそらす守旧派の罪と罰
Webサービスは有望なテクノロジである。なのに、どうして普及が進まないのか。この問題はシステム開発が抱える根本的な問題から考察しなければ、満足のいく答えは見つからないだろう。この連載では3回にわたってWebサービスを成功に導くために必要な開発者の“意識改革”について提言を行ってみたい。（編集局） |
株式会社ビーコンIT
岩本 幸男
2003/12/13
前回の「Webサービスを阻害するシステム開発の旧弊を絶つ」では、Webサービスの普及を阻害する要因として、現状のシステム開発に堆積する多くの問題点を指摘した。第2回の本稿では、問題点の切り分けをさらに進め、“標準化”の重要性について議論を深めてみたい。また、Webサービスの目指す究極の姿であるサービス指向アーキテクチャ（SOA）と、そこへ到達するために解決するべき問題点も提言してみよう。
 |
前回で指摘したように、現行システムがある意味で悲惨な状況のため、さまざまな課題や問題が噴出している。特に、ビジネスサイドから出される緊急を要するものが多い。「モノ作り」日本の製造業を見たとき、現在抱えるビジネスの課題といえば、以下の3点に集約されるのではなかろうか。
- 連結経営の強化
- IT活用によるスピード経営
- グローバリゼーション
そして、これらの経営課題を遂行するための施策として、企業は下記のような取り組みを行っているだろう。
- 調達の効率化（一括調達、最適地調達）
- 計画サイクルの短縮、リードタイム短縮
- 在庫削減、スループットの向上（最適地生産）
- グローバルSCMの構築と効率運用
- 連結グローバルでの固定費最適化
- キャッシュフローの改善
しかし、実際に経営課題を解決すべく、最適なシステムが構築されている企業はまれである。現行システムの状況が理解できたいま、理由は明白である。上記の経営課題を解決するためには、局所最適化、単一最適化のアプローチでは無理なのである。グローバルレベルでの標準化が成功のための必須条件であることは明らかだが、IT部門には過去にそのようなシステムを構築した経験がないうえに、横割りシステム基盤の構築技術を新たに習得する必要がある。実際に噴出している問題を考察してみよう。
世の潮流に乗り、全社（システム）横断的なデータウェアハウスを構築するというプロジェクトにあちこちで遭遇する。データウェアハウス構築ツールを購入し、在庫数量の把握、在庫回転率の分析、リードタイムの短縮、予算計画などに活用しようというビジネスサイドからの要求である。ところが、ツールは調達したが活用できていない、以前は活用していたが活用しなくなった、というユーザー企業が多い。データの標準化ができていなかったため、分析するために集めたデータの品質が悪く、使いものにならないのである。
またビジネスニーズによる組織変更にシステムが追従できずに、実際の組織とデータの内容に矛盾が生じているケースも多い。この場合、数年後にはシステムから出てくる数字が信頼できなくなり、使われないシステムとなってしまう。すべてはデータの標準化、つまりはコードの統一ができていないことによってもたらされる弊害である。
製品コードを取ってみても、グループ各社で異なるコードが振られていることなど、ごく普通のことであり、社内でも、設計、製造、流通、販売でそれぞれコードが異なることがある。これらは、もともと各システムが業務ごとに作られ、その業務で最適に管理できるように製品にコードが振られたためである。
特にグローバルシステムにおける問題は、既存システムによって個々に管理されるコードの意味の不統一ある。例えば、在庫といっても、それぞれのシステムで示す内容が異なる。購買システムでは [購買場所コードと購買品コード] によって [在庫数] を示しているが、製造システムでは [工場コードと製造品コード] で示され、販売システムでは [部門コードと商品コード] で示される。また社外向けには [業界統一場所コードと業界統一品コード] によって示され、管理はバラバラである。在庫を管理するといっても簡単ではない。
 |
| 図1 企業内に混在するさまざまなコード |
そもそも、このような状況はコード体系に問題がある場合が多い。購買品コード、製造品コード、商品コードなど、役割によってコード化してはならない。これでは組織が変更されるたびに、システム全体に大きな変更が要求されることになる。企業合併ともなれば想像もできない組織の変更が発生するのだ。どうすれば変化に強いコード体系が作れるのか。1つの解決策は、購買品、製造品、商品などを [品] の属性として管理するようにすればよい。これによりコード体系は組織に依存しなくなる。簡単なようだが、皆さんの自社システムでも確認していただきたい。
 |
| 図2 上位に［品］を設け、組織依存部分は属性にする |
コードにはもう1つ重要な問題がある。それはコードが表現している粒度の問題である。中期製造計画で用いられるコードは [機能＋仕向仕様] で構成され、短期製造計画で用いるコードは [機能＋仕向仕様＋色＋梱包形態] で構成される。また、[品質] や [製造工場] がコード内に必要なケースもあるが、資産評価のためには [機能] だけあれば事足りる。これらの粒度の異なるコードで表された商品を単純にまとめて、在庫と表現しても経営判断の助けにはならない。原材料や調達部品のコードがバラバラで一括購買が容易にできるのか。各システムの顧客コードがバラバラで顧客の取引動向に関する情報が取得できるのか。当然できない。
データの活用という面でも、コードの整備が行われない状態のまま、コンテンツが増えると、ゴミの山になってしまう。コンテンツも重要であるが、それを管理する上位のメタ情報はもっと重要である。さまざまな部分最適化を実現するために設計されたコードは、ほかのシステムと通信する際に、統一コードに変換されなければならない。この「個別システムのためのローカルコード」と、「全体最適化のためのグローバルコード」の変換は1対1になることもあれば、n対mとなることもあり、変換規則とグローバルコード体系の設計がポイントとなる。
同様の理由により、グローバルSCMに限らず、部門や企業間にまたがる調達システム、CRMシステム、会計システムの構築は難航する。当初予定されていたROIを達成できるシステムは皆無といってもよい。
CRMでは顧客コードの問題が顕著に現れる。Aシステムでは顧客を企業レベルで管理しているが、Bシステムでは部門レベルで管理している。管理するコードの粒度が統一されていない状態で統合しても、名寄せすらできない。まずはコードの表す粒度を統一することから始めることになる。この粒度合わせができた後の顧客マスタや顧客管理サービスが、次期システムで再利用される部品となるわけである。しかし現実には、システム管理者の権限が及ぶ範囲内だけで標準化が行われ、部分最適化のための部品しかできないのである。グローバルシステムの部品化は単一システムの部品化と比べ次元の異なる難しさがある。
2000年問題を思い出していただきたい。もしデータ項目が管理されていれば、日付項目を探し出し、西暦を4けたにするだけのために莫大（ばくだい）な工数を取られずに済んだはずである。システムごとに独自に作られた日付項目が、2000年というイベントによって表面化した1つの例であるが、このようなシステムをWebサービスでつないでも、お互いのシステムで管理されている日付項目すら付き合わせができないということである。
システム間の連携を行う際に、「インターフェイスを合わせる」という作業を行う。そもそもインターフェイスが標準化されていれば、わざわざ合わせる必要はないのだが、そのような理想的な状況は存在しない。インターフェイスが合わないとは、その構成要素であるデータ項目が標準化されていないため変換が必要だということである。論理的なデータ項目が標準化されていれば、システム間通信に伴う「インターフェイスを合わせる」という作業が不要になる。そして、標準化されたデータ項目は、個別システムの外側つまり全体システムの管理者によって管理・維持される必要がある。管理されないデータ項目は、瞬時に使い物にならなくなり、ゴミの山と化す。
Webサービス普及のための必要条件は、データ項目の標準化である。そして現状のWebサービス普及を阻害している要因の1つは、このデータ項目の整備不良であり、産業化の遅れたソフトウェア構築による標準部品の供給不備なのである。
先述したようにビジネス環境は激変している。しかし、どんなに環境が変化しても、扱うデータ項目の数はさほど変わらないはずである。業務によって必要とされるデータ項目は、受注システムなら、[受注番号]、[顧客番号]、[受注年月日]、[納入年月日]、etc…と90％以上はどんな企業でも同一項目によって構成されているのではなかろうか。そうだとすれば、グループ企業内でのデータ項目の標準化ができていれば、グローバルシステムの構築は、あっけないほど簡単なはずである。業界内での標準化が可能であればBtoBシステムも同様にインターフェイスを気にする必要がなくなる。BPRがあっても、ERPを導入しても、ダウンサイジングしても、企業合弁があっても、この論理的なデータ項目はほとんど変化しないはずだ。
しかし、現状は業務に合わせて、その都度システムが構築されているため、似通ったデータ項目が該当システム用に新規に作成され、既存のシステムとの間で無用なコミュニケーションとそれに伴う変換作業が発生してしまう。
|
|
部品化は遅れているが、XMLやWebサービスが使い物にならないわけではない。現状の利用局面でもそれぞれのメリットを生かし十分に活用できる。前述したような問題があるからといって利用を控える必要はまったくない。
Webサービスの活用場面の1つである、企業間のシステム通信といえば、従来、固定長データ形式によるEDI（Electronic Data Interchange）が一般的である。しかし、固定長あるいはCSV形式によるデータ表現では、データの長さや属性、順番などが厳密に決められており、しかも論理的な情報と物理的な構造が一致しなければならない。そのため、非常に拡張が難しく多くの問題が発生する。
例えば、書籍のデータをCSVで送信すると、下記のようになる。
1994,TCP/IP入門,岩本,幸男,ビーコン書籍,1900 |
このフォーマットで100社とEDIを開始した後、もし、101社目に参加した大手の取引先が「書籍名の直後にISBN番号を入れなけば取引できない」といったらどうなるか。取引をやめたくなければ、対応手段は2つしかない。第一の手段は、既存の取引先100社にお願いして各社のシステムを修正してもらい、かつ、100社が一斉に新しいシステムへ切り替える方法である。しかしこれは現実的ではない。現実的な次の手段は、101社目のお得意さま仕様のEDIシステムを、既存のEDIシステムと並行に立ち上げることである。通常、このようにしてEDIでは同じようなシステムが複数構築されてしまい、メンテナンスに翻弄されることもまれではない。
しかし、書籍データがXMLで表現されていれば、下記のようにtitle要素の直後にISBN要素を挿入するだけでよい。
<?xml version='1.0' encoding='UTF-8'?> |
このISBN要素の挿入による、既存100社のシステムに対する影響はまったくない。つまり既存の100社に影響を与えず、101社目の大手と取引が開始できるのである。XMLを活用したシステムはタグ名を判断して処理を行うように設計されるため、知らない新規のタグ<ISBN>があっても無視するだけである。このように、XMLを活用すればシステム間通信のネゴシエーション・コストを大幅に削減できる。XMLは、システム間通信の共通言語として優れたデータ表現構造を持ち、ビジネスの変化に柔軟に対応可能なデータ基盤を構築することができる。
このようにXMLが、システム間コミュニケーションに適している理由は、次のような特徴を保持しているからである。
- 文書の論理構造をタグで表現するマークアップ言語である
- 構造化データをテキスト形式で記述できる
- タグを自由に定義することができる
- スタイルの適用でさまざまな形で表現できる
- 厳密な文法チェックが可能であり、プログラムからの処理が容易である
- データ交換に柔軟に対応できる
- インターネット技術に標準対応できる
- メタ言語なので拡張性がある
XMLはタグによってデータを区切り、その名称を記述するという非常に単純な仕組みである。しかもXMLは、Web上で送受信されたり、データベースに格納されたりするという操作の対象でしかない。つまり、XMLデータをどのようにしてデータベースから取り出し、特定のスタイルに変換させるかなどの処理にはXMLに関連する周辺技術が必要となる。
以下に、XMLの周辺技術として代表的なものを挙げておく。
| 技術分野 | 技術名 |
| 問い合わせ言語 | XPath、XQuery |
| スタイルシート | XSLT、XSL-FO |
| スキーマ | DTD、XML Schema、RELAX NG |
| API | DOM、SAX |
| Webサービス | SOAP、WSDL、UDDI |
| そのほか | XML Signature、XPointer、XLink、XHTML、XForms、SVG…… |
XMLを上手に活用するには、「XMLは単なるデータ形式である」ことを理解し、周辺技術との関連を理解することが重要だ。XMLもそれを利用する周辺技術がなければ、ただのタグ付きデータにすぎない。
XMLが注目される理由は、技術的な面での優位性ばかりではなく、その導入がビジネスにもたらすメリットが大きいからである。
第一に、XMLを活用することにより、臨機応変なIT基盤が構築できる。前述の例でも示したとおり、XMLはデータ構造の変化に柔軟に対応可能であり、企業間のシステム通信にXMLを活用すればデータ形式の変化を吸収することができる。外界の変化に応じて、企業間でやりとりされるデータ形式が変更になった場合でも、XMLであればシステムの変更が少なくて済み、保守費用を削減することができる。
第二に、XML活用により業務効率を改善することができる。システムがデータの意味を理解できれば、ある程度の自律的な処理が可能になるため、システムは人手を介することなく自動的に処理を進めることができる。複数部門あるいは複数企業にまたがるSCMで採用する事例が出始めているが、これらは業務効率の向上をもたらす。
このようにシステム間のコミュニケーション基盤として有望なXMLだが、タグ名はだれが決めるのかという問題がある。タグ名が標準化されなければ、XMLを受け取ったシステムはそのXMLデータを解釈できない。また、タグ名が標準化されていても、そのデータの表す意味を正確に解釈することは難しい。
例えば、あるXML文書に「1900」という文字が含まれていたとしよう。この「1900」が何を意味しているかは、システムで判断することはできない。長さかもしれないし、金額かもしれない。この問題は、XMLの特徴からすれば、容易に解決できるはずである。XMLはタグを任意に定義できるため、長さであれば「<length>1900</length>」、金額であれば「<price>1900</price>」のように表現し、ある程度の意味を区別することができる。
ところが何を表す長さなのか、何の金額を示しているのか、消費税は含まれているのか、単位は円なのかドルなのかまでは、システムには理解できない。つまり、XMLでコミュニケーションを円滑に行うためには、あらかじめ業界団体などでタグの標準化と詳細な意味の統一を図らなければならないのであり、そこで決められた標準は、ほかの業界では通用しないということを認識する必要がある。コミュニケーションは統制の効く範囲内でしか有効ではないのである。
XMLを使えば単純でしかも可視的な記述方法によりデータを表現できる。しかし、これだけでは、システムとシステムはコミュニケーションができない。なぜならば、XMLは言語でありプロトコルではないのである。受発注を例に取れば、XMLにより発注伝票の各項目は規定されても、その伝票を相手のシステムへ送信する手順、また受け取る手順を決めなければコミュニケーションは成立しない。
また、システム間でコミュニケーションを取る場合は、もう1つの問題がある。コミュニケーションはいつも同じ相手と行うとは限らない。新しいサービスやよりよいサービスを求めて、コミュニケーション先をダイナミックに「探す」そして「接続する」必要がある。人が介在していればさほど複雑なことではないが、システムが自律的に行うのは簡単ではない。
これらの課題を解決するのは、もちろんWebサービスとSOA（サービス指向アーキテクチャ）によるダイナミックバインディングである。SOAとは複数業務で使用される機能を共通のサービス（部品）として切り出し、複数のシステムで共有できるようにするアーキテクチャである。SOAにより、企業は自社の得意とする機能をサービスとして公開することができ、新たなビジネスを展開することが可能となる。また、サービスの機能それ自体はさまざまな業務で再利用が可能となり、システム全体では大幅なコスト削減になる。再利用のメリットは開発段階での工数削減もさることながら、そのサービスがテスト済みであることによるメリットが大きい。また、サービス（部品）の組み合わせで構築されたシステムは、外界の変化に適応し、臨機応変な組み替えが容易である。
取りあえず、つないだからといってコミュニケーションが保証されるわけではない。
プラットフォームの問題
インターネット自体が、Webサービスを運用するプラットフォームとして完ぺきではない。そもそもインターネットはWebサービスのプラットフォームとして設計されたものではない。システム間通信を実現しようとしたとき、たまたま、インターネットが一番普及していたネットワークであり、Webサーバが一番普及していたサーバであり、HTTPプロトコルがファイアウォールを越えられるプロトコルであった。「たまたま」そうなったということであり、そこに完全を求めてはならない。HTTPは99.9％信頼できるが100％ではない。ビジネス・トランザクションが、この0.1％を許してくれるだろうか。たまに注文が届かなくても問題ないことなどはあり得ない。信頼性が十分なシステムを作るにはアプリケーションの工夫が必要である。
セキュリティの問題
Webサービスの利点は「HTTP上で動作する」ことであり、同時に欠点は「HTTP上で動作する」こと、といわれる。まさにトレードオフの関係にある。HTTPを使用するということは、ファイアウォールを越えて他社のシステムと連携が可能になるということだが、同時にファイアウォールの内側に見ず知らずのシステムが侵入してくることを意味している。
Flow ControlとTransactionの問題
複数のWebサービスを呼び出す順番やルールを定義する必要がある。また、複数のWebサービス間のトランザクション処理を保証する明快な方法が確立されておらず、更新処理を伴うサービスのインテグレーションには考慮が必要である。
コードの問題
先述のとおり、システムの連携・統合を考えると、まず初めに出る問題は「コードの整備」である。同一製品を示すにもかかわらず製造部門と営業部門で、製品コードが異なるなどは日常茶飯事である。在庫管理システムが国ごとまたは地区ごとに構築されている場合、コードの整備がなされていなければ、企業全体での在庫数の把握などできるはずがない。
上記の課題がすべて解決できたとしても、世界中のすべての企業と自由に連携を行えるようになるわけではない。与信管理や法的な契約に関する問題など、企業間でビジネスを連携させる際には、さまざまな付帯作業が必要となる。現時点では、いくつかの課題が残されているが、インターネットほどWebサービスの運用を低コストに実現するプラットフォームは存在しない。取りあえずできるところから始めることが大切である。リスクを背負う価値は十分にある。
◇
本稿では、XMLによる管理コード統一の重要性と、それを実現した先に訪れるWebサービスとSOA（サービス指向アーキテクチャ）の現実性について議論した。最終回となる次回では、データ指向とサービス指向を組み合わせた標準部品化アプローチを提言する。（次回に続く）
■バックナンバー
1. Webサービスを阻害するシステム開発の旧弊を絶つ
2. データ標準化から目をそらす守旧派の罪と罰
3. データ指向とサービス指向、そして約束の地へ
 |
緊急提言：Webサービスの光と陰を考察する |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
