Salesforceエンジニア・コンサルがフリーランスになるには｜必要な経験と独立までの進め方

Salesforceのエンジニア・コンサルとしてフリーランスになるには、どのクラウド（製品）で、標準機能の設定・開発・要件定義のどこを自分で担ったかを具体的に説明できる経験が必要です。Salesforceの案件は役割の切り分けがはっきりしていることが多く、「Salesforceの経験があります」だけでは、どの枠に入れる人なのかが伝わりません。

独立の準備は、自分の役割を「アドミン・開発・コンサル」のどこに置くかを決め、扱った製品と機能を棚卸しし、標準機能で済ませる判断をした経験を言葉にすることから始めます。

まず自分の役割の軸を決める

Salesforceの案件は、同じ製品を扱っていても役割によって求められることが大きく違います。最初に、自分がどの役割で参画するのかを決めておくと、スキルシートも面談の準備も組み立てやすくなります。

実際の案件では、アドミンと要件定義、開発とアドミンのように、二つの役割をまたぐ募集もよくあります。自分の軸は一つに決めつつ、隣の役割のどこまでなら担えるかを整理しておくと、応募できる案件の幅が広がります。

製品（クラウド）ごとの経験を分けて書く

Salesforceには、営業支援、カスタマーサービス、ポータル、マーケティングなど、目的ごとに複数の製品があります。たとえばSales Cloudの商談管理と、Service Cloudのケース管理では、業務の流れも使う機能も違います。案件側は「どの製品を、どの業務で使ったか」を見て、すぐに動ける人かを判断します。経験した製品ごとに、扱った業務と主な機能を分けて書き出しておきましょう。

「標準機能で済ませる判断」が評価される

Salesforceは、設定だけでかなりのことができる一方で、作り込みすぎると保守やバージョンアップの負担が大きくなる製品です。そのため、どの職種でも「標準機能で実現できるか、開発が必要か」を判断した経験がよく見られます。

• 要望をそのまま開発せず、標準機能やフローで実現する案を出した
• 開発が必要な部分を限定し、理由を説明して合意を得た
• 既存の作り込みを整理し、標準機能に戻した

こうした経験は、コンサルだけでなく開発者にとっても強みになります。開発者であれば、ガバナ制限（1回の処理で使える資源の上限）を意識した書き方や、テストコードの考え方を説明できると、任せられる範囲が広がります。

データと権限の設計は避けて通れない

Salesforceの導入や改修では、オブジェクトの関係、項目の持たせ方、共有ルールやロールによるアクセスの設計が、後から変えにくい部分になります。権限まわりの不具合や、データ量が増えたときの性能の問題は、案件の現場でよく起きる話題です。どんな考え方で設計したか、問題が起きたときにどう切り分けたかを話せるようにしておきましょう。

独立前に積んでおきたい経験

会社員のうちに、次のような経験を意識して積んでおくと、独立後に参画できる案件の幅が広がります。

1. 導入の最初から関わった経験：要件の聞き取りから本番の切り替えまで、一つの導入を通して見た経験
2. データ移行の経験：既存の顧客データや取引データを整理し、重複や項目のずれを直して取り込んだ経験
3. 外部システムとの連携：基幹システムやマーケティングの仕組みとデータをやり取りする設計・開発の経験
4. 利用定着の支援：導入後に使われない状態を、画面の見直しやレポートの整備、説明会で改善した経験
5. リリースへの対応：製品の定期的なアップデートで、既存の設定や開発への影響を確かめた経験

特に利用定着の経験は、Salesforceならではの論点です。入れたものの使われていない組織からの改修案件は多く、営業やサービスの現場の声を拾って直した経験は、面談で具体的に伝えやすい材料になります。

認定資格の位置づけ

