mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
この連載では良いニュースと悪いニュースを語ることになる。
先に良いニュースとは何かを明らかにしよう。それは、IT業界にはこれから開拓すべき未開の分野が膨大に存在することである。それによって、ベンダーやシステムインテグレータは新しいビジネスを行うことができるし、ユーザはこれまでシステム化できなかった分野の効率化をはかることができるだろう。
そんなに都合の良い話があるのか、といわれそうだがそれは間違いなくそこにある。特にIT化できる処理はすべてIT化済みで、これから何を作っていけば良いのかと考えているようなシステムインテグレータやユーザにとっては、良いニュースといえるだろう。
では、悪いニュースの方を明らかにしよう。それは、これまでのIT業界は業界内外の人々が思っているほど的確にはユーザのニーズに対応できなかったという事実を暴露してしまうということである。これは、特に自分の仕事に誇りを持っている技術者には腹立たしい話だろう。あるいは自社の技術に絶対の自信があるシステムインテグレータには嫌な話かもしれない。
しかしこの良いニュースと悪いニュースは、1つの問題の裏と表を表現しているということに注意を払っていただきたい。従来のIT業界の仕事に抜けている部分があるからこそ、そこに大きな潜在的なニーズが眠っているということなのである。
▲図1:それは表と裏の関係
そしてその潜在的なニーズを満たす技術こそがXMLデータベースであると考える人たちがいる。筆者もそうではないかと考えている。
本連載では3回に渡って、潜在的なニーズとは何か、XMLデータベースとは何か、どうやってXMLデータベースによってニーズを満たしていくかを語っていく。
では前置きはこれぐらいにして、本題に入ろう。眠っている潜在的なニーズとはいったい何だろうか。
例えばこういう経験はないだろうか。自分で体験していないまでも、こういう光景を目撃したことはないだろうか。
ここで、貴方は紙でやり取りされていた様々な書類を電子化する新しいソフトウェア/システムを開発・導入するための担当者になったとするとしよう。このドラマに登場するのは、貴方の他にそのシステムを開発する技術者とシステムを使うユーザの3つの立場である(話を単純化するために、立場をこの3つに絞った)。
最初の手順は、おそらく電子化したい書類を技術者に見せることだろう。すると技術者はこういうかもしれない。
「同じような書類の書式が何種類もあって無駄が多いですね。統一して効率化はかりましょう」
貴方はそれはもっともだと思うかもしれない。確かに筋の通った提案である。ではさっそく、書式の統一を含むシステムの設計を依頼する。
ここで、貴方は運良く仕事のできる優秀な技術者と仕事をしているとしよう。貴方は、まもなく素晴らしいシステムの仕様書を見ることができるだろう。膨大な種類の似て非なる書類は最低限の数の書式に統合され、何の無駄もない効率的なシステムの姿が描かれている。
「これさえあれば、我が社の業務が効率アップすること間違いなし!」
しかし誰もが喜んでくれると思って社内に発表すると、思いも寄らない抵抗が貴方を押し包む。
「こんなものでは仕事ができない!」「今まで通りの書式を使うようにしろ!」「すぐやめさせろ!」
貴方は慌てて技術者に相談しに行く。だが技術者からは、どんなことでもそれまでのやり方を変えさせようとすれば人間は抵抗するものだから、根気よく説得するしかないと諭されてしまう。
貴方はこれほど素晴らしいシステムをこのまま葬るのは大きな無駄だと思ったので、社内の感情的な反発を誠意ある説得で1つ1つ解消していく。
だが、貴方は最終的に説得不可能な壁に突き当たることになる。
一見意味のない書式の差としか見えなかったものが、実はビジネスを行うために重要な意味を持つケースがあったのだ。例えば自社指定の書式に合致しないと受け付けない、罫線の位置をミリ単位まではかって一致しないと却下する取引先であるとか、確かにビジネスを行う上で避けて通れない独特の書式というものがあったのだ。
貴方はその事実を技術者にところに持って行き、設計変更を求める。だが技術者は激怒する。
「そういう、意味のない慣習を打破しなければ効率化などできはしないのだ!」「それを解消するために説得するのがあなたの仕事だろう!」
それを聞いて貴方はムカッとするかもしれない。誰かが説得して変えられるぐらいなら、とっくに変えている。誰もそのような特殊な書式を喜んで使っているわけではないのだ。
貴方は今度は技術者を必死に説得し、そのような特殊な書式もサポートするように設計を変更させる。だがそれによって、美しかった設計は見るも無惨に汚くなっていく。あちこちに無駄やほころびが見えはじめる。それでも業務の効率はアップするので、貴方は必死にシステムの完成を推進する。
そしてついにシステムは完成した。
貴方の説得が功を奏して、もはや社内には感情的な反発はない。誰もが新システムを使う日を楽しみに待っていた。
だが稼働させてすぐにトラブルが続出した。社内の誰もが上手く行くと思った設計なのに、どうしても業務が上手くまわせない部分がでてきたのだ。
更に、このシステムでは扱えない書類が存在することも明らかになった。それはごく最近取引をはじめた企業が要求する書式で、設計段階では存在しなかったものだった。
釈然としない貴方はそれでも技術者にシステムの修正要求をまとめて持って行った。
その結果として技術者が見積もったのは、法外とも思える高額な値段と、びっくりするほど長い納期だった。システムを作ったばかりで、それほど大きな予算が取れるわけもなし。また、今ここに遂行できずに困っている業務があるのに、何ヶ月もの時間を待つことなどできるはずもなかった。
結局、このシステムはお蔵入りとなった。貴方はどこで間違えたのだろうか?
先のドラマは現実のシステム開発を単純化しすぎているところがあり、実際はもっと違うという意見はあるだろう。私ならこのような愚かなミスは犯さない、という人も多いだろう。
しかしこれはいくつかの教訓を埋め込んだ一種の寓話である。では、どういう教訓が埋め込まれているのだろうか。
このドラマでの「貴方」「ユーザ」「技術者」の「発言」「行動」の問題点を見ていこう。
最初に技術者は書式統一の提案を行っている。このような提案は間違いではない。しかし統一するという提案だけでは十分ではない。業務には、常に取りこぼされる例外というものがあるのだ。そしてたいていの場合、例外を扱うのが最も大きな負担となる。つまり貴方は統一の提案を納得した上で、「では、統一できない書式はどのように扱うのですか?」と質問すべきだったのだ。
新システムを発表したときにユーザたちは一斉に反発している。実はこのとき、ユーザたちは根拠のない感情的な反発と、実際に業務に差し障りのある問題点を明確に区別できていない可能性がある。業務を遂行している担当者本人が的確に自分の業務内容を把握しているかというと、実はそうではないからだ。ルーチンワーク的に業務をこなせるということと、業務に絶対必要とされる条件を正しく把握するということは同じではない。
つまり、このような抵抗の大多数が感情的反発に過ぎないと見えても、そこに本当に有益な指摘が含まれている可能性は否定できない。単に説得すれば良い、という技術者のアドバイスは適切ではない。
特殊な書式をサポートさせた結果、美しかったシステムの設計は汚くなっていった。しかし実は設計が「美しい」であるとか「汚い」というのは、きわめて主観的な価値観であり、さしたる意味はない。
予算内で必要な性能と機能を提供し、維持や修正も低コストかつ短期間で可能となるシステムこそが良いシステムといえる。そして、美しいシステムなるものは、往々にして完成度が高すぎて修正を入れにくくメンテナンス性の低い難物になることがある。
つまり貴方は「美しい設計」を素晴らしいものと思ってはいけなかったのである。
誰もが上手く動作すると確信していたシステムが、実際に運用してみると上手く動作しないというのはよくある事例といえる。なぜ事前にわからないのかといえば、いくつかの理由がある。
1 | すでに説明したように、業務を行っている者がその業務のことを正しく理解しているとは限らない |
---|---|
2 | 業務の遂行ルールそのものが、実は厳密に定義されておらず、小さな範囲で揺れていることがある |
3 | 業務の遂行ルールが、実は担当者ごとに微妙に食い違っていることがある |
いずれにしても実際に稼働させてみるまでは、本当に業務で使用できるという確信を持つべきではない。
設計時にはまだ使用されていなかった例外的書式がシステム稼働日には使用されていた。これは単なる連絡不足という問題ではない。例え新しい書式が必要だという連絡が適切に行われていたとしても、この例で見ているようなシステムの場合、設計変更やプログラムの変更など、多くの手順を踏まねばその書式を使用可能にできない。つまり新しい書式に即座に対応することができないかもしれない。
更にいえば、システム稼働開始日以降であっても、新しい書式が業務で必要とされる可能性がある。つまり未来は予見できない。当然、後から必要とされる書式をあらかじめ設計に組み込むことはできない。言い換えれば、たいていのシステムは常に「予見不能の未来」という脅威にさらされているといえる。
このドラマでは、貴方、ユーザ、技術者のいずれもが「予見不能の未来」に対する備えを一切考えていない。
これらの問題について、より深く問題の本質を探ってみよう。
「業務ルールの細部は常に揺れている」あるいは「人によって細部が違う」というのは人間が行う作業である以上、避けることができない。これに対処するには2つの選択があり得る。
1つは、システム側でルールを規定してしまい、揺れを許さないという選択である。もう1つは、揺れを許さないといってしまうと業務が滞るため、硬直的なシステムによって業務を支援することができない場合である。つまり柔軟なシステムが必要とされる。
未知の未来に備えることはできないという問題は、未来を見ることができるタイムマシンが発明されていない現在では避けることができない。しかし、対策が存在しないわけではなく、いくつかの方法が考えられる。
まず、ワープロや表計算ソフトなどの汎用性の高いソフトを使い、業務専用のソフトを使わない方法。効率は良くないがどのような変化にもすぐ対応できる。別の選択は、常に変化にさらされるという前提となるシステムの開発スタイルを取る方法である。
本当の業務を誰も知らない、という問題も実は回避できない。知るための努力を払えば正しい業務の厳密な知識を得られるのではないか、と思うかもしれないが、これは努力だけで解決できる問題ではない。
業務というのは、例え零細企業であっても、様々な専門分野のスキルが相互に絡み合って運営されているものであり、自分の業務に関係する情報をたぐっていくと、どうしても他の専門分野に入り込み、情報量が一人の人間に把握できる量を超えてしまう。
またそれらの情報を学んでいる間にも、徐々に変化は続いている。仮にすべてを学ぶことができたとしても、その時点での持っている情報はすでに古いということである。この問題に対処するためには、すべてを知ろうとするのではなく、システムをテスト稼働させつつ実際に業務にすりあわせていく方が良い。
これらの問題に対処する方法は、一言で要約すれば「変化を抱擁する」ということになる。
システムを常に柔軟に変化させつつ、実際に行われている業務にすりあわせ続ければ十分に実用性の高いシステムが運用できるだろう。実際、開発方法論の1つであるエクストリームプログラミングは「変化ヲ抱擁セヨ」とスローガンに掲げ、このような開発スタイルを積極的に肯定している。
それにも関わらず、柔軟に変化し続けるシステムで成功したという話はあまり聞かれない。それはいったいなぜだろうか。
実はプログラム言語のレベルでの「変化を抱擁する」ための手法はエクストリームプログラミングなどにより、事実上完成しているということができる。
それにも関わらず、「変化を抱擁する」システムが増えたという話はまったく聞かれない。その理由の中には、もちろん新しいスタイルを知らない古い技術者が多いなどの理由もあるだろう。だが、それだけではない。
実はシステムが「変化を抱擁する」ことを妨げる巨大な壁が存在しているのである。
それはデータベースである。プログラム言語がいくら変化を手に入れても、データベースが変化を拒む限り、システムは変化を抱擁できない。
では、変化を拒むデータベースとはいったい何だろうか。それは現在のデータベースの主流となるRDB(リレーショナルデータベース)である。しかしRDBが変化を妨げるというのはどういうことだろうか。
その秘密は「正規化」という手順にある。RDBはデータベースを設計する際に、正規化という手順を必要とする。正規化によって、データをどのように分割して保存するかを確定する。
ここで問題になるのは、保存すべきデータの種類が変わる場合である。つまりデータベースが扱う情報の種類が追加・削除される場合である。情報が追加・削除されれば、RDBは「正規化」をやり直さねばならない。
それによって、データの分割方法が大きく変わらない場合は良いのだが、これが変わってしまうと大変なことになる。これは、データベース内でのある情報が置かれた場所が変わるということなので、プログラムの大規模な変更が要求されてしまう。また、データベース本体も構造を変換しなければならない。変換中は業務が止まるかもしれないし、万一変換中にデータの欠落などがあれば、大問題である。
RDBにおいては、できるだけ変化を回避しようとする態度を取ることが正当だといえる。RDBにおいてデータを変化させることは、たとえ僅かなデータの追加であっても、大規模なシステムの変更につながる可能性が存在するのだ。寓話ドラマのラストシーンで、技術者が法外な値段と長い納期を提示したのは何ら不思議なことではない。
だからこそRDBを扱う技術者が、それを全力で回避しようと努力を払ったとしても何ら不思議ではない。寓話ドラマの中で設計変更を求めたときに、逆に激怒して「それを解消するために説得するのがあなたの仕事だろう!」と正当な変更要求を他人の努力不足に責任転嫁してしまうのは、データベースの設計変更を回避するためだといえる。
さて、ここで重要なことを述べておこう。
世の中には、それほど大きな変更要求にさらされていない業務と変化し続ける業務が存在する。前者はRDBでも十分に実用的なシステムを構築することができる。そのため、RDBに実用性はない...、と言い切ることは間違いだといえる。分野によっては、RDBは十分に強力であり、問題解決能力を持つ。
しかしすべての業務に対して問題解決能力を持っているわけではない。それが、RDBによって取りこぼされたニーズである。そして、ほとんどの場合RDBを中核にしてシステムを構築してみせる現在のIT業界が取りこぼしてきたニーズである。
「本当にそのようなニーズがあるのだろうか?」「RDBであらゆるシステムを上手く構築してきたのではないか?」という疑問を持つ方も多いと思う。
その答えは簡単である。
まず筆者自身が取りこぼされたニーズを持つ者であり、まるでそのようなニーズが存在しないかのようされてきた数十年の歴史を刻んできた事実がある。
そして、2005年より徐々に起こりつつあるいわゆる第2世代XMLデータベース・ブームの担い手達も、実は同じように取りこぼされたニーズを持つ者たちであったといえるのである。
次回は、いかにしてそのようなニーズとXMLデータベースが結びついていくのかについてと、XMLデータベースの特徴や種類を解説していく。
▲このページのTOPへ