量り売りの設計書のその後。
当初はプログラムが原因のバグが多かったが、後半は仕様バグが頻発した。理由は簡単である。仕様書の書き方が曖昧であるのに、仕様がFIXしたものと勘違いしていたからである。よって、当初は曖昧さの解釈が異なる「プログラムのバグ」が多く、後半は仕様自体の甘さによる「仕様バグ」が頻発したのだ。

仕様書は、解りやすくなくてはならない。解りやすいための条件として、読む人によって解釈の余地が発生しないことが挙げられる。そのためには矛盾があってはいけない。

よく、プログラムを作ってから後付で仕様書を作成するケースがある。プロジェクト規模やエンジニアの力量によっては設計書を作らずとも実装はできる。しかし、当初作った設計書を結構手直ししなくてはならないようなら、「設計力」に問題はないかを疑ってみるべきだろう。

いい設計書は、そのままプログラムに落とし込めるし、ツール化すれば自動プログラミングも夢ではないだろう。しかし、IT業界の設計書は、どういう訳かレベルが低いものが多いように感じる。