「ソフトウェア見積り」3章「正確な見積りの価値」のまとめ。見積りは大きめにするのが正解。

「ソフトウェア見積り」の3章「正確な見積りの価値」の内容をまとめます。

結論は「見積りは大きめにするのが正解」で、その理由などが説明されています。

前の「2章 見積り能力のチェック」のまとめはこちら

次の「4章 見積り誤差はなぜ起きる?」のまとめはこちら

1部「見積りの考え方」

3章「正確な見積りの価値」

大きい見積りのデメリット2つ

以下の2つが「大きい見積り」のデメリットとして有名です。

  • 見積りを多めにすると、人は多くとった期間を使いきるように仕事を作ります。これを「パーキンソンの法則」と言います。
  • 多くとった期間の前半はのんびり過ごす。期限がせまってきてから急ぐ。これを「学生症候群」と言います。

私も夏休みの宿題はギリギリまでやらない派だったので、納得しちゃいますね。

小さい見積りのデメリットは沢山

見積りが少ない場合のデメリットは2つと言わず、沢山あります。

  • チームの人数を少なめにしてあとで困る
  • 設計が中途半端になり、けっきょく作り直す
  • 調整のための打ち合わせによる時間の浪費
  • 再見積もりによる時間の浪費
  • プレッシャーによるバグの増加
  • 開発チームの信頼が下がる

などなど。

何度かプロジェクトを経験した技術者なら、全力でうなずける内容ではないでしょうか。

見積りは小さいより大きいほうが良い

小さい見積りと大きい見積りどちらがマシか、上記を見れば明らかです。

大きい見積りのほうが被害は少なく済みます。

小さい見積りの被害は無限に増えますが、大きい見積りの被害は与えられた期間以上には増えません。

見積りをもっと多くすることから始める必要がある

いくつかの調査によれば、ソフトウェア業界全体として見積もりは小さくなることが圧倒的に多いです。

そして、小さい見積りは様々な被害を生みます。

私たちはまず、見積りを大きくしていく必要があると考えておきましょう。

見積りは幅と予測可能性

ソフトウェアの見積りは100%正確にはできないため、幅をもたせる必要があります。

しかしビジネスでは、幅のある見積りはあまり喜ばれない事は理解しておいたほうが良いです。

4か月~8ヵ月で完了するという見積りをした場合、流通や生産を考えれば結局8ヵ月で計画を立てなければいけなくなります。

「予測可能性」の高い5か月~6か月という見積りのほうが歓迎される事が多いようです。

とはいえ柔軟性があったほうが良い場合もあるので、プロジェクトごとに何が重要か考えていく必要があります。

良い見積りのためには、ビジネスへの理解も必要になりますね。

その他の情報源

「ソフトウェア見積り」の3章では以下の本が紹介されています。

私は「クリティカルチェーン」をは読みました。

平行作業やリードタイムの考え方などがプロジェクトを考えるうえで参考になりますよ。

 

3章「正確な見積りの価値」のまとめはここまで。

前の「2章 見積り能力のチェック」のまとめはこちら

次の「4章 見積り誤差はなぜ起きる?」のまとめはこちら

見積りが上手くなりたい方は読んでみてください。

ちなみにこの本を書いたのはスティーブ・マコネルという人ですが、この人の書いた「コードコンプリート」もかなり好きな本で、おすすめです。

ページ数は多いですが、分かりやすく書かれていて面白い本です。