« 「帳簿組織の育成」としてのシステム開発 | トップページ | さらば「方眼紙エクセル仕様書」 »

2011.04.02

「DB構造を見直さない」というアンチパターン

 システム開発プロジェクトの失敗原因のひとつに「システム刷新時に、DB構造を見直しせずにプログラムの言語だけを置き換える」というものがある。アンチパターンとまでは言えないとしても、クリティカルな問題をはらんでいる。にもかかわらず、いくつかの理由からこの方針は無批判に受け入れられるか、場合によっては歓迎さえされる。

 なぜか。まず、システムの問題がDB構造(帳簿組織)の悪さから来ているという認識を、ユーザーやシステム部門が持ちにくいため、その見直しが明示的に求められないからだ。また、必要なスキルを持った技術者が少ないため、開発側として(大手SIerでさえ)なるべく見直ししたくないのが本音だったりするからだ。いかにも問題がありそうに見えても「求められないから手をつけない」という理屈で通す。また、DB構造が多少おかしくてもエレガントなクラス構造でカバーできるから一刻も早くプログラミングさせてほしい――開発者もそのように考えがちだ。さらに、開発コストを抑えたいので、複雑なデータ移行作業などせずに速やかに軽やかにカットオーバーしたいというお互いの思惑もはたらく。

 それゆえ「DB構造の見直し」は、しばしば双方にとってのタブー(禁止語)となる。結果的に、DB構造が古臭く硬直的なわりにUIだけがモダンなシステムが今日もまたどこかで生み落とされる。大枚をはたいて出来上がったものは「見かけだけ新品のレガシー」であり「建材や壁紙だけが最新のものに更新された竪穴式住居」である。

 純粋にUIだけの刷新を目的としたプロジェクトもないわけではないが、刷新されるようなシステムのDB構造は多かれ少なかれ見直しが必要になっているのがふつうだ。見直しせずに移行することのリスクを事前に理解して、それでも「竪穴式住居再建」をあえてやりたいとクライアントが望むのであれば問題はない。しかし、リスクが周知されているとは言いがたい。なにしろタブーなのだ。

 「DB構造には手を入れない」という方針で生まれ変わった業務システムは、企業にとって拘束具のようなようなものになる。その種のシステムは、事業の変化・発展に追随させにくいからだ。まず「なぜこのように設計されているのか」が刷新前よりもわかりにくくなる。設計意図がわからないので、修正すると何が起こるかもわからない。とりあえず今は動いているのだから触らないようにしよう。そのように判断されやすい。ようするに変化することが許されなくなる。

 大枚をはたいて刷新したのに、そのシステムのおかげで事業を変化させられないなんてたまらない。これではいけないてんで、一大決心をしてERPを導入して、さらにコストをかけて硬直化するという絵に描いたような転落パターンもある。

 いっぽうDOAでは、必要とされるDB構造をゼロベースで再構築して、これを起点としてシステムを構造化しようとする。このやり方の正当性の根拠として「データ処理の過程は変化しやすいが、DB構造は変わりにくい」と説明されることがある。それはそれで間違った言い方ではないのだが、多少の語弊がある。

 むしろそれは「いったん完成するとDB構造を大幅には変えにくい」というDBシステムの特性として語られるべきかもしれない。だからこそ「少しでもDB構造を変えやすくするため」の配慮としてDOAがある。正規化することでデータ項目間の論理関係が明確になって、DB構造の変化・発展を手堅く企画できるようになるからだ。それほどにDB構造は、システムのアーキテクチャやライフサイクル、あるいは業務プロセスのあり方までを隠然と規定し続ける。

 良いシステムの条件とされる「良好な保守性」を、データ処理プログラムを保守しやすいという意味だけに捉えてはいけない。そこにはDB構造の保守(変化)の起こしやすさも含まれる。なぜなら業務システムは、事業とともに変化・発展してゆくものだから。DB構造のレベルから変化しにくい業務システムは、決して破れないサナギの殻のように、変化・発展しようとする命を圧殺する。

|

