プログラム開発には、まず仕様書が書かれる （・・・はずだ。 これについてはまた書こう）
ここでの問題は仕様書は読まれているのかだ。
ビル・ゲイツは翌日の会議のために、仕様書をプリントアウトし持ち帰り、会議に赤ペンで書き込まれた仕様書を持ってくるという。
これはすごいことだ。 仕様書を読むのは苦行なのだ。
第一に、面白い文書ではない （誰か、スティーヴン・キングのように書いてくれないか？）
第二に、脳をフルに稼動させ、集中させないとどこに論理ミスがあるのかは見つからない。 （間違いなく、IQサプリより難しい！！）
という最もな理由があっても仕様書は読まなければいけない。 論理ミスがあればそれを発見しなければいけない。 ユーザーインターフェースに問題があれば、それを発見しなければいけない。 これらがいつの間にか神の手によって解決されていることを期待してはいけない。 さもなければ、そう、誰もが経験している地獄を見る。 開発の最後の最後になって、ここがおかしい、あそこが間違いだ、となる。
家がすっかり出来上がってから、やっぱりキッチンは東じゃなくて西にしよう、ということになったらどんなことになる?
仕様書のレベルで、ワードの文書のあそこを修正して、そこを追加することは簡単だけど、組みあがったプログラムコードはそんな風に直せない。
憂鬱な気分になるのはやめよう。 みんな幸せでなくては。 だから、仕様書を読もう。
（知っています。 顧客に仕様書を読んでもらうのが難しいことを。 結局最後に仕様書が役に立たなくなることを。 この問題については、また改めて）
もちろん社長ご存知かと思いますが、こうした問題を回避するためには、顧客にRFPを要求したらいかがでしょうか。
この段階をヒアリングで代替することが多いですが、改めてRFPもらった方がその後、安全ですし、
RFPの後に、要件定義、仕様設計があり、WBSに基づくマイルストーンがあるのですから、土壇場になって顧客の心変わりを抑えることができるかと思います。
それよりも一番の原因は仕様書の解釈のズレですね。
言った言わないになるので、細かく議事録とって、サインもらっています。
コメントをありがとうございます。
ご指摘のように、ＲＦＰを顧客からいただくのは理屈にかなったやり方です。 しかし、現実問題として、顧客はこれを書けない（あるいは、書かない）ことに、どう対応するのかには頭を悩ませます。
それから、要件定義、仕様書は、どうせ変更になってしまうのだから、変更になることを前提にプロセスを組むべきだという考えが主流になってきたように思います（アジャイル手法のように）。 しかし、これも言うは易し行なうは難し、でどうもうまい具合にはいきません。
いまだに、ソフトウェア開発手法は、成功の公式がないようなので、各社それぞれのやり方を試行錯誤しながら考え出しているのだと思います。
他のソフトウェア会社は、どのような試みをしているのでしょうか？
読ませていただきました。
大変参考になりました。
これからも、良い情報の発信をしていだければと思います。
ありがとうございました。