こんにちは、うしまるです。
この記事では、エンジニアにとって避けて通れない「見積もり交渉」についての話をします。
ここがしっかりできていないと
- デスマーチをひた走ることになる
- 顧客から希望通りの単価がもらえなくなる
- 無駄な改善要求をされる
この記事では、そんな見積もり交渉で上手く言ったパターンとそうでなパターンを先日同じ日に経験しましたのでその時の話をします。
先日こんなことがありました
先日見積もり交渉を顧客としました。
見積もり共有会を実施し、2つの案件の共有をしたのですが、片方はボロボロに、もう片方はすんなりOKがもらえるという経験をしました。
なぜそうなったのか、2つの見積もり交渉の中でその違いが見えてきたので見積もり交渉に悩みを抱えている方の参考になれば幸いです。
うしまるのプロフィール
違いについて説明する前にうしまるについての簡単なプロフィールを紹介します。
企業向けのWindowsアプリケーションを開発で4人チームのPLをやっています。
ただ、人員構成が少し特殊で社内の立場的には、上司2人と若手1人に私といった構成です。
その他のプロフィールはこちらにもありますので興味がある方は覗いてみてください。
交渉で上手くいかないのはなぜ？
- タスク量の違い
- タスク内容が大雑把
- 案件難易度の違い
見積もり交渉で揉めるのは、QCDと呼ばれる「品質・コスト・納期」に関する部分です
品質でいえば、顧客の作って欲しいものが作れないとかイメージが違うとか
コストは、基本Slerにおいてはプログラマに対してどのくらい作業をさせるかといった人件費がほとんどなので工数がどのくらいかかるかですね
納期は、コストにかかる部分もありますが、Slerの場合他の案件をやっているときもあるのでいつから着手できるのかとかいつまでに終わらせられるのかといったところが話題になりやすいです
特に企業向けの場合、全体的なソフトのリリース時期や市場のインパクトを考えて早く出したいといった側面もあるので気にされることが多いです
タスク量の違いでモメル
仕事を依頼する人には大きくは2種類います
1つ目はそのソフトの仕様面で精通している人
このパターンの場合は、ある程度見積もり対象になる案件の中身にも精通しているので過去の案件からこのくらいっていう目星がついています
しかし、がっつり開発に携わっているわけではないので常に正しい訳ではありません
この感覚のズレが上手く埋められないとOKを勝ち取ることができなくなります
今回はこのパターンでモメてしまいました
2つ目はそのソフトに精通していない人
Slerの仕事依頼の中にはそもそもIT知識ゼロと行った方もいらっしゃいます
そういった人は見た目部分しかわからないため、プログラミングを学んでいる人はよく分かると思いますが見た目は少し変わっただけでも内部の処理は大工事になることも十分ありえます
ただし、わからない人にはそんなこと言われても…
となってしまうためここの感覚のズレも上手く埋められないとOKwo勝ち取ることができなくなります
タスク内容が大雑把でモメル
一つ前のと被ってしまう部分にはなってしまうのですが
タスクが細かく見積もれていないことでモメるパターンもあります
これは、見積もりは時間をかければかけるほど精度があがりはするのですが、その分時間も消費してしまうので結局のところ交渉するのにどこまで見積もるかが担当者の腕の見せ所になってしまうわけです
※場合によっては見積もりでほぼできちゃったなんでことも…
これは見積もり依頼をする人によって違ってきますが
顧客との認識が違う場合は作業を落とし込んでの議論となります
このとき、見積もり担当者のイメージが漠然としていると
言いくるめられてしまいます
これも2パターンあって
ソフトの仕様面で精通している人は、過去の経験値から細かい作業は抜きにしておおまかなやらないといけないことはイメージがついていたりします
しかし、それが見積もり担当者の口からスラスラ出てこない場合に、大丈夫なの？
といった形でモメていきます
今回はそのパターンでした
もう1つがソフトに精通していない人は
結局の所細かいところを専門知識を並び立てて話したところで結局理解してもらえないときは理解してもらえないので、いかに伝え方を工夫するかが鍵になっていきます
案件難易度の違いでモメル
これはアサインする担当者のスキルによるところもあればそもそも見た目は簡単そうに見えたけれど実は調査してみると難しいことがわかった場合などに影響します
特に問題になるのが、相手がカンタンだと思っている場合
例えば一見簡単そうな場合でも、既存のソフトウェア改修をするときに
作り上どうしても回避できない場合とか
お決まりのルールに則ることが難しい場合とかがあるわけです
見積もり上こういったところは調査すると本当に見積もりで開発がほぼ終わる
なんてことにもなりかねないので塩梅が難しいところです
結局のところ
顧客とモメル原因はわかったとしてもじゃあどうすればいいの？
というところですよね
ここでやってはダメなのが安易に顧客の言いなりになることです
多いと言われたのでここは減らそう
とか
ここの納期を早めよう
とか
そんなことをした先に待っているのは
デスマーチの日々でしかありません
ということでもう一つの事例が一つの正解になるかもしれません
見積もり交渉をスムーズに行うために
- タスクの共有をしておく
- タスクの細分化をしておく
今回紹介した見積もり交渉でうまくいった原因は何だろう？と考えたときこの2つの項目があったからこそ成功したと考えています
どちらかというとコスト面では、上手く行った側の方がコスト面で不利でした
それでも顧客がOKを出してくれた理由がまさに
タスクの共有と細分化です
会議は始まる前にすでに終わっている
では無いですけれど、この2つが事前にできていたことでスムーズに進みました
タスクを共有しておく
タスクを共有しておくというのは何かというと
事前調査の段階で不明点や大変なところを見積もり依頼者へ共有しておくということです
つまりいかにタスクの難易度が高いのか
いかにタスク量が多いのかを見積り依頼前に共有しておいたことで提示した見積もりは妥当だよねという合意がすでに形成されていたのです
タスクの細分化をしておく
見積もりの認識が違う場合は、いったいどういった作業に時間がかかるのか交渉する必要があります
私達もたとえば車車検に出そうと持っていったときに1週間かかります！とか言われたらなんでやってなりますよね
見積もり時にもせめて、こういった部品を交換するのに取り寄せをしないといけないのでとか言われるとまだ納得できますよね
それと同様のことが見積もりの段階でもできておく必要があります
そのためにも事前調査でこうしてああしてくらいはピックアップできてると良いです
ここはどこまで細分化するかは何度かすり合わせながら調整していく必要があるので少し経験がものをいうところがあるかもしれません
ある程度普段の作業を細かいタスクで管理するようにしておくと見積もりがしやすくなりますのでおすすめです
最後に
今回は、うしまるの開発現場で経験したことをもとに見積もり交渉の失敗例と成功例を紹介しました
見積もりは、大なり小なりSlerで働くとついてまわす作業ですし、ここを間違ってしまうと本当につらい日々を過ごしかねないので仕事を依頼してくれる人と仕事を受ける人両者ともWin-Winになる境界線を模索していきたいですね
それでは、今日はこのへんでノシ
ポチッとしてもらえると励みになります！
