へなちょこSEの考察

0x1E歳のへなちょこSEが、日々思うことを考察します。自社内、金融系を経て現在法人系PKG開発に従事。

「設計」とは?

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


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


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


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


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


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


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


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


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