Salesforceエンジニア・コンサルのスキルシートの書き方｜面談で評価される実績の見せ方

Salesforceのスキルシートは、プロジェクトごとに「どの製品で」「どの役割を」「どの工程で」担ったかをそろえ、標準機能・フロー・開発のどれを選んだかの判断まで書くと伝わります。Salesforceの案件は製品と役割の組み合わせで募集されることが多く、読み手はまずその組み合わせが合うかを確かめるからです。

この記事では、Salesforceならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルはSalesforceのスキルの記事で解説しています。

「Salesforce経験◯年」だけでは伝わらない

Salesforceの経験者のシートで多いのが、スキル一覧に「Salesforce（5年）」とだけ書かれている形です。Salesforceは営業支援、カスタマーサービス、ポータル、マーケティングなど製品の幅が広く、同じ5年でも、アドミンとして設定を続けてきたのか、開発者としてApexを書いてきたのか、要件定義から導入をまとめてきたのかで、まったく違う経験になります。

読み手が確かめたいのは、次の3つの組み合わせです。

• 製品：どのクラウド・機能群を扱ったか
• 役割：アドミン、開発、コンサル（要件定義・設計）、アーキテクトのどれか
• 工程：新規導入、追加開発、運用保守、移行のどこを担ったか

スキル一覧は、この組み合わせが見える形で書くと、読み手が案件の条件と照らし合わせやすくなります。

新規導入・追加開発・運用保守を分けて書く

Salesforceの案件では、新規に導入するプロジェクトと、すでに使われている組織に手を入れるプロジェクトとで、求められる力が違います。

• 新規導入：業務を聞き取り、標準の機能にどう合わせるかを提案する力。データの設計を一から考える力
• 追加開発・改修：既存の設定や開発の中身を読み解き、影響の範囲を見極める力
• 運用保守：利用者からの依頼を受けて設定を変え、権限やデータの品質を保つ力

すでに長く使われている組織では、過去の担当者が作った自動化や項目が積み重なっていることが多く、既存の作りを読み解いて整理した経験は評価されやすい傾向があります。プロジェクト欄の冒頭に、どの工程のプロジェクトかを書いておくことをおすすめします。

使った機能は具体的な名前で書く

担当内容の欄に「カスタマイズを担当」「開発を担当」とだけ書くと、深さが伝わりません。Salesforceのシートでは、扱った機能や技術を具体的な名前で書くのが基本です。

それぞれに、自分が設計から担当したのか、決められた設計どおりに作ったのかを添えると、任せられる範囲が伝わります。

「標準で済ませた判断」を書く

Salesforceの案件では、何でも開発で作るのではなく、標準の機能やフローで済むところは済ませる判断が評価されやすくなります。開発が増えるほど、保守の手間やバージョンアップへの対応の負担が増えるためです。

この判断は、シートの「工夫・成果」の欄に書くと目に留まりやすくなります。

記入例（架空）：判断が伝わる書き方

工程：新規導入（要件定義〜リリース、約8か月）
案件概要：専門商社向け 営業支援の導入。表計算ソフトで管理していた案件と見積の情報を移行
組織の規模：利用者は数百名規模、既存の基幹システムと受注情報を連携
役割：コンサル兼開発（チーム5名のうち、要件定義と設計の主担当）
担当内容：営業部門への聞き取りと要件定義。商談・見積のデータモデルと、営業部門ごとの権限の設計。見積の承認はフローと承認プロセスで構成
判断した点：当初は見積の画面を開発で作る案が出ていたが、標準の画面と入力規則で要件の大半を満たせることを示し、開発は割引計算の部分だけに絞った
成果：開発の範囲が絞られ、導入後の項目追加を社内の担当者が行えるようになった

これは書き方を示すための架空の例です。業種、規模、判断の内容は、ご自身の経験に置き換えてください。

開発者の方も、Apexで作った部分について「なぜフローでは足りなかったか」を一言書いておくと、面談での説明につながります。

組織の規模は丸めた数で示す

Salesforceの案件では、組織の規模によって設計の難しさが変わります。利用者が多い組織や、データ量が多い組織、他のシステムとの連携が多い組織では、権限やデータの扱い、処理の上限への配慮が必要になるためです。

規模の欄には、次のような項目を丸めた数で書きます。

• 利用者の規模（数十名、数百名、数千名など）
• 利用している部門の数
• 連携している外部システムの数
• 移行したデータの規模（件数の桁がわかる程度）

ライセンスの契約数や、顧客データの実際の件数などは、社外に出せない情報にあたることがあります。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

認定資格の書き方

Salesforceの案件では、認定資格が役割の目安として見られることがあります。資格欄には、正式な名称と取得年月を書き、役割ごとにまとめて並べると読みやすくなります（例：アドミン系、開発系、コンサルタント系）。

取得後の維持の扱いは、公式の案内で必ずご確認ください。そのうえで、現在も有効な状態かを正確に書いておきます。資格の位置づけや選び方はSalesforceのスキルの記事とSalesforceエンジニア・コンサルがフリーランスになるにはで解説しています。資格の数を増やすことより、資格と同じ役割の実務をプロジェクト欄で示すことが評価につながります。

他のシステムの経験の書き方

Salesforce以外の開発経験やCRMの経験がある方は、それを別のプロジェクトとして書きつつ、Salesforceの案件に生きる要素を一行添えます。たとえば、Java開発の経験はApexの開発に、業務パッケージの導入経験は要件定義に、データベースの設計経験はデータモデルの設計に、それぞれ結び付けて書けます。

要約の欄では、Salesforceの経験を上に置き、他の経験は「連携先のシステムの開発経験あり」のように補足の形で書くと、Salesforceの案件に応募するときの軸がぶれません。

よくある質問

アドミンとしての運用経験しかありません。どう書けばよいですか？

運用の経験も、扱った機能と依頼の種類を具体的に書けば十分な判断材料になります。項目やページの追加、権限の見直し、フローの作成、データの整理など、自分で設計から行ったものを分けて書くと、アドミン案件だけでなく設計寄りの案件にも出しやすくなります。

準委任の案件と請負の案件で、書き方は変わりますか？

書き方の型は同じですが、請負の案件では、自分が担った成果物と品質への責任の範囲を明確に書いておくと読み手に伝わりやすくなります。契約の形の違いは準委任と請負の違いの記事で解説しています。

古いバージョンの機能を使った経験は書かないほうがよいですか？

書いてかまいません。過去の自動化の仕組みから新しい仕組みへの置き換えに関わった経験は、既存の組織を整理する案件で評価されることがあります。古い機能を使った時期と、現在の機能への置き換えの経験があるかを分けて書くと、現役で使えるスキルが伝わります。