「設計」とは？

SEをやっていると、当然ながら「設計」というものとは縁が切れません。
ハード屋さんだろうがソフト屋さんだろうが、その粒度や重要度はそれぞれだとしても、「設計」が全く無いなんてことはありえない。
でも最近僕は、この「設計」というやつが何なのかということがわからないのです。

自分はソフト屋さんな上にPGよりな人間なので、特に気になるのが「詳細設計」というやつです。
当然ながら、設計書を元にプログラムを書き、設計書通りだよねと試験をする。
特に僕の働いているところはCOBOL全盛時代からの文化を引き継いでますので、「ここでこうして、次こうやって」と事細かに書かれていることがままあります（プログラム設計と呼ぶ場合もあるそうです）。
こうすれば、意図した通り動いてくれてめでたしめでたし・・・・ということもあったのでしょう。

実際のところ、この方法を取ると後々に必ず、「設計と実装の乖離」という問題が出てきます。
こいつが厄介で、ほんのちょっとの違いならいいのに、ちょっとで済むことなんてわずか。
また、バグが出て、設計上は問題ないはずなのにと思ってソースを追ったら設計と違う実装で、そいつが原因だったとか。
こうなると設計書が信用出来ないので結局ソースを読まなきゃいけなかったり、さて設計書とソースとどっちを直すかって話になります（たいてい、設計書を直します）。

一昔前、プログラムのコンパイルに数時間かかるような時代であれば、設計を極力精緻に行なって、実装はそれをなぞればいいというのは必要なことだったでしょう。
でも、今どきコンパイルなど数分もかからないのが普通。
当時の設計書の「必要性」が薄れてきています。
では今、設計書を作る理由とはなんなんでしょうか？

これは個人的解釈なのですが、設計とはそもそも「間を埋める」ためにあるものなのではないかと思っています。
現実とシステムの間にある溝を埋めるためにあるもの。
建築の設計図であれば、建材をどう使ってどう建てていくのかという情報で埋める。
プログラムの設計書であれば、現実に期待する動作をプログラミング言語に翻訳するために作る・・・・。

でもここで、なんか違和感があるのが、プログラムの設計書は、そもそも動作を日本語に「翻訳」してるのに、それをさらにプログラミング言語に「翻訳」してるわけです。
これがどうにも気になっているんです。
二度手間じゃないかと。

そもそもロジックの構築に関して言えば、プログラミングを経験した人間の方がそうでない人より上手い（相対的に）と思うので、ロジックの構築もプログラマがやるべきではないかと。
つまり、設計＋製造をプログラマがやるほうが、効率・品質共に上がるのではないでしょうか？
Agileも製造しながら設計をBrush upしていくようなので、同じような考えなのかな？

なーんて熱く語っておいて、「そんな会社お前んとこだけだよ」とかね。
あるある。

とりあえず、ウォーターフォール型開発が今でも正しいのか、それぞれの工程の概念ややり方はそのままでいいのかを、疑って見る姿勢が必要になっているような気がします。
妄信的にAgileに行くつもりも無いですが、やはり新しいものも知っておきたい。
勉強せねばーですね。