XMLデータベースを本音で語る　エンジニア特別対談

1、プロローグ　～開発者の生の声を届けたい～

小野：皆様本日はお忙しい中、有難うございます。まず私からこの座談会を企画したきっかけをお話させて頂きます。あるシステムベンダの方とXMLデータベースに関する勉強会をやっていまして、その中で「XMLやXMLデータベースの良さは理解していて、XMLデータベースが合うのであれば積極的に採用したいと考えている。しかし、実際にデータベースの選定段階になると、【見事に全部RDB】になってしまう。これは如何なものか」という一言がきっかけでした。

梶原：確かにその通りですね。弊社は主に百貨店や通信テレコムなどの業界を中心としたシステム開発やパッケージ開発を手掛けているのですが、社内で構築したシステムは、【見事に全部RDB】でしたね。

小野：システムベンダの方は基本的に、お客様（エンドユーザ）の情報システム部門が指定するハードウエアやミドルウエアを使ってシステムを設計して提供するわけですから、お客様から「データベースはXMLデータベースで」と指定がない限り、使い慣れた、技術者も多いRDBを選択するのは自然な流れだと思います。一方で、システムベンダの営業や提案活動を行う方の一部には、XMLデータベースに対して、非常にポジティブな考えをお持ちの方も沢山おられます。RDBの苦手なデータ管理に対して、無理やりRDBを使うとデメリットがある事を認識されている方です。

安達：私は、エス・エフ・アイで昨年までシステム開発に携わり、今年から営業活動を行っていますが、システムの提案段階にかかわる営業の立場からしても、ご指摘の通り、適材適所で様々なデータベースを提案の中に入れていくべきだと思います。

小野：今回は、エス・エフ・アイさんで開発されたXMLデータベースを組み込んだ流通業向けの業務パッケージソフト「RiverTone簡単出荷」の開発経験を元に、一般論ではない、アプリケーション開発現場の生の声を詳しくお話し頂きたいと思います。

2、きっかけは流通BMS「業界標準のXMLメッセージに可能性を感じた」

小野：梶原さんは、流通業界で長年スーパーやドラッグストアといった業種の業務システムの構築に関わられていますが、一言でいうと、XMLの良い所はどこだと思われますか？

梶原：データフォーマットとしてのXMLの最大の特長は、「可読性」だと思います。データの中身を見ただけでその「意味」と「値」さらには「構造」までを読み取ることができます。CSVと比較して目的の情報に早くたどり着けるのはどちらか、それは一目瞭然ですね。

小野：人が探しやすい、誰でも見てわかりやすいというのは非常に重要ですね。しかしシステムやプログラムからみた場合はどうでしょうか？データがXML形式である事のデメリットもあるのではないでしょうか？

梶原：「タグ」が付いている分、プログラムの処理は重くなりますね。同時に処理する件数に比例してCPU負荷やメモリが必要になります。XMLが登場した2000年当時は、XMLを快適に処理するにはハードウエア・スペックが追いついていなかったと考えています。

小野：御社は流通業向けのシステムインテグレーションや通信パッケージの開発を行っていますが、その分野における、XMLの位置付けや最新動向についてお話頂けますでしょうか。

梶原：流通業界のシステムは、POSシステムに代表される「販売情報管理システム」と、メーカー、卸、小売などが受発注を行う「企業間電子商取引システム」、さらには「商品情報管理システム」や「市場分析・マーケティングシステム」など様々です。その中で、小売、卸、メーカーなど数多くの企業や団体が参加し「流通システム標準化事業」が発足、企業間の電子商取引（EDI）の効率化を目指し、受発注のデータを専用回線ではなくインターネット上で交換することを前提にした、XMLベースのメッセージフォーマットである「流通ビジネスメッセージ標準（流通BMS）」が策定されました。

小野：流通BMSは、流通システムにとってどんなメリットがあるのですか？

梶原：流通業では、専用回線と固定長のデータフォーマットでEDIが行われていましたが、通信コストが高価、モデムが必要で保守コストが高い、漢字、画像が送れないという問題がありました。

【図1：流通BMSの概要とメリット】

小野：メッセージフォーマット自体は、特に問題はなかったのでしょうか？

