メッセージ。 - でも、後半ちょっと違...

でも、後半ちょっと違和感があるかもなぁ。たぶんウォーターフォールの人からすれば、「仕様書を満たすことが目的」こそ正しいんじゃないかな。仕様書にないものは作るなと。そこまで含めて仕様書（要求仕様や機能仕様）をまとめてから、コーディングしろと。コーディングのときに余計なことをするなと。仕様書を作るときにそこまで煮詰められるという前提があるなら、これも理解できない考えじゃないですね。

でも、仕様書を作るときにそこまでできないのが普通だと思うんですよ。なぜなら—理由はいろいろありますが一番大きいんじゃないかと思っているのは—お客さんが作ってる途中で仕様を変えたがるからです。作ってるうちに「このほうがいいな」とか、顧客側の現場（実際にシステムを使うことになる人たち）から要望が上がってきて、変えざるを得なくなるのが通常です。

バカ征くさんには釈迦に説法ですね。でも、こう、（ぼくや読んでいる人の）認識を確認できれば、それだけでも価値があるかなと思ったので。間違ってると思うところがあれば、指摘してもらえるとうれしいです。……ただ、後半部分もおおむね同意なんですよね。「退屈な作業はミスしやすい」、「本当の目的はいいシステムを作ること」ってのは、本当にそのとおりだと思います。

「仕様書を満たすことが目的になりがち」ってのは、現場の作業者レベルでの意識を指摘したものでしょうね。仕様書を満たすことが目的になると、仕様書が間違ってても気付けないんですよね。……そして、仕様書って実際には間違ってることが多い。そもそも、要求仕様の作成時に現場の人から要求仕様をすべて聞き出せなかったりしますし、その後作りはじめてから仕様変更があるのに、仕様書を変更するための時間をもらえなかったり。ほんと現場って、グダグダになりますよね。