Salesforceエンジニア・コンサルのフリーランスがつまずきやすい点と対策

Salesforceのフリーランスがつまずきやすいのは、「設定ならすぐできる」と思われて役割が際限なく広がること、本番の組織を直接変える現場の習慣、自動化の重なりやデータ量による思わぬ不具合、導入の区切りで契約が終わる収入の波です。どれも、Salesforceが設定だけで多くのことをできる製品であることと関係しています。

対策の多くは、参画の前と最初の数週間で手を打てます。この記事では、契約・現場・技術・お金の順に、起きやすいことと対策を整理します。

契約でのつまずき

アドミン・開発・問い合わせ窓口が一人に集まる

Salesforceの案件では、「アドミンとして参画したのに、利用者からの問い合わせ対応、レポートの作成依頼、Apexの修正まで頼まれる」ということが起きやすくなります。画面から設定できる作業は、頼む側にとって「ちょっとした作業」に見えやすいためです。

対策は、契約の段階で役割の範囲を言葉にしておくことです。

• 主な役割（アドミン・開発・要件定義）と、それ以外を担う場合の扱い
• 利用者からの問い合わせを直接受けるのか、社内の窓口を通すのか
• 開発の作業があるなら、レビューやテストまで含むのか

範囲の外の依頼が来たときの伝え方は追加の依頼を断るときの伝え方、範囲が広がったときの契約の扱いは作業範囲が広がったときの記事で解説しています。

準委任のつもりが、完成を約束する形になっている

Salesforceの案件は月単位の準委任が多い一方で、「この画面とこの自動化を作る」とまとめて引き受ける形では、成果物の完成を約束する請負になっていることがあります。どちらの形かで、不具合が見つかったときの責任や検収の扱いが変わります。契約書の名前ではなく中身で確かめましょう。違いは準委任契約と請負契約の違いにまとめています。

本番への変更の責任があいまい

本番の組織に変更を反映する権限を持つかどうかは、責任の重さに直結します。誰が反映の承認をするのか、不具合が出たときに誰が戻すのかが決まっていないまま権限だけを渡されると、問題が起きたときに一人で背負うことになりがちです。

現場でのつまずき

本番の組織を直接変える習慣が残っている

Salesforceには、本番と切り離された検証用の環境（Sandbox）を作り、開発やテスト、研修に使う仕組みがあります（Salesforce Helpによる）。ところが現場によっては、急ぎの修正を本番で直接設定する習慣が残っていることがあります。

この状態に合わせて自分も本番で直接変えると、検証用の環境と本番の内容がずれ、次の開発で思わぬ上書きが起きます。対策は、直接変えた場合も変更の内容を記録し、検証用の環境に戻す手順を決めておくことです。現場の習慣を変える提案は、記録が溜まってから根拠を添えて行うほうが受け入れられやすくなります。

ドキュメントがなく、作り込みの理由がわからない

長く使われている組織では、項目や自動化が「なぜあるのか」を説明できる人がいないことがよくあります。使われていないように見える項目を消したら、別の部署のレポートや外部連携が止まった、というのは典型的なつまずきです。

消す・変える前に、その項目や自動化がどこから参照されているかを確かめ、利用部門に確認してから進めましょう。参画初月の棚卸しの進め方はSalesforceの参画初月にやることで解説しています。

利用部門の要望を直接受けて、優先順位が崩れる

Salesforceの利用者は、営業やサービスの現場の人たちです。顔が見える関係になると、窓口を通さずに直接要望が届くようになり、目の前の小さな改修を重ねるうちに、本来の課題が後回しになります。要望は一度窓口に集め、優先順位を発注側と決めてもらう流れを作っておくと、自分の判断で優先順位を変えずに済みます。

技術でのつまずき

自動化が同じオブジェクトに重なっている

