設計書とは何か

古くからプログラム仕様書、機能仕様書と呼ばれるものが、この設計書にあたる。

プログラムのロジックに焦点をあて、プログラムの流れを模倣して書かれたものである。

フローチャートなどはその代表例である。HIPO、PADなど現在はあまり使われなくなった書法もある。

だが、一般的には関数の中のロジックを自然言語で、やるべきことを順番に書いている形式の仕様が多いのではないだろうか。

その手順通りにプログラムを書くとプログラムが動くという発想である。

昔から何もプログラムチックな仕様書を書こうと思っていたわけではないと思うが、Whatにあたる仕様の書き方が分からないので、勢いHowのような書き方になったのではないかと思う。

それが精度を高めようとすればするほど、プログラムに近い書き方になり結局よく分からない設計書が、仕様となったケースが多いのではないだろうか。

もう一方の流れとしては、ある枠組みにはめてプログラムを作成するような環境（現在のフレームワークのようなもの）では、枠組みに沿って可変の部分だけをプログラミングするような環境を用意し、その可変の部分だけを穴埋め式として設計書を記述する方式も広く使われている。

最近の例ではJ2EEでソフトウェア工場と称してソフトウェアのパターン化を行い、フレームワークにそった記述書を書けばプログラムが動くというやり方をしていたところがあった。

J2EE、特にEJBの生産性が恐ろしく悪いので効率化にはならなかったが、何十年も前からこのようなことは何度と無く繰り返されうまく行っていない。パターンなどが出来た頃にはそのフレームワークやプラットフォームが陳腐化してしまっている。また、学習コストが以上に高く生産性の向上までには行き着けないことがおおい。

いずれにして仕様を決める人とプログラムを作成する人の間でのコミュニケーションツールとして設計書が存在する。そのためにどうしてもプログラムに近くなってしまう。

ここに落とし穴が存在する...