システム開発に工数見積りはつきものです。でないとスケジュールを立てられません。
では工数の見積りはどうやってやるのでしょうか。経験から話したいと思います。
見積りが難しい場合はバッファを設けるしかない
まずはプロジェクト全体のスケジュール、納期があったとして、あとは工程ごとにPMやリーダーが大体のスケジュールを作るでしょう。
設計はこれくらいまで、実装はこれくらいまでに、テストはこれくらいから開始してこれまでに終わらせるとか。
ですが新規開発だとどの工程にどれくらいかかるものか見積りが難しいです。
保守などで開発実績がある場合はそれを参考にすればいいので見積りしやすいですが
新規だとベースというか拠り所にするものがありません。
一応ファンクションポイント法だとか見積り方法はありますがあてにならないので実際は使わないでしょう。
（あれで見積り出されたら憤慨だ。）
結局何かしら見積りの根拠を探しますが、今回やろうとしているプロジェクトに開発手法やら、開発環境やら、業務内容やら、未知の部分が多ければ多いほど過去の経験が使えずただでさえ不確かになりやすい見積りがさらに不確かなものになってしまいます。
不確かな見積りは炎上への道です。
でも見積りは立てないといけない。
困った、今回スケジュールはなし、というわけにはいきません。
こういうときはスケジュールにバッファを持たせるしかありません。
これも闇雲にバッファ持たせてもしょうがないのでいったん仮に作ったスケジュールに係数をかけて作成します。
例えば何も問題なく順調だと20日で終わる予定だが不確定要素があって2割程度遅延を見込むとするなら1.2をかけて24日とするわけです。
ここではわからないなりにでもなぜ2割にしたのかを明確にしておいたほうがいいです。
そうすれば後でその根拠に対して2割が妥当だったかどうかの振り返りができます。
あるいはスケジュールのレビュー時点で妥当かどうかの指摘をしてもらえるかもしれません。
なんとなくの2割だとそういうことができません。
無理なスケジュールだったら交渉すべし
さて大枠のスケジュールが出来たので実際の担当者に割り振りして作業してもらいます。
あなたが担当者だとしてもらったスケジュールでいざ作業開始してみたら、工数的にとてもスケジュール的に無理なことが判明しました。
その場合どうするでしょうか？
多大な残業が見込まれてもスケジュールを守るために残業するでしょうか。
まだ残業してリカバリできるならいいですが、仕様が不確定、あるいは開発環境が整備されてないなど自分一人では手に負えない場合はどうでしょうか？
もちろんこういう場合は今のスケジュールでは難しいことを伝えて交渉するべきです。
まあ、ただ無理といっても建設的でないのでこういう理由でこれくらいかかります、という言い方になるでしょう。
受け入れられればリスケされるでしょうし、別の方法を提案されるかもしれませんが悪くはならないはずです。
（ここで聞いてくれなければブラックです。）
この世に交渉できない仕事はありませんから黙って受け入れる必要はありません。