一つのオブジェクトに、複数のフロー、Apexのトリガー、古い仕組みで組まれた自動化が重なっていると、保存したときの動きが読めなくなります。新しい自動化を足しただけのつもりが、別の自動化と組み合わさって、更新が繰り返されたり、処理の上限にかかったりします。

対策は、足す前に、そのオブジェクトにどんな自動化がすでにあるかを一覧にすることです。重なりを見つけたら、すぐに統合するのではなく、まず発注側に状態を伝え、整理を作業として計画してもらいましょう。

データ量が増えてから性能や上限の問題が出る

検証用の環境では少ないデータで問題なく動いたのに、本番で大量のデータを扱ったとたんに処理が止まる、ということがあります。Salesforceは1回の処理で使える資源に上限があるため、データ移行や一括更新のときに表面化しやすい問題です。一括の取り込みでは、ふだんの自動化が一度に動いてしまうこともあります。移行の前に、本番に近い量のデータで試す段取りを入れておきましょう。

検証用の環境では動くのに、本番では動かない

検証用の環境で確かめた変更が、本番に反映したとたんに動かないことがあります。原因として多いのは、本番だけにある項目や自動化、利用者ごとの権限の違い、反映の対象から漏れた部品です。検証では管理者の権限だけで確かめ、実際の利用者の権限で試していなかった、というのもよくある見落としです。テストの観点に「どの利用者の権限で確かめたか」を入れておくと、反映後の手戻りを減らせます。

製品の更新で、設定や画面の動きが変わる

Salesforceは製品の更新を続けており、更新ごとにリリースノートを公開しています（2026年10月時点ではWinter '27のリリースノートが公開されています）。更新によって既存の画面や設定の動きが変わることがあるため、リリースノートで自分の担当範囲に関わる変更を確かめる習慣を持っておくと、不具合の問い合わせに慌てずに済みます。

お金でのつまずき

導入の区切りで契約が終わる

導入の案件は、本番の切り替えから少したつと区切りを迎えやすく、次の案件を探し始めるのが遅れると収入が途切れます。契約期間の終わりが見えてきたら、更新の見込みを早めに確かめ、次の案件の準備を並行して進めましょう。更新の仕組みは契約更新の記事をご覧ください。

稼働時間が膨らみ、報酬が見合わなくなる

調査に時間がかかる組織では、月の稼働時間が想定を超えることがあります。精算幅（稼働時間の上限・下限）がある契約では、上限を超えた分の扱いを確かめ、超えそうなときは早めに報告しましょう。仕組みは精算幅の記事で解説しています。稼働の記録は稼働報告書の書き方も参考になります。

学習と認定の維持の時間を見込んでいない

製品の更新に追いつくための学習や、認定資格の維持には、稼働とは別に時間がかかります。この時間を見込まずに稼働を詰めると、維持の期限を過ぎてしまうことがあります。維持の仕組みはSalesforce認定資格の記事をご覧ください。

よくある質問

前任者の作り込みが原因の不具合を直すよう頼まれました。引き受けるべきですか？

契約の範囲に含まれるかで判断します。範囲に含まれるなら、原因と影響の範囲を調べてから、直し方と見込みの時間を報告して進めるのが基本です。範囲の外であれば、作業として追加するかどうかを発注側と決めてから着手しましょう。

本番の組織で直接設定するよう指示されました。どうすればよいですか？

まず、その指示が現場のルールとして決まっているのかを確かめます。そのうえで、変更の内容と日時を記録し、検証用の環境にも同じ変更を反映する手順を決めておくと、後でのずれを防げます。リスクが大きい変更は、その理由を伝えて手順を見直してもらうことも考えましょう。

つまずかないために、案件を選ぶ段階でできることはありますか？

あります。既存の組織の状態（作り込みの量、ドキュメントの有無）、本番への反映の流れ、自分が担う役割の範囲を、面談の段階で確かめておくと、多くのつまずきは避けやすくなります。選び方はSalesforce案件の選び方にまとめています。