読み始めは早かったんだけど，途中でしばらく休止状態を
入れつつ何とか読み終わったと言う感じ．
一通りの見積もりについて書かれているので，
いろいろな見積もりをどの時期に適用できるのかなどを
踏まえて利用できるようになっている．
また，各見積もり手法の文献も載っているので
詳細が知りたい場合にも良い感じかな．
でも，結論からするとよい見積もりはよりデータの収集から．
そして，当たり前のことだけど，より新しい過去データを
使った見積もりが一番良いと言う結論と言う感じだね．
さすらいびとの会社みたいに自社の開発組織を使うわけでは
ないところにはきちんとした見積もりは出来ないというのは
これからはっきりするね．
それと，「熊とワルツを」でも書かれていたけど，見積もりは
必ず幅を持たせるというのは何度も述べられていたね．
そして，あるタイミングで再度見積もりをしてより精度を
上げるようにするのと，その際にはより細かいデータから
行う見積もり手法に切り替えるようにすべきだとのこと．
まあ，当たり前すぎることだけどね．
一応，分かっているなと思ったのは，開発者は論理的な交渉は
ともかくビジネス的，政治的な交渉が得意ではないということで，
どんなことに注意するべきなのかも述べられていたこと．
多くの役員やビジネスサイドの人に次の言葉を知っておいて
もらいたいところ．
技術者にソフトウェア見積もりの交渉を期待するのは，
麻酔なしで「親知らず」を抜いてもらうくらいの冒険だ
社会人として交渉が出来ることは必要かもしれないが，
日々交渉に慣れた役員などとの交渉で対等に行うのは
難しいのは当たりまえというもの．
技術者も注意すべきものとしては次のことは念頭に置くべきかと．
コミットメントは交渉できるが，見積もりを
交渉の対象にしてはならない
交渉というのはバーターで，ゼロサムだというのを忘れないこと，
そして，「開発の成功」はゼロサムではなく，Win-Winなのだと．
見積もりを交渉することはWin-WinとLose-Loseを駆け引きするだけ．
そのことは常に両者の共通認識とすべきというのは大いに賛成するところ．
ソフトウェア見積り―人月の暗黙知を解き明かす/スティーブ マコネル
- ￥3,570
- Amazon.co.jp
- 熊とワルツを - リスクを愉しむプロジェクト管理/トム・デマルコ
- ￥2,310
- Amazon.co.jp