ことの経緯 その２

はじめに

ことの経緯 その１でユーザインタフェースに強く依存したシステム開発が与える影響についての疑問を書きました．実はこの「漂流記」には，データモデル・アプリケーションルール・ユーザインタフェースの独立だけでなく，もうひとつ意図があります．「設計からプログラミングまでを１本の線でつなぐ」という考えです．

設計とプログラミングの断絶

エンティティ・リレーションシップ図（以下ER図）もデータフローダイアグラム（以下DFD）も目新しい記述法ではありません．古臭いとすら言えるかもしれません．私の周りでも，これらを作図したプロジェクトはいくつもあります．しかし，その評判は芳しくありませんでした．手間ばっかりかかって何の役にも立たなかった，という評価です．

手間ばかりかかる最大の要因は，以下のようなものでした．

それまで，詳細設計で決まっていたことを，プログラミングの前にもう一度詰めないといけなかった．ER図もDFDも要件定義や設計には役に立つかもしれないが，プログラミングには役に立たない．

設計者も製作者も（同一人物であれ，別人物であれ）プログラミングを行う際に，ER図やDFDがあることの利便性を感じることができなかったわけです．「ER図やDFDをプログラミングに生かせていない」ということなのです．

ER図やDFDの結果を生かせなかった理由は，ER図やDFDからプログラミングへ，そのまま移行できる方法が見つけられなかったことにあります．その結果，ER図やDFDの結果を無視して，プログラミングの前にもう一度「それまでのやり方」にあわせた設計をやり直す必要があったのです．プログラミングまでに行った設計をすべてなかったことにして，プログラミング用に再設計を行うわけですから，手間ばっかりかかって役に立たないのは自然です．

「ER図やDFDは要件定義や設計のため」という先入観があったのかもしれません．「何のためにこれらの図を描くのか，そもそもわかっていなかった」のかもしれません．プログラミング以降，使われなくなってしまったことは事実ですし，広く他のプロジェクトで使うこともありませんでした．

ER図はそのままRDBMSのテーブル定義に流用できるので，有効性がわかりやすいかもしれません．DFDもプログラミングに直接生かせるものなのです．

プログラム設計があるのはこのためです．