こんにちは。Kaneyasuです。
先日、すごい広島 IT初心者の会 忘年会に参加しました。
その場で、見積に関する質問があったので私なりのテクニックをまとめてみました。
本記事のターゲット
本記事は、過去私が所属していた二次請のSIerにおいての見積に関する経験をもとに書いています。
二次請け以降のエンジニア、若手のエンジニア。
技術には明るいけれど、見積の作り方はよくわからない方に読んでもらえれば幸いです。
全体的に経験に基づく主観です。
見積には魂を込める
基本的に見積には時間をかけてください。
ほぼほぼここでプロジェクトや仕事の成否が決まります。
見積に時間をかけずに、後で問題が露見して工数オーバーになった場合、挽回はとても難しいです。
仕様変更ならともかく、見落としによる追加請求は基本通りません。
現在の私も通さないと思います。
もし見落としがあったら次に活かす方向で考えたほうがよいです。
概算見積の金額を後で超えることは許されない
ざっくりとした見積が欲しいと言われて概算見積を求められることがあります。
この時、ざっくりとした見積が欲しい理由に着目してください。
ざっくりとした見積が欲しい理由が、予算の確保の可能性があります。
そうだとすると、発注金額は確保した予算以上にはならないので、概算見積で提出した金額を超える見積を出し直すのは基本通りません。
予算を超えるからです。
そこに悪気はないと思います。
ざっくりとした見積と言われても、できる限り時間をかけて見積を作りましょう。
時間がない場合は思いっきり盛りましょう。
盛った場合は、現状不明点が多いので盛っていること、明確になった時点で再見積することを説明しましょう。
クライアントも大体わかってくれます。
できれば、明確になった時点で概算金額を超えるような仕様が見つかった場合は調整させて欲しいと言っておくのがよいと思いますが、これはクライアントとの関係性次第かなと思います。
あまりにも先が見えない場合は、今時はPoC（Proof of Concept、概念実証）しましょうという方向で、一旦工数ではなく期間での見積に切り替える手があります。
計算する時は自分の粒度で、見せる時は相手の粒度で
見積工数を計算する時は、粒度を小さくして計算するほうがよいです。
より明確に答えられるまで粒度を小さくしてそれらを積み上げていきます。
データベース、バックエンドプログラム、フロントエンドとか、それも難しければ部品単位でもよいでしょう。
ただ、これをそのままクライアントに見せるのは避けたほうがよいです。
細かすぎる見積は見る方もエネルギーを使うので、悪印象を持たれるかもしれません。
仮に、見積の説明の場があるとしたら、細かい見積は説明も長くなるので、双方が真面目になりすぎてピリついたり、中弛みになって大切なことが伝わらなくなる可能性があります。
見せる時は、業務や画面などのクライアントのイメージしやすい単位にサマリーしてあげましょう。
数字の根拠を求められた時に説明できれば大丈夫です。
数字に意味を持たせる
わからないことがあったり、不明点が多い内容は、見積がしづらいです。
ここでは、見積がしづらい要素があるのをリスクが有ると書かせてもらいます。
見積を見せる時は、リスクが無い内容と有る内容は、数字に差をつけたほうがいいです。
全体的に工数に統一感があると、どれも難度が同じなのかと思われてしまいます。
リスクが無い内容と有る内容は、パッと見で違和感を感じるぐらい数字に差があってよいと思います。
違和感から、リスクはなんなのか？どうすれば解消できるのか？という議論を発生させられるかもしれません。
見積は通したいものですが、リスクがあることを意思表示しない・気づいてもらえない状態で通ってしまうと後でお互い不幸になる可能性があります。
なお、見積を提出する時、リスクによる工数を複数の内容に分散させて積むのは危険です。
見積に書かれている内容は、全部を発注してもらえるとは限りません。
一部をカットして、発注されることもあります。
この場合、リスク用の工数を全体に分散しているとせっかく積んだリスク用の工数が消えてしまう可能性があります。
営業的なテクニックは使わない
エンジニアが見積するのは基本的に工数のみで、利益の部分は営業の方に任せる関係性がよいです。
（見積途中に金額も計算しますけどね。）
エンジニアは基本プロジェクト単位で考えますが、営業の方ならより広い視点でこれは利益を取る、これは取らないという判断ができるからです。
もしエンジニア自身が利益のところまで考える必要があり、直接交渉もしないといけないのならば、営業的なテクニックは使わないほうがよいと思います。
昔、見積は値下げが来るのを見越して120％で出すという方法を習いましたが、
これは常日頃金額の交渉をする営業の方が語るテクニックなのでこれと同じことをエンジニアがやると高確率で失敗します。
私はこれを実践してまどろっこしいことをするなと叱られたことがあります。
エンジニアはあくまで積み重ねるようなロジックに基づく数字で話をすべきでしょう。
最後に
本記事は以上です。
エンジニア界隈では、見積のノウハウを教えてもらう機会は少ないと感じています。
本記事が誰かの役に立つことを願います。
何かご意見・質問ある場合はコメントいただいけると幸いです。