古典中の古典なのについ最近存在を知ったという体たらく。一応ソフトウェア工学を学んだ人間なのにこれは恥ずかしい。。
ただ、会社人としての労働を積んだ今の方が本の内容によく納得しながら読めたと思います。
※ところでこういうときに貼るリンクは出版社のものにしているのだが、この本は良いページが無かったのでAmazonを利用している
読むべき人間
ITエンジニア全般。見積もりを要求される人ならなおさら。
「見積もり」と「コミットメント」
この本の一番の教えは、第一章でも語られている『見積もりとコミットメントは異なる』という概念でしょう。「見積もり」は交渉やなにかで動かせるものではなく、役員からプレッシャーを掛けられても動かすべきではないが、「コミットメント」は別物であり動かせるものであるということです。例えば、5ヶ月かかるという「見積もり」は変えられるものではなく変えるべきでもないが、「3ヶ月後に展示をしなければならない」というビジネス目標に対して、何かしらの出力を約束するという「コミットメント」は交渉あるいは問題解決として動かすべきものだということです。
これ読んだときは電撃走りましたし、目から鱗で、膝を叩きすぎるものでした。大きな工数がかかるという見積もりに対し、「過大すぎるから小さくしろ」というプレッシャーがかかるのはまぁよくあることだし、それに対してイライラするのもよくあることでしたが、あれは「見積もり」を出して「コミットメント」を要求された結果か！と納得したもんです。
見積もりの教訓が様々
さすがに古い本なので見積もりツールに関してはもはや生き残ってるか怪しいですし、「第三世代言語」とかもはや聞いたこと無い人が多いんじゃないかという言葉もでてきます。が、見積もりでやるべきことや落とし穴などの概念的な部分は今でも全然通用すると思います。（どっちかというとその概念部分を教える本ですし）
印象に残ったものを箇条書きで。
まとめ
この本を一言で表すなら「見積もりの心得を教えてくれる本」というフレーズを付けたい。見積もりとは何であるか、見積もりがいかに間違いやすいか、「数えて、計算して、判断する」ことが如何に重要であるか、あるいは直感の見積もりがどれほど間違えるか、etc、見積もりに関する心構えを教えてくれる本です。
古典であり概念的な話も多いですが、実際に見積もりをやるとなったらやるべきことの示唆にも富んでいますね。私が本格的な見積もり業務をやることになったとしたら、 ①機能数なりストーリーポイントなりファンクションポイントなり画面数なり、とにかく数える ②過去のデータを収集する。あるいは今から収集する。 という指針でやるといいだろうってことがこの本から見えてきます。
プログラマーでもなんでも、シニアになっていくにしたがって見積もりを要求される場面はどんどん増えていくものなので、ITエンジニアなら読んで頭に叩き込んどいて良い本だと思いました。
余談
「できるかどうかじゃない、やるんだ」って格好いいけど好きじゃない言葉だったんですが、この本読んでそれは「有害な言葉」まで跳ね上がったかもなあっていう。見積もりに対して過小なスケジュールでのコミットメントを要求されるときにまさにこの言葉が出てくると思うんですが、実際問題として過小なスケジュールで無理矢理作ったもののクオリティなんぞたかがしれており、そういう低クオリティの成果物が出ると関わった人間全員を不幸にしていくんですよね…… プロジェクトは失敗し、企画と開発の関係は破綻し、ユーザーのストレスはマッハ。最悪の場合、解雇や倒産につながるという。（しかも言った当人が責任を取ることもなく）
人生の指針としての「やるんだ」は基本的に有益なんでしょうけど、現実世界の問題に対して「やるんだ」は有害極まりないので、創作物でもあんま使ってほしくないよなあと思いだしたところ。