Salesforceには、アドミニストレーター、デベロッパー、コンサルタント向けなど、役割ごとの認定資格があります。案件によっては、資格の保有を条件や歓迎要件にしていることがあり、知識の裏付けとして役立ちます。ただし、資格だけで参画できるわけではなく、実務でどう使ったかが重視されます。認定資格には、取得後に資格を保つための手続きが定められているため、名称や要件は公式の案内で最新の内容をご確認ください。

独立までの進め方

1. 製品 × 役割で棚卸しする

関わったプロジェクトごとに、業種、利用部門、ユーザー数の規模、扱った製品、自分の役割（アドミン・開発・要件定義）、使った機能を書き出します。開発者は、使った言語やツール、連携の方式も加えます。手元のメモでは細かく書き、スキルシートに移すときに社名や固有の情報を伏せて整えます。書き方はSalesforceのスキルシートの記事で解説しています。

2. 希望する条件を決める

Salesforceの案件は、リモートで進めやすいものも多い一方、要件定義の時期は利用部門との打ち合わせのために出社を求められることがあります。次の条件を先に決めておきましょう。

• 稼働日数（週5日か、週3〜4日か）
• 出社の頻度とリモートの希望
• 希望する報酬の下限
• 担当したい役割と、受けない作業（例：開発中心の案件は受けない）

報酬の決まり方はSalesforceの報酬の記事、リモートの傾向はSalesforceのリモート案件の記事をご覧ください。

3. 手続きとお金の準備

独立したら、事業を始めた年分の確定申告期限までに、納税地の税務署へ開業届を出すことになっています。青色申告を選ぶ場合、1月16日以降に開業した人は、事業開始日から2か月以内に承認申請書を出します（いずれも2026年10月時点、国税庁の案内による）。手順は開業届の出し方と会社員からフリーランスになる手順で解説しています。税務の判断に迷う場合は、税理士にご相談ください。

4. 案件を探し、面談を受ける

最初の案件は、これまでの製品と役割に近いものを選ぶと、立ち上がりが早くなります。案件の探し方はフリーランスエージェントの使い方、選び方は独立後の最初の案件の記事で解説しています。

契約で確かめておきたいこと

Salesforceの案件は、多くの場合、準委任契約で月単位に稼働します。一方で、画面や機能の開発をまとめて引き受ける形では、成果物の完成を約束する請負契約になっていることもあります。どちらの形かで、責任の範囲や検収の扱いが変わるため、契約前に確かめておきましょう。違いは準委任契約と請負契約の違いで解説しています。

フリーランス法では、発注側は業務を委託したときに、業務の内容、報酬の額、支払期日などを書面またはメールなどで直ちに明示する必要があります。報酬の支払期日は、給付を受け取った日から60日以内のできるだけ短い期間で定めることとされています（公正取引委員会の案内による）。

また、Salesforceの組織には、発注元の顧客情報が入っています。本番環境に触れる権限の範囲や、作業に使う端末の扱いも、参画前に確認しておくと安心です。

よくある質問

アドミンの経験だけでフリーランスになれますか？

アドミンの役割で参画できる案件はあります。権限の管理、項目や画面の設定、レポートの整備を自分で担い、利用部門の要望に応えてきた経験を具体的に整理しておきましょう。要件定義や開発に広げたい場合は、改修の中で要望の整理や設計を担った経験を書き出しておくと、次の案件につなげやすくなります。

他のシステムの開発経験しかなくてもSalesforceの案件に入れますか？

Javaなどの開発経験は、Apexや外部連携の開発で生かせます。ただし、フリーランスの案件では、Salesforce上での開発や設定の実務経験を求められることが多くなります。会社員のうちにSalesforceのプロジェクトに関わり、標準機能と開発の使い分けを経験してから独立するほうが、案件を選びやすくなります。

認定資格は何から取ればよいですか？

担当したい役割に合わせて選ぶのが基本です。アドミンや要件定義を軸にするなら管理者向け、開発を軸にするなら開発者向けの資格が、実務の知識と結びつきやすくなります。資格の名称や維持の要件は変わることがあるため、受験の前に公式の案内で最新の情報をご確認ください。