ソフトウェアの開発工程は、「要求仕様定義」、「詳細設計」、「コーディング」、「デバッグ」の４つに分類できる。
時間配分がどうなるかはプロジェクトによって様々だが、一般的には、
要求仕様定義 － 20％
詳細設計 － 20％
コーディング － 20％
デバッグ － 40％
と言われている。
スケジュールや予算の見積もりをするベストなタイミングはどこだろうか？
最も合理的に考えれば、要求仕様定義が終わった後である。 要求仕様定義が完了してはじめて、何を作るのかがわかる。
ところが、一般的な商習慣として、私たちがスケジュールや予算の見積もりを作成しなければいけないのは、要求仕様定義をする前なのだ。
どう考えても、見積もりが間違う。 何を作るのかがはっきりしないのに、スケジュールを組んだり、予算を組んだりするのだから、当然そうなる。
「ソフトウェア開発は人類史上最も複雑な作業である」と主張する人たちがいる。 本当に複雑なのだ。 その工程にほとんど事務作業ですませられる部分のない作業なのだ。
このようなものを何を作るかはっきりしない段階で見積もるなんて、そもそも無理がある。 本当は、要求仕様定義を終えてからすべきなのだ。
しかし、ここに一つの問題がある。 要求仕様定義を終えるということは、全工程の20％を終えているということだ。
顧客との契約が成立するのかどうかわからないものに対して、仕事の20％を無償サービスするわけにはいかない。
最善の方法は、「要求仕様定義」の作成だけを独立した仕事として成立させることではないかと思う。 まず「要求仕様定義」の作成業務だけを取引するのだ。 それを元にその後の開発の金額とスケジュールが提示される。 提示された見積もりに合意すれば、その後の開発も同じ会社が行えばいいし、合意できなければその仕様書を持って別の会社に依頼するのもよい。
考えてみれば、このような仕組みは他の産業ではめずらしいことではない。 例えば、建築業界では、設計者と建築者はわかれている。
ソフトウェア業界でもできるのではないか？ ソフトウェアは今となっては社会を動かす重要な産業なのだからもっと積極的に動くべきだと思う。 どういう団体がこういうことをドライブすべきか知らないが、社会で発生している諸々のトラブル（銀行端末が止まったり、電車の改札口が開かなかったり、・・・・）や労働環境の問題（過度な長時間労働、など）を解決するには、ソフトウェア開発の特性にあった商習慣やルールを作らないといけないときにきているのではないかと思う。
