Salesforce開発案件で単価交渉に失敗する理由｜Apex・LWC経験者が陥る落とし穴

先に結論を書く。Salesforce開発案件で単価交渉に失敗するエンジニアの多くは、技術スキルが低いからではない。むしろ逆で、ApexもLWCもそれなりに書けるのに、交渉のテーブルで技術以外の情報を握っていないから足元を見られている。本業でSalesforceの開発をやりながら案件情報を追っていると、「腕はいいのに安く受けている人」の多さに毎回うなる。この記事では、Apex・LWC経験が2年以上ある個人受託・フリーランス向けに、単価が伸びない理由を3つの盲点から解きほぐしていく。

なぜSalesforce開発経験者は単価交渉で失敗するのか

まず認識を一つ壊しておきたい。技術スキルの高さは、交渉力の高さとは別物だ。この二つを混同していると、「自分はこれだけ書けるのに、なぜ単価が上がらないのか」という不満だけが溜まっていく。

クライアントやエージェントから見て、ApexやLWCが書けることは加点要素ではある。ただ正直なところ、「できて当たり前」の領域に入りつつある。Salesforce認定資格の保持者は年々増えていると言われるし、開発案件に応募してくる人材のベースラインも上がっている。つまり「Apex歴◯年です」だけでは、あなたを他の候補者と区別する材料にならない。

そしてもう一つ、身も蓋もない話をする。案件を出す側は、常に「相場より少し安く、それでいてちゃんと動くものを作ってくれる開発者」を探している。これは悪意ではなく、予算を預かる立場として当然の動きだろう。だからこちらが黙っていれば、単価は相場の下限に寄っていく。放っておいて上がる交渉など存在しない。

落とし穴1：クライアント企業の予算構造を見ていない

最初の盲点は、相手の財布の中身を想像していないことだ。同じ「Salesforce開発案件」でも、予算構造はまるで違う。

たとえば大手SIの下請けとして入る案件は、すでに元請けが顧客と契約金額を握っており、そこから何次かの中抜きを経てあなたに届く。この構造では、いくら技術力をアピールしても、そもそも交渉できる原資が薄い。一方で中堅企業の直請け案件は、意思決定者との距離が近く、予算配分の裁量も相手側にある。同じ工数でも、後者のほうが単価は動きやすい。

交渉の成否を分けるのは、その案件の工数見積もり権限がどこにあるかだ。目の前の担当者が見積もりをそのまま通せる立場なのか、それとも上に稟議を上げるだけの窓口なのか。ここを確認せずに単価の話を始めると、決裁権のない相手に熱弁をふるうことになる。

加えて、企業の業種による「開発費の位置付け」の差も見逃せない。外資系や大手メーカーはシステム投資を事業コストとして織り込んでいるが、ITに縁の薄い非IT企業だと、開発費が「よくわからない高い出費」に見えていることがある。前者では相場ベースの交渉が通りやすく、後者では金額そのものより「なぜその金額なのか」の納得感づくりが先になる。

落とし穴2：提案を『受け身で聞く』だけになっている

二つ目は、交渉の主導権を最初から手放しているケース。エージェントや営業から提示された単価を「これが相場なんだな」と受け取り、そこからの値引き交渉だけをしている人が多い。

提示単価はあくまで相手の希望額であって、天井ではない。にもかかわらず、自分の工数感や成果物の範囲を固める前に単価の話に入ってしまうと、「範囲が曖昧なまま安い金額に合意する」という最悪の流れになる。あとから作業が膨らんでも、単価は据え置きだ。

順番が逆なのだ。まずクライアントが「実現したい状態」を引き出す。次にそれを満たすために必要な工数と成果物範囲を、自分の言葉で定義する。単価交渉はそのあとに来る。要件を握っている人間の言葉には重みが出るし、「この範囲ならこの金額」という線引きができれば、値引き要求に対しても「では範囲を調整しましょう」と返せる。この準備の型については、エンジニア給与交渉で失敗しないコツ｜事前準備から交渉テーブルまでの実践ガイドで交渉前の組み立て方を詳しく書いた。受け身から抜け出したい人は先に読んでおくといい。

落とし穴3：『Salesforce経験』だけで単価が上がると考えている

三つ目は、経験年数への過信だ。「Salesforce歴5年」という肩書きが、そのまま単価に反映されると思っている人がいる。残念ながら、市場はそこまで単純ではない。

評価されるのは年数よりも、特定の機能領域の深さだ。たとえば「Experience Cloudでの外部公開サイト構築を何度もやってきた」「大規模データ量下でのApexのガバナ制限を踏まえた設計ができる」といった、案件のリスクを下げる具体性がある人は強い。逆に「広く浅く一通り」だと、単価は平均に寄る。

その案件に必要な周辺スキルを持っているかも大きい。REST APIによる外部連携、カスタムメタデータ型を使った設定の外部化、CI/CDまわりの整備など、「その案件で今まさに困っていること」に刺さるスキルは、経験年数より雄弁だ。Salesforce経験そのものが市場でどう評価され、どう年収に結びつくかの全体像はSalesforceエンジニアの年収相場｜案件単価と転職で年収を上げる実践戦略にまとめてある。自分の立ち位置を確認する材料にしてほしい。

さらに現場でよく見るのは、純粋な開発力より、対クライアント折衝・要件整理・納品までやり切ったデリバリー実績のほうが単価に効いている場面だ。発注側からすれば、「言われたものを作る人」より「曖昧な要望を形にして着地させる人」のほうがリスクが低い。Apex開発に絞った単価帯の考え方はApex開発案件の単価相場｜スキル習得から高単価案件獲得までのロードマップで整理しているので、技術軸で単価を判断したい人はあわせて見てほしい。

失敗を回避するための3つの実践アクション

抽象論で終わらせたくないので、明日から使える動きに落とす。難しいことではない。要は「聞く」「言語化する」「記録する」の3つだ。

• 初期接触で予算感・規模・判断権限を確認する：最初の打ち合わせで、プロジェクトの規模、想定期間、そして「この単価はどなたが決めますか」を自然な形で聞く。ここで相手の財布と権限が見える。
• 工数と成果物をクライアント視点で言語化してから見積もる：「Apexを書きます」ではなく「この業務のこの手作業を、この範囲で自動化します」と相手の得になる言葉に変換する。単価の話はそのあと。
• 過去案件を単価帯別に記録する：受けた案件を「単価・クライアント属性・必要だったスキル・折衝の重さ」で残しておく。次の交渉で「この条件ならこの単価が妥当」という自分の相場観が武器になる。

正直なところ、この3つは地味だ。派手なテクニックではない。それでも単価交渉で損をしている人の多くは、技術の勉強には時間を使うのに、この地味な準備を飛ばしている。腕があるのに安く受けているなら、伸びしろは技術ではなく交渉の設計側にある。次の案件の最初の一本の連絡から、相手の予算構造を一つ確認するところ。まずはそこから始めてみてほしい。