プログラムが設計書だとすると設計という工程はプログラミングになるはずだが？

最近のソフトウェア開発業界の風潮で、プログラムは設計書であり、プログラミングは設計工程という考え方がある。

今までは、プログラマがブルーカラー、いわゆる製造業でいうところのライン作業者みたいなイメージが蔓延していた。製造工程なんだから、部品を作り上げるまでの時間は的確に見積もれるし、完成までのスケジュールも把握できるという考え方だ。

プログラミング作業は製造工程だとすると、その上に設計工程が存在するはずである。ソフトウェア開発には、一般的にプログラム開発チームと設計チームが分かれていて、設計チームが設計書（非プログラム）を書き上げてプログラマに渡すのである。

ここでハードウェアの世界を見ると、ハードウェアでは設計者とライン作業者は完全に分断されている。設計者が設計書を書いて、工場に渡す（正確には直接ではないが）というのが一般的なのだと思う。

設計書（図）というものは、その通り作れば確実に動くという状態になっているはずのものである。なぜ矛盾がないと言えるかというと、実際に作って試したり、実際に作れない場合はミニチュアを作ったりして、試すからである。実際に作って試して問題なく動くことがわかってから、設計書を作るのである。

それでもハードウェアの場合、実物の部品というのは精度の誤差が積み重なって動かなかったりする。電子部品の場合は部品の質にばらつきがあることもある。それを最後のテストでチェックするということになる。

ところが、ソフトウェアは大きく異なる。プログラマに渡される設計書というのは、精度の差こそあれ矛盾無く記述されているということはない。なぜか？

逆説的に言えば、プログラムが最終的な設計書なので、プログラム以外の設計書が矛盾無く書かれていることはありえないということになる。矛盾がない非プログラムな設計書は、自動でプログラムに変換可能である。

さて、非プログラムな設計書は曖昧（何かが欠けているか矛盾がある）だとすると、ソフトウェアにおける非プログラマである設計者の存在とはなんなのだろうか。

プログラムはわからくても、設計はできるというような話をたまに耳にするが、設計という言葉の定義が少し異なるのだろう。最終的な設計書はプログラムだとすると、プログラムを見て検証しない限り、設計上正しいかどうかは解らないはずだが、それを無視してテストに頼っていたのが現状ではないだろうか。

ソフトウェア開発における設計者とプログラマの分離の弊害を指摘したのが、XPやスクラム等のアジャイル開発手法である。設計者という曖昧な存在を排除して、プログラマが設計してプログラマがプログラムを書くという、いたってシンプルな考え方だ。

ソフトウェア開発業界は、他業界のモデルをそのまま引っ張ってくるのではなくて、もう少しソフトウェアの持つ特性を意識した開発モデルを考えないといけないのではないだろうか。