ITエンジニアで開発をしていると「この開発の見積もりをして」とざっくりお願いされることがあります。
ただ、見積もりが初めての場合や経験したことのない大きな案件の見積もりとなると「どうすればいいんだ？」と思ってしまう方が多いのではないでしょうか？
この記事では僕自身の経験をもとに「こうしたら迷わず見積もりができるんじゃないか？」ということをご紹介します！
この記事は、こんな人にオススメ！
・始めて見積もりをする人
・大きな案件の見積もりをお願いされて不安な人
見積もりを始める前に
なぜ見積もりをするのか？
さっそく見積もりのやり方をご紹介したいのですが、「見積もりをお願い！」と言われて「はい」の２つ返事をしていませんか？
単に見積もりと一言に言っても見積もりをお願いされるケースは
- ざっくりで良いから最大（最小）でどれくらいかかるか出して欲しい
- 工数感によってやる/やらを判断するようなケース
- 少し時間がかかってもできる限り正確に見積もって欲しい
- やることは確定な開発をスケジュール通り終わらせるために必要なリソースを把握したいようなケース
- 工期が知りたい
- 見積もり対象だけではなく、他の開発との兼ね合いでいつリリースできるのか知りたいようなケース
とさまざまです。
僕自身の経験だと、ざっくりでいいって言われて出した見積もりが経営層までそのまま報告されてしまい、
ざっくりなので当然ブレブレで「なにやってんだー」ってなったことがあります😓
なので、見積もりをお願いされたら
- 見積もりの結果ってどう使われますか？
- どのくらい正確さが求められますか？
というような相手の求める見積もりのイメージを聞き出すようにしましょう！
ゴール（成果物）を意識する
見積もりをする前に、見積もり後のことも考えてみましょう。
見積もりなのでとりあえず「〇〇人月」という数値は最低限必要そうです。
ただ、そのまま報告すると。。。
見積もり終わりました！〇〇人月です！
その根拠は？
。。。。。
報告時のこの沈黙は冷や汗をかきますねw
だいたい見積もりの根拠は聞かれるので、こんなふうに答られるよう意識して見積もりを進めましょう！
この開発は、機能A・B・Cの開発が必要です。
機能Aは、過去の機能Dと同じくらいの規模感なので◯人月です。
機能Bは、機能Aと同じくらいの規模感なのですが使ったことのない技術を新たに使うので、バッファで△倍して◯人月です。
機能Cは、全く新しい領域のため一旦◯人月で見積もっていますが、x/xxまでに開発の一部分をやってみるので
その時により正確な見積もりを出します。
見積もりのやり方
見積もりの目的が確認できて、ゴールも明確になったところで、見積もりのやり方をご紹介していきます。
この記事を読んでくださっている方はきっと「見積もりができない」というような気持ちで読んでくださっていると思うので、「なぜそう思うのか？」から整理してみます。
なぜ見積もりができないのか？
いきなり「AIを使った業務改善のためのシステム開発の見積もりをして」って言われたら「えっ？」ってなりますよね？
けど、「Webページのこの部分のURLを書き換えの見積もりをして」って言われたらどうでしょう？
後者ならできそうな気がしますよね？この違いはなんでしょう？
おおまかに規模と作業の具体性で比較してみます。
| 規模 | 作業の具体性 | |
|---|---|---|
| AIを使った業務改善のためのシステム開発 | 大きい | 抽象的 |
| Webページのこの部分のURLを書き換え | 小さい | 具体的 |
つまり、自分がイメージできるレベルに「規模が小さく」「作業が具体的」であれば見積もりができるということです。
なので、「規模が大きく」「作業が抽象的」で見積もりができないと思ったら、
見積もりがレベルまで「規模が小さく」「作業が具体的に」なるまで分解しましょう！
過去の経験と比較できるまで分解
先ほどは「Webページのこの部分のURLを書き換え」というのを「規模が小さく」「作業が具体的」な例として出しましたが、規模が大きければ大きいほどこんな粒度まで分解していてはキリがないですよね😅
そこで、目安として「過去自分が経験したことのある類似開発と比較できる」粒度に分解してみると良いと思います。
ここは経験に応じて、機能単位で良い人もいれば実装ファイル単位まで必要な人もいると思います。
「ゴールを意識する」で紹介した「機能Aは、過去の機能Dと同じくらいの規模感なので◯人月です。」が言えればOKです！
不確実性の分はバッファを積む
例えば、組織として初の試みをしようとしていたり、転職直後だったりすると「類似経験はあるけれどもそれが本当にそのまま適用できるのかわからない」という時があります。
そう言った場合には、不確実性がある分バッファを積んでおきましょう。
バッファの積み方については見積もり時の慣例を現場ごとに聞くので、事前に聞いておくと良いと思います。
余裕があったらスモールトライアル
もし見積もりの期間に余裕があれば、その時間でごく一部を実際に開発してみましょう！
機能A~Zまであるのであれば、機能Aだけ開発〜リリースまでやってみるという具合です。
※機能よりももっと細かい単位でもOK
実際に手を動かしてみると予想外のところで時間がかかったり、工数に積むのを忘れていたことに気付けたりします。
そして見積もり対象の開発自体の、最も根拠として強い経験を得ることができます！
まとめ
2. 分解した１つ１つに工数を当てはめる
2-1. 類似経験の工数を参考にする
2-2. 不確実性に応じてバッファを積む
2-3. スモールトライアルで経験を積む
最後に…
見積もり経験が浅いと出した見積もり通りに開発が進まないなんてこともあると思います。
けど、大丈夫です。100%の精度の見積なんて存在しません。なぜならコストが分からないから「分からないなりに分かろうとする」のが見積だからです。
思い通りに進まなかったその経験で、早期に見積もりし直せば挽回の可能性があるかもしれませんし、別の見積もりのときの軸になってくれます！
