序論
本稿では、近年、流通業においても、注目を集めているXML-EDI(eXtensible Markup Language-Electronic Date Interchange)の導入について、ビジネスと技術の両面から論じ、各事業者がどのように対応するべきかの指針の提示を試みる。製造業のXML-EDIは各産業別にその実績を見渡した場合、現状では頭一つ抜け出している感があり、単純にXML-EDIの議論をする場合、中心が製造業に偏るきらいがある。今回の試みでは、流通業からみたXML-EDIに関して、そのコンテキストを正確にトレースするのが目的であり、流通業特有の問題から、XML-EDIについて論じていきたい。
まず、日本の流通業のビジネスは国内を主に展開されているという点を考慮する必要がある。製造業に関しては、原料調達・組み立て加工などの業務連携は、国際化が進んでおり、したがって、グローバリゼーションのコンテキストでXML-EDIを語ることに関して違和感はない。これに対して、日本の流通業では一部を除いては、国際化ということのメリットが現実のビジネスとは結び付いておらず、そのため、流通業のXML-EDIの議論に、ビジネスがグローバルであるというコンテキストをそのまま持ち込むことは、現状では適切ではない。流通業の標準EDIの導入を論じるときに、「なぜならばXML-EDIは国際標準であるから」という考え方は、現行の流通業のドメインではそのままストレートには通用しない。
次に、現行の流通業におけるEDIのあり方について、整理しておく。現状、EDIという言い方をする場合、多くは受発注を中心とした、データの送受信並びにその手続（プロトコル）を指す。現行のEDIのプロトコルとして、代表的であるものはJCA手順と呼ばれる固定長の電文フォーマットとそのプロトコルであり、20年以上の伝統と格式を誇るプロトコルである。日本チェーンストア協会(JCA)が自ら定めたという点において、また結果的に広く普及した点において高く評価されてしかるべきプロトコルである。現行の流通業のオンライン取引はこのJCA手順によるものが主流であり、既存のEDIの仕組み＝JCA手順、という図式を、議論の認識の枠としてとらえておくことに、異論は少ないと思われる。
XML-EDIを論ずる前に、JCA手順に代わるプロトコルとして、検討され、実際には一部で運用までされたプロトコルとしてJEDICOS(Japan EDI for Commerce Systems)について言及する。この規約はグローバリゼーションを意識しており、可変長のEDIフォーマットである上に、規約自体がメタレベルまで言及している。汎用性という意味では極めて高いレベルまで実現したプロトコルであり、規約成立時にはJCAに代わる次世代EDIの柱になるものと期待された。しかしながら、このプロトコルは期待されたほど普及せず、その役割を果たす前に忘れ去られようとしている。
XML-EDIを議論するのであれば、まず、なぜJEDICOSは普及しなかったのか、ということを整理しなければ、同じ轍を踏むことになる。現状のXML-EDIの議論を鳥瞰すると、とりあえず単にJCA手順を置き換えればよい、という考え方が散見されるが、これは非常に短絡的な見解であり、また反省を活かさないという点で賢明ではない。JEDICOSが普及しなかったことに関してはさまざまな要因が考えられるが、利用者側から見るとJEDICOSを採用した場合のコストとメリットを比較したときに、前者の方がはるかに大きかったということがある。同様にXML-EDIを考えるときに、JCA手順の問題点を乗り越えられるだけの機能を期待できるかどうかに加え、その導入によるメリットがコストに見合うかどうかを検討することは極めて重要なことである。
今回の議論では、(1)現行のJCA手順の問題点の把握と、(2)それを乗り越えられるだけの機能をXML-EDIに期待することが可能であるかどうかという技術的検証と、(3)そのためのコストとメリットを一定の仮定を用いて定量化したい。 以下、順に議論していく。
現行JCA手順の問題点の把握
最初に、現行のJCA手順の最大の問題点は何か、という議論を整理しておく。まず古い、という議論があるがそれは、モールス信号はもう古いので、次の規格を考えましょうというのと同じくらい無意味な議論である。また、2003年2月現在、JCA手順をサポートするモデムが生産停止になるという話が流布しているので、次の手順を考えましょうという意見もあるが、これもハードの問題とプロトコルの問題を同一の次元に考えているという意味であまり生産的ではない。JCA手順の最大の問題点は、そのプロトコルがもはや、現在のビジネスの要求に応えられなくなりつつあるということである。
特に近年、流通業においてビジネスサイドで、もっとも変化が激しい問題は消費者の問題意識の変化である。これはここ数年で急激に変化したというよりも、少しずつ発生してきた潜在的な変化が近年、急激に顕在化してきたという表現の方が適切である。すなわち、個々人の個性の尊重とともに、最終消費者において自己の意思決定に関して、十分な情報を収集した上で自ら購買行動指針を決定することが通常のこととなってきている。
これは、公共セクターに対する信頼の欠如が明確になりつつあることと同時に、共時性をともなったコミュニケーション基盤が日本から失われつつあることも一因となっている。下世話にいってしまえば、「XX機関が認定しているから」だとか、「お隣さんが薦めてくれたから」だとか、という理由で、最終消費者が購買の意思決定をする機会が減少しているということである。この潮流の顕在化は、潜在するさまざまな社会的リスクを個々人が自分で負担することが要請されつつあり、そのための情報基盤が必要とされ、また、それに呼応するかのようにInternetがその情報提供の基盤整備に大きな役割を果たしつつあることもその一助となっている。
このビジネスサイドの要求が、流通業界にさまざまな影響を及ぼし始めている。流通業が消費者から情報開示を要求されるとともに、必要に応じて定性的なデータまでも開示せざる得ない状況に追い込まれつつある。これはBSE問題に発した食品の安全性の問題にもその影響をうかがい知ることができる。元々、特定牛がBSE検査を通過したかどうかの表示が問題であったのであるが、現状では、特定牛の出自・飼料の内容などまで開示するという問題に変貌しつつある。
このようなビジネスサイドの要求として、現行のEDIで対応が可能であるかといえば、残念ながらイエスとはいえない。BSE問題一つとっても、小売側在庫管理、発注IDとの関連、生産者側の出荷ID、生産物ID、その関連飼料との関連を明示的にサポートするプロトコルが必要とされることは、議論を待つまでもない。特に定性的データはデータが構造的になる可能性が強い上、固定長では対応することは不可能である。したがって、こうしたデータを扱うことのできないJCA手順では、現状の消費者のニーズ・ウォンツに応えるEDIを確立することは不可能である。
では、XML-EDIでそのような情報開示に耐えうるプロトコルが確立できるのであろうか。次に、より具体的にXML-EDIに関して検討していくことにしよう。
XML-EDIの技術的検証
これまで述べたように、XML-EDIの妥当性は、現行のEDIを新しいプロトコルに切り替えることによって発生するコストとメリットのバランスによって、判断されるべきものである。ここでは、これらのコスト要因に関わる、技術的な検証を行う。
まず、現行のEDI継続によるデメリットとしては、これまでの議論で、最終消費者に対して、商品についての定性的な情報開示を行えないことの重要性を指摘した。ここで述べる定性的なデータとは、固定長でコード化することのできないデータのことである。固定長でコード化できるデータは、価格や重さのように数値化できるデータや、あるいは色や容器の形状のように規格化できるデータであり、現行のプロトコルで交換できるのは、これらのデータに限られている。
XML-EDIでは、企画意図のような可変長のテキストとして表現されるデータや、流通過程を表現する複数の種類のIDを関連づけた複雑な構造を持つデータを扱えることが重要な要件となる。また、こうしたデータの種類や構造は、上述のBSEに見られるように、社会的、経済的な要請に応じた、迅速な追加・変更が必要になるという特徴があるため、それに対応できる柔軟性を持つ必要がある。
次に、プロトコル切り替えに関わるコスト要因としては、新しいプロトコルに対応したインフラ整備のためのコストを低く抑えられることが重要である。ただし、その際にこれまでのプロトコルで保障されていた信頼性、安全性、パフォーマンスについてのリスクがないことが前提となる。インフラ整備の観点からは、インターネットの利用は有利であるが通信の信頼性と安全性という点でのリスクが大きくなる。
以下、柔軟なデータ記述を可能にするフォーマットとしてのXMLと、さらにその特性を生かし、インターネット上でのEDIを可能にするebXMLの検討の2つにわけてXML-EDIの妥当性を論じる。
XML
XMLは、1998年に勧告されたデータフォーマットの国際標準である。XML-EDIのコンテキストで重要な特徴は、Internet標準であること、表現能力の高さ、標準を記述するための標準であることである。
XMLの開発にあたったW3C(World Wide Web Consortium)は、HTMLやHTTPといったWWWを実現するための中核となる標準を開発し、今日のInternetの普及の基礎を築いた標準化団体である。つまり、XMLはW3Cのお墨付きを得た、次世代のInternetの正統な標準データフォーマットであり、現在、広い分野に急速に普及している。データフォーマット自体が持つ利点に加え、国際標準として普及しているということから、有力なメーカーやユーザー団体がXMLを積極的に採用しており、XMLを利用するためのツールやライブラリを安価に入手することができる状況をもたらしている。このことが、XMLをベースにしたシステム構築のコストを引き下げる役割を果たしている。
XMLの前身はSGML（Standard Generalized Markup Language）である。そもそもは文書管理の研究をその端緒としているが、現在では広く、ビジネスプロトコル一般の記述までに利用されるに至った。元々は章立てのしっかりした文書の論理的な構造を記述するために開発されたことは、データ特性を理解する上で重要である。データの表現は基本的に、可変長のテキストデータを階層構造に構造化するものであり、この特性によって従来のEDIで用いられてきた固定長のレコードデータには表現できない、定性データの記述が可能になる。
XMLは標準を記述するための標準ということができる。XMLは、SGMLを前身とするフォーマットであるという点では、HTMLと同じであり、タグを埋め込んだテキストということで見た目もよく似ている。両者の決定的な相違点は、HTMLでは、利用することのできるタグの種類が決められているのに対して、XMLでは、XMLSchemaと呼ばれるスキーマ言語によって、利用するタグの種類などを記述できるところにある。
XMLSchemaは、XMLデータ中に出現できるタグの種類、データ型、構造についての制約を記述することができ、データの解釈の仕方を規定できる。従来、標準フォーマットを定める場合に、データが満たすべき構造を、人間によってのみ理解できる規格書によって記述してきた。これに対して、XMLベースの標準フォーマットでは、プログラムによって解釈可能なXMLSchemaによって標準の記述が可能になる。これにより、標準化の作業プロセスを短縮し、時代の要請に応じた追加や変更が可能になる。
ebXML
XMLによって業界固有のデータフォーマットを記述することができるが、それだけでは、EDIの規約として十分ではない。XMLデータの送受信のためのパッケージング方式や、データの送受信で従うべきプロセスについても規定する必要がある。XML-EDIを策定する活動には、RosettaNetなどいくつかあるが、流通業界のコンテキストでは、GCI (Global Commerce Initiative) が採用を表明したebXMLが重要になる。
ebXMLは、インターネット上での取引に必要な信頼性、安全性を備えたEDIの規格であり、それまでに実用化されたXMLベースのプロトコルの長所を取り込んだ、最も進歩したプロトコルである。 ebXMLは、XMLを用いた企業間取引を実現するために定められた国際標準の仕様群のことである。XMLベースの標準の乱立による混乱を収拾し、世界単一電子市場の創造(Creating Single Global Electronic Market)を目指して開発された。元々、国連のEDI標準化下部組織UN/CEFACT(United Nation/Center for Facilitation of Practices and Procedures for Administration Commerce and Transport)と米国のXML実装標準化を推進しているコンピュータ企業と業界団体のコンソーシアムであるOASIS(高度構造化情報システム推進組織)の下で2001年5月までの期限付きプロジェクトとして標準化が行われた。プロジェクトは解散したが、主要なものは現在も引き続いて次バージョンの策定が進んでいる。
RosettaNetが、半導体、電子部品、コンピュータをはじめとするIT業界における電子商取引の標準化のための規格を規定しているのに対し、ebXMLは、どの業界にも適用できる汎用の仕様である。そのため、交換文書のフォーマット、プロセスなどは、各業界で取り決める必要がある。また、ebXMLでは、単に企業間で送受信するメッセージの形式をXMLに置き換えるだけではなく、インターネットでの新たな取引コンセプトを提案している。このため、ebXMLを利用する際には、目指しているコンセプトを理解した上で、実際の取引の現実との間で整合を取る必要がある。
ebXMLの仕様群のうち、現在標準化されているものには、MS、BPSS、CPPA、R&R、CCがある。MS (Message Service)はSOAPをベースとしたメッセージのパッケージングを規定し、二重配送の防止やデジタル署名などにより、信頼性、安全性の高いデータ通信手順を可能にする。BPSS(Business Process Specification Schema)は、パブリックフローと呼ばれる、企業間でのビジネス情報の送受信手順を記述するためのスキーマを定めている。RosettaNetでは、企業間のパブリックフローを規定するための、100以上ものPIP(Partner Interface Protocol)が、規格の大きな部分を占めるが、BPSSを用いれば、こうした取り決めを体系的に記述することが容易になる。
CPPA (Collaborative Protocol Profile and Agreement)は、従うことのできる手順を含む企業プロファイル(CPP)と、企業間での取引に関する合意(CPA)を記述する。R&R (Registry & Repository)は、企業プロファイルなどについての情報を格納するリポジトリの構造と検索サービスを規定している。CC (Core Components)は、交換されるXMLデータで利用できる標準的な要素を規定する。
これらの規定を利用した取引シナリオの例を示す。まず、R&Rによって定められるデータ共有のためのリポジトリに、各企業がどのようなメッセージ送受信に対応しているかのプロファイル情報をCPPの形で格納する。取引相手が決まると、自社のCPPと相手のCPPとから，合意を取り決めたCPAを作る。このCPA情報と、BPSSを用いて定義された送受信プロセスから、実行時の通信手順が定まる。こうして確定した通信手順に沿って、送受信されるメッセージがMSで規定される形式で作られる。MSは、HTTPで送る場合には、マルチパートMIMEとして2つのパートに分けられたメッセージになる。最初のパートはSOAPエンベロープと呼ばれ、対応するCPAや，実行するサービスなどを指定し、第2のパートはペイロード(搭載物)と呼ばれ、送信したい本体のXMLデータを格納する。
現在、流通業以外に、米国を中心とした旅行業界のコンソーシアムOTA (Open Travel Alliance) 、北米の自動車販売業界のIT標準化組織STAR (Standards for Technology in Automotive Retail)などが、メッセージ交換にebXMLを採用することを表明している。RosettaNetも次のバージョンはebXMLに準拠することを表明しており、RosettaNetを採用している企業のすべてがebXMLを採用することになる。アジア諸国でもebXMLを用いた商取引の推進のために、国を挙げた取組みが進められている。こうした活動によって、環境が整備されていけば、インフラ構築のためのコストが低くなり、さらなる普及を推進することになる。
XML-EDI導入のコストとメリット
最後に、XML-EDI導入のコストとそのメリットに関して一定の仮説を準備しながら、議論していく。
コスト
XML-EDIの導入コストに関して、ハードとソフトの両面から考慮していく。まず、ソフトウエアであるが、スキーマ自体は、財団法人流通システム開発センターなどの標準化団体が進めている標準フォーマットを利用するので、コストはかからない。次に構成ソフトになるが、これは機能的に2つの部分に分かれる。プロトコルハンドルを行うゲートウエイ的な機能と、受け取ったXMLを内部的にハンドリングする機能の2つの機能である。これらの機能に関しては既に実装されたパッケージが相当数、市場に流通しており、ベンダーも各社ある。
これらのベンダーは、その出発点をITバブル時代のB2B狂乱ともいうべき状況に持ち、そのプロダクトはXML-EDIに関して実績がある。価格に関してはサイトライセンスで数千万円というのが2002年末の実勢価格であるが、この価格は技術のサチュレーションとともに、今後は低下傾向をたどると予測され、早晩500万円から600万円前後に収まる可能性が強い。
この価格は、前述の2つの機能のうちの後段の機能、つまり、受け取ったXMLのハンドリングに関する機能に、フォーマットの相互変換やワークフローといった、いわゆるEAI（Enterprise Application Integration）的な機能によるコストを含んでいる。単純に前述のうちのプロトコルハンドリングを受け持つ部分だけに機能を限定するのであればソフトウエア・パッケージとしてはその価格は100万円を切る価格まで下落するであろう。したがって単純にゲートウエイ機能としてXML-EDIに関するソフトウエアを導入するのであれば、ソフトウエア自体の導入コストはカスタマイズを含めて、最終的には数千万円前後に落ち着くと思われる。
ただし、問題はゲートウエイを介して受け取ったXMLを処理する側の現存するプログラムの改変・新規開発の工数である。例えば、単純に商品マスターを受け取る処理にしても、パーサーによるスキーマとの整合性チェックのみではなく、ビジネスロジックによるチェックが必要になる。つまり、既存DBとの整合性、バイヤーの目視による確認、対象店舗の設定、関連データとの整合性確認などの処理が必須になる。
これらのプログラムの変更・新規開発の工数はソフトウエアの初期導入費用をはるかに上回る金額になる。また、その工数も、導入する企業の既存のシステムがいわゆるオープンアーキテクチャーにどれほど移行されているか、という度合いに依存する。特にXML-EDIであれば、2003年現在ではハンドリングの環境としてはJavaまたはC＋＋がもっとも適しており、逆に汎用機を中心としたCOBOL環境では、そのハンドリングのハードルはシステム的に高いといわざるを得ない。
経験的に述べれば、Java・C++といったオープンアーキテクチャーがほとんど存在しない環境であれば、前述のプログラム開発コストはコンバージョン・接続を含めて、数億円以上になる可能性は極めて高い。したがって現状の受発注がJCA手順＋COBOLという環境で構築されている場合、XML-EDIの導入コストとして、一般にソフトウエアと既存部分の改変・プログラムの新規開発で数億円とみておくことは、妥当と思われる。もっと正確にどの程度になるか、ということに関しては統計的データもないため、筆者の経験からの推測の域を出ないが2億円から５億円の範囲である可能性が高いと推定される。
次に検討する課題として、ハードウエアであるが、近年、ダウンサイジングとオープン化の波のなかで、コストパフォーマンスが著しく改善されつつある。ハードウエアの規模は、トランザクション量に依存するので、これも一概にコストを推定することは難しいが、経験的には数千万円のサーバーをクラスタリングする程度で、10数年前の汎用機に見合うだけのパフォーマンスが得られるのが現状であり、その意味でXML-EDIを導入するハードウエア・コストは５～６千万円というのが2003年現在では相場になると思われる。
以上より、XML-EDIの導入費用としてはハードウエアとソフトウエアの費用を考えた場合平均的に3億円前後とみておくのは、2003年現在では、妥当であると思われる。通常はソフトウエア・ハードウエアの償却は５年であるので、年間のコストは0.6億円程度と推定される。念のためにもう一度記述するが、これらの金額は多くの仮定に基づいており、現実の金額は導入するそれぞれの企業の環境に大きく依存することをお断りしておく。
なお、ここではInternet利用によるコストメリットは議論しない。通常のアナログ回線・VAN回線に比して、Internetの利用料金は、そのコストパフォーマンスを考慮した場合比較にならないほど廉価になりつつある。しかし、Internet利用のメリットは、そのセキュリティリスクの甘受とのトレードオフが現状では成立するため、単純にコストメリットのみ強調するわけにはいかない。
現状のInternetでの大規模なB2B取引を成立させるには、特にセキュリティと認証の問題への対応は脆弱であり、今後の大きな問題になる。特に認証の問題に関しては、何らかの公的な制度が必要なはずであるが、流通ドメインに限っていれば、その動きが皆目みえない、という意味で関係所管の注意の喚起を促しておきたい。私見ではあるが、これらトレードオフを考慮したとしても、Internetを利用するメリットは、特にコストパフォーマンスの点から看過できない状態になりつつある。
メリット
次に、XML-EDIを導入することによるROI（Return On Investment）を算出する。通常であれば割引率として各企業ごとのWACC（Weighted Average Capital Cost）を利用することが妥当であるが、現実的な長期金利・現状のデフレの市場状況を考慮すれば、WACC＝０とみなしても決して乱暴な仮定ではない。したがって、ここでのROIの計算上では便宜上、金利は事実上ゼロとみなす。
まず、現状のデフレの環境を鑑みた上で、GMS・SM・CVSなどの業態等の平均粗利益を30%と仮定しよう。無論取り扱う商品カテゴリー単位で粗利益率は大きく異なる。付加価値ベースの高い商品であれば50％から60%という粗利の商品もあるし、生鮮品に関しては店舗レベルで粗利が０%に近い商品カテゴリーがあることも事実である。しかしながら正確なデータは取得することが困難であり、一般に入手できる情報から消費財の小売業での商品粗利をリベートも含めて30%と仮定することは、議論の前提としては許容範囲であると思われる。
ここで重要な仮説として"定性的なデータを適切に顧客に開示することで、買上げ率が1%上がる"としよう、すなわち正確な商品情報を開示することで、100個売れていた商品が101個売れるようになった、と仮定することになる。前述のように、現状の消費者の情報需要を考慮すれば、これはそれほどでたらめの仮定ではない。もちろん、筆者の経験からいって、昨年対比で売上を販売点数で1%上げるのは、口でいうほど簡単な話ではないことは重々承知している。
しかし、すべての商品で定性的なデータを完全に正確に開示した場合、販売点数が昨年対比で1%増える（断っておくが売上ではない）という仮定は、まったくでたらめか、といえばそれを明確に否定できるほど、現状では実際の現場で情報開示がされていないのも、また事実である。
現状では商品の平均単価は対前年比95%で推移しているので、金額ベースに換算した場合、売上に与えるネットのインパクトは95% ×1% = 0.95%となる。これに粗利利益率を30%と試算して0.95% ×30% = 0.285%。すなわち、売上対比でのリターンの比率を0.285%と仮定し、ROIをプラスにするのであれば、この比率で0.6億円を割り戻し、必要な売上としては最低でもおよそ210億円と算出される。前述のように割引率は考慮しない。
以上の議論から、年商がおよそ200億円以上の小売業であれば、投資効率として、JCA手順からXML-EDIに移行することはROIという観点からみても整合性がとれる投資であるということになる。一部のGMSを除けば、1店舗の売上は10億円からの範囲に納まることが多いので、店舗数が10数店舗以上の小売業であれば、JCA手順からXML-EDIに移行することはビジネス判断としては、大きな間違いではない。
では、年商200億円以下の小売業ではXML-EDIを導入する意味があるのか、という議論も、結果的に提示されるが、一般に、年商200億円以下の小売業で、年間コストが0.6億円かかる投資は明らかにIT投資としては過剰投資である。しかしながら、年商200億円以下の小売業が接続に何億円もかかる受発注システムを稼動させているか、といえば極めて疑問であり、もし、既存システムとの接続に関わるコストを、十分低く抑えることができるのであれば、年商が低い小売業でも、XML-EDIを導入することは現実的な選択肢となる。
結論
最終消費者の行動原理の変化への対応、XML-EDIの特徴、投資効率の検討を順次行ってきたが、結論としては、少なくとも流通ドメインにおいてはXML-EDIを次世代EDIの仕様として、そして実際に適用することに関して肯定的に考えることについて障害は少ないと考えられる。さまざまな仮定に基づいた議論であるとはいえ、これらの仮定を明確に覆すほどの厳然たる事実もまた流通ドメインにはないのである。