Salesforceエンジニア・コンサルのフリーランス面談でよく聞かれる質問と答え方
公開 2026-10-29 監修：株式会社エージェントベスト
Salesforceのフリーランス面談では、どの製品を、どの役割で、どの工程で担ったかを確かめたうえで、「その要望は標準機能で実現できなかったのか」「権限はどう設計したか」「本番にはどう反映したか」といった、判断の理由を問う質問が続くことがよくあります。発注側が知りたいのは、機能の名前を知っているかより、任せたときにどう考えて動く人かです。
答え方は、模範解答を覚えるより、自分の案件から「判断した場面」を3〜4つ選び、理由と結果を話せるようにしておくのが近道です。この記事では、Salesforceの面談でよく出る質問の意図と、答えを組み立てる考え方を整理します。業務委託の面談全般の質問は面談でよく聞かれる質問の記事にまとめています。
面談の最初に確かめられる「製品・役割・工程」
最初に聞かれやすいのは「これまでの経験を簡単に教えてください」です。Salesforceの面談では、この答えで次の3つがそろっているかが見られます。
- 製品：営業支援、カスタマーサービス、ポータルなど、どの製品を扱ったか
- 役割：アドミン、開発、コンサル（要件定義）、アーキテクトのどれか
- 工程：新規導入、追加開発、運用保守、移行のどこを担ったか
「Salesforceを5年やってきました」だけで話し始めると、面談の相手は質問で一つずつ埋めることになり、時間を使います。直近の案件から、この3つを一文ずつで言える形にしておくと、残りの時間を深い質問に回せます。経歴の見せ方はSalesforceのスキルシートの記事、話す順番は自己紹介の組み立て方で解説しています。
よく掘り下げられる質問と答え方の考え方
以下の質問はSalesforceの面談で出やすいものです。答えの例は考え方を示すための架空のもので、そのまま使うものではありません。ご自身の案件の事実に置き換えて組み立ててください。
「その要望は標準機能で実現できなかったのですか」
開発やカスタマイズの経験を話したときに、ほぼ決まって続く質問です。意図は、作り込みすぎて保守の負担を増やす人ではないかを確かめることにあります。
答えるときは、検討した選択肢、選んだ理由、合意の取り方の順に話します。
（架空の例）見積の承認は、最初に標準の承認の仕組みで試しましたが、金額と商品の組み合わせで承認者が変わる条件が多く、設定が追えなくなると判断しました。そこで条件の判定だけをフローにまとめ、画面は標準のまま残しました。利用部門には、条件が増えたときに社内の管理者が直せる形を優先した、と説明しました。
開発を選んだ場面だけでなく、「要望を聞いたが作らなかった」場面も一つ用意しておくと、判断の幅が伝わります。
「部署をまたいでレコードを見せたいとき、どう設計しますか」
権限の考え方を確かめる質問です。Salesforceでは、組織全体の共有の初期設定、ロール階層、共有ルール、プロファイルと権限セットを組み合わせて「誰が何を見られるか」を決めます。
答えでは、機能の名前を並べるより、まず何を基準に考えるかを話します。たとえば「見せない状態を基本にして、必要な範囲だけ開く」「例外が多い場合は、部署の構造そのものを見直す提案をする」といった考え方です。過去に権限の不具合を切り分けた経験があれば、どこから調べたかを順に話すと具体性が出ます。
「同じオブジェクトにフローとトリガーが混在していたらどうしますか」
改修や保守の案件でよく聞かれます。既存の組織を読み解く力と、整理の進め方を見ています。
答えの骨組みは、現状を調べる→動く順番と役割を整理する→すぐ直すものと計画的に直すものを分けるです。全部を一度に作り直すと言うより、影響の小さいところから段階的に移す考え方を示すほうが、現場の事情を分かっている人として受け止められやすくなります。
開発者に聞かれやすい質問
開発の役割では、次のような質問が続くことがあります。
- 大量のデータを処理するときに、処理の上限に当たらないためにどう書くか
- テストクラスを、反映のための形式としてではなく品質の確認としてどう書いているか
- 開発した部分を、フローとどう役割分担させたか
- ソースコードの管理と、本番への反映の手段に何を使ったか
コードを書く課題や画面共有での説明を求められる場合もあります。形式の確かめ方は技術面談への備え方で解説しています。
「データ移行で何を確かめましたか」
移行の経験を話したときに出る質問です。件数の照合、重複の扱い、項目の対応づけ、移行の順番、やり直しの手順など、移行の前後で何をどう確かめたかを話します。移行の当日に問題が起きた経験があれば、そのときの判断も具体的な材料になります。
「利用部門から反対されたとき、どう進めましたか」
コンサルやアドミンの役割でよく聞かれます。Salesforceの導入では、これまでの業務のやり方を変えてもらう場面が多いためです。相手の懸念を何と受け止め、どこを業務側に合わせてもらい、どこをシステム側で受けたかを分けて話すと、調整の進め方が伝わります。
稼働と進め方について聞かれること
技術の質問のほかに、働き方の確認もあります。Salesforceの案件ならではの論点は次のとおりです。
- 本番反映やリリースの時間帯：業務時間外や休日に反映作業がある場合に対応できるか
- 研修や切り替えの日の出社：リモート中心の案件でも、特定の日に現地へ来られるか
- 定期リリースへの対応：保守の案件で、リリース前の確認作業を担った経験があるか
- 引き継ぎ：前任者からの引き継ぎ資料が少ない状態で、どう立ち上がるか
できないことは、面談の場で正直に伝えたほうが、参画後のずれを防げます。リモートと出社の考え方はSalesforceのリモート案件の記事にまとめています。
逆質問で確かめておきたいこと
面談の最後に質問の時間があれば、仕事の中身を確かめる機会として使います。Salesforceの案件では、次の点を聞いておくと参画後の働き方を見積もりやすくなります。
- 導入から何年たった組織で、設計書や変更の記録が残っているか
- Sandboxの構成と、本番への反映を誰がどの手順で行うか
- 社内に管理者がいるか、依頼はどの経路で届くか
- 自分の役割の比重（要件定義・設定・開発の割合）
逆質問の全体の考え方は逆質問の記事、契約前に確かめる点はSalesforceの案件の選び方で解説しています。
面談前の準備の進め方
準備は、想定問答を暗記するより、次の順で材料をそろえると応用が利きます。
- 直近2〜3件の案件を「製品・役割・工程」で一文ずつにする
- 判断した場面を3〜4つ選ぶ：標準機能で済ませた場面、開発を選んだ場面、権限やデータで迷った場面、利用部門と調整した場面
- それぞれ「選択肢・理由・結果」をメモにする：数字は守秘の範囲で丸める
- 苦手な質問を一つ決めて準備する：触れていない製品や機能を聞かれたときに、どこまで分かり、どう補うかを話せるようにする
- 認定資格を聞かれたときの答えを決める：資格で学んだことと実務で担ったことを分けて話す（Salesforceの資格の記事）
声に出して話してみると、説明が長くなる場面に気づけます。一つの答えを1〜2分に収め、詳しく聞かれたら広げる形が話しやすくなります。
よくある質問
触ったことのない製品について聞かれたら、どう答えればよいですか？
経験がないことは正直に伝え、近い経験と補い方を添えます。たとえば、別の製品で似た業務を扱った経験や、検証の環境で試した範囲を話すと、立ち上がりの見通しが伝わります。知らない機能を知っているように話すと、続く質問で差が出てしまいます。
面談で設定画面の操作を求められることはありますか？
案件によっては、画面を共有して設定の考え方を説明したり、簡単な課題に答えたりすることがあります。事前に形式を確かめられる場合は、聞いておくと準備しやすくなります。選考の範囲を超える作業を求められたときの考え方は面談での課題の記事をご覧ください。
アドミンの経験だけでも、面談で設計の質問をされますか？
されることがあります。権限の見直しやフローの作成で、自分が設計から考えた部分があれば、それを中心に話しましょう。決められた設計どおりに作った部分と分けて話すと、任せられる範囲が正しく伝わります。