昨日に引き続きアート・オブ・プロジェクトから
オライリー・ジャパン
売り上げランキング: 96079
バイブルにしています
プロジェクトマネジメントに関する教科書的な一冊 プロマネ、必読 プロジェクト大災害で大炎上 真のマネジメントがここにある
精度か正確さか
見積もりの精度はよく問題にはなるが、どれだけ精度が高くても正確でなければ意味が無いというのが本書で言わんとするところだ。ここで言う”精度”とは数字上の精度。
言ってしまうと、小数点桁何桁まで出した数字だろうと、その出す過程が根拠を伴って出されてない限り、何の意味も持たないってことだ。では、根拠のある数字を出す過程とはどんなものだろうか。
ソフトウェアの開発では、いわゆる機械による大量生産のように同じものをひたすらに作るわけではなく、常に一品モノの物作りとなる。
時には技術的に不明確な部分に対して切り込まなければならない開発。。。というよりは”研究”に近いのかもしれないこれら作業を正確に見積もることなんてできるのだろうか？
しかし、お客様に「いくらかかるか分からないし、いつ完成するかわからないけど頑張ります」なんて言った途端に「それじゃ、いつ発注するかわかんないよ？」なんて言われてしまうかもしれないわけで、なにかしら見積もりはしないといけない。
規模が小さい開発であればそこそこの正確さを持った見積もりが出てくるが、規模が大きくなればなるほど見積もり誤差は大きくなる。自己負担分も増えていく。（デスマーチの）鼓笛隊の歩む音が聞こえてきそうだ。
これは経験にゆだねるしかないのだろうか。
一つの答えとしては多分そうなんだろう。ただし、その”経験”は、”会社としての経験”であって”個人としての経験”であっては困るわけだ。
見積もりに対する根拠・仮説を記録しつつ、結果を検証することを繰り返す必要がある。これは積もり積もったデータベースとして、組織の財産としての扱いを受けるべきだろう。
そもそも誰が見積もるのか
ここまで書いて、ふと思ったのは、”見積もりをしているのはだれなのか？”という事だ。
これは”仕様や設計を行っているのはだれなのか？”という事に置き換える事も出来るかもしれない。
本書では見積もりの精度に関して”優れた設計から生み出される”としている。
優れた見積もりというものは、信頼性の高い設計と要求が揃って初めて生みだされるという事です。そしてエンジニアリングにおける優れた情報と優れたエンジニアという2つが揃って初めて生みだされるのです。（P.40）
そんなに多くの事例を見たことがあるわけではないので断言できるわけではないのだが、見積もりや設計を行うのは実際にコーディングを行うプログラマーやプログラマーのリーダーではなく、”過去にプログラムを組んでいた管理職”か、”プログラムを組んだことのない管理職”が多いのではないだろうか？
そして、何かしらの根拠があって見積もっているわけではなく、感覚論で見積もってしまっているのではないだろうか？
そうであるならば、見積もりはリーダーだけでなくプログラマ、品質を管理する担当者（テスター含む）等にも参加してもらい、そもそも出来あがる機能が、業務的に本当に有益な形でお客様に提供できるようになっているのか？等、様々な角度から求め
ていかなければいけないだろう。
ただ、未受注の機能に対してここまで大がかりな見積もり体制を築き上げてしまうと、実は中小のソフトウェア会社では回らなかったりする。要するにお金になるのか分からない作業に対して人を割り当てる余裕が無いということだ。もちろん、そういう企業の場合はプログラマからテスターまで多くの作業を兼任するので必然的に少人数にはなるだろうが、それはそもそも人が足りないわけで、逆にノリで見積もりをしそうだ。
私が所属している組織において、本書でいう”正しい見積もり”が完全に機能しているとはとても言えない。見積もりが個人のスキルによってしまい、引き継ぎも出来ないうえに当たり外れが出始めている。
銀の弾丸が無いとはいえ、組織内において蓄積された基準や、見積もる上でのプロセスを見直す必要がある。
動かなければいけないな