値下げを受け入れた開発会社に何が起きたか｜相見積もりで安くさせた先にあるもの

この記事は、開発会社としてあまり書きたくない話を書いています。相見積もりで値下げを受け入れた結果、FUNBREW側の工数が苦しくなり、本来できたはずの提案ができなかったという経験です。発注する立場からすると、値下げ交渉は当然の行動です。ただ、その先で何が起きるのかを知っておくと、価格の見方が変わるかもしれません。

相見積もりで、最後に効くのは何か

他社の見積もりは、こちらからは見えない

前提として、開発会社が他社の見積もりを知り得る機会は多くありません。負けた案件について「いくらの差で負けたのか」を教えていただけることは稀ですし、勝った案件でも詳細までは分かりません。ですので、以下は限られた情報からの実感として読んでください。

選ばれる理由は、多くの場合 品質に集約される

そのうえで感じているのは、最終的な判断は多くの場合品質に集約されるということです。金額だけで決まるなら、常に最も安い会社が選ばれます。実際にはそうならず、話を聞いたうえで「この会社に任せたい」という判断が先にあり、そのあとに価格の話が来ることが少なくありません。

値下げを受け入れた案件で、実際に起きたこと

依頼したいが、金額を下げてほしいという相談

最終的にFUNBREWを選んでくださったお客様の中に、こういう経緯の方がいらっしゃいました。他社がかなり低い見積もりを出していたため、その金額を引き合いに、依頼したいので価格を下げられないかというご相談をいただいたのです。

ありがたいお話でしたし、お引き受けしたい案件でもありました。そこで価格を抑えてお受けしました。判断としては、値引きを飲んででも受けたい案件だった、ということです。

結果として、最上の提案ができなかった

正直に書きます。結局のところ、こちら側で工数が苦しくなり、最上のご提案ができなかったという事実があります。

作るべきものは作りました。ただ、値下げした分の工数はどこかから捻出するしかありません。そのしわ寄せが行くのは、動作するかどうかとは別のところ——「もっとこうした方がいいのではないか」と提案する余地です。決められた仕様を満たすだけなら削れませんが、より良い形を考えて持っていく時間は、削ろうと思えば削れてしまいます。

安くさせたとき、最初に削られるもの

ここは一般論ではなく、自社で起きたことからの説明です。値下げを受け入れたとき、まず影響が出るのは次のような領域です。

発注側から見て厄介なのは、削られた側は見えないということです。頼んだものは納品されているので、何が失われたのかは分かりません。提案されなかった案は、存在しなかったのと同じように見えます。

予算の絶対額が小さいほど、この現象は強く出ます。総額が小さいところから工数を削ると、融通を利かせる余地そのものが無くなるためです。この構造は「これは追加費用です」と言われるのはどこからかや小規模なシステム開発で契約書は必要かでも触れています。

発注側は、価格差をどう見ればよいか

安い見積もりが悪い、という話ではない

誤解のないように書いておくと、「安い見積もりを出す会社は品質が低い」と言いたいのではありません。前提となる作業範囲が違えば、金額は当然変わります。比べるべきは金額そのものではなく、その金額で何をどこまでやるのかです。同じ機能名でも、含まれる作業が違えば別の見積もりになります。

値下げを頼むなら、範囲もセットで相談する

もし予算が合わない場合、同じ内容のまま金額だけを下げてもらうのではなく、その予算に収まる範囲はどこまでかを聞いていただくのが、結果的に発注側の得になります。範囲を一緒に削れば、残った部分に工数を集中できます。金額だけを削ると、どこが薄くなったのかが誰にも見えないまま進むことになります。

営業担当と実際に作る担当が分かれている会社では、この調整がさらに難しくなります。その点は営業と実務が分離した開発会社に発注するときに書きました。

まとめ

相見積もりで最後に効くのは、多くの場合は品質です。金額だけで決まるなら常に最安の会社が選ばれますが、実際にはそうなっていません。

一方で、値下げを受け入れた案件では、こちらの工数が苦しくなり最上の提案ができませんでした。値下げした分は、仕様どおりに動かす部分ではなく、より良い形を考える余地から削られます。そして削られた側は、発注側からは見えません。

予算が合わないときは、金額だけを下げるのではなく、その予算でどこまでできるかをご相談ください。範囲の組み直しからお手伝いします。お問い合わせよりご連絡ください。