今日読んだ本

SEのための見積もりの基本 (amazon)

見積もりの2つの側面

• 見積もることそのもの
• 実際に起こったことを、見積もりに合わせて調整すること

やはりこの世の真実はそうだったのだ。それ自体が正しい見積もりなど存在しないのだ。最初に掲げた見積もりに合わせて、現実の方を修正する。自己成就予言という奴だ。この本には顧客や会社に対しての報告数値をごまかして、あたかもプロジェクトが見積もり通り終わったのだということにするための手練手管が書かれているのであろう。

しかし「見積もりが正しい」ってどういうことなんだろう？結果が実際にそのようになれば正しいのか？そして見積もりはなぜ正しい必要があるのか。

本書は、システム開発の流れに沿って、局面毎に必要になる見積もりとその方法を解説する構成になっている…はずなんだけど。扱う見積もりの種類がシステムの規模・工数から性能予測、バグの件数まで多岐にわたっていること。そして、見積もりから外れてしまいそうになった時への対処に多くの紙面が割かれていること。この2点の影響で、見積もりそのものをこの本から学ぶのは、かえって難しいのではないかと思われる。

本の内容は、開発の局面毎に順を追って構成されており、その場その場で必要な技法が紹介されている。それはそれでいいのだろうが、それぞれの局面で何を見積もる必要があって、それはなぜなのかという説明が（恐らくは自明のものとして）省かれているので、何かにつけて、とても唐突な印象を受ける。単体テストでは、境界値と網羅率でテストをし、エラーを測ってエラー率を計算し、信頼度成長曲線を引きます。えっ、そりゃそうでしょうけど…。

本書の対象読者は「SEやPMなど、見積もりを作成する全ての人」とされている。それだけでなく、発注者側・受注者側、双方の立場で読めるようになっている。各人の担当により、プロジェクトの中でどのような利害対立が起こるかの図示から始まる構成は面白いと思った。ただ、タコのように足を多方向に伸ばした結果、今読んでいる説明が誰の立場で書かれているかがわかりにくくなっているのが惜しい。また、複数の立場の者に読ませようという意図があるなら、数値の出し方だけでなく、それぞれの立場での読み方（例えば、出て来た数値の妥当性をチェックする観点）も書かれていないと片手落ちだろう。

1冊の本を書き上げるのには、大変な労力がかかる。一生のうちに、複数の本を出版できるなんて、想像できる人も少ないだろう。今まで何冊か読んできて思ったのは、1冊で何もかも書いてやろうとしてわかりにくくなっている本の多さだ。要素技術にフォーカスしている本と違って、実際のプロジェクトへの適用を意識した本だと、なかなかスパッと整理されたものが出てこないね。想定する前提で変動するものが多すぎ、大きすぎるのだろうか。かといって、事例を挙げるだけだと「お前の中ではそうなんだろう。お前の中ではな…。」になっちゃうしなぁ。