工数見積もりをするときに迷ったらどうすべきか

はじめに

最近見積もった案件で、いろいろ迷ったり悩んだりしたことがありました。
その時は、「なんか違うんだけど、時間がない」ということで全体の雰囲気に流されてしまいました（で、今は失敗したな～って気持ちでいっぱいです）。

というわけで、自社の先輩方に「どうしたらよかったのか」をいろいろ聞いてみました。
・・・なので、文末がやたらと「だそうです」とか「らしい」とかになってます

仕様が決まってない部分の工数が出せない！

わかってる範囲だけ見積もって、「仕様があやふやなので、見積もれない部分があります」ってお客さんに素直に伝えていいそうです。
だけど、理由はちゃんと添えないとダメです。例えば、「ファイルのフォーマットによって難易度が変わるので」とか。

また、「仕様が不明だから、xxxの想定だと10日だけどyyyの想定だと20日くらい」って感じにお客さんに伝えると、見積もりの精度を上げたいが故に、仕様を固めてきてくれる可能性も期待できるらしいです。

リスクはどのくらい積んだらいいの？

上司やリーダーが話をしに行くのか、それとも自分が話をしに行くのかによって、リスクを積む・積まないが変わります。
余談ですが、工数って減らすと喜ばれるんですが、なぜか増やすと顔色がよくないんですよね・・・（笑

自分が最終判断者の場合

「最悪のパターン・MAX仕様での開発を想定した工数」をリスク込みの工数とするのが無難

自分が最終判断者ではない場合（＝リーダーなどが話をしに行く場合）

リスクを含んだ数字を出してもいいし、リスクゼロで数字を提出して、最終判断者（＝リーダーなど）に積み上げてもらってもいいし、どっちでもいいです。
迷ったら、リスクゼロの数字を出して、リーダーなどに別途積み上げてもらうのも１つの方法だそうです。

ただし、リーダーなどにリスクゼロの数字を提出するときは、「リスクやバッファは一切入ってない」って伝えておかないとダメです。
私は先日「バッファゼロですよ」って言い忘れました・・・。おかげで、わずかな仕様変更にすら耐えられないスケジュールに放り込まれました

お客さんの想定する工数があまりにも現実とかけ離れた場合にどの工数を削ったらいい？

たいていお客さんの想定が少なすぎるんですけどね・・・
それと、そう簡単に工数を削っちゃダメです。

だけど、もしも削るとしたら、テスト工数。
開発側のテスト期間とお客さんの検収期間をかぶらせるようにすれば、なんとなく削減できたように見せられます。
その代り、その分のリスクやデメリットはちゃんと説明しないとダメです。じゃないと「なんでこんなバグだらけのものを納品したんだ！」って怒られます。

外部システムとの結合が必要な場合は、相手先に依頼してテストデータを作ってもらう必要があることもあります。
そういう場合は、「相手先システムとの調整もあるので、結合試験はお客さんの方でやってくれますか？」ってお願いしてもいいかもです（実際、私の今いる案件では、お客さん側の協力もあってこのやり方が通用してます）。
開発側で持つべきテスト工数をお客さんに丸投げしてるだけなんですが、なぜか「手元に早く納品される！」ってことで、工数に納得してもらえることがあります。

自分の出した工数と他メンバーの出した工数に大きな差があるんだけど・・・。

こういう時って、声の大きいメンバーに流されがちです（少なくとも私は）。
でも、声の大きいメンバーが自分より少ない工数を出していると、流された時に苦労するのは自分です（想定より短い工数で仕上げなきゃいけないので）。
なので、「 自分の出した数字は譲らない 」のが基本スタンスだそうです。

どんな数字であれ、自分なりの根拠をちゃんと持っていること。

譲らないためには、ちゃんとした根拠がないとダメです。じゃないと、
流されるよりも先に（消去法で）切られます

例えば、こんな感じの根拠が必要です。

• ：以前の類似案件がn人日だったから、同じくらいn人日必要。
• ：１画面n人日とすると、x画面作らないといけないからnx人日必要。

FP法やLOC法など、確立してる見積もり手法を使うのも、根拠の１つとしてよいそうです

他メンバーの意見もちゃんと聞くこと。

自分の考えが必ず正しいわけじゃないので
自分１人では思いつかなかった・気づかなかった視点を、他メンバーが持っている可能性も大いにあります。
（そういうのを埋めていくのが、プランニングポーカーなのかもしれませんが。）
他メンバーの意見も聞いて、自分の工数を修正していくのも大事なことです。

ただし
自分の工数を修正するのも根拠が必要です。じゃないとただ流されてるだけです（＞＜

どうしても歩み寄れない場合は他の人に判断してもらう。

乱暴な言い方になってしまうんですが、自分が最終判断者でない場合は、根拠と数字をセットで出して「あとは判断をお願いします」で責任を押し付けてしまってよいんじゃないかと（って多くの先輩方に言われましたそのためのリーダーだろ？とも）。

もしあとで何か言われても、「私は十分な根拠も含めて工数を提示しましたが、他メンバーの意見を採用したのはあなたの判断です」で逃げることが出来ます！（笑

どうやっても初回見積り時の数字はブレ幅が大きくなってしまう。

わかってないことが多すぎるとどうしてもブレ幅は大きくなりがちです。
だけど、それは仕方ないことだそうです
仕方ないからこそ、リスクや不明点を明確にして、ブレ幅が存在する理由を説明しないといけないです。

そこは前述した「仕様が決まってない部分の工数が出せない！」と通ずるものがあると思ってます。
あと、「自分なりの（ブレる）根拠を持っているかどうか」ってとこにも。

規模が大きすぎて途方に暮れてるんですけど。

分割するしかないみたいです。見積もり可能な大きさになるまで、ひたすら分割する。
分割できれば、リリース時期のフェーズ分けもできるようになるかもしれないです。
私も、すごくざっくり２分割しただけで、だいぶ見積もりやすくなった経験があります。

そんな短期間じゃ見積もり作れないよ！

「超概算」であっても、あれこれ調査したくなることはあります。
例えば、「こういうAPI使ったらいけそうな気がするんだけど・・・」とか「すでに別の機能で同じようなのを実装済みな気がする」とか。
そういうのは「調査ための時間」を確保して対応しましょう
詳細であっても概算であっても、見積もりは見積もり。調査のための時間＝自分なりの根拠となる材料を集めるための時間だそうです。
だから、「時間がないので見積もれませんでした」もアリっちゃアリ（・・・という先輩もいたんですが、ちょっとそんな勇気は私にはないです）。

まとめ

あれこれ書いた割には、以下の２点に集約される気がしました

• 自分なりの根拠をちゃんと持つこと。
• どうにもならない・できない時は上の人に判断をしてもらう。

というわけで、これを生かして、次回以降は同じ後悔をしないようにしたいと思います

おまけ

こちらもどうぞ
工数見積りをするときに注意したい３つ＋１つのこと