XMLDB解説

インターネット全盛の世の中である。インターネット上にWebカタログを公開したいと考えるのは、当然の成り行きである。カタログに乗せる写真やタイトルを決め、デザイナーと打ち合わせ、カタログは完成する。その間、1ヶ月。期間もできばえもそこそこ満足できる。そのうち、個々のカタログを商品マスターから動的に生成すれば、新製品にもそのまま適用できるという話を聞きつけ、早速検討してみる。そして開発の見積もりを依頼すると、開発期間半年。何故そんなにかかる?

自分で開発などできないから仕方がない。開発会社のSEと打ち合わせを持つ。「現在商品マスターはお持ちですか？」とSEは言う。今時、電子化していない情報などあるかと思いながら、エクセルのデータを見せる。「いえ、そうではなくデータベースになっているデータの事です。情報は社員全員が共有できるデータベース化される事により、始めて会社の財産となるのです。」今でもこのエクセルのデータを、全社員とは言わないが部門内では共有しているのだが。

SEは、「仕方がありませんね。スキーマの設計から始める事になります。」と言って、データベースの設計を始めた。カタログを作りたくて始めた事が、いつの間にか商品マスターの作成にすりかわったような気がしたが、商品マスターがなければ、カタログはできないようなので、致し方ない。カタログ化というのはひどく面倒なものだと思いながら、打ち合わせを重ねる。そのうち、スキーマというものが出来上がったので、型とサイズを確認して欲しいと言われる。今の段階でサイズなどわからないと言うと、「多めに取っても特に不都合はありません。わからない場合は、多めに見積もってください。」それなら別にサイズなど要らないんじゃないか。

データベースの設計が終わり、プログラムの開発が始まる。デザイナーとも協議し、画面レイアウトも徐々に具体化していく。すると今まで想定していなかった幾つかの項目をデータベースに追加したくなってきた。その事をSEに相談すると彼は眉間にしわを寄せ、「それは、何の属性ですか？商品の属性ですか？カテゴリーの属性ですか？ページの属性ですか？マスターに項目を追加する事で対応できませんか？」
何故数項目の追加にこれほど神経質になる必要があるのだろう。

実データによるテストが始まり、噂を聞きつけた社員が見に来た。予想通り各部門で勝手な事を言っている。「この商品の売りは、この値ではなくこっちなんだがな。これでは、商品のピントがずれているよ。この商品だけ別にできないのか？」ある部門の責任者の言葉である。「全部同じ背景じゃない。商品毎にイメージカラーとかあるよね。」女性陣の意見である。「いろいろな意見が出てくるじゃないか。課題山積でうらやましい。」同僚の言葉である。
カタログは出来上がった直後からメンテナンスが始まる。

Web カタログを立ち上げる際、普通はこんな感じで展開される。筆者はプログラム開発者である。われわれプログラム開発者に接する担当者の方が、このように思われているのではないかという事柄をまとめたものが上記の文章である。またそう思われても仕方がないなと思う事柄でもある。勿論、我々プログラム開発者としてその問題点に何らかの回答をしなければならないという責任は感じるのであるが、現状完全な回答というものはない。しかし、ある程度満足のいく方法は既に存在していると思う。それが、XML をコアとしたWebカタログであろうと筆者は思う。

これは一言で理由がいえます。それは、決めなければならない事が多すぎるからです。決めるという行為は神経をすり減らす本当に嫌な仕事です。我々プログラム開発者もお客様に本当に大変な思いをさせているなと思う事もあります。紙にして数十枚のスキーマを来週までに目を通して、これでいいかどうか判断してください、などと平気で言っている。決めなければならない事は決めなければならないので、仕方がないのですが、少なければ少ないほどいいと常に思う。

これについては解答はないかもしれない。使いやすいアプリケーションを使い、そのまま情報共有できればそれが理想であろう。バックエンドで何がどうなっているかなどは、本来エンドユーザーが知る必要のない事ではないだろうか。とはいっても現実は共通の形式でなければ、それらの情報は使い物にならない情報となる。その為、アプリケーションレベルでエンドユーザーに不便を強いているというのが、現状であろう。

大なり小なりスキーマは必要である。現在最も用いられる事の多いRDBの世界では、スキーマがなければ何も始まらない。また、マスターテーブルがあり、トランザクションテーブルがあり、それらが複雑に関連している。それだけではなく、コードに意味があり、コードによりレコードの意味が変わったりもしている。これでは、専門職でないと理解できないなと誰もが思うし、事実それが敷居を高くしている。もうそろそろ敷居を低くする手法がでてきてもいいのではないかと思う。

実際大変な作業となる時もあるし、そうでない時もある。大抵の場合は、全体に影響を与えない程度の変更が多いと筆者は思うが、実際はどうなのであろうか。しかし、私を含めた開発者全般は、あまりいい顔をしない。その理由はプログラムの修正以外にやらなければならない事が多いからだし、その影響範囲を考えるのが苦痛だからだ。自分が設計したシステムでも、その変更が与える影響範囲がどれだけになるか、直感的にわかる設計者はどれほど存在するであろうか。大変な作業かどうかはっきり言えないが故に、いい顔をしないというのが本当のところであり、もし簡単な作業である事がわかれば、開発者もそれ程意地悪でないので、快諾するであろう。

筆者はプログラム開発者なので、デザインには疎いが、基本設計時にデザインの事まで考える事は少ない。これは、我々開発者だけではなく、担当者も同じであろう。スキーマなどの論理性を必要とする設計時に、プレゼンテーションのような直感、表現力を必要とする作業を並行して行う事自体、不可能かもしれない。しかしこれは逆の見方をすると、カタログ生成の敷居が高いからそうなっているだけかもしれない。もし敷居が低かったらどうだろう。我々開発者とデザイナーがプロットタイプを前にして、議論する場が実現するかもしれない。

デザインは変更が当たり前であり、運用にはデザインの変更が含まれていると考えるべきだ。デザインの変更だけではなく、それに伴い、情報の追加変更もありうると考えた方がよい。Webカタログはいともあっさりと陳腐化し、何がしか新しいものを常に供給し続けなければならないという宿命を持つ。運用担当者には大変な事だと思うが、そういう宿命ならば、開発時からそのコストを見積もっておかなければならない。勿論コストがかからない方式を選択するのがベターである事はいうまでもない。

以上、問題点を挙げたが、次回以降、これらの問題点がXMLをコアとすることにより、どのように軽減されるか見て頂きたいと思っている。

▲このページのTOPへ