先に結論を書きます。「Salesforceエンジニアの年収」を一つの数字で語れると思っているうちは、相場を見誤ります。この求人名は実際には管理者・開発者・アーキテクト・コンサルタントに割れていて、同じ肩書きでも任される工程がまるで違う。
だから年収も割れる。私自身も本業でApexとLWCを書きつつ外部連携の設計をやっていますが、面談でも採用票でも「どの工程まで見られるか」で評価が変わる場面を何度も見てきました。求人票の読み分けと、年収を分けている本当の軸を現場目線で整理していきます。
「Salesforceエンジニア」という求人は、実は4つに割れている
まず認識を一つ壊しておきます。「Salesforceエンジニア」という職種名は、求人サイトの検索上の都合でひとまとめにされているだけです。中身は少なくとも4種類に分かれていて、それぞれ単価も評価軸も違う。
見分け方はシンプルで、求人票の「業務内容」に書いてある動詞を見ます。設定・項目追加・権限管理が中心なら管理者寄り、ApexやLWCを「書く」と明記されていれば開発者寄り、要件定義や業務設計から入ると書いてあればコンサルタント寄り、全体アーキテクチャや他システムとの統合方針を決めるならアーキテクト寄りです。
| 役割 | 求人票に出るサインの文言 | 主に任される工程 |
|---|---|---|
| 管理者 | 「設定」「画面・項目のカスタマイズ」「権限・プロファイル管理」「ノーコード中心」 | 運用・保守・軽微な改修 |
| 開発者 | 「Apex」「LWC」「Flow」「API連携の実装」 | 設計の一部〜実装・テスト |
| コンサルタント | 「要件定義」「業務設計」「お客様折衝」 | 上流・要件定義 |
| アーキテクト | 「全体設計」「システム統合方針」「ガバナンス」 | 全体設計・技術判断 |
ここを混同すると、管理者求人に開発者の単価を期待したり、その逆が起きます。私が求人を眺めていて毎回思うのは、同じ「Salesforceエンジニア」の見出しの下に、年収帯の違う仕事が平気で同居していることです。肩書きではなく中身で読む。これが最初の一歩になる。
もう一歩踏み込むと、同じ求人票の中に複数の動詞が混ざっていることがあります。「設定を中心に、一部Apexの改修も」と書いてあれば、管理者を主軸に開発者の仕事も振られる位置づけです。業務内容の一行目にある動詞が重心で、後ろに付く動詞が仕事の染み出す範囲。
この「どこに重心があり、どこまで染み出すか」を分けて読むと、提示される年収帯の理由が見えてきます。ここを読むだけで、求人票の解像度は一段上がる。
年収を分けているのは言語スキルじゃない。工程の幅だ
ApexやLWCが書けるかどうか。ここに年収差があると思われがちですが、実務ではもう一段上の話で決まります。要件定義・設計・実装・リリース運用のうち、どこまで一人で任せられるか。この「工程の幅」が評価を分けます。
なぜ幅が効くのか。発注側の立場で考えると分かります。実装だけできる人を入れると、要件を固める人、設計する人、リリースを管理する人を別に用意しないといけない。
人を増やすほど伝達のロスと失敗確率が上がる。だから「要件を聞いて設計まで落とし、本番反映まで面倒を見られる人」には、その分の対価が払われます。
これはリスクの引き受け料です。工程を一人で貫けるということは、途中の手戻りや連携ミスを発注側が被らずに済むということ。単価や年収の差は、スキルの難易度よりも「引き受けているリスクの量」に近い。私の本業は中規模ユーザー環境の構築と最適化が中心ですが、面談でいちばん効くのは実装の細かさより「要件から運用まで通して見た経験」のほうです。
逆に言えば、Apexをどれだけ速く書けても、工程が実装に閉じている限り評価の上限は早めに来ます。ここを勘違いすると「これだけ書けるのになぜ上がらない」という不満だけが溜まる。
転職で上がる人と、上がらない人の分かれ目
同じ「Salesforceエンジニア」でも、どこに所属するかで評価軸と年収の上限の作られ方が変わります。転職で上がるかどうかは、移動先の構造を理解しているかにかかっている。
| 所属先 | 評価されやすい軸 | 年収の上限の作られ方 |
|---|---|---|
| 事業会社の情シス | 自社業務の理解・運用の安定・内製化への貢献 | 社内の等級制度に縛られやすい |
| SIer | 複数案件をさばく力・下流〜上流の工程幅・資格保有 | プロジェクト単価と役職で決まる |
| 開発会社・コンサル | 要件定義・提案・技術リード | 役割の格上げで跳ねやすい |
事業会社の情シスは働き方が安定しやすい反面、年収は社内の等級表に収まりがちです。腕が上がっても、表の上限以上は出にくい。一方でSIerや開発会社・コンサルは、工程の幅や役割の格が上がれば待遇が動きやすい構造になっています。
だから「もう何年もやったのに上がらない」と感じる人は、スキル不足ではなく、上限の低い箱の中で頑張っている可能性があります。自分がどの箱にいて、その箱の上限がどこにあるかを先に見ること。交渉の武器は資格の枚数ではなく、何を要件から任され、どう解いたかを数字と固有名詞で語れる具体性です。給与交渉の事前準備は別記事で詳しく扱ったので、面談前に目を通しておくといい。
案件単価を動かすなら、効くレバーは案件選び
正社員の昇給を待つより、業務委託案件の単価を動かすほうが速いのは確かです。給与テーブルは会社の都合でしか動きませんが、案件単価は市場と交渉次第で数ヶ月単位で変わる。ここでもスキルより案件選びが効きます。
同じ実力でも、短期の小規模改修と大規模・長期のプロジェクトでは提示額が違う。長期案件は継続前提で予算感も大きいため、単価が伸びやすい。
相場観については、レバテックフリーランスが職種別・言語別の単価相場を公開しています。ただしこれは民間の掲載案件ベースの月単価で公的統計ではなく、経験年数別の内訳も出ていません。単価がどう決まるかという構造そのものはSalesforceに限らないので、相場の見え方を整理したいなら単価を決める要因を扱った別記事も参考になります。具体的な提示額は案件ごとに確認するのが現実的です。
資格はどこまで効くのか
認定資格の話も触れておきます。認定デベロッパーや管理者資格は、名刺代わりや案件応募の足切り回避には役立ちます。SIerが提案書に「認定保有者◯名」と書くために、受注側の都合で資格が求められる場面もある。
ただし資格が単価を大きく押し上げる加速材料になるかというと、そこは期待しすぎないほうがいい。取るなら「持っていないことでふるい落とされないため」と割り切るのが現実的です。受験料は資格区分ごとに数万円程度かかり、再受験にも追加の費用が必要になります。
実額や税区分は変わりやすいので、申込時にSalesforce公式の最新情報を確認してください。
自分がどこで止まっているかを、先に見る
Salesforceは専門性が評価されやすい市場です。ただし黙っていて上がるほど甘くはありません。年収を止めているのは言語スキルではなく、たいてい工程の幅か、所属している箱の上限のどちらかです。
管理者として運用に閉じているなら設計と提案へ、実装に閉じているなら要件と運用へ。箱の上限が低いと感じるなら、評価軸の違う箱へ移る。自分がどの要因で止まっているかを見極めて、一番効くレバーから引く。遠回りに見えて、それがいちばん早い。
【PR】おすすめサービス(アフィリエイト広告を含みます)
IT・エンジニア専門の転職エージェントです。求人票に出ない条件面の交渉まで相談でき、無料で使えます。
→ エンジニア専門の転職エージェント【ユニゾンキャリア】