梶原：実は、小売企業各社には、独自のメッセージフォーマットが存在するため、複数の小売企業と取引がある卸・メーカーは、固定的なメッセージフォーマットでは既存の固定長のフォーマットでは対応が困難になっていました。このような対応には、プログラムの修正が必要で、メッセージ毎にデータ変換機能を行うマッピングプログラムを都度、実装していました。

小野：プログラムを開発するシステムベンダも対応が大変なのではないかと思いますが、具体的にどのような事が現場では起こっていたのでしょうか。

梶原：システムやプログラムを設計開発するシステムベンダは、お客様の取引先が増える、または取引ルールが追加変更される度にプログラムを個別に開発し、テストしていました。お客様もシステムベンダも大変な作業でしたし、個々のプログラムが複雑に絡み合い、修正する際の影響範囲がどんどん拡大してしまいます。お客様のビジネスの形態や取引ルールが激しく変化する今の時代には全く考えられないですね。また、運用段階では、取引メッセージの内容を照会する必要が頻繁に起こるのですが、システムが複雑すぎるため、メッセージの内容をシステムから取り出すだけの専門の技術者がお客様先に常駐するなど、運用保守にかかるコストが必要でした。

小野：流通BMSになる事で、お客様は「通信コストの削減と処理コスト削減」「データ照会作業の省力化」「取引形態やルールの変更へのスピーディな対応」といったメリットが享受できるのですね。

梶原：はい、その通りです。流通BMSの策定が始まってすぐに、お客様だけでなくシステムベンダにとってのメリットを感じていました。もちろん流通BMSのベース技術であるXMLという技術にも大いなる可能性を感じていました。

3、XMLベースのメッセージをそのままデータベースに格納するメリットとは

小野：流通業向けの受発注業務に使うEDIパッケージを、流通BMSに対応させる時、製品企画時点でXMLデータベースを組み込むという発想はありましたか？

梶原：当社は、流通BMSに対応した「RiverTone簡単出荷」という製品を自社開発しています。インターネットを使用したEDIと流通BMSに対応した業務アプリケーションを一体化させたソフトウェアです。主な機能は、新規伝票入力、受注から出荷までの一連の流れ、さらに仕入計上や支払案内などの情報系機能の受信も可能です。私の頭の中では、この製品にXMLデータベースを組み込むことによるメリットは既に頭の中で整理されていて、後は製品と実現方法を決めるだけでした

小野：そのメリットについて、もう少し詳しく教えて頂けませんでしょうか。

安達：流通BMSのXMSメッセージの受信処理を例にとって説明します。 流通BMSのXMLデータを受信してRDBに格納する場合、一般的に下記のような4つの工程が必要となります。
① 通信ソフトでXML形式のメッセージを受信
② XMLデータの妥当性を判断するために、スキーマチェックを行う。
③ XMLデータをCSV変換する。
④ 変換したデータの入力チェックを再度行い、RDBにデータを登録する。
1つのメッセージを受信する過程で、2回の入力チェックとCSV変換処理が必要となります。さらに、プログラムの保守範囲が広がってしまうことで導入コストも増加します。

流通BMSのXMLデータをXMLデータベースにそのまま格納する場合、以下のようなシンプルな処理になります。
① 通信ソフトでXML形式のメッセージを受信
② 受信したXMLデータをXMLスキーマで入力チェック、プログラムレスで妥当性を判断
③ そのままXMLデータベースに格納
このように、いくつかの無駄な処理が排除され、パッケージの開発コストが削減できるだけでなく、パッケージとしての信頼性も増します。XMLデータベースのメリットは、開発コスト・保守負荷の削減が実現できた事だと思います。

【図2:アプリケーション開発におけるXML DBのメリット】

小野：開発コスト削減や保守の負荷の軽減は、そのまま製品価格や導入・保守コストに反映されるため、ユーザもそのメリットを享受できるわけですね。その他のメリットについては如何でしょうか？

安達：小売業は企業毎に受発注のメッセージフォーマットが微妙に異なります。XMLベースのシステムでは、お客様単位でXMLスキーマの追加を行うだけで吸収できるため、このような仕様の微妙なゆれを「プログラムレス」で対応する事が可能となりました。従来のRDBアプローチでは、【CSVフォーマット変更】⇒【DBMS側のテーブル設計変更】⇒【マッピングプログラム変更】⇒【テスト】といった工程が必須で、企業は新たな取引先が増える度に、時間とコストをかけてシステム運用担当のベンダにメンテナンスを依頼していたのです。ある企業では、そのコストだけで年間数千万円かかっていたと言われています。

