結論
Salesforceエンジニア転職は、宣言型設定(Flow/設定画面)とApex/LWCのどちらが主業務かを求人票で先に固定し、資格要件はjob tagとIPA DX資料で用語整理しつつ、面談で実務範囲を確認してから応募するのが安全です。
この記事はこんな人向け
- SalesforceのFlow/設定中心で業務改善してきた方
- Apex/LWCでカスタム開発している方
- SIerのSalesforce案件からプロダクト寄りへ移りたい方
- 資格要件のある求人の実態を確認したい方
このテーマの要点
Salesforceエンジニア転職では、宣言型設定(Flow、Process Builder後継、設定画面)、Apex、Lightning Web Components(LWC)、Integrationのどれが主業務か求人票だけでは判別しにくいことがあります。このページはバックエンド総論とは別に、宣言型vsコード、パッケージ開発、Sandbox/本番リリース運用、資格表記の読み方を軸に整理します。資格の詳細はSalesforce公式URLは使わず、job tagとIPA DX資料で用語整理します。平均年収や求人数は媒体ごとに定義が異なるため掲載せず、求人票で確認する前提で読んでください。
- 宣言型開発(Flow等)
- コードを書かず設定画面とFlowで業務自動化。Apex/LWC案件との境界が転職時の最大論点。
- Apex/LWC
- Salesforce上のコード開発。トリガー、バッチ、LWCコンポーネント等。ガバナ制限が固有の論点。
- Sandbox/本番リリース
- 変更セット、CI/CD、パッケージデプロイ等。エンジニアの運用範囲はチームにより異なる。
- 資格表記
- Administrator/Developer/Consultant等。必須条件か優遇か、実務と一致するかを面談で確認。
Salesforceエンジニアで混同しやすい役割
Salesforceは「設定で完結する業務改善」と「Apex/LWCでコード開発する案件」で必要スキルが大きく異なります。バックエンドエンジニアのAPI開発とも語彙が異なるため、以下の表で宣言型とコードの境界を切り分けてください。
| 役割 | 主な判断 | 転職で見る境界 |
|---|---|---|
| 宣言型(Flow/設定) | 業務フロー設計 | Apex比率 |
| Apex/LWC開発 | コードとガバナ制限 | Flow/設定のみか |
| Salesforceコンサル | 要件と設定 | 開発工数の比率 |
| Integration | 外部API連携 | Middleware/ETL含むか |
| バックエンドAPI | 汎用HTTP API | Salesforce固有オブジェクト |
Salesforceエンジニアの役割比較では、「役割」は「宣言型(Flow/設定)」、「主な判断」は「業務フロー設計」、「転職で見る境界」は「Apex比率」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの役割比較では、「役割」は「Apex/LWC開発」、「主な判断」は「コードとガバナ制限」、「転職で見る境界」は「Flow/設定のみか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの役割比較では、「役割」は「Salesforceコンサル」、「主な判断」は「要件と設定」、「転職で見る境界」は「開発工数の比率」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの役割比較では、「役割」は「Integration」、「主な判断」は「外部API連携」、「転職で見る境界」は「Middleware/ETL含むか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの役割比較では、「役割」は「バックエンドAPI」、「主な判断」は「汎用HTTP API」、「転職で見る境界」は「Salesforce固有オブジェクト」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforce開発者向き
- Apex/LWC開発
- Integration設計
- Sandbox/本番リリース運用
別職種に近い仕事
- Flow/設定のみ
- コンサル/要件定義のみ
- データ移行スクリプトのみ
求人票で見る項目
Salesforce求人票では「Platform Developer資格」と書かれていても、実態がFlow設定だけのことがあります。逆にApex必須で設定中心のケースもあるため、三列表で確認してください。
| 書いてあること | 確認したい実態 | 面談での質問例 |
|---|---|---|
| Salesforce 3年以上 | Flow/Apex/LWCの内訳 | 直近で主に触った開発形態は? |
| Platform Developer | 資格必須か優遇か | Apex/LWCの実務比率は? |
| Flow | 新規Flowか既存改修か | FlowとApexの使い分け基準は? |
| LWC | 新規UIかClassic改修 | Aura資産の移行範囲は? |
| Integration | REST/SOAP/Bulk API | 外部システム連携の障害一次対応は? |
| SIer案件 | 常駐と納期 | エンジニアが要件折衝まで行うか? |
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「Salesforce 3年以上」、「確認したい実態」は「Flow/Apex/LWCの内訳」、「面談での質問例」は「直近で主に触った開発形態は?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「Platform Developer」、「確認したい実態」は「資格必須か優遇か」、「面談での質問例」は「Apex/LWCの実務比率は?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「Flow」、「確認したい実態」は「新規Flowか既存改修か」、「面談での質問例」は「FlowとApexの使い分け基準は?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「LWC」、「確認したい実態」は「新規UIかClassic改修」、「面談での質問例」は「Aura資産の移行範囲は?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「Integration」、「確認したい実態」は「REST/SOAP/Bulk API」、「面談での質問例」は「外部システム連携の障害一次対応は?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
Salesforceエンジニアの求人票の読み替えでは、「書いてあること」は「SIer案件」、「確認したい実態」は「常駐と納期」、「面談での質問例」は「エンジニアが要件折衝まで行うか?」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。
- Flow/設定とApex/LWCのどちらに強いか言えるか
- Sandbox/本番リリース運用に関与したか
- 資格要件と実務の一致を確認したか
- Integration/外部API連携の範囲を説明できるか
- ガバナ制限を意識した設計判断をしたか
確認ポイントは「Flow/設定とApex/LWCのどちらに強いか言えるか」です。Salesforceエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。
確認ポイントは「Sandbox/本番リリース運用に関与したか」です。Salesforceエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。
確認ポイントは「資格要件と実務の一致を確認したか」です。Salesforceエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。
確認ポイントは「Integration/外部API連携の範囲を説明できるか」です。Salesforceエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。
確認ポイントは「ガバナ制限を意識した設計判断をしたか」です。Salesforceエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。
経験の棚卸し方
Salesforceエンジニアでは、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。
- 01Flow/設定/Apex/LWCに区分
各プロジェクトで宣言型とコード開発の比率と、自分が判断した範囲を書き出します。
- 02資格と実務の対応表
保有資格と、実際に担当したFlow/Apex/LWC/Integrationの対応を1枚にまとめます。
- 03リリース運用の質問リスト
Sandbox種別、変更セット/CI/CD、本番デプロイ承認フローを面談用に用意します。
- 04求人三件を表で読み替え
宣言型/コードの実態ギャップを可視化し、応募優先度を決めます。
公式情報の使い方
Salesforceの判断材料は、求人票の記載、job tagのIT職業情報、IPA DX資料を参照します。個別資格の合格率や年収相場は確認できないため書きません。Sandbox/本番のリリース手順は面談で具体例を確認してください。
Salesforceエンジニア転職ガイド|宣言型開発とApexの境界の判断材料は、出典が公開されている情報に限ります。媒体ごとの求人数や平均年収は集計定義が違うため、求人票や公式サイトの最新情報で確認してください。内定や年収アップは保証できません。提示された労働条件は書面で確認し、口頭の話だけを契約内容にしないでください。
相談先の選び方
Salesforce案件は、SIer系コンサル寄りと開発寄りでエージェントの強みが分かれます。宣言型中心かApex/LWC中心かを一文で伝え、重複応募を防ぐ管理表を作ってから相談してください。
- Salesforce開発寄りエージェント
Apex/LWC求人とFlow中心求人の切り分けを理解した担当者が見つけやすいです。
- SIerから開発寄りへ
宣言型中心経験をコード開発語彙に置き換える相談は、SIer-to-webの職種・テーマと合わせると有効です。
- 資格と実務の整理支援
資格表記と実務比率の確認を一緒に整理してくれる相談先もあります。
相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。
よくある失敗パターン
- Flow設定をApex開発と同一視
宣言型とコード開発は別スキルです。求人がApex必須ならコード開発範囲だけを強調してください。
- 資格名だけをアピール
資格と実務の不一致は面談で露呈します。Flow/Apex/LWC/Integrationの具体例を準備してください。
- ガバナ制限を無視した設計アピール
Salesforce固有の制限を理解した設計判断を1例説明できると、開発寄り求人とのミスマッチが減ります。
面談で先に聞くこと
Flow中心経験をApex求人にどう転用しますか?
業務フロー設計、オブジェクトモデル理解、Sandbox運用の経験を共通語彙で説明してください。Apex必須案件は学習中であることと、小さなApex/LWC自作例を準備します。
Salesforce資格は必須ですか?
求人によります。必須か優遇かを求人票で確認し、実務説明を優先してください。資格の詳細はjob tagとIPA DX資料で用語整理し、合格率等の未確認数字は書きません。
Salesforceとバックエンド総論の違いは?
Salesforceはプラットフォーム固有のオブジェクト、Flow、ガバナ制限が中心です。汎用API設計の語彙はバックエンドを参照しつつ、このページで宣言型/コード境界を確認してください。
SIer Salesforce案件の確認点は?
常駐、納期、宣言型/コード比率、エンジニアの折衝範囲を面談で確認してください。SIer-to-webの職種・テーマの観点も併用します。面談では直近の具体例を1つ依頼し、曖昧な回答の場合は応募優先度を下げてください。確認できない数値や保証表現は志望理由に使わないでください。
応募前の1週間
応募前の1週間は、経験をFlow/設定/Apex/LWC/Integrationに区分し、求人三件を三列表で読み替え、リリース運用と資格要件の質問を用意してから応募可否を決める流れがおすすめです。
- 01月:job tag/IPA DXで用語整理
job tagのIT職業情報とIPA DX資料で、説明用語を揃えます。
- 02火:区分棚卸しと経歴推敲
宣言型とコードの関与範囲だけを残し、一般バックエンド記述との境界を明確にします。
- 03水:求人読み替えと質問リスト
資格必須/Flow中心の矛盾がある求人を重点確認します。
- 04木〜金:面談またはエージェント相談
Apex/LWC比率とリリース運用範囲を確認してから応募可否を決めます。
おすすめ転職サービス
相談先は得意領域と対象経験を確認し、複数の提案を比較して選びましょう。
よくある質問
AdministratorとDeveloper、どちらの求人ですか?
Administrator寄りはFlow/設定中心、Developer寄りはApex/LWC中心のことが多いです。求人票の必須スキルと業務内容の両方から読み替えてください。
Salesforce未経験から転職できますか?
求人次第です。関連するCRM/業務システム経験を一般化して説明できる場合もあります。未経験歓迎の求人でも、宣言型/コードの主業務を面談で確認してください。面談では直近の具体例を1つ依頼し、曖昧な回答の場合は応募優先度を下げてください。確認できない数値や保証表現は志望理由に使わないでください。
LWCとAura、どちらを優先して書くべきですか?
LWCが主流ですが、レガシーAura資産がある案件も残っています。求人が明示する方を先に書き、移行経験があれば補足してください。面談では直近の具体例を1つ依頼し、曖昧な回答の場合は応募優先度を下げてください。確認できない数値や保証表現は志望理由に使わないでください。
Integration求人の確認点は?
REST/SOAP/Bulk APIのどれか、外部Middlewareの有無、障害一次対応範囲を面談で具体例で聞いてください。面談では直近の具体例を1つ依頼し、曖昧な回答の場合は応募優先度を下げてください。確認できない数値や保証表現は志望理由に使わないでください。
Salesforceエンジニアとコンサルの境界は?
コンサル寄りは要件と設定、開発寄りはApex/LWC/Integrationが中心です。面談でコード開発の時間比率を確認してください。面談では直近の具体例を1つ依頼し、曖昧な回答の場合は応募優先度を下げてください。確認できない数値や保証表現は志望理由に使わないでください。
パッケージ開発(ISV)求人の見分け方は?
自社組織内カスタマイズとパッケージ製品開発ではリリースモデルが異なります。面談でNamespace、バージョン管理、AppExchange公開の有無を確認してください。
まとめ
Salesforceエンジニア転職は、宣言型設定(Flow/設定画面)とApex/LWCのどちらが主業務かを求人票で先に固定し、資格要件はjob tagとIPA DX資料で用語整理しつつ、面談で実務範囲を確認してから応募するのが安全です。
サービス内容や応募条件は変わる可能性があります。最終的な判断の前に、各社の公式サイトと面談で最新情報をご確認ください。
あわせて読みたい記事
参考資料
以下は技術・職務理解の参考資料です。転職サービスの推奨順位や採用結果の根拠を示すものではありません。