B2Bサーバ 普及の要件と期待
インフォテリア株式会社 井下田 久幸（いげた ひさゆき）
普及しそうで普及しない「B2B（Business-to-Business）」の電子商取引であるが，海の向こうでは「B2B」はもう一昔前のはやり言葉として使うのを恥ずかしがっている企業もでてきた。今では「B2B」の変形バージョンが氾濫するようになった。「B2G」（G＝Government）「B2E」（E＝Employee）「B2M」（M＝Mobile）など，あたかも次のステップにフェーズが移行したかの如く演出している。果たしてそこまで「B2B」は根付いたのだろうか？
「B2B」は，今までに流行った言葉と比べると，かなり目的が具体的だ。「AI（人工知能）」，「ナレッジ・マネジメント」，「ネットワーク・コンピューティング」，「グループウェア」，「eビジネス」，etc. さまざまな言葉が生まれてコンピュータ市場に多かれ少なかれ影響を与えてきた。名前の流行だけで終わったものもあれば，しっかりビジネスに貢献してきた言葉もある。「B2B」は，抽象的な表現が多かったこれまでの流行語に比べ，「企業」と「企業」を結びつけるための仕組みというかなりしっかりした目的意識を持った言葉である。その分，根付いてもよさそうな言葉のように見えるのだが，まだまだ浸透しているとは言い難い。
「B2B」普及における大きな阻害要因は，既存のソフトウェア資産だろう。社外のシステムと繋ぐために，社内のシステムを作り変えなければいけないとしたら，既存システムの構築に携わっていた者にとって，自己否定に繋がりかねないからである。将来を見据えたシステム構築でなく，つぎはぎだらけのシステムであることを露呈してしまいかねない，とう心配が頭をよぎるわけである。
もう一つの大きな要因は，違う歴史，違う文化，違うアーキテクチャのもとで構築してきた，それぞれのシステムの融合の難しさだろう。この問題は社外との接続だけに限らない。社内であっても部門が違うだけで，内容は似ているのに，別々のシステムが動いていて一元化に苦しんでいる企業は多数存在する。ましては社外と接続なんてとんでもないというところも多いだろう。
企業間の取引に，専用回線を結ぶのが主流だった時代はB2Bではなく，「EDI」（Electronic Data Interchange）と呼ぶことが多かった。この時代は，主導権を持った企業が子会社や系列会社に自社のフォーマットに合わせてデータを交換させる，といった形態が主流であった。系列会社にとってみればデータ交換する会社ごとにそれ専用の端末を用意したりする必要があった。とても，自由なやりとり，対等なやりとりといえるものではなかった。日本企業の場合は，データのシンタックス・ルールも日本独自に決めた標準である場合が多く，国際性に乏しかった。
これらのシステムは，総じて硬直的であり，データ項目を変更したり追加しようとすると，それに関わるすべてのソース・プログラムを修正しなければいけないのが普通だった。このため，システムの更新は，まるで腫れ物に触るが如く，なかなか進まない作業となった。その意味でインターネットの普及がもたらす意義は大きい。インターネットは誰でも参加できる自由なネットワークである。実力さえあれば，規模に関わらず対等に商売ができる素地を提供している。しかも専用回線を使う場合と異なり，決まった相手だけとのやり取りに留まらない。その気になれば地球の裏側の知らない企業とも商取引ができる。郵便から電話，船から飛行機というように，地球上の「距離」を縮める変革と同様に，インターネットの普及は，システム上の「距離」を縮める大きな革命的できごとであったといえる。
ただ，電話を例にとっても，会話をスムーズに行うための共通の言語が必要であったように，「B2B」においてもインターネット上流れるデータに共通のフォーマットが必要である。片側が「英語」，片側が「日本語」ではコミュニケーションにはならない。カンマ区切りのCSVファイルでは，なにかカタコトで単語を並べて喋っているようなものである。単語の順番が変わったり，語彙が微妙に違ったりすれば，もうそれでコミュニケーションは成り立たなくなってしまう。B2Bの世界でも，自然言語における「英語」のような普及した標準言語が必要であり，その最有力候補としてタイミングよく登場したのがXMLなのである。
ここで自然言語における共通言語を「エスペラント語」と言わずに「英語」といったのには意味がある。「エスペラント語」も標準言語として設計された言語で，人工的だという点ではXMLは「エスペラント語」に近いのかも知れない。筆者はエスペラント語を知らないが，人工的に作り出しただけに例外文法も少なく理想的な言葉なのだろうと推察している。しかし現実的には，標準語としてそれほど普及していない。言語としては理想的でないかもしれないが，多くの人がビジネス上の標準語としているのが英語である。
XMLに関して，その技術の内容そのものよりも，現実的な標準化活動を伴っていることに，その価値を説く人も多い。「XML」の前身である「SGML」は，仕様としては優れているものの，実際にはほとんど使われていないという，ある意味では「エスペラント語」的な運命をたどった。その反省を活かして改良された「XML」は非常にタイムリだったといえる。「SGML」の派生言語である「HTML」が普及した直後に出てきたという時間的タイミングの良さも効を奏したといえる。
さて「英語」的存在であるXMLでコミュニケーションをしようにも，現存のシステムは堅物でなかなか「英語」を話すことができない。「英語」を覚えるようになるまでには時間もかかり，他社に先を行かれてしまう恐れがある。このスピード時代には，便利な通訳者が必要となる。
この通訳の役目を担うのが，「B2Bサーバ」である。社外的には「XML」という言葉を喋り，社内的には既存システム固有に対応した言葉でやりとりする。B2Bサーバの現状 B2Bという言葉の流行の割にはB2Bサーバはまだまだ数少ない。B2Bサーバといっても，まだ製品としての成熟度が低いというのが正直なところであろう。世界的に見て「B2Bサーバ」をうたい文句に出しているベンダは数社あるが，まだまだコンサルティングなしでの利用はできない（図1）。何が原因なのだろうか。
XMLはそれ自体，汎用性/拡張性があり過ぎ，システム間の会話のためにはもう少し限定した会話のフォーマットが必要である（これについては後述）。そのフォーマットやそれに伴う会話のプロセスをB2Bサーバでは実装しきれていないためだ。B2Bサーバで実装しきれていない分，社内の対応するアプリケーションの側で，それらのプロセスを実装せざるをなく，それをカバーすべくコンサルティングが必要になってくる。
もう一つの要因は，B2Bサーバの提供形態と価格である。B2Bの普及には，規模が小さい会社でも自由に参画できる基盤の提供が不可欠である。そのためにも安価な価格帯のB2Bサーバが求められている。コンサルティング付きのB2Bサーバはどうしても高価であり，とても中堅企業には手が出ないし，早期実現も夢の話である。大企業が積極的にイニシアティブを発揮してB2B市場を創出していき，同時に中堅企業も容易にB2Bに参画できる構図が，普及促進のキー・ポイントだと信じる。B2Bに特化した業種ごとのXMLスキーマ普及の気配 XMLがB2Bに欠かせない会話手段（データ・フォーマット）であることは述べてきたが，Extensible
Markup Languageの名が示すように，XMLは拡張性が高いタグ付け言語である。建築家が医者同士の会話を理解できなかったり，医者が金融業者の会話を理解できなかったり，またはこれらの逆のことが起こるように，業種や業務によってそれ専門の用語（語い）や会話（データ構造やプロセス）によって，あらかじめやりとりを決めておかないと会話が成り立たないケースがよくある。ましてや双方がコンピュータとなると人間のように想像力や柔軟性で理解・解釈することは不可能である。B2BにおいてXMLを使用する場合も同様で，どの業種のどんな内容の業務のやり取りを行っているのかを決めておく必要がある。これらの規定をXMLでは「XMLのスキーマ」とか「XMLのフレームワーク」と呼んでいる。それ専門の用語（語い）やデータ構造をXMLのスキーマで取り決めることができる。またXMLの規定の対象外とはなるが，業務のプロセス，つまり社内でいうワークフローの規定も行っておくと，B2Bの会話がスムーズに進む。
現実に，さまざまな業界で，XMLを使ってフォーマットの策定（フレームワーク）が進められている。（表1）
| RosettaNet | PIP |
| 米Ariba社 | cXML |
| UN/CEFACT,OASIS | ebXML |
| 米Commerece One社 | xCBL |
| 米Microsoft社 | BizTalkフレームワーク |
電子部品の調達系ではRosettaNetという団体がパソコンのチップなど，電子部品の受発注のフォーマットやプロセスを取り決めしている。地図情報ではG-XMLとか，間接材では米Ariba社提案のcXMLとか，さまざまなフレームワークがある。他にも米Commerce One社提案のxCBL，UN/CEFACTとOASISによる共同提案のebXML，米Microsoft提案のBizTalkフレームワークなどさまざまである。
それぞれ一長一短あろうが，普及という観点でいうならば，電子部品のB2Bを行うためのフレームワークを取り決めている「RosettaNet」は業界垂直型のソリューションを目指しており，進捗度も高く，最も実現に近いXMLフレームワークとして期待されている。現に他の業界ではこのRosettaNetを参考にフレームワークを決めようとしている業界もあるくらいである。B2Bサーバ普及の条件 まず一番に言えることは，B2Bサーバが「通訳者」として有能で，既存の企業システムの負荷を如何に軽減してくれるかである。言い換えると既存のシステムが社外のシステムと会話をするにあたってどれだけ少ない負荷の開発でXMLベースの会話へ対応できるか，そしてどれだけ早く実現できるかである。しかもXMLというベースとなる言語（専門的には「メタ言語」と呼ぶことが多い）ではなくて，「RosettaNet」語や「cXML」語といったその応用の言語を話せる通訳者でなくてはならない。
プラグイン感覚でいろいろな言語を話せるようになる「通訳者」こそがB2Bサーバの理想的な姿となる。しかも既存のシステムから見た場合，RosettaNetで取り決めているようなプロセスをアプリケーション側のアルゴリズムでハードコードするのでなく，B2Bサーバ側である程度，吸収してくれていることが肝要である。既存のシステムは，単純なAPIの操作でB2Bに参加できるようになる，これが理想である。
例えばB2B専用マシンが登場したとして，中堅企業において普及するケースを想定すると，そのマシンはソニーのプレイステーションのように手軽である必要がある。例えば「RosettaNet」のCD-ROMを挿入して電源を入れると「RosettaNet」のゲームが立ち上がり，「ebXML」のCD-ROMを挿入した場合には「ebXML」のゲームが立ち上がる，というイメージである。
もちろんニーズによっては「バイリンガル」でなく「トライリンガル」やそれ以上といった多言語を喋れるB2Bマシンになれることが望ましい。
一方既存の基幹システムとの接点では，以下のインタフェースを準備しておく必要があるだろう。
- COMインタフェース
- Javaインタフェース
- RDBインタフェース
COMやJavaインタフェースは，既存の開発環境を生かすこと，開発生産性の観点から言うまでもないであろう。そしてもう一つ忘れてはならないのが，RDBインタフェースである。現在の企業システムでは，企業データを最終的にはRDBに保存しているケースが多く，同じ形式のデータベースを利用できることの便宜性は高い。もちろんRDBに限らずノーツなどのグループウェアでも構わない。B2BサーバからRDBへの直接的なインタフェースを用意しておくと，場合によってはB2Bの処理結果を既存のRDBに自動的に格納させ，既存システムはそのRDBを常時監視するだけでB2Bに対応できるようにすることも可能である。そして既存システムへのデータ連携は，RDB同志なので非常に容易となる。XMLとB2B さて今度はB2Bサーバの内部的な要件を考えてみよう。（図2）
XMLとB2Bが一緒に語られることは多いが，それは単にRosettaNetやcXMLなどが，B2Bのデータ交換用フォーマットでXMLを採用しているからだけの理由で語るのは，あまりにも希薄である。XMLの利便性は社外の連絡手段としてだけでなく，社内のやりとりでも有効である。
プログラミングの経験のある者なら誰もが感じることだが，プログラムを汎用的にしようとすればするほど，iniファイルやパラメータ中の各項目の順番を変えても対応できるようにしたり，追加の項目が出てきても影響が最小限に済むようデザインをしたくなるものである。このようなときにXMLは重宝する。なぜならXMLは項目の追加や順番の変更に対して影響が最小限で済む特徴を持っているからである。この考え方を発展させ，プログラム間の結合性を高めようとインターフェイスをXMLで取り決めしたのが，Microsoftなどが採用したSOAP（Simple Object Access Protocol）である。 B2Bサーバの場合も例外ではなく，B2Bサーバ間の連絡手段だけでなく内部構造もXMLで統一すると効率性，便宜性が向上する。
XMLで内部的にも統一することのもう一つの利点は，他社B2Bサーバから自社B2Bサーバが呼び出されるときも，社内システムから自社B2Bサーバを呼び出すときも，共通のインタフェースでデザインできることである。
外部のB2Bサーバから送られるデータは前述したように各業種に合わせたXMLフォーマットである。B2Bサーバ内部のインタフェースもXMLであれば，この間の変換はXLSTの技術を応用すれば簡単にできる。一方，社内のシステムとB2Bサーバ内部のインタフェースであるXMLとの間はいくつかの変換ツールが活躍することとなる。前項で述べたようにCOMやJavaは社内システムとの連絡をとる際に重要なインターフェイスとなるが，幸運なことに最近は商用ベースのXMLエンジンにもCOM対応やJava対応のものが普及してきている。また社内システムに保存してあるRDBにしても，最近ではRDB自身がXMLインターフェイスを搭載し始めているし，XMLベンダからも連携する製品が登場している。このようなことからB2Bサーバをデザインする際，内外ともXMLで統一することは接続性において重要な要件となるし，併せて品質面，拡張性の面でも効力を発揮する重要な要素となる。
つまりXMLネイティブなB2Bサーバが究極のデザインである。B2Bサーバのデータ格納庫 B2Bサーバは，片や基幹システムと連携する以上，それ自身もある程度トランザクション処理に耐えられる設計ではなくてはならない。ログの管理は当然であるし，中間結果を格納するデータ格納庫なるものも必要となってくる。
ここはかなり難しい議論となるところだが，格納庫として相応しいデータベースは，どういったものになるのだろうか。もちろんRDBという選択肢も十分考えられるし実現可能な手段だと思う。しかし効率性，特に前述のXMLネイティブ性を考慮するとXMLネイティブなストレージ構造であることの方が適しているかもしれない。その方がインタフェースであるXMLフォーマットを表形式などデータベース形式に変換せずに済む分，効率的であるからである。
しかし現在のOSの持つファイル・システムの構造は必ずしもXMLのフォーマットに最適化されているわけではなく，例えオブジェクト構造のデザインをとったとしても最適なパフォーマンスが出せるかは検討が必要である。理想は，OSを介在しないネイティブなファイル・フォーマットの採用が決め手となるかも知れない。プラグイン感覚のビジネスロジック実装の重要性 B2B実現の際に，各業界でRosettaNetなどの標準化が進められていることは既に述べたが，標準化ができたところで，B2Bの普及にはまだ大きな壁が存在する。なぜならこの標準化で取り決めされたビジネス・ロジックを社内と繋ぐアプリケーションで実装しなければならないからである。現状のB2Bに挑戦している企業を見ていると，予想以上に工数がかかり苦労しているようである。この工数削減こそが「通訳者」であるB2Bサーバの役割であり，工数削減の度合いがB2Bサーバの評価を左右するといっても過言ではない。
できることならプラグイン感覚でビジネス・ロジックを実装でき，社内アプリケーション側はXMLのフォーマットやビジネス・ロジックを知らずともB2Bを実現できることが望ましい。
かなり内部アーキテクチャの話に寄るが，ではどのような言語で実装するのが最もプラグイン感覚に近いものになるのであろうか？
Java，Enterprise Java Beansという意見も当然出てくるだろう。ただ現実の開発環境を見る限り，Javaのスキルを持っている開発者の絶対的少なさ，バージョンやプラットフォームの違いによる微妙な不整合などが，普及への大きな阻害要因となっているように感じる。
XMLがテキスト・ベースであることからもXMLを使用する開発言語もスクリプト系であることが，普及に欠かせない要件となる可能性が高い。スクリプト系言語はインタプリタを実装しており開発も容易であり，各種ビジネス・ロジックの実装には多いに活躍するものと思われる。
このようなデザインを採ることで，B2BサーバはB2Bという目的だけでなく，アプリケーション・サーバとしての将来性も秘めることになる。その他必要な内部アーキテクチャ B2Bサーバの処理のきっかけとして，外部のB2Bサーバからの要求と社内システムからの要求のケースがあることを述べたが，もう一つ考えられるのはスケジュール・ベースでB2Bを行う場合である。相手企業のタイミングに合わせたり，月末などのタイミングに合わせてB2Bを起動することも考えられる。このような要件に合致するためにはB2Bサーバにはイベント管理の機能も内蔵しておく必要がある。同様な発想からインターネット上のプロトコルとしてはHTTP以外に，非同期に処理可能なSMTPへの対応も必要だろう。
その他暗号化を含めたセキュリティ機能やアクセスコントロール，ロギング管理，プロセス管理といった機能が必要なことは言うまでもない。BxBという発想 冒頭で「B2B」以外に「B2E」や「B2M」などバリエーションが流行り始めていることを述べたが，筆者はバリエーションを持たせるなら真中の「2」のところではないかと思っている。それが「BxB」である。「x」は「XML」の「x」でもあるし，複数の「B」（企業）の組み合わせで企業間取引が可能だという意味で「掛け算」の意味としても捉えることができる。「B2B」つまり「BtoB」は1対1の企業をイメージさせる。
EDIと異なりB2Bで求められていることは1対1ではなくて，n対nの企業間やりとりである。かつそれぞれのB2Bサーバが自立しており，どこかのスーパサーバを経由しなくても自由に同列の他社とB2Bが実現できる「自立分散型」である。このように柔軟な構成にも対応できるB2Bサーバの登場が，B2Bの普及には不可欠となってくるだろう。一方，最近ASPで流行ってきているホスティング・サービスへの対応も大事なポイントである。予算，スペースなど，さまざまな観点から自社内でB2Bサーバを持てない企業に対するB2Bホスティング・サービスの登場も普及に不可欠だろうと見ている。この場合はB2Bサーバがスーパサーバにもなれることが求められる。1台のB2Bサーバで内部的に論理分割可能であることが要件となる。
ホスティングが可能なスケーラビリティを兼ね備えながら，自立分散も可能なコンパクトなB2Bサーバの登場，これが今後のB2B普及のキーとなる。終わりに ネットワークの普及の影に「ルータ」の存在があったように，B2Bの普及の裏には「B2Bサーバ」の存在が重要なポイントとなっている。XMLの技術はもちろんのこと，その上で取り決められたB2Bに特化した各種XMLフレームワークの存在も重要である。この各種フレームワークを喋ることのできる「B2Bサーバ」が，如何に既存のシステムと親和性高く，容易に結び付けられるか，ここにかかっているといっても過言ではない。「B2Bサーバ」は「ルータ」のように専用マシンであっても構わない。既存のインターネット・サーバ上で動くソフトでも構わない。
他のテクノロジーの例に漏れずB2Bの世界でも日本は遅れをとっている。日本の「集団意識」の文化がもたらした弊害であると思う。なかなかグローバルでかつオープンな市場取引へのパラダイム変換ができないのである。しかし幸運なことにB2Bの普及はこれからである。ここ2∼3年が勝負どころだろう。B2Bが日本市場だけでなく，グローバルに展開されていくことが自明である以上，いまこそB2Bを真剣に検討すべきタイミングを迎えていると信じる。日本が主導権をとっていく可能性はまだまだ十分秘めている。
今後の動向が要注目である。
(C) 2001 Infoteria Corporation 【禁無断転載複製引用】
日時: 2001年04月23日 00:00 | | TrackBack
