methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

散々言い尽くされた話

http://d.hatena.ne.jp/sakuneko/20060417#p2

私自身が実行ファイルではなくソースコードを最終的な成果物として納めている立場ですので、最終的な設計作業はあくまでも関数仕様書に基づく関数設計であって、ソースコードは製造するものなのですよね。

多分、「製造」の定義が違うんでしょうね。設計書を書いて提出している人が行っている作業は、設計書の製造なのか、設計なのか。
さらに言うと、「設計書の製造」なら短時間に大量の設計書を作れば効率が良い筈だが、実際には時間をかけて「設計」を洗練させるべきで、悪い設計のまま「設計書」だけ大量に作る人間なんて害悪以外の何者でもない。
もし創造的な作業を製造と言うのなら、その製造は工学の製造とは別物で、同じものを何度も作るわけじゃないから工学的管理手法はやっぱり適用できない。


http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
コーディングが設計の一部だというのは、かなり昔からの定説です。
90%が創造的な作業であるソフト開発に「製造」の管理手法を無理やり適用させようとしている「自称ソフトウェア工学屋さん」が、この定説に対してマトモに反論している文書を読んだ事がありません。

逆に、コーディングが設計作業だという証明は簡単に出来ます。

1. コーディングから創造的な作業を無くすほど完全な設計書があったと仮定する。
2. その設計書には完全に動作が記されているので、人間がコーディングしなくてもその設計書のコンパイラを作ればその設計書通に動くソフトウェアが作成できる。
3. その設計書は、コンパイラで変換できるので、ソースコードである。
4. その設計書はソースコードなので、その設計書を書く作業はコーディングである。
5. 1.と4.は矛盾するので、1.の仮説は間違い。

というわけで、「コーディングする前に設計書を完成させてレビューしる!コーディングを始めてから設計書を修正するのは後戻りで悪い事なんだ!」見たいな事をのたまう管理者は、確実にソフトウェア開発について判っていません。絶対に仕事の中に口を出せないように、オブラートに包み込んで隔離しましょう。