見積もりの過小算出を防ぎ、精度を高めるためのポイント

cover image from Unsplash

Photo by Jay Ruzesky on Unsplash

はじめに

業務の見積もりを出す時、実際の工数や時間を少なめに見積もる人が多いように感じている。
これにはいくつかの要因があると考えている。

過小算出のリスク

私の場合、受託開発の企業に勤めているため、工期厳守が最優先事項であるが、見積もりの過小算出は工期厳守を困難にする。

見積もりが過小算出されると、実際の作業量に対して不十分な工期が設定される可能性が高くなる。
また、過小算出に基づいて、社内でプロジェクトに必要なリソースが適切に割り当てられない可能性がある。
このように、見積もりの過小算出はプロジェクト全体の成功に深刻な影響を与えるため、過小算出を避け適切な見積もりを行うことが不可欠である。

適切な見積もりを行うためのポイント

前提条件

見積もりを出す際は、社内向けか発注者向けかで求められる内容が異なる。
発注者向けの場合、求められるのは社内の平均レベルのエンジニアの作業速度に基づいた工数である。
一方で、社内向けの場合は、開発担当者の作業速度を考慮した実作業日数の見積もりが求められるかもしれない。

以下では、両者に共通する見積もりのポイントを紹介する。

タスクの細分化

ログイン機能の実装の見積もりを求められたとする。
そのまま見積もりを出すと次のようになるかもしれない。

タスク作業日数
ログイン機能の実装5日

しかし、タスクを細分化してから作業日数を書き出すと、次のように異なる見積もりになることがある。

タスク作業日数
ログイン画面のデザイン1日
ログインAPIの実装2日
フロントエンドのログイン機能統合2日
テストとデバッグ2日
合計7日

これは、テストやデバッグにかかる時間が考慮されていなかったためである。
このように、本来7日で見積もるべきタスクを5日で見積もってしまうリスクを減らすために、タスクを細分化することが重要である。
また、分割したタスクは、見積もり結果を伝える際に根拠として提示することができる。

相対評価の活用

タスクを分割した後、それぞれのタスクに対して難易度を評価する。
以下は、私が使用している評価基準の例である。

難易度作業日数
1週間以上
3~5日
数日
極小1日未満

次に、見積もりやすいタスクから実作業日数を設定する。
残りのタスクについては、先に見積もったタスクを基準に相対的な作業日数を見積もっていく。

この方法は、プログラミングで一番難しいのは「見積もり」だと思う - Qiitaを参考にしている。
記事内では、人は絶対評価よりも相対評価の方が精度が高いという点が強調されている。
この相対評価のアプローチにより、個々のタスクにかかる時間をより現実的に見積もることが可能になる。

まとめ

さまざまな要因により、見積もりは小さめに出される傾向があるが、見積もりの過小算出はプロジェクト全体の成功に深刻な影響を与える。
見積もりの過小算出を防ぎ、精度を高めるためには、タスクの細分化と相対評価の活用が有効である。

参考

プログラミングで一番難しいのは「見積もり」だと思う - Qiita