« 「帳簿組織の育成」としてのシステム開発 | トップページ | さらば「方眼紙エクセル仕様書」 »

コメント

システム開発の現場においてDB構造(帳簿組織構造)は基本的に所与のものであって、自分たちシステム設計者が工夫する対象では無いという意識があるような気が、以前からします。
帳簿組織を工夫すること自体が業務システム設計の主要なテーマである、というように理解が切り替わっていけば、業務システム開発はもっと楽しく創造的な仕事に変わっていくでしょうね。

投稿: keis | 2011.04.02 12:59

keisさん

そうですよねえ。じぶんの役割はUIの改善か、せいぜい業務プロセスの改善だけと思い込んでる。

なぜDB構造の妥当性を問題にしないのかと問うたら、「データってのはお客さんが長年かけて築き上げてきた財産で、そこには企業の歴史的必然が反映されている。それを安易にさわれると考えるほうがおかしい」と反論されたことがあります。

それって、赤ん坊の頃に着てたベビー服に布をつぎ足して、大人になってもまだ着ているようなもんですよ。歴史を誠実に記録するために一度も洗ってません。この肘の部分の染みは7歳の頃に机のカドにぶつけて出た鼻血のあとです(キリッ)みたいな(^^;

投稿: わたなべ | 2011.04.02 15:38

現在、将来の業務にあった適切なデータベースを設計できることと、これまで利用されてきたデータベースを新たなるデータベースを移行させるデータベース・リファクタリングの能力をもった技術者にしかできないところが難しい要因ですね。

リファクタリングをアシストするようなツールがあると、取り掛かりやすいのかもしれませんね。
データベース・リファクタリング テスト駆動開発でしょうか? (笑

投稿: 黒麹 | 2011.04.03 20:01

黒麹さん

業務システム開発に関わる技術者であれば、ゼロからDB構造を考えることも、部分的に見直しすることも出来て当然なんですけどね。DBリファクタリングのような機能が整備されても、DB構造を扱う技術がなければ、ほとんど意味はないかもしれません。

投稿: わたなべ | 2011.04.04 15:28

DB構造を見直すチャンスをみすみす見過ごすなんて、もったいないですよねー
でも、ベビー服を継ぎ足して大人になってもまだ着てるって・・・めちゃおもろい例えですね。それはそれでちょっと見てみたい気も。。あぁ継ぎ足してー。

投稿: ret315 | 2011.04.04 19:11

ホスト時代のデーターをRDB化したときの事を思い出しました。
正規化されていない実績データーをクレンジングする作業は、ユーザーにとってもシステム屋(私)にとっても、大変な作業でした。

先に正論を発してコストを掛けてつくり直すか、それよりも大きくなるかもしれないコストを後で支払うことにするかは、ユーザー(経営者)の判断も必要になるんじゃないでしょうか。

その判断材料を経営者にも判りやすく説明するのもシステム屋の仕事と思っています。

投稿: neteru | 2011.04.04 19:12

>ret315さん

見てみたいなんて趣味悪いなあ。でも見るだけなら面白いかもね(^^;

>neteruさん

ホストの実績データのクレンジング、私も何度も苦労しました。ようするに、システム刷新時にデータ移行でプロジェクトが苦労するか、保守フェーズでユーザ企業が苦労するかの選択問題。どっちでもいいといえばいいのですが、後者がほとんど自動的に選択されてしまうのが問題です。システム屋がまずは双方のメリット、デメリットをわかりやすく示して、経営者に意識的に選択してもらうべきですよね。

投稿: わたなべ | 2011.04.05 09:39

じゃばらと申します。
このエントリ、非常に耳が痛いです。
目前のコスト低減にとらわれて本質的な解決方法を提案できないという状況を多く経験していますので。
でももっと根深いのは
「提案できない」のではなく
「提案しない」ことですよね、きっと…

投稿: じゃばら | 2011.06.05 19:49

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「DB構造を見直さない」というアンチパターン:

« 「帳簿組織の育成」としてのシステム開発 | トップページ | さらば「方眼紙エクセル仕様書」 »