勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

前任者の見積りを信用しない

他人が担当したプロジェクトを引き継いたり引き取ったとき、私は「前任者の見積り」を信じないようにしている。自分で情報を改めて収集整理して見積もり直してみる。前任者の見積りと大きな差が無ければ問題ないが、差があればマネジメントなどに必要なエスカレーションをして、差を小さくするための作戦を考える。

そもそも「見積り」というものは危険な爆発物なのだ。他人の精錬したブツに命を預けるなどということは恐ろしくて考えられない。

「前任者の見積り」に潜むリスクはたとえばこんなもの。

  • 見積りを行った時の状況がわからない。3ヶ月かけてじっくり検討した結果なのか、「明日までに見積もって」と顧客から言われて算出したものなのか
  • 見積りの暗黙的な前提がわからない。重要なインプットや前提はだいたい明記されているけれど、関係者間の「あたりまえ」が抜けていたりするので怖い
  • 見積りをした人のスキルや能力が読み切れない
  • 見積りの参考にした資料が何かわからない。前回のプロジェクトの実績補正をしたのかどうか……

「過去の見積り」を参考にした見積りをしてはいけない

どのブロジェクトでも過去から引き継いできた見積りのテンプレートや過去の(前任者が行った)見積りファイルが蓄積されている。単なる事務仕事として見積り作業を行うのであれば、過去の資料を雛形に変更点だけ修正するのが一見すると効率良く見える。しかし、そこに大きな落し穴がある。

  • 過去の見積りが正しいという保証はないどころか、ただしくない可能性のほうが高い。
    • まずソフトウェアの見積りは一般論として楽観的になりやすいということを知る必要がある。よって、過去の見積りも楽観的なものである可能性が高い。
    • 見積りは普通は価格やスケジュールのプレッシャーを受ける(「早く、安く!」)。過去の見積りはプレッシャーを受けた後のものかもしれない。流用して見積りを作っても、さらに新たなプレッシャーで二重に下方修正させられるかもしれない。
    • その見積りが過小で以前のプロジェクトが失敗していても、通常は過去の見積りを修正などしない。大トラブルであれば組織内で話題となったりするので情報が得られるかもしれないけれど、小トラブルであれば情報も得難い。
  • 人の入れ替えがあればチームの生産性も大きくリセットされる。
    • 特殊な環境(枯れた技術、変化しない外部環境、全員が優秀なエンジニアかそのクローン兵士)でなければ、前回と同じようにブロジェクトを進めることは絶対に出来ない。

思い出補正

話は変わるけど、社内の見積りレビューの時やお客様との折衝時に「以前のプロジェクトではこんなに工数(金額)はかからなかった。なんでだ」といった指摘を受ける事もよくある。実際には見積りミスであることもあるけれど、思い出補正がかかっている場合も多い。

  • 指摘者の念頭にあるのは前回の見積りであって、「実績」ではない。現場の苦労や実績稼働が考慮されていない。
  • 失敗したことは忘れられる。もしくは失敗したことのある人は指摘をしない(生存者バイアス)。
  • 環境の変化も考慮されていない。コンプライアンスや品質管理、リスク管理はこの10年で大きく変化している。
    • 残業時間や労働時間の考え方とか
  • そもそも過去の「あたりまえ」と現在の「あたりまえ」が大きく異なる。
    • 構成管理とか、CIとか、TDDとか
    • UIなど10年前に比べて隔世の感が
    • 発注者と受注者の関係も

というわけで、知識や気づきという観点では老兵の意見は参考になるけれど、見積りに関しては気をつけたほうがいいとか、そういう話。