Salesforceエンジニア・コンサルのフリーランス案件の選び方｜契約前に確かめたいこと

Salesforceの案件を選ぶときは、報酬や稼働日数に加えて、役割の比重、組織の状態、使える機能の範囲、本番反映の手順と承認者、自分がどの立ち位置で入るか、成果物と契約の形、顧客データの扱いを契約の前に確かめておくと、参画後のずれを防げます。

Salesforceの案件は、同じ「導入」「改修」でも、組織の積み重なり方や発注側の体制によって、実際の仕事の重さが大きく変わります。この記事では、Salesforceならではの確かめどころを、面談や条件のやり取りで聞く順に整理します。契約書の一般的な確認点は業務委託契約書のチェックポイントにまとめています。

1. 役割の比重と「受けない作業」

最初に確かめたいのは、要件定義・設定・開発・運用のうち、どの仕事が何割くらいかです。Salesforceの募集は「コンサル兼開発」「アドミン兼開発」のように役割をまたぐことが多く、案件票の書き方だけでは比重が分かりません。

• 会議と資料づくりが中心なのか、Sandboxで手を動かす時間が中心なのか
• 開発がある場合、誰が設計し、自分は実装だけか、設計から担うか
• 利用者からの問い合わせ対応が含まれるか

あわせて、自分が受けない作業を先に伝えておきます。たとえば「開発は受けない」「利用者向けの研修は担当しない」などです。仕事の種類ごとの違いはSalesforceの仕事内容の記事で解説しています。

2. 組織の状態と、調べる時間の見込み

既存の組織に手を入れる案件では、組織の状態がそのまま仕事の重さになります。導入からの年数や設計の記録の有無など、面談で聞ける質問はSalesforceの報酬の記事で紹介しています。案件を選ぶ観点としては、さらに次の点を見ておくと判断しやすくなります。

• 自動化の一覧があるか：同じオブジェクトにどれだけの自動化があるか、社内で把握されているか
• 外部から入れたアプリの数：外部のパッケージや連携のアプリが多い組織は、影響の調査に時間がかかる
• 本番で直接変更してきた慣習があるか：Sandboxを通さずに本番で設定を変えてきた組織では、変更の管理の仕組みづくりから始まることがある

調査に時間がかかりそうな組織でも、それ自体が悪い案件というわけではありません。調査の時間が見込まれた期間と業務範囲になっているかが分かれ目です。

3. 使える機能と、契約の範囲

Salesforceは、発注側が契約している製品やライセンスの内容によって、使える機能や上限が変わることがあります。要件定義で「標準機能で実現できる」と提案したものが、契約の範囲では使えないと後から分かると、設計のやり直しや追加の開発につながります。

• どの製品を契約しているか、追加の契約を検討しているか
• 利用者の数と、ライセンスの種類が分かれているか
• 新しい機能やAI機能を使う前提なら、それが契約の範囲に入っているか

ライセンスの判断は発注側や販売元が行うことで、フリーランスが決めるものではありません。ただ、提案の前提として「どこまで使えるか」を聞いておくと、提案の手戻りを減らせます。

4. 本番反映の手順と承認者

本番の組織に誰が、いつ、どの手順で変更を反映するかは、責任の範囲に直結します。

• Sandboxの構成と、本番への反映の手段が決まっているか
• 反映の承認者は誰か、自分に本番の管理者権限が渡されるか
• 障害が起きたときの連絡先と、切り戻しの判断を誰がするか

本番の権限を持つ場合の注意点はSalesforceの報酬の記事でも触れています。権限が渡される案件ほど、承認の流れが文書で決まっているかを確かめておきましょう。

5. 自分がどの立ち位置で入るか

Salesforceの案件では、Salesforceを使う会社から直接受ける形のほか、導入を請け負った会社のチームの一員として入る形もあります。立ち位置によって、次の点が変わります。

業務委託である以上、作業の進め方を細かく指示される働き方は本来の形とずれることがあります。指示の受け方に不安がある場合は、準委任契約と請負契約の違いもあわせてご覧ください。

6. 成果物と契約の形

月単位で稼働する準委任の形か、画面や機能の完成を約束する請負の形かで、責任の範囲が違います。Salesforceの案件で特に確かめたいのは次の点です。

• Fit&Gapで開発が増えたときの扱い：要件定義の結果、開発の範囲が当初の見込みより増えた場合に、期間や報酬を見直すか（作業範囲が広がったときの記事）
• 請負の場合の検収の条件：何をもって完成とし、誰がいつまでに確かめるか（検収の記事）
• 設計書・手順書の扱い：作った設定や開発に加えて、どの文書を成果物として残すか

フリーランス法では、発注側が業務を委託したときに、給付の内容、報酬の額、支払期日などを、書面やメールなどで直ちに明示することが求められています。報酬の支払期日は、給付を受け取った日から60日以内のできる限り短い期間で定めることとされています（公正取引委員会「フリーランス法特設サイト」、2026年10月時点で確認）。

7. 顧客データの扱い

Salesforceの組織には、顧客の名前、連絡先、商談や問い合わせの内容が入っています。データ移行や不具合の調査では、こうしたデータに触れる場面が避けられません。

• 本番のデータを見てよい範囲と、Sandboxにどのデータを入れるか
• 移行のためにデータを書き出す場合、どこに保存し、いつ消すか
• 契約の終了時に、ログインの権限と手元のデータをどう返すか

個人情報を扱う委託の考え方は個人情報を扱うときの契約の記事、終了時の扱いはデータの返却・削除の記事で解説しています。

8. 期間と山場の時期

最後に、契約期間と仕事の山場の関係を確かめます。

• 本番の切り替えが契約期間のどこにあるか、直後の問い合わせ対応の期間は含まれるか
• 稼働後に保守の契約へ切り替わる予定があるか
• 定期リリースや年度の替わり目など、稼働が増える時期はいつか

山場の直前に契約が終わる形や、山場の時期だけ稼働が大きく膨らむ形は、条件の段階で分かれば対策が立てられます。リモートと出社の条件はSalesforceのリモート案件の記事にまとめています。

確かめる点の一覧

面談で聞きにくい点は、逆質問の時間を使うと自然に確かめられます。聞き方は逆質問の記事をご覧ください。

よくある質問

組織の状態は、面談の前に分かりますか？

案件票には書かれていないことが多く、面談で聞いて分かる部分がほとんどです。導入からの年数、設計の記録の有無、本番への反映の手段などを聞くと、おおよその状態がつかめます。答えがあいまいな場合は、調査の時間がかかる前提で期間と業務範囲を考えておくと安心です。

導入会社のチームとして入る案件と、使う会社から直接受ける案件では、どちらがよいですか？

一概には言えません。導入会社のチームとして入る形は、進め方や品質の基準が整っていることがある一方、顧客と直接話す機会が限られることがあります。使う会社から直接受ける形は、業務の理解を深めやすい一方、社内の体制によっては一人で抱える範囲が広がります。自分の役割と、指示を受ける相手が明確かどうかで判断しましょう。

契約の後に役割の比重が変わったら、どうすればよいですか？

業務範囲が個別契約の内容から変わる場合は、早めに発注側と話し、変更を書面やメールで残すことが大切です。報酬や期間の見直しが必要かどうかも、あわせて確かめましょう。考え方は作業範囲が広がったときの記事で解説しています。つまずきやすい場面と対策はSalesforceのフリーランスがつまずきやすい点でも扱います。