正確な見積もりを作る方法について学んでみた
モチベーション
プロジェクトの新規機能の追加などの際に工数の見積もりを求められるケースが増えてきたので、この辺りで一度基本的な見積もり方法を学んでおきたいと思った。
プロジェクトに入っていると、
- ベテランでスケジュール管理が優秀な方ほど余裕のある見積もりをしている。プロジェクトにゆとりを持たせている
- ジュニアであるほど「すぐにできると思います！」というように甘い見積もりをして遅延させがち
というような印象がありました。
ジュニアのエンジニアが結構時間がかかりますというと「実力がないから時間がかかるのではないか」と思われてしまう..というような考えがあったり、実装前に考慮できることが少ないため「すぐにできます！」というようなことを言ってしまいがちになっているのかなと。
一度お伝えしたスケジュールを守れないのは、仕事をする上でどうなのか..(情けない)と思っていたので、自分もここについてはしっかりと学びたいです。
(僕も想定外の事態への見積もりの甘さが理由で遅延させてしまったこともちらほら...😭)
一度言ったことは守りたいですよね。
根拠を持って工数やスケジュールについては説明し、お客様にも納得してもらいたいですよね。
見積もりの流れ
- 基本設計
- 工数見積
- スケジューリング
- バッファ追加
- 金額見積もり
- レビュー
基本設計
精度の高い工数見積もりをするためには、基本設計が必須。プログラマにそのまま渡せるくらいのものを作成するべき。
工数見積
基本設計をベースに工数見積もりを行う。
想定メンバー
工数見積を行う時には要求する技術経験年数が3年のエンジニアを想定すると良い。
理由
- 想定メンバーが誰になっても計画に影響しにくい
- 要求する技術経験年数が3年のエンジニアなら、外部から調達しやすい
優秀なエンジニアを想定して見積もりを行ってしまうと、その人がいなくなったり不足の事態が起こったりした場合に、計画が破綻してしまう。
見積もりの明細の記載内容
実装を担当するエンジニアにそのまま作業依頼できるくらいには細かく作ると良い。
実装担当者に失礼のない工数
高稼働を強いるようなスケジュールではだめ。
スケジュールに余裕がないと高品質なものができない。
インフルやコロナなどの不足の事態が起こった場合に、遅延してしまう。
スケジューリング
- 工数見積もり
- アサインできるエンジニアが何月に何%稼働できるか
を考慮してスケジューリングを行う。
バッファを確保するために各月の予定はギリギリまで設定しないようにしておくと良い。
余裕がない開発は想定外の事態に対応できない。(見積もりの時点で想定外の部分まで完全に把握し切るのは無理ですよね..笑)
小さめなプロジェクトや機能追加の場合は自分が頑張って尻拭いしちゃえばOKということも通用しますが、大きくなると無理だと思うので。
バッファ追加
想定外の事態への対応のために必須。
- 病気や怪我
- 開発の進捗が想定よりも遅れている
- 基本設計時の考慮漏れ
など。
提示したスケジュールを守るためにも、必ずバッファを追加したスケジュールをお客様に提示する必要がある。
バッファにお金を取るの?
スケジュールの遅延などへのリスクヘッジは「高品質なシステムを作るための付加価値の高いマネジメントサービス」なので有料！
バッファ追加の方法
- 完了日の期間を延ばす
- 現人員にて未割り当ての日程を組む
- 人員を追加配置する
完了日は遅いほど守れる確率は高いですし、人員はいるに越したことはないですよね。
バッファ追加箇所
- リリース日
- 難易度が高い機能の開発工程
- 外部関係者と共同作業をする工程
自分でコントロールできない箇所や、不測の事態に陥りやすい難しい機能の実装などリスクが高めなところにバッファ追加しておくと良い。
工数追加が難しくてもリリース日だけはなんとか延ばせると良い。
スケジュールは開発側が決めれると良い。
金額見積もり
見積もり金額 = 工数 × 単価
これはシンプル。
人員コストの考え方
こちらも見積もり対象プロジェクトで必要とする技術の経験年数が3年のエンジニアを想定しておくと良い。
特定の人員を想定したものの場合は、その特定のメンバーが入れなくなった場合に想定とコストが変わってしまう。
実際に想定しているのが経験年数3年のエンジニアなので、そりゃコストも同様ですよね。
レビュー
お客様に工数見積もり・スケジュール・金額見積もりを提示する前に必ずレビューを入れる。
大きなプロジェクトであれば社内レビューだと思いますし、小さなプロジェクトでは、実装担当者などに直接確認するのが良いのかなと。
「工数はなるべく積んでおいた方が良い」「スケジュールはなるべく余裕を持って延ばせると良い」と100万回くらい先輩エンジニアの方々から言われてきているのですが、それでも 見積もりが甘い or お客様側からの要望に応えたいなどの理由で余裕のある見積もりができていないことが多々ある状況です。
要望はなるべく叶えたいし、期待もできるだけ応えたいんですが、遅延するくらいなら頑張って交渉するべきですよね。
(自分に言い聞かせています)
レビューが完了し、万全を期した状態で見積もりを提出しましょう！
(と言ってもなるはやで作る必要があるんですけどね)
最後に
いかがでしたか。
とりあえず工数/金額の見積もりの要点は押さえられた気がしませんか。
もっと細かく内容も参考文献に書かれていたので、どこかでこの記事を増強したいです。
参考文献
ウォーターフォール型の開発での見積もり方法やコツを説明してくれていました。
普段はアジャイルでの開発が多いですが、参考になるポイントは多いのかなと思います。
X(旧Twitter)ではエンジニアとして技術関連の発信をしています
ぜひFollow Meです！
Discussion