座談会 ～XMLデータベースの活かしどころ、RDBの泣きどころ～柔らかいデータとRDBのミスマッチを討論する～
2004年6月1日 更新
■座談会メンバー
三井情報開発株式会社
チーフテクニカルマネージャ 鉢蝋 吉久 氏
XML DB製品「NeoCore」を販売・サポートする立場から、ユーザー事例に基づいた意見を述べる。
ウルシステムズ株式会社
ディレクター 林 浩一 氏
XML DB製品を利用した電子カタログや、SOAによる企業システム連携などのソリューション開発を通じて、XMLの高次利用を啓蒙・推進している。ユーザー側に立ってIT化の助言を行うコンサルタントの立場で、ユーザーと開発者の接点に鋭い指摘を放つ。雑誌記事執筆、セミナー講演も多数あり。
株式会社日本ユニテック
主任システムズエンジニア 吉田 晃伸 氏
XMLによるドキュメントソリューションを数多く手掛け、NeoCoreセミナーの講師も務める。XML書籍の著書も多数あり。
データ構造の変更に対応できるデータベース
――NeoCoreをはじめとするXML DBがよく利用され成功事例も多いのは、企業の商品カタログだといわれています。NeoCoreを使ったシステム開発に携わっている鉢蝋さんから、そのあたりの事情をお話いただけますか。
鉢蝋：商品カタログがWebで公開されるようになり、しかも改訂の間隔が短くなっています。印刷物なら一度作ると、例えば、3カ月間は改訂しなくてもよかった。それはコストの問題で3カ月後でないと改訂できなかっただけで、本当はもっと細かく改訂したいはずです。
ところが、カタログをデータベース化するユーザーは「年に4回ぐらいは改訂したいね」というんです。本当は毎月でも変えたいはずなのに、初めからできないと思いこんでいる。NeoCoreを使って「何回でも変えていいですよ」というシステムを作ったところ、年に20回から40回ぐらい改訂するようになりました。
――その案件ではどのタイミングでRDBからNeoCoreにリプレイスされたのですか。
鉢蝋：カタログをWeb公開しようという企画であるSIerさんがRDBを作り、運用コストを試算してみたところ、ユーザーが考えていたコストの4倍から5倍になったそうです。RDBでシステムは作ったのに、最終的なGOサインが出なかった。
運用コストについては、「修正要望がたまってから（システム変更を）やりますよ」というのがRDB型のシステム開発・運用のスタイル。RDBでも「新しい項目を追加するとコストはいくら」とはじけるのですが、将来の要望（改訂の回数）は分からないので適正なコストは算出できない。そこで「SEを2人にプログラマ4人をスタンバイさせておきます」みたいな話になり、非常に高い運用コストになってしまった。
――XML DBであれば、データ構造（スキーマ）が変更されても、RDBのようにテーブルやインデックスを作り直す必要はない、ということですね。
鉢蝋：そう、スキーマ変更に柔軟に対応できるわけです。もう1つ、XML DBの利点はスキーマレスで動くことです。アプリケーション側に新しい商品情報のロジックを加えても、XML DB側は変更する必要はなく、すぐに新しいデータ運用が始められます。あるユーザーでは、1年に40回のカタログ改訂を行って、その間に1回もデータベースを止めませんでした。
多くの業務を切り捨てて成り立つRDBシステム
――林さんもXML DBのシステム開発を数多く経験されているそうですね。
林：カタログソリューションのデータベース化はXML DBが適している分野だと思いますね。注意するべきポイントの1つは、カタログの価格表示です。製造元なら価格を固定にしておいて構わないかもしれませんが、代理店などがエンドユーザーや取引先に見せる場合は相手に合わせて価格を変える、ワン・ツー・ワン的な処理が発生するので、SIerが要件定義に苦労するところだと思います。
鉢蝋：先ほどのユーザー事例では、カタログサイトの構築、運用がうまくいき、3カ月後には受発注業務が稼働し始めたのですが、BtoCとBtoBにまたがっていたため、取引条件が極めて複雑でした。バックマージンは発生するし、在庫取り置きならば倉庫使用料も計算しなくてはいけない。取引先は全部で50社ほどなのですが、1社ごとに取引条件が違っていました。そのあたりは実際にシステムを作り込んでいかないとユーザーも教えてくれません。作って動かしてみて、初めて「ここが足りない」といわれる。XML DBの場合、このような開発スタイルが多くなります。
――そのユーザーの場合、紙ベースのカタログ＋RDBのころは、どのように業務処理をしていたのですか。
鉢蝋：RDBでは価格の処理はできていませんでした。RDBから抜き出した情報をもとに事務員が手作業で処理していたんです。
林：RDBで処理できるのは標準の情報であって、それ以外の複雑なローカルルールが入ってくる価格のような処理はしにくいわけですね。
私は現在、システム開発の上流工程でコンサルティングを行っているのですが、業務分析をやっていると、そうした例外処理がたくさん出てきます。そのすべてをシステムの要件に取り込んでいるときりがないので、システムで対応するところと運用で対応するところを切り分けないといけません。むしろ、それがきちんとできるSIerがよいSIerといえます。ユーザーの望むことを全部そのままシステムに反映していたら、システムはいつまでも完成しません。できることを見切ったうえで、データベースでどの情報をどう使うのかという観点から、やることとやらないことを明確にアドバイスする必要があるんです。
――本当に開発できるかという点から、どこまでシステムでやるかをきちんと決めないといけない。
林：そのとおりです。ただ、そのSIerがどれだけ使えるツールや技術を持っているかで、その結果は変わってきます。XML DBを使いこなせて、どれぐらいのことができるかが分かっていれば、RDBよりも制約を少なくできるケースはかなりあると思います。
XML DBのSIerにとってのメリットとは？
――システムの運用フェイズでユーザーからの変更要求が多くなると、一般にSIerが赤字になるといわれています。XML DBでも同じ構造ではないでしょうか。
鉢蝋：システム変更の料金は一般に、保守契約を結んでSEを張り付けて定額にするケースが多いのですが、RDBに比べるとオーバーヘッドが減るので、定額でもSIerはペイできます。
――RDBだとアプリケーションの変更に加えてデータベース再構築となるところを、XML DBならアプリケーションの変更だけで切り抜けられるわけですね。
鉢蝋：そうです。ユーザーにとっても、従来なら1回のシステム変更で100万円単位のコストがかかっていたものが、数十万円の定額で自由に直せるという割安感があります。
林：ビジネスとして当然のことですが、SIerはシステムが完成すると開発プロジェクトを解散して、また別の開発プロジェクトを編成します。なので同じ開発者がずっと保守作業を担当することはほとんどありません。保守担当者がシステムの内容を完全に引き継いで、追加開発できるような体制を整えておくのは非常にコストがかかるんです。ユーザーも普通はそこまでの費用は負担できませんから、システムは作ったときが一番よくて、その後、どんどん使えなくなっていきます。いまの鉢蝋さんの話は、作ったときからどんどんよくなるという構図だと思います。莫大な投資をして開発したシステムの価値をいかに下げないようにしていくか。これからは、これが重要になってくると思います。
――吉田さんはNeoCore HANDS-ONセミナーの講師をされていますが、参加者の中にカタログ関連のシステムをXML DBに変えてみたいというニーズはありましたか。
吉田：マニュアル作成の話はありました。そのケースでは、製品ごとにマニュアルに記載するデータ項目がかなり違っていて、マニュアル作成部門の人たちは紙ベースで設計部門から情報をもらってマニュアルを作成していましたが、それだと手間もかかり、バージョンアップの度にコストがかかるのが問題でした。
そこでシステム化を目指したのですが、RDBだと完全に表現できない部分があった。自分たちでデータ項目と内容を決められるシステムが理想だったことから、XML DBを採用したそうです。設計部門はXML DBからXML形式のデータを出力し、マニュアル作成部門の人たちはそこから必要な情報を引っ張っています。マニュアルの作成サイクルが早くなり、スペック変更が生じても対応しやすくなったそうです。
RDBでできることはRDBで。リプレイスよりも相互補完の関係へ
――これまでXML DBのメリットを中心にお話しいただきました。視点を変えて、XML DBだとつらい面は何かありますか。
鉢蝋：「OracleでできるのになぜXML DBが必要なの？」といわれるのがつらいですね。「じゃあ、Oracleでやってください」というしかない（笑）。実際、RDBの方が実績も豊富だし、売る側も「RDBでできるとこはRDBでやった方がいいですよ」というべきです。RDBでできるものを無理にXML DBへリプレイスすると、第一世代XML DBのようになってしまいます。
| XML DBテクノロジ談義 vol1 |
|---|
『第一世代XML DBはなぜ普及しなかったのか』 林：第一世代というとXML 1.0の標準化とほぼ同時期に登場した一群のXML DBのことですね。当時のXML DBがつまずいたのは、製品の能力の問題もありましたが、使い方を間違えていたケースが多かったと思います。RDBと同じデータ構造で情報をXML DBに乗せてしまい、パフォーマンスが出ないという結果を招いてしまった。RDBのテーブルをそのままXMLで表現すると、RDBに比べてパフォーマンスが出ません。もともとRDBに合わせたデータ構造をXML DBに置き換えても、RDBより遅くなるのは当たり前です。 鉢蝋：更新はかなり速くなっています。ただ、XML DBはロックの値がRDBより大きくなります。RDBなら特定のカラムだけをロックすればよいのですが、XML DBの場合は、カラムの下に子ノードがあるかもしれないので、簡単には切り捨てられない。NeoCoreでは、格納したときのドキュメント情報のXMLサイズがロック単位となります。更新がすごく多いシステムだと、XML文書を小さくして更新するなどのテクニックが必要になります。動的に更新する場合はロックの粒度を下げるわけです。 |
――RDBとXML DBの切り分けは、判断が難しそうですね。
鉢蝋：社内にそれなりのIT部門を抱えているユーザーならば自分たちで判断するでしょうが、現実には多くの場合、SIerが判断しています。ユーザーはどのようなデータベース製品であって、コストに見合うパフォーマンスが得られればよくて、XML DBを使うことの利点はSIerに一番あるからです。
林：ユーザー側の知識にもよりますね。先ほどのカタログサイトの話でいえば、年40回の変更が可能だと知っていればSIerにしつこく要求できますが、知らなければ、SIerに「そんなことできませんよ」といわれたら我慢するしかありません。
鉢蝋：SIerは慣れているRDBを安易に選びがちですね。SIerにとって年に4回しかスキーマを変えられないことのデメリットは何もない。ユーザーも中途半端にITを知っていると、SIerから「できない」といわれれば納得してしまうでしょう。
――かえってITを知らないと、スキーマ変更などできて当然と考えるでしょうね。
鉢蝋：あるユーザーの方に聞いた話ですが、貨物のトラッキング・システム開発があって、「季節ごとにデータ項目を変えられるようにしてほしい」と要求したら、開発者に「それはできません」といわれた。RDBのことは何も分からなかったので「できないはずはない」と突っぱね、開発者にRDBで無理やり作ってもらったそうです。季節ごとにデータ項目を変えるといっても、項目が確定するのは前の晩という状況だったので、ずいぶん無理な要求ですね。その意味で、ユーザーのレベルが高いか、低いかのどちらかがよいのでしょう（笑）。
林：最近話題の無線ICタグを使ったトレーサビリティの話にしても、買った商品がどういう経路で流れているかを管理するという簡単な話では終わりません。例えば、お弁当の中にはいろんなおかずが入っていますが、それぞれのおかずの材料の経路情報はどうたどるんだという話になってくる。
――おかずの材料は、頻繁に変わるものですよね。それに伴って材料の種類もがらっと変わる。XMLのツリー構造でないと扱えそうにありません。
林：本当にやりたいことを突き詰めていくと、柔軟な構造を持ったXMLが必要になってくる場合がたくさんあります。それをXML DBでは自然に扱えるようになっています。どうやって有効に使っていくか。これから方法論を磨いていくべきところでしょう。
鉢蝋：逆に要求が固まっていれば、トレーサビリティシステムもRDBでできないことはないと思います。ただ、仕様が決まった次の日に「これを変えて」といわれるとRDBはつらい。先ほど話をした貨物のトラッキングシステムでも、開発者からは「先に変更するデータ項目をすべて出してくれ」と切り返されたそうです。現実にはそんなこと不可能です。そこで、システムは簡単に変えられないからビジネスも変えらない、というおかしな話になる。
――ビジネスが激しく変化する現在、RDBでは対応できない部分が増えているのですね。
鉢蝋：カタログサイトと受発注システムを連携させているユーザーの場合、新しい取引先が出てきたら簡単にデータを増やせるようになっています。どのようなデータ項目が増えるかなんて予測はできませんからね。どちらにしろ、ユーザーから「取引先を変えるからこういう業務ルールを入れて」といわれたら、その業務ルールを取り込めるデータベースを作らないといけない。ただ、そのルールを取り込むのに半年待ってくださいというのか、すぐに対応できるのかの違いがあります。
林：基幹業務（金融や財務管理など）に近づいていくとデータはかっちりしていかざるを得ないところがあり、RDBが適しているような気がします。それが情報系に近づいてくると、データ（項目）を変えられないというのは致命的でしょう。
ExcelとRDBの中間にある柔らかいデータをどう扱うか
――情報系システム開発で何か参考となるユーザー事例はありますか。
鉢蝋：ある科学データを扱うユーザーの事例が参考になると思います。データはExcelで管理していて、データ項目もほぼ分かっている。データベースに格納して情報を共有したいという案件でしたが、RDBにうまく格納できない。
もともとExcelで管理していたので、無茶なデータがいっぱいありました。ある品目は3回試験をやって平均をとるが、別の品目は5回の平均をとるなどバラバラ。しかもExcelのようにデータを横につなげていって、自由に項目を挿入したいなど要求も厳しいものでした。そこでXML DBを用いたわけです。
林：それはスキーマを決めることのできない非定型データですね。先ほどのカタログサイトの話はスキーマを頻繁に変更するためにXML DBを使ったわけですが、この話はあまりにもデータ構造が複雑なのでスキーマも作れないという違う種類の話です。
鉢蝋：このユーザーは面白いことに、XML DBからCSV形式でデータを出力してExcelに戻し、分析レポートを作成しています。ExcelとExcelの間にXML DBがある感じです。
――Excelでデータをため込み、それをデータベース化したいと考えている企業は多いでしょうね。
鉢蝋：Excelのデータを共有したいというニーズは必ず出てきます。先ほど話をした貨物のトラッキングシステムも、データベース化する以前はExcelで管理して、メールで情報共有をしていましたから。
――吉田さんがかかわっているマニュアル系では、その傾向が強くないですか。
吉田：マニュアルだと、スキーマがきちんと決まっている部分と同時に、表現を自由に変えたいというニーズが強いですね。項目が決まっている範囲ならRDBで管理できるのですが、その範囲外は手作業になってしまうという課題があるので、そこをシステムでどうやって補っていくか。
製品の市場投入サイクルがどんどん短くなってきて、マニュアルも早く作成しなくてはいけない。たとえデータ項目は決まっていても、それを自由に表現したり、データ項目以外の内容を組み合わせたりできる柔軟なデータベースが必要になっています。
ドキュメント系データはXMLの独壇場
――三井物産では現在、基幹系システムのリプレイスに伴って、業務処理マニュアルを電子化して共有しようとしているそうですね。NeoCoreが採用された経緯は？
鉢蝋：総合商社なので多くの取引先があり、取引先ごとに業務処理の手順が決まっています。従来は営業と営業サポートが連携して業務処理を行っていましたが、これからはセンターにアウトソーシングしていくことになった。それには手順書のデータベース化と情報共有が必要になります。最初はあるXML DB製品の採用を検討しましたが、パフォーマンスが出なくてダメで、次にRDBを検討しましたが、そもそもXMLが前提だったのでやはりダメで、最終的にNeoCoreの採用に落ち着きました（笑）。
――そもそもなぜXMLだったのですか。
鉢蝋：データ項目が変わってしまうからです。取引先が変わると新しい属性が出てきます。そもそものカテゴリも変わってくる可能性があります。XML形式でないと対処できないですからです。
――林さんは、XML DB製品をベースにしたソリューション開発に携わっていたころ、ドキュメント系のシステムを手掛けることは多かったのですか？
林：数年前の話になりますが、それほど多くはありませんでした。1つの理由は、ナレッジマネジメントや文書管理システムでは必ず全文検索が求められるからです。例えば、営業日報のようなものなら、XMLの構造として項目を切れるのですが、その下にテキストがどっとあると、XML DBと全文検索を組み合わせないといけない。初期のXML DBのバージョンは日本語の全文検索とそれほど効率よく連携できなかったので、別エンジンを併用するわけです。当時はXML DBを使ったシステムの価格自体が高かったこともあって、よほど余力のあるユーザーでないとそうした構成はとれなくて、それほど広く受け入れられなかったんだと思います。
吉田：マニュアル作成の分野では、SGMLの時代から文書の構造化に取り組んでいる人もいますので、取り組みやすいんだと思います。ある程度標準化されたスキーマも存在していますので、ドキュメントのデータを構造化しやすく、文書のXML化に取り組みやすい面がありますね。
林：マニュアルは部品化してシステマティックに記述するからやりやすいんでしょう。ただ、それでもすべてをRDB化していくと、どこかで破たんしてしまって、どんどん使われなくなって個人のノウハウが埋もれていってしまう。
吉田：一般的には、データを構造化するという意識がまだ薄いんだと思います。管理できるものと管理できないものに分けてしまって、その中間にあるものを管理しようとしていない。それなので、RDBか検索エンジンかのどちらかという選択肢しかイメージできないんです。
林：私は電子カタログはもっと普及すると思っていました。導入した企業は必ずといっていいほど「よかった」といっているので、しかるべき企業に入る可能性は大きいと思うのですが。
鉢蝋：これからの課題ですね。去年の案件の中には電子カタログの案件がかなりありました。
――eラーニング分野でのXML DB利用はどうでしょうか。
林：教科書をXML化するという話もありますが、いろいろ細かいところ、数式のフォントなどは統一しにくく、普及のネックになっています。
吉田：わたしたちも論文システムをいくつか手掛けていますが、筆者によって細かな部分のこだわりが違うのでけっこう大変でした。数式をXML化する規格として「MathML」が存在しています。論文システムにも適用しようとしましたが、やはり筆者のこだわりが強くて全然ダメでしたね（笑）。
林：現状でもeラーニングはけっこう流行っていますが、既存のコンテンツをFlashにしているだけのものがほとんど。本当ならXML DBにして、カスタマイズした設問を動的に生成するような仕組みが必要なんですけどね。
吉田：私の手掛けたある理工系のeラーニングシステムではXML DBを使って教材データの管理をしています。さまざまな制約からフリーウェアのXML DBである「Xindice」を採用しました。問題の記述にXMLを採用していますが、自由に問題を記述できるようにしているので処理が重く、頻繁に更新も走っているので、パフォーマンス的にちょっとつらいですね。ただ、XMLで標準化していく意義が大きいんだと思います。
| XML DBテクノロジ談義 vol2 |
|---|
『XML標準化のメリット、デメリット』 鉢蝋：XMLに関連する技術が完全に標準化されていなくてもXML DBは使えると思います。逆に完全に標準化されたらRDBでも構わない。ただ、すべて標準化されてガチガチに固まるということは、現実にあり得ないと思います。きっと永久に変わり続ける。そういう前提で動いた方がよいでしょうか。もちろん、ある程度の標準化は必要なのでしょうが。XMLの議論は大抵、標準化と結び付いてきますが、完全な標準化には何年もかかります。 林：XMLの最大のメリットの1つは、標準化に必要なプロセスを大幅に短縮したという点ですね。以前はXMLのような扱いやすい共通データフォーマットがなかったので、標準化メンバーはそこから決めていく必要があった。いまではXMLのスキーマを定義すれば済むので、本質的なところの合意さえできれば、標準化のプロセスは大幅に短縮されると思います。 |
RDBのひずみを矯正するXML DB
林：オラクル社のOracle XML DBとNeoCoreは競合することがありますか。
鉢蝋：あまりないですね。
林：Oracle XML DBはスキーマが必要になりますが、RDB製品でありながらXMLネイティブといえるアプローチをとっています。スキーマを使うなら有力な選択肢だと思います。RDBも付いてきますし（笑）。
吉田：Oracle9iで導入されたOracle XML DBでびっくりしたのは、スキーマを切り直すとデータを再格納しなくてはいけないところでしたね。データ量が多いとつらいでしょう。最新バージョンのOracle 10gでは改善されたようですが。
鉢蝋：最近はOracle（Database）と競合することも少なくなっています。以前は、「社内にあるOracleは使えないのか」と聞かれることがよくありましたが。
――NeoCoreを導入するユーザーはどのような規模の企業なのですか。
鉢蝋：データベースを購入できるぐらいの企業ならどこでも（笑）。価格は高いので必然的に規模の大きな企業が多くなっていますが、従業員1000人以下の企業もありますよ。一番小さな企業は100人以下の工場でした。組み込みなら個人ユーザーもありますよ。
――RDBからXML DBにシフトする際の共通パターンのようなものは何かありますか。
林：運用のないシステムはありません。何かしら工夫して運用しています。先ほども話したようにシステムは最初が最もニーズにフィットしていて、時間とともにだんだん合わなくなってきます。新しい処理を取り込んだりしていくうちに、システムと業務にひずみが出てくるんですね。そのタイミングがXML DBの採用を検討するきっかけになると思います。少しずつの変化でひずみがたまってくる場合もありますし、組織変更や事業合併などの大きな変化により一気にひずみが発生する場合もあります。
鉢蝋：初期投資にたくさんお金をかけられないシステム開発の場合、SIerは3回ぐらいの追加開発で利益を出そうとします。まず、ユーザーの要望の7割ぐらいの範囲でシステムを作り、1割ずつ機能を上げていく。その1割の機能アップのための開発が従来の半分のコストで済む、これこそSIerがXML DBを利用するメリットです。フェイズ分けして何段階かでシステムを完成させる場合にXML DBはフィットします。
――開発者側のメリットの方が大きいのですか。
鉢蝋：開発者側のメリットというのはユーザーのメリットでもあります。運用し始めてから楽なシステムを作りたいなら、XML DBのような柔らかいデータを扱えるデータベースが必要ですね。ユーザーにとってXMLかどうかは関係ないですから。
吉田：逆にいえば、スキーマが決まっていれば、RDBでもいいわけですよね。
鉢蝋：そうです。やりたいことが決まっているならRDBで作った方がよいと思います。
吉田：ただ最近、企業の中にしっかりした情報システム部門がなくなっていて、仕様をきっちり固めてからSIerに委託するケースが少ない気がします。その意味でも柔らかなデータベースが必要だと感じます。
ユーザーの認知度アップが不可欠
――企業のWeb活用が本格化しているので、XML DBはこれから急速に普及してもおかしくない。そこまで進んでいかない「壁」は何だとお考えですか。
鉢蝋：認知度でしょう。RDBで発生しているひずみを取り除く解決策がXML DBかもしれない。このことがまだ十分に知られていないですね。
林：ある程度の知識があっても、乗り替えようという気持ちにはなっていないケースも多そうです。
――運用コストが下がるという話は、経営側の人を説得する材料となりますか。
林：難しいですね。開発するコストを問題にしているときに「次にくるかもしれない追加開発のコストが安くなりますよ」といっても、なかなか納得してくれませんね。XML DBの初期コストはRDBと同じぐらいですが、よくよく考えると、長期には絶対得というケースは結構あると思いますよ。
鉢蝋：そうですね。だから既存システムの償却が終わったのでリプレイスという形でXML DBを導入する企業が多いですね。
それから「うちはまだXMLをやってないから」という発想を持つユーザーも多いですね。そういう場合は、「XMLをやっている、やってないは関係ありません。RDBで何か困っていることはないですか」と聞いて、「こういう解決策もあります」と（NeoCoreの効能を）説明すると、大抵は「なるほどね」という反応が返ってきます。
――林さんがコンサルティングするユーザーの中には、XMLに対するアレルギーはありますか。
林：経営層にとってXMLを利用するかどうかは関心の範囲外です。情シスの人たちになると「長期的に見れば、XMLで情報が流れて連携していく」という認識はあるようです。一方で、「ただ、まだ早いかな」という気持ちもある（笑）。それは情シスの人たちが主に基幹系を担当しているからで、本当は情報系でXMLはもっと使いでがあるはずなんです。その部分が知られていない。先ほどのカタログサイトの年40回の変更などが典型例ですが、ユーザーが「こんなことまでできるんだ」という部分を知った上でSIerに要求しないといけないんです。
――SIerの存在が「壁」になっている？
林：最近、SIerはものすごくハイリスクなビジネスなんですよ。開発期間は短くなっていますし、要求も多様化しています。新しいツールにはけっこうバグが残っていますから、ただでさえリスクが高いのに、はじめてのテクノロジを入れてさらにリスクを増やしたくないという気持ちはよく分かります。それにエンジニアもみんながみんなむやみに勉強熱心なわけではないんですね（笑）。それでなくてもキャッチアップしなければならない技術が山ほどある中で、まったく経験のないテクノロジを覚えたいと思いますか？ OracleでできることはOracleでやりたい。そう考えるエンジニアは結構多いと思いますし、別に悪いことでもありません。
それなのでユーザーが「こんなことができるんだ」「将来的にはここまでできるんだ」と理解したうえで、XML DBを選択肢の中に入れていくしかありません。SIerの壁はユーザー自身で乗り超えるしかない。
鉢蝋：そのとおりだと思います。先の貨物のトラッキングシステムでも、ユーザーにXML DBの知識があれば、必ず検討していたと思いますから。
――吉田さんのところのセミナー参加者の反応はいかがですか。
吉田：まだ1回しか開催していませんが、そのときの実感からいえば、両極端のように思います。XMLにある程度精通していて、XML DBをもっと活用するためのポイントを探りにきたユーザーと、XMLが頭の片隅にあって基本を学びに来たユーザーに分かれていました。入門コースの方は管理者の人が多くて、XML DBがどれぐらい使えるものなのか、RDBと何が違うのかを学びにきていました。徐々にXML DBが検討対象になっているようです。
鉢蝋：興味を持つ人は増えていますが、自社で使うとなるとためらう人も多いのが実状で、ブレークポイントにはまだ達していません。そのため多くの人にNeoCoreの効能を実感してもらうために、5月から最新バージョン「NeoCore XMS 3.0」を非商用・個人利用に限定して無償化しています（無償提供版の名称は「Xpriori＝エクスプリオリ）」）。
| XML DBテクノロジ談義 vol3 |
|---|
『NeoCoreのインデックス技術「DPP」』 鉢蝋：NeoCoreの検索パフォーマンスですが、やはり速い検索と遅い検索があります。その違いはそれほど難しい話ではなく、情報がどのように入っているかが分かっていれば検索は速くて、「こんな感じの情報を持ってきて」というあいまい検索だと遅くなります。 林：XML DBの検索メカニズムはひととおり見てみましたが、高速化に使える技術の種類はけっこう限られているんですね。最も効果的なのはインデックス技術ですが、それもBツリーなど、従来から知られている技術を駆使して高速化を追求しているようです。その点、NeoCoreのコア技術であるDPPは、これまでにない種類の技術という点で非常にユニークです。 |
――最近、コンテンツ管理としてRDBに入っていない社内情報をどうやって管理していくかが注目されています。そして企業にある情報のほとんどはRDBに入っていない。
鉢蝋：まさにNeoCoreが狙っている分野です。NeoCoreはRDBのリプレイスにも使えますが、それよりもデータベースに入れる必要があるのに入っていない、さまざまな情報を格納し、共有するためのツールなんです。柔らかいデータベースだからこそ、多様な情報を効果的に管理できます。このあたりもユーザーに訴えていきたいと思っています。
――今後の動向が楽しみですね。本日は有難うございました。
― 終わり ―
▲このページのTOPへ
▲NeoCoreについて記載されています！
▲XMLマスター教則本です。試験対策はこれでばっちり！
