- なぜプログラマーの工数見積もりが難しいのだろう？
- 見積もりで気をつけることは？
6年半の間プログラマー(Linuxアプリケーション)として働いてきた私が、プログラマーの工数見積もりが難しい理由と対策を解説します。
目次
プログラマーの工数見積もりが難しい理由について
プログラマーの工数見積もりが難しい理由は次の通りです。
- 期限内に見積もらなければならない
- システム仕様を短時間で理解しなければならない
- システム仕様が難しい場合がある
- プログラミングが難しい場合がある
- 見積もり根拠をまとめなければならない
対策も含めて、順番に解説していきます。
①期限内に見積もらなければならない
決められた期限の中で見積もりを完了させなければなりません。
製品のリリース日が決まっていることがほとんどなので、のんびり見積もることはできません。
お客様が提示する期限内に後述する②〜⑤の困難を乗り越える必要があります。
この意味で、個人的には見積もり作業が一番疲れます。
②システム仕様を短時間で理解しなければならない
見積もりを始めるにあたり、まずは担当する機能のシステム仕様を短時間で理解しなければなりません。
なぜなら、仕様を理解しないと、プログラミングのボリューム・試験工数を正確に把握できないからです。
それに加えて、見積もり時はシステム仕様書が未完成である場合が多いです。
照査・検認を受けておらず、「表現がわかりづらい」「誤字脱字がある」ことも多いです。
不明点は質問をするべきですが、時間も限られています。
表現がわかりづらい仕様は、見積もり資料の補足欄に「仕様書のこの文言は、こういう仕様であるという理解で見積もりしました」と明記し、お客様に了解を得ることが重要です。
こうすれば、自分の仕様理解が間違っていて工数が大きく膨れ上がることになっても、「見積もりの時に、この仕様の理解で良いとお客様から了解を得ていたので、私だけの責任ではないですよね！？」と言えるのです。
③システム仕様が難しい場合がある
システム仕様が難解であるほど、見積もりは難しくなります。
例えば次のような機能のシステム仕様は難解になりがちです。
- アプリケーション・プロセス間通信に関わる機能
- 画面遷移
順番に解説していきます。
アプリケーション・プロセス間通信に関わる機能
アプリケーション・プロセス間通信に関わる仕様は、検討が甘いと特定の状態・タイミングでのみバグが発生する場合があります。
たとえば、プロセス間通信中に「優先度が高い割り込み処理が発生した」「相手側のプロセスが終了した」場合も、システム全体が正常に動作するように仕様が決められていなければなりません。
状態遷移図やタイミング図で仕様が整理されていれば問題ありませんが、システム仕様が文章だけで構成されている場合は危険です。
システム仕様で揉めることを想定し、別枠でリスク分の工数を大きめに見積もる必要があります。
あまりにも難解である場合は、直接打ち合わせをして確認するほうがいいでしょう。
お客様も正確な見積もりを望んでいるので、依頼をすれば打ち合わせをしてくれると思います。
画面遷移
画面遷移に関する仕様もややこしくなる場合があります。
例えば、カーナビの画面で次のような仕様があったとします。
仕様
- 走行中の車のドアが開いたら最優先で「ドア開警告画面」を表示し、ドアが閉まったら「直前に表示していた画面」に戻る。
- いずれかの故障が発生したら最優先で「故障警告画面」を表示し、故障が解除されたら「直前に表示していた画面」に戻る。
この時、下記のような不明点が出てきます。
仕様の不明点
- ドア開警告画面表示中に故障が発生したら故障警告画面を優先して表示すべき？
- 故障解除で、故障警告画面から直前に表示していた画面に遷移すると不都合が起きる（起動時のロゴだけ表示する画面に遷移して永久に画面操作できない等）が、この場合はどこに遷移すべき？
このように、見積もり時点で影響がある全ての画面遷移ケースを洗い出すことは困難なので、この場合もリスク分の工数を大きめに見積もる必要があります。
④プログラミングが難しい
サードパーティのライブラリ追加、OS更新に伴うアプリケーションの変更など、動かしてみないとどんな問題が出るかわからない場合があります。
この場合、見積もり前に検証作業の時間を設けてもらうことが理想です。
それができない場合、最悪のケースを想定してリスク分の工数を大きめに見積もる必要があります。
また、流用性・保守性をどこまで担保するのかも、お客様と事前に調整しておくことが無難です。
システム仕様通りに動くプログラムを作るだけなら簡単だが、他のプロジェクトにも流用できる仕組みを盛り込むとなると途端に難易度が上がる場合があります。
「できるだけ早く作って欲しい」のか「流用性・保守性を重視してほしい」のかはお客様にしかわかわないので、事前に確認するのがベストです。
⑤見積もり根拠をまとめなければならない
プログラマーは、見積もりの根拠を説明できるように準備しておかなければなりません。
というのも、お客様から見積もり資料にツッコミが入ることは多々あるからです。
お客様としては、高品質な成果物を「早く」納品して欲しいと思っています。
お客様の欲求に流されないためにも、「数字ベース」か「過去の実績ベース」で工数を見積もれば、見積もり根拠をスムーズに説明できます。
「数字ベース」の場合は、「ソフトウェア設計書の修正ページ数（10ページ）」「プログラムを1000ステップ追加」「試験ケース数は50」などと洗い出し、単位ごとにかかる時間を掛け算して工数を算出します。
「そんなに細かく見積もる時間がない！」といった場合は、過去の実績(似たような機能の実装にかかった工数)を参考にして工数を算出しても良いでしょう。
まとめ
プログラマーの工数見積もりが難しい理由と対策について解説しました。
見積もりは経験が浅ければ浅いほど難しいものです。
たくさん経験を重ねて慣れていきましょう。