━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第24回 動かない理想システム
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
数年前に携わっていたシステムのお話ですが、このシステムはとても高い思
想によって作られていました。
その理想とは、データベース設計不要、プログラミング不要で動作するシス
テムです。
何かの妄想かと思いきや、かなり本気で取り組んでおり、ほぼ完成という状
況まで出来上がっていました。
なぜデータベース設計不要、プログラミング不要なのかと言いますと、シス
テムに関するデータを全て１つのテーブルに格納するからです。
１つのテーブルなのでデータベース設計不要ということのようです。
データには番地がついており、この番地がツリー構造になっています。
データを取得したいときは、このツリー構造を元に取得するという仕組みが
用意されています。
取得したデータは、小さいモジュールを順番に実行していき、最終結果を画
面に返します。
この順番制御も、画面もすべてデータベースで定義します。
初めてこの話を聞いたとき、何をおかしな事を言っているのだ？と思ったも
のでしたが、実際に動作するのを見ると驚きます。
画面もHTMLを書いたりする必要が全くないので、データベースに番地と設定
データを入れていくという作業を半日ほどしただけで、全ての画面が出来上
がり、中身は空ですが、画面遷移までするようになっていました。
●致命的な検索スピード
ですが、このシステムは全く業務で使えないものでした。
わずか100件の受注データを表示させるだけで5分以上掛かるのです。
普通のシステムならば、受注テーブルと受注明細テーブルに対して、JOINす
るSQLを発行し、その結果をフェッチして表示するだけなのですが、データ
をツリーとして取得する仕組みしかないので、SQLが発行できません。
この件について担当者に聞くと、「このシステムはそういう思想で作ってい
る」とのことです。
それだけではありません。
開発も後半に差し掛かると、設定データが膨大な量になります。
この設定データをWEBサーバ起動時にツリー状態にして読み込むために、WEB
サーバを起動するだけでメモリがパンクしてしまいました。
WEBサーバにはメモリが2GB詰まれていましたが、それがWEBサーバを起動す
るだけで使い切ってしまうのです。
結局、メモリを増設することで起動するようにはなりましたが、根本的な解
決にはなっていませんし、もちろん検索速度が向上することはありませんで
した。
●原因はこだわり過ぎ
これを設計したエンジニアは大変優秀な方達です。
でも、ユーザー視点で設計する力は持ち合わせていなかったと思います。
ユーザーから機能を追加してくれと言われても、「このフレームワークはそ
ういう使い方を想定していません」と断っていました。
実現はもちろん簡単にできるのですが、フレームワークの思想から外れるの
でダメという理屈です。
毎日のようにシステムダウンが発生しても、フレームワークの造りにこだわ
って、根本的な解決を行いませんでした。
私もアプリケーションフレームワークを作成したことがあるのですが、やは
りシステムには予期しない仕様変更が発生することが多いです。
フレームワークをガチガチに作ってしまうと、そういった事態に対応できな
くなり、結果的に思想がバラバラなシステムが出来上がってしまいます。
特にSQLが自由に書けないフレームワークは複雑なシステムには不向きで、
生産性や性能がかなり低いことがあります。
オープンソースで公開されているフレームワークにも、こういった身動きの
取れないフレームワークがありますので、多機能でも制限が多いものには注
意した方が良いと思います。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━