« サロゲートキーの事例解説 | トップページ | 開発基盤のトリガーとDBMSのトリガー »

2012.02.15

ショボいDB設計で突っ走るための50の方法

 DB(データベース)設計の良し悪しは、開発プロジェクトのパフォーマンスに決定的な影響を与える。ところが、ショボいDB設計のまま突っ走るためにその場をしのぐ方法が山ほどある。50はある。ポール・サイモンの歌みたいだ。

 私は駆け出しの頃、いろいろなプロジェクトの設計書を覗きまわるのが好きだった。「プログラム仕様書」は情報量が多すぎて手に余ったが、「テーブル定義書」からは短時間で多くのことを学べた。

 読み漁るうちに、設計者の馬脚がDB設計に現れることがわかってきた。DB設計はある意味で、担当者の論理構成力や言語能力の結実である。DB設計書を半時間ほど眺めれば、そのプロジェクトが「うまくゆくかどうか」まではわからないにせよ「困ったことになるかどうか」は予測できた。とくに、DB設計からシステム要件を把握しにくいプロジェクトは、規模が大きければ決まってデスマーチに突入していった。

 私はコトナカレ主義の覗き屋だったが、それでもあんまりなケースについては見直しを提案した(もちろん小心者らしくヒソヒソ声でだ)。そのときの反応は申し合わせたように同じだった。「もう確定済みなので、見直すわけにはいかない」――それならばと次のプロジェクトで早めのタイミングで提案すると、こんどは「まだちゃんとまとめてないのに、おかしいなんて言われても困る」と言われた。これら2つのフェーズの間隙はきわめて短いように思われた。3分くらいかもしれない。

 そういえば、DB設計がまとまるのにさんざん待たされるような場合、設計書としてきっちりしているわりに内容がショボいケースがなぜか多い(だからER図はないか、あってもショボい)。担当者が「せめて体裁だけでも立派にしよう」と考えるからかもしれない。「(体裁を整えるのに時間がかかり過ぎたので、内容を)見直す時間がない」と言い訳するためなのかもしれない。そんな悪意がなかったとしても、例のExcel方眼紙と格闘しているうちに「汗水流してじっくりと設計している」ような充実した気分になるためかもしれない。

 中でも「見直す時間がない」というのは代表的な言い訳のひとつだが、それはたいてい言外に「データ要件が曖昧だったせいで、DB設計にひどく時間がとられてしまった」という恨みつらみが含まれている。しかし、データ要件が最初から明確なプロジェクトなど例外的だ。DB設計の専門性は、当初は曖昧であるはずのデータ要件をたちどころに明確にする点にある。曖昧さを言い訳にできるのは初心者だけだ。

 言い訳は他にもまだたくさんある。めぼしいものを取り上げよう。「時間がない」の次に多いのが「現行のDBがだいたいこんな感じだし、見直しも依頼されていないから」というものだ。その姿勢は一見何も問題がなさそうだが、技術者が負うべき設計責任を素人の発注者に預けているという意味で正しくない。DB構造というものは、建築物の「土台(基礎)」に相当する。現行の土台がどんなに腐っていようが土台の刷新がことさら依頼されるとは限らない(発注者が事の重大さを理解していないだけかもしれない)。

 彼らに対しては、必要に応じて「現行の土台を刷新したほうがいいですよ」と頼まれもせずに提案するのが専門家としての正しい姿勢というものだ。もちろん土台の刷新にともなって余計なコストがかかることも言い添えよう。もしそれで発注者が難色を示すなら、プロジェクト炎上のリスクに触れつつ、やりとりを抜け目なく文書化しておこう。

 ショボいDB設計のまま突っ走るために、他にも「プログラミングで対処できるから」とか「アジャイルだから」とか「シンプルイズベストだから」とか「ブラジルのジャングルで蝶が羽ばたいたから」とか「太陽がまぶしかったから」などの多彩な根拠が語られる。どれもショボい言い訳だが、ショボいDB設計で突っ走るための方法という意味では似つかわしい。しかし、それで突っ走らされるほうはタマらんのだよ、これが。

|

« サロゲートキーの事例解説 | トップページ | 開発基盤のトリガーとDBMSのトリガー »

コメント

いつも興味深く読ませていただいております

DB設計の良し悪しよりも、とりあえず見た目動くモノを早く多く作って稼動させることが
業績評価の一義的な基準になっているような文化の場合
設計にじっくりと時間をかけるというようなことは仕事が遅いとか仕事をしていないと見られますね

次から次へとEXCEL方眼紙を大量に作成してプログラマ、主に協力会社にばら撒いて
叩いて叩いて開発させる、というほうが
仕事をしているという風になっていってしまい

結果として、データ構造の整理がまったくなされていないDBから
摩訶不思議なロジックでもってデータを取り出したり書き込んだりという、
限られた数人の当事者にしか読めないような
魔法のようなプログラムが大量に出来あがっていきます。。。

投稿: yamato | 2012.02.17 00:57

yamatoさま

なるほど。DB設計書というものはプログラム仕様書に比べてドキュメントの「量」が少ない。「作成されたドキュメントの量」が評価基準のひとつとされているような職場であれば、DB設計よりもプログラム仕様書の作成のほうに重点が置かれるかもしれませんね。

しかも、DB設計がいいかげんなら、プログラム仕様書の情報量も無駄に増える。「おお、仕様書の量がけっこう多いな。どれどれ...おお、ロジックも複雑そうだ。がんばってるじゃないか」なんて評価されてもねえ(^^;

投稿: わたなべ | 2012.02.17 18:06

ブラジルで蝶が羽ばたいたから桶屋が炎上する・・・みたいな感じですか(`・ω・´)

投稿: RET315 | 2012.02.20 20:12

RET315さま

うひゃー、桶屋は儲からずに炎上してまいたかー(><)

投稿: わたなべ | 2012.02.20 23:29

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/53989819

この記事へのトラックバック一覧です: ショボいDB設計で突っ走るための50の方法:

« サロゲートキーの事例解説 | トップページ | 開発基盤のトリガーとDBMSのトリガー »