値引き交渉、その安さは品質とどう引き換えか

「もう少し安くなりませんか」——相見積もりの金額を見比べながら、この一言を発注先に伝えたことがある経営層・現場責任者は多いのではないでしょうか。多少の値引き交渉は商習慣の範囲内だと感じていても、心のどこかで「これを言ったら、どこかにしわ寄せが行くのでは」という引っかかりを覚えた経験はないはずです。

実はこの引っかかりは、根拠のない不安ではありません。見積もり金額は工数と単価の掛け算で組み立てられていて、金額だけを削ると、その分の工数がどこかから消えるという構造になっています。消える工数が、テストやレビューといった「見えにくい工程」から優先的に削られてしまうことが、品質に跳ね返る本当の理由です。

この記事では、値引き交渉がなぜ品質リスクにつながりやすいのか、その構造を整理したうえで、金額交渉をする際にどこを確認しておけば安心かを解説します。

値引き交渉で「安くなった分」はどこから出ているのか

見積書の金額は、おおまかに「設計」「実装」「テスト」「プロジェクト管理」といった工程ごとの工数に、エンジニアの単価を掛けて積み上げられています。発注側が「もう少し安くなりませんか」と交渉したとき、開発会社側の選択肢は実質的に二つしかありません。一つは単価そのものを下げること、もう一つは工数を減らすことです。

単価を下げる対応には限界があります。会社として利益を一定確保しなければならない以上、無制限に単価を下げるわけにはいきません。そのため、交渉が重なるほど、実際には工数側——つまり作業時間の方を削って帳尻を合わせる対応が取られやすくなります。削られる工数の多くは、発注側の目に触れにくいテストや検証の時間に集中しがちです。画面の見た目や動作確認はすぐに分かりますが、例外的な入力への対応や、負荷がかかったときの挙動確認といった地味な検証は、発注側からは工程として見えにくいためです。

ここは、値引き交渉をする前に知っておきたい構造です。「金額が下がる＝作業がまるごと効率化された」のではなく、「金額が下がる＝どこかの作業時間が短くなった」という前提で見ておくと、交渉後の仕上がりへの見方が変わってきます。

なぜテスト・レビューが真っ先に削られやすいのか

工程の中でも、なぜ設計や実装ではなくテストやレビューが削られやすいのでしょうか。理由は、発注側が検収時に確認する内容と直結しているかどうかの違いにあります。

• 設計・実装：画面や機能として「動くかどうか」が目に見えるため、工数を削ると不具合がすぐに表面化しやすい
• テスト：正常な操作では問題が出ず、特殊な条件や想定外の使い方をしたときに初めて不具合が見つかることが多い
• レビュー（第三者によるコードの確認）：外部からは工程の有無そのものが見えにくく、省略されても検収時点では気づきにくい

つまり、検収時に「ちゃんと動いている」ことさえ確認できれば、テストやレビューをどこまで丁寧に行ったかは、発注側からは判別しづらいという構造があります。開発会社が悪意を持って手を抜いているというより、限られた予算の中で「検収に通る部分」を優先せざるを得なくなった結果として、こうした工程が後回しになりやすいということです。リリース直後は問題なく見えても、半年後、アクセスが増えたときやイレギュラーな操作が重なったときに不具合が表面化しやすいのは、こうした経緯が背景にあります。

値引き交渉そのものが悪いわけではない

ここまでの話は、「値引き交渉はしない方がいい」という結論には直結しません。相見積もりを取って金額を比較検討すること自体は、発注側として当然の権利です。一方で、発注者と受注者の間での一方的な価格のしわ寄せは取引上の課題として国レベルでも注目されており、公正取引委員会は下請事業者との取引において、合理的な理由のない著しい低単価での取引を「下請代金支払遅延等防止法」上の買いたたきにあたり得る行為として整理しています。値引き交渉そのものが問題なのではなく、交渉の仕方や対象の選び方によって、品質への跳ね返り方が変わってくる点が実務上のポイントです。

同じ値引きでも、「テスト工程を含めた範囲全体で何パーセント下げられるか」という聞き方と、「テスト工程はそのままに、管理費だけ削れないか」という聞き方では、削られる場所がまったく違ってきます。前者は結果的にテストが薄くなるリスクがあり、後者は品質に直結しない部分から調整してもらえる可能性が高くなります。見積書の「管理費」「諸経費」どこまで妥当かで扱っているように、諸経費や管理費には開発会社によって含まれる内容に幅があるため、値引きの交渉先としてまず確認する価値がある項目です。

交渉の際に「どの工程を削って金額を下げるのか」を具体的に聞いておくことは、実務上ここがポイントです。開発会社側も、何も聞かれなければ安全策としてテストを削ることが多いため、発注側から先に聞く姿勢自体が、結果的に品質を守る行動になります。

交渉前に確認しておきたいこと

値引き交渉をする前、あるいは交渉の最中に、以下の点を確認しておくと、金額だけを見て判断する状態を避けやすくなります。

1. 削る対象を工程名で聞く：「全体で◯%下げてください」ではなく、「どの工程の工数を減らして金額を調整するのか」を具体的に尋ねる
2. テスト項目の一覧を事前にもらう：値引き前後でテスト項目数に変化がないか比較できるようにしておく
3. 検収基準を文書化しておく：何を確認すれば検収完了とするかを明文化しておくと、工数が削られた影響が検収段階で見えやすくなる
4. 要件定義の曖昧さを先に潰しておく：そもそも要件が曖昧なまま見積もりが作られていると、値引き交渉以前に工数の見積もり精度自体が低く、どこを削っているのか把握しづらくなる

特に4点目は見落とされがちですが、要件定義が固まっていない段階での値引き交渉は、削られている工数が本当にテストなのか、そもそも設計の手戻り分なのか、発注側からは判別がつきません。追加開発費用が高く感じる理由と相場の考え方でも触れているように、工数の見積もり精度は要件の明確さに左右される部分が大きいため、値引き交渉をする前に、まず何を作るかの認識合わせができているかを確認しておくことが、遠回りのようで近道になります。

まとめ

• 値引き交渉で金額が下がるとき、削られているのは単価か工数のどちらかであり、工数側はテストやレビューなど発注側から見えにくい工程から削られやすい構造がある
• 値引き交渉自体は商習慣として自然なものだが、「何を削って金額を下げるのか」を工程名で確認するかどうかで、品質への跳ね返り方が変わる
• 交渉前には、テスト項目や検収基準を文書化しておき、そもそもの要件定義が曖昧なまま見積もりが作られていないかも合わせて確認しておくと安心材料になる