« ナチュラルキーを主キーにしてはいけない | トップページ | 古いデータの一括削除処理を設計する »

2011.07.23

「DB構造の前にUIを決める」というアンチパターン

 画面定義書があるのにまともなER図がない。業務システムの開発プロジェクトがそういう状況を一瞬でも経由したのであれば、大きなリスクを抱えていると考えたほうがいい。小さな案件でない限り、デスマーチに陥る公算が高い。

 喩えるなら、高層ビルの「上モノ」の図面が詳細に出来上がっているわりに「土台」の図面がないようなものだ。その点を問われ、

「ああ、ボーリング調査も土台設計も後でしっかりやるから大丈夫です。土台の図面なんてほら、専門的すぎてお客さんが見てもピンと来ないじゃないですか。お客さんが知りたいのは土台とかではなくて上モノのデザインなんですよ。なんといっても顧客の納得感が大事です」

なんて言う建築士はいない。「顧客の納得感」が重要でないと言うつもりはないが、それだけを基準にして高層ビルを設計できるのなら苦労はない。専門的な仕事の難しさは、顧客には見えないし想像もできない膨大な部分の整合性をはかる点にある。

 画面定義書が出来上がった時点で既にER図があるとしても、安心できない。ER図と称していながら、まともなデータモデルの体(てい)を成していないことがあるからだ。現行のテーブル一覧の中からめぼしい名称を拾い出して、枠に囲んで配置して、枠と枠の間を直線でもっともらしく結んだもの――それを「ER図」と称しているような例を私は何度も見てきた。それがER図と呼べるのであれば、DB設計など素人でもやれる。大規模集積回路のようなER図もダメ。レビューする気が起こらないからだ。

 レビューする方も問題だ。「えーっと、規定ではこのタイミングではER図を用意することになってますが、ありますか?お、ありますね。ふむふむ、けっこうテーブルが多いようですが、がんばってくださいね。はいオーケーです」なんて調子のレビュワーは追放されたほうがいい。本来は「一部のテーブルに代理キーが置かれているように見えます。必要性や補完仕様を説明してくださいますか?」くらいのテクニカルなツッコミができるくらいでないと、設計資料のレビュワーなんて勤まらない。

 ER図がマジメに作られていたとしても、まだ安心できない。大規模なプロジェクトでは、なぜかER図を作る担当(そういう専門家がいるらしい)と画面定義書を作る担当とが別だったりする。そして悪いことに、画面定義書を作る過程でER図が参照されなかったりする。「オレは専門家として主翼を設計するよ。オマエは尾翼な。では試乗テストで会おう」と言ってるようなものだ。試乗テストには誘われたくないものだ。

 ER図と画面定義書の相互関係を正しく理解しよう。ER図は画面定義書に「先行」して作成されていなければならない。そして画面定義書は、ER図で示されたデータ構造に立脚した形でまとめられなければいけない。ER図がしっかりしていさえすれば、場合によっては画面定義書がなくてもいい。実装過程でアジャイルに決めていけばいいからだ。とにかく大前提として、データモデル(ER図)がすべてに先行して確立されなければいけない。そんな専門的な図面を見せてもユーザにはピンとこないと思えるなら、タフなピアレビュー(同業者によるレビュー)に晒して鍛えてもらうべきだ。

 データモデルがUIよりも重要なのはなぜか。UIというものは「DB構造の影」だからだ。ダイナミックなデータ処理の過程でその「影」は多彩に変化する。しかし、それはあくまでも「処理される対象の形(DB構造)」から論理的に導ける形しか取り得ない。つまり、DB構造が明確でない限り、その影であるUIをデザインすることは本来は不可能である。言い換えれば、現行のパネルや帳票といった手がかりが一切なくても、データ要件を把握して、必要なDB構造と業務の流れをデザインできるスキル――それがまともなシステム設計スキルというものだ。そして、設計されたUIの妥当性は、その時点で既に確立されているデータモデルと業務定義の双方から検証されない限り検証できない。

 にも関わらず、ER図も業務定義も参照せずに画面定義書が出来上がってしまう事例が多いのはなぜか。理由はひとつ。そのやり方だと簡単だからだ。COBOLかVBあたりで作られた旧システムのパネルイメージを今風に直したものを、EXCEL方眼紙上に一所懸命に移し替える――そんな風に出来上がった資料が画面定義書と呼べるのであれば、UI設計など素人でもやれる。それはちょうど、複雑な立体構造物をスケッチすることが難しくしても、その「影」のスケッチなら絵心がなくても描けるのと同じ。そして、スケッチされた影(UI)にもとづいて本体の形(DB構造)を後で決定するようなやり方をとれば、デスマーチは確実だ。なんとハタ迷惑な話だろう。

 ER図も画面定義書も、本来は簡単に作れるものではない。これらをまとめる局面で設計者はしっかり考えなければならない。しかし、わずか「しっかり考える」だけの配慮で、多くのプロジェクトがデスマーチに陥らずに済むのであれば、それをやったほうがいい。もちろん、ただ考えるだけではダメで、「効果的」に考えなければいけない。そのためには専門家としての学びと鍛錬と適性が必要だ。

本ブログでの関連記事
「DB構造を見直さない」というアンチパターン
事務仕事の現場は「情報処理工場」である
複数の視点で描かれた図面同士の牽制が重要

|

« ナチュラルキーを主キーにしてはいけない | トップページ | 古いデータの一括削除処理を設計する »

コメント

すごい納得です。

投稿: mmiyajima | 2012.05.18 14:32

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「DB構造の前にUIを決める」というアンチパターン:

« ナチュラルキーを主キーにしてはいけない | トップページ | 古いデータの一括削除処理を設計する »