見積もりの過小算出を防ぎ、精度を高めるためのポイント
Photo by Jay Ruzesky on Unsplash
はじめに
業務の見積もりを出す時、実際の工数や時間を少なめに見積もる人が多いように感じている。
これにはいくつかの要因があると考えている。
- テスト等の工数が考慮されていない
- トラブルなく順調にタスクが進むという前提条件に基づく楽観的な見積もり
- 上司や発注者からのプレッシャー
- 熟練技術者が自身のタスクペースで見積もり、社内の平均レベルから乖離してしまう
過小算出のリスク
私の場合、受託開発の企業に勤めているため、工期厳守が最優先事項であるが、見積もりの過小算出は工期厳守を困難にする。
見積もりが過小算出されると、実際の作業量に対して不十分な工期が設定される可能性が高くなる。
また、過小算出に基づいて、社内でプロジェクトに必要なリソースが適切に割り当てられない可能性がある。
このように、見積もりの過小算出はプロジェクト全体の成功に深刻な影響を与えるため、過小算出を避け適切な見積もりを行うことが不可欠である。
適切な見積もりを行うためのポイント
前提条件
見積もりを出す際は、社内向けか発注者向けかで求められる内容が異なる。
発注者向けの場合、求められるのは社内の平均レベルのエンジニアの作業速度に基づいた工数である。
一方で、社内向けの場合は、開発担当者の作業速度を考慮した実作業日数の見積もりが求められるかもしれない。
以下では、両者に共通する見積もりのポイントを紹介する。
タスクの細分化
ログイン機能の実装の見積もりを求められたとする。
そのまま見積もりを出すと次のようになるかもしれない。
タスク | 作業日数 |
---|---|
ログイン機能の実装 | 5日 |
しかし、タスクを細分化してから作業日数を書き出すと、次のように異なる見積もりになることがある。
タスク | 作業日数 |
---|---|
ログイン画面のデザイン | 1日 |
ログインAPIの実装 | 2日 |
フロントエンドのログイン機能統合 | 2日 |
テストとデバッグ | 2日 |
合計 | 7日 |
これは、テストやデバッグにかかる時間が考慮されていなかったためである。
このように、本来7日で見積もるべきタスクを5日で見積もってしまうリスクを減らすために、タスクを細分化することが重要である。
また、分割したタスクは、見積もり結果を伝える際に根拠として提示することができる。
相対評価の活用
タスクを分割した後、それぞれのタスクに対して難易度を評価する。
以下は、私が使用している評価基準の例である。
難易度 | 作業日数 |
---|---|
大 | 1週間以上 |
中 | 3~5日 |
小 | 数日 |
極小 | 1日未満 |
次に、見積もりやすいタスクから実作業日数を設定する。
残りのタスクについては、先に見積もったタスクを基準に相対的な作業日数を見積もっていく。
この方法は、プログラミングで一番難しいのは「見積もり」だと思う - Qiitaを参考にしている。
記事内では、人は絶対評価よりも相対評価の方が精度が高いという点が強調されている。
この相対評価のアプローチにより、個々のタスクにかかる時間をより現実的に見積もることが可能になる。
まとめ
さまざまな要因により、見積もりは小さめに出される傾向があるが、見積もりの過小算出はプロジェクト全体の成功に深刻な影響を与える。
見積もりの過小算出を防ぎ、精度を高めるためには、タスクの細分化と相対評価の活用が有効である。