先に結論を書きます。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つは地味です。派手なテクニックではない。それでも単価交渉で損をしている人の多くは、技術の勉強には時間を使うのに、この地味な準備を飛ばしている。
私が案件情報を眺めていて思うのは、差を生んでいるのは話し方の工夫ではなく、相手の予算構造を一つずつ確認する習慣のほうだということです。腕があるのに安く受けているなら、伸びしろは技術ではなく交渉の設計側にあります。次の案件の最初の連絡から、相手の予算構造を一つ確認してみてください。
