Salesforceエンジニア・コンサルのフリーランス案件で求められるスキルと経験

Salesforceのフリーランス案件で求められるのは、データモデルと権限の設計、フローなどによる自動化、ApexやLightning Web Components（LWC）による開発、外部システムとの連携とデータ移行、そして業務を標準機能に合わせて提案する力です。どの役割で参画するかによって、このうちどれが中心になるかが変わります。

この記事では、Salesforceの案件で見られるスキルを技術の分野ごとに整理し、役割ごとに求められる深さ、認定資格の位置づけ、スキルの示し方を解説します。役割の決め方や独立の進め方はSalesforceエンジニア・コンサルがフリーランスになるにはにまとめています。

役割ごとに求められるスキルの深さ

Salesforceの案件は、アドミン（管理者）、開発、コンサル・要件定義、アーキテクトのように役割が分かれていることが多くあります。同じスキルでも、役割によって求められる深さが違います。

自分の役割の列で「担える」と言える項目と、隣の列で一部なら担える項目を整理しておくと、応募できる案件の幅が見えてきます。

案件でよく求められるスキル

データモデルと権限の設計

Salesforceの導入や改修で、後から変えにくいのがデータモデル（オブジェクトと項目、その関係）と権限の設計です。標準オブジェクト（取引先、商談、ケースなど）をどう使い、どこからカスタムオブジェクトを作るか、参照関係と主従関係のどちらで結ぶかといった判断が、レポートの作りやすさや性能に影響します。

権限では、プロファイル、権限セット、ロール、共有ルールなどを組み合わせて、「誰が、どのレコードを、どこまで見て編集できるか」を設計します。組織が大きくなるほど設計は複雑になり、権限まわりの不具合の切り分けができる人は頼りにされます。

フローなどによる自動化

コードを書かずに処理を自動化するフローは、どの役割でもよく使われます。レコードの作成や更新に合わせた処理、承認の流れ、画面での入力の案内などを、標準機能の範囲でどこまで実現できるかを判断できることが求められます。

自動化は、作りすぎると処理の順番が分かりにくくなり、不具合の原因を探しにくくなります。一つのオブジェクトにどれだけの自動化が積み重なっているかを整理し、まとめたり減らしたりした経験は、改修案件で評価されやすい部分です。

ApexとLWCによる開発

標準機能やフローで足りない部分は、Apex（サーバー側の処理）やLWC（画面の部品）で開発します。開発の案件では、次の点が見られます。

• 大量のデータを処理しても上限に当たらない書き方ができる（Salesforceは多くの組織で基盤を共有しているため、1回の処理で使える資源に上限がある）
• テストクラスを、本番に反映するための形式だけでなく、品質を確かめる目的で書ける
• トリガーの処理を整理し、フローとの役割分担を設計できる
• 開発した部分の保守のしやすさを考え、標準機能で済む部分を残している

外部連携とデータ移行

Salesforceは、基幹システム、会計、マーケティングの仕組みなどとデータをやり取りすることが多くあります。APIを使った連携の設計と実装、連携の失敗時の扱い、連携ツールの利用経験が求められます。Salesforceの製品案内では、連携と自動化の分野でMuleSoftが挙げられています。

データ移行では、既存のデータの重複や表記のゆれを整え、項目の対応を決め、移行の順番を組み立てる力が見られます。顧客データの移行は業務への影響が大きいため、移行の前後で件数や内容をどう確かめたかまで説明できると、経験の深さが伝わります。

業務を標準機能に合わせて提案する力

コンサル・要件定義の役割では、営業やカスタマーサービスの業務を理解し、要望をそのまま作るのではなく、標準機能に合わせた業務の進め方を提案する力が中心になります。商談の段階の定義、見込み客の管理、問い合わせの振り分けなど、Salesforceの標準の考え方と業務をすり合わせる経験が評価されます。

新しい機能への追従

Salesforceの製品は更新が続いており、公式の製品案内では、AIエージェントの基盤であるAgentforceや、データを統合するData 360などが並んでいます（2026年10月時点の公式サイトによる）。こうした新しい機能を案件で使った経験はまだ限られた人にしかないため、検証環境で試した経験も含めて話せると、新しい機能を扱う案件で目に留まりやすくなります。

設計の考え方の土台

Salesforceは、設計の判断の拠り所として「Well-Architected」という枠組みを公開しています。安全で法令に沿った設計による信頼（Trust）、障害が起きても動き続けて回復できる信頼性（Reliability）、運用の観察と自動化と継続的な改善（Operational Excellence）、長い目で見た価値を高める資源と費用の最適化（Resource and Cost Optimization）などの観点が示されています（2026年10月時点の公開内容による）。

アーキテクトやリードの役割を目指す場合は、こうした観点で自分の設計を説明できると、判断の根拠が伝わりやすくなります。開発やアドミンの役割でも、「なぜその作りにしたか」を説明するときの言葉として使えます。

認定資格の位置づけ

Salesforceには、Platform アドミニストレーターをはじめ、開発者、コンサルタント、アーキテクトなど、役割ごとの認定資格があります。案件によっては、特定の認定資格の保有を条件や歓迎要件にしていることがあり、書類の段階で役割の目安として見られます。

認定資格は、取得した後も、製品の更新に合わせて資格を維持するための手続きが定められています。スキルシートに書くときは、資格が有効な状態かを確かめておきましょう。資格の名称や試験の内容、維持の要件は見直されることがあるため、受験や更新の前にTrailheadの公式ページで最新の内容をご確認ください。

スキルをスキルシートと面談で示す方法

Salesforceのスキルシートでは、プロジェクトごとに次の点を書くと、役割とスキルの深さが伝わります。

1. 製品と業務：使った製品（営業支援、カスタマーサービス、ポータルなど）と、対象の業務
2. 組織の規模：ユーザー数、データ量、他システムとの連携の数など、伏せられる範囲で
3. 役割と工程：アドミン・開発・要件定義のどれで、どの工程を担ったか
4. 使った機能と技術：データモデル、権限、フロー、Apex、LWC、連携の方式など
5. 判断した点：標準機能・フロー・開発のどれを選んだかと、その理由

面談では、上の5を掘り下げられることがよくあります。書き方の例はSalesforceのスキルシートの記事、スキルと報酬の関係はSalesforceの報酬の記事をご覧ください。

よくある質問

フローが使えればApexの開発経験はなくても大丈夫ですか？

アドミンやコンサルの役割では、フローの経験を中心に参画できる案件があります。一方、開発の役割では、Apexでの設計・実装・テストの経験が求められます。フローで実現が難しい処理を見極めて開発の担当者に渡せるだけでも、標準機能と開発の使い分けを理解していることは伝わります。

Salesforce以外のCRMの経験は評価されますか？

営業や顧客対応の業務の理解、データの移行、外部との連携などは、製品が変わっても生かせる経験です。ただし、フリーランスの案件では、Salesforce上での設定や開発の実務経験を求められることが多くあります。ほかのCRMの経験は、業務の理解の裏付けとして伝えるとよいでしょう。

英語の情報を読む力は必要ですか？

公式のドキュメントや新しい機能の情報には英語のものも多いため、読めると調べものが早く進みます。会話の力まで求められる案件は、海外拠点が関わるものなどに限られます。日本語の情報だけで進められる案件も多いため、必須の条件ではありません。