仕事で工数見積もりを依頼されたので、開発チームで話し合い（といっても2人だったが）、工数見積もりを作成して提出したところ、お客さん側から仕様書作成工数が多いんじゃないか？と言われてしまったらしい。

ドキュメント作るのに、そんなに時間がかかるのか？と、まともにドキュメントを作ってくれない人に言われている俺ら。俺らの上げた工数の半分で作れるんじゃないか？と言ってきているようだ。できるのなら、やってくれぃ。まあそんな時間でできるのは仕様書じゃないだろうけどね。

設計書がちゃんとしていれば、後は作りこむだけだから、プログラミングは簡単になる。いうなれば、一番重要なところが、仕様を考えてドキュメントにするところである。社内開発であれば、プロジェクト管理ツール（RedMine）にプロジェクトを作成して、そこに機能のチケットをばしばし発行して、仕様もそこに書いていってOKなのだが、お客さんがいる仕事では成果物が必要なので、ドキュメントとソース（プログラムコード）を納品する必要がある。

仕様が明確になっていれば、プログラマーの腕に関係なく、仕様通りのものが作成されるはずであるが、時間がないからと仕様書の作りこみがあいまいだと、疑問だらけになってプログラムする上で仕様確認の嵐になり、結果的に工数の大幅な遅れが生じることが多い（というかほとんどそう）。

それを何度も繰り返しているお客さんだが、学習能力がないのだろうか？どうもドキュメントは軽んじられる傾向にある。俺はドキュメント至上主義ではないが、個人の開発でもRedMineにログを残すようにしてる。じゃないと、何をどこまでやったか、どんな仕様をめざしていたかを忘れるからなのだが、それが実質仕様書と化す。まあ個人ならそれでいい。

もうだいぶ慣れっこになっているが、仕様も提案型でプログラムしているので（質疑応答の応酬で工数がかかる。ひょっとしたらこれをアジャイルと勘違いしているのか？）、今回もそれでやって、プログラム作成後にドキュメント作成してくれってスタンスなんだろうか？

今回の案件は要件定義はほぼ確定しているので仕様書をカッチリ作りこんでからのほうがプログラムもしやすくて稼動工数も少なくて済むから、仕様書のほうに時間を割いたのに（しかもそんなに多くない）、そこに文句をいわれるとは。そして、もっと工数削れるんじゃないの？という仕様変更・再見積もりの嵐・嵐・嵐…。その再見積もりの回数で、既に削ってほしいといわれてる分の工数を使ってしまってるんじゃないか？という…。

ちなみにこの仕様変更・再見積もりで何十万も変わるんならまだしも、数万程度しか変わらないんだったら、さっさとOK出したほうが両社にとって得だと思うんだけどね～。再見積もりを吟味する時間を他の仕事に充てることができるんだから。数万削ったその工数分をそちらさんの担当者が再見積もりで食いつぶしてまっせ！と思う。