小野：XMLデータベースのパフォーマンス面の評価をお話頂けますでしょうか。

安達：通常の処理においては全く問題ありませんでしたね。ただ、一部の機能については、パフォーマンス・チューニングの時に苦労した点もありました。

4、XMLデータベース内蔵・流通業向け受発注業務パッケージ開発秘話

安達：流通業向けの受発注業務に使うEDIパッケージは、一般的に1日に数百の伝票（トランザクション）と数千の明細（レコード）を処理します。「RiverTone簡単出荷」に、「データ一括ダウンロード」機能がありますが、パフォーマンス検証の際は、月次のデータ一括処理でパフォーマンス･チューニングを行いました。

小野：具体的にどのようなチューニングを行いましたか？

安達：XMLのデータ構造の一部見直しを行いました。また、XQueryの記述で、データベースアクセスをより効率良く行う方法に見直しを行いました。この2点を徹底的に見直し、パフォーマンステストを繰り返すことで、問題は解決に向かいました。もちろん、全て自力では解決できなかったので、メーカー（サイバーテック）の技術サポートは必須でした。

小野：当社のエンジニアが御社の事務所に出向き、トラブルシューティングを行った事もありましたね。結果的に、開発期間はどのくらいだったのでしょか？

安達：当社のエンジニアのトレーニング期間も含めて、約4カ月で開発を行いました。一番時間がかかったのが、開発を担当するエンジニアへのトレーニングと、XMLのデータ構造も含めた全体アーキテクチャの設計でした。この2つの壁を越えてしまった後の開発工程やテスト工程は、非常に短期間で完了しました。

小野：御社の中で、XML技術を使った開発の経験者は、何名程おられたのですか？

梶原：私だけです(笑)。後は全員RDBエンジニアでしたから、まずは社内の開発エンジニアに対してXMLへの「心理的障壁」を取り払い、プログラミングノウハウを伝授する事から始めました。

小野：XMLやXMLデータベースに対する「心理的障壁」について、もう少し詳しく教えてください。

梶原：エンジニアにとって、新しい技術に触れる事はとても重要であると同時に、アプリケーションを設計する際の設計思想などについては、慣れ親しんだ方法から抜け出すことができないのです。当社もエンジニアのほとんどが、RDBしか触った事がないエンジニアでした。そのような状況の中でXMLデータベースを製品に組み込む決断をし、社内を説得する事は開発よりも大変な作業だったと言えます。

5、今後の展望とシステムベンダへの提言　～今こそXMLデータベースを学ぶチャンス～

小野：XMLやXMLデータベースだけでなく、新しい技術の適用については、どこの企業も慎重になるのは日本のシステムベンダだけでなく、ユーザ企業の情報システム部門も同じだと思いますが、エンジニアの視点から見て、今後どのような啓蒙活動が必要と感じていますか？

梶原：システムベンダの立場は、「顧客からXMLデータベースを使いたい、と指名されないと採用できない」という事だと思います。しかし、それだけで本当に良いのかと言いたい。顧客にとってのITシステムは、課題を解決するための手段であり、ITシステムのプロであるシステムベンダは、適材適所で新しい技術やしくみを積極的に提案すべきだと思います。

小野：ご指摘の通りだと思います。データベースを扱う上でRDBの良さとXML DBの良さ、この両方を本当の意味で知っているエンジニアが、顧客提案の競争を勝ち抜く事が出来るのだと思います。「顧客ニーズの多様化」「システム投資規模の縮小」「IT技術のライフサイクルの短縮化」システムベンダにとっては、厳しい時代だからこそ、XMLデータベースを学び、顧客提案の武器として使う絶好の機会ではないかと思います。

梶原：その通りです。エンジニアだけでなく、システムベンダの営業も是非､XMLデータベースを活用したシステムの構築事例やビジネスモデルを勉強して頂きたいと思います。私たちは、実際にビジネスを推進し、さらにXMデータベースを使ったシステムを開発した経験者として、一人でも多くの方にこの経験を伝えていければと考えています。

小野：はい、今後ともどうぞ宜しくお願いいたします。本日は本当に有難うございました。

関連コンテンツ

「流通BMS対応：XML DBを活用した次世代のEDIソリューション」：
https://www.cybertech.co.jp/xml/contents/xmlxmldb/talk/special_sfi-scm.php