SAP HCM・SuccessFactorsコンサルのスキルシートの書き方｜面談で評価される実績の見せ方

SAP HCM・SuccessFactorsのスキルシートは、プロジェクトごとに「製品と環境」を1行で示し、担当した機能を正式な名前で書き、関わり方の深さを動詞で書き分けるのが基本です。人事の領域は機能の幅が広いため、「人事システム担当」のような書き方では、何を任せられる人なのかが伝わりません。

もう一つ大切なのは、人事・給与の経験を書くときに、従業員の個人情報や発注側を特定できる情報を書かないことです。この記事では、書き方の型と、架空の記入例、面談で深掘りされやすい点を整理します。基本の書き方はスキルシートの基本をご覧ください。

プロジェクト欄の冒頭に「製品と環境」を1行で書く

人事の案件では、オンプレミスのHCMかSuccessFactorsかで、読み手が想像する仕事がまったく違います。プロジェクト欄の最初に、次の要素を1行でまとめておきましょう。

例（架空）：「SuccessFactors（Employee Central）＋オンプレミスHCM給与の併用／移行／国内グループ会社複数／勤怠システム・会計との連携あり」

規模は「従業員数千名規模」のように、会社が特定されない程度のおおまかな書き方で十分です。どこまで書いてよいかはスキルシートと守秘義務の記事で解説しています。

機能は正式な名前で、深さは動詞で書く

「人事担当」ではなく機能の名前で書く

オンプレミスなら組織管理（OM）・人事管理（PA）・勤怠管理（PT）・給与計算（PY）、SuccessFactorsならEmployee Central、Recruiting、Onboarding、Performance & Goals、Learning、Succession & Developmentのように、機能の名前で書きます。SAP Learningでも、オンプレミスの機能とSuccessFactorsの機能の対応が示されており、両方の名前を並べて書いておくと、移行案件の担当者が読み取りやすくなります。

関わり方の深さを動詞で分ける

同じ機能でも、「要件を決めた」のか「設定した」のか「テストした」のかで、任せられる範囲が違います。動詞を使い分けて書きましょう。

「参加した」ばかりのシートは、経験の深さが伝わりません。逆に、主担当でなかったものを「設定した」と書くと、面談で深掘りされたときに説明が続かなくなります。

給与の経験は「範囲」と「検証」で書く

給与の経験は、案件側が特に知りたい項目です。次の点を具体的に書いておくと、判断がしやすくなります。

• 計算の範囲：月例給与、賞与、退職時の精算、遡及の計算、年末調整のどこを担ったか
• 制度への対応：社会保険や税の制度変更、会社の手当や等級の変更にどう対応したか
• 並行稼働：何か月分の並行稼働を行い、差異をどう分類して解消したか
• 連携：給与の結果を会計の仕訳として渡す設計や、勤怠のデータの受け取りを担ったか

書き換えの例（架空）：

• 書き換え前：給与計算の保守を担当
• 書き換え後：オンプレミスHCMの給与計算（PY）で、手当の改定に伴う計算規則の変更を設計・設定。過去月の遡及計算を含めて検証し、人事部門に差異の理由を報告

記入例（架空）

次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。

期間：20XX年4月〜翌年9月（1年6か月）
環境：SuccessFactors（Employee Central）＋オンプレミスHCM給与の併用／移行／国内グループ会社複数／勤怠システム・会計との連携あり
業種・概要：サービス業（従業員数千名規模）の人事システム刷新
立場：人事領域チーム6名のうち、人事マスタと給与連携のサブリーダー
担当工程：要件定義、設計・設定、移行、並行稼働、本番稼働の支援
担当内容：オンプレミスの人事管理（PA）・組織管理（OM）からEmployee Centralへの移行で、発令の種類と項目の対応表を作成し、人事部門と移行の範囲を決定。Employee Centralの基礎データと業務ルールを設定。人事マスタから給与への連携の仕様を設計し、受け渡しのエラーの監視手順を整備
工夫・成果：並行稼働を3回行い、差異を「データ移行」「計算規則」「運用の違い」に分類して一覧化。人事部門が自分で差異を判断できる形にした。マイナンバーの項目を見られる権限を人事の担当者に絞る設計を提案

実際に書くときは、ご自身の経験に置き換えてください。

個人情報を書かない・載せない

人事・給与の経験を具体的に書こうとすると、つい実データに近い内容を書いてしまいがちです。次の点に気をつけましょう。

• 実在の人物の情報は書かない：従業員の氏名、給与の額、評価の結果などは、たとえ一部でも書かない
• 画面の写しや帳票を添付しない：設定画面や給与明細の画像は、個人情報や発注側の情報が映り込むおそれがある
• 社名や制度の固有名を伏せる：社内だけで使う手当の名前や、制度の名前から会社が特定されることがある
• マイナンバーの扱いは「仕組みの話」として書く：個人情報保護委員会のガイドラインでは、マイナンバーは法令で定められた事務に限って使え、委託先にも同等の安全管理が求められます。スキルシートには、権限の設計や削除の手順をどう仕組みにしたかを書き、データそのものには触れない

個人情報の取扱いに慎重であることは、人事・給与の案件では評価の材料にもなります。

移行・連携・保守の経験の見せ方

移行は「何を、どこまで、どう照合したか」

移行の経験は、移したデータの種類（在籍者、退職者、履歴、組織）、移した範囲（何年分の履歴か）、照合の方法（件数・金額・サンプル確認）で書くと伝わります。

連携は「つなぎ目」として書く

人事から給与、給与から会計、勤怠から給与のように、どこからどこへ何を渡したかを書きます。連携のエラーが起きたときに、どこで止まり、誰がどう直す手順にしたかまで書けると、運用を考えられる人として読まれます。

保守は「制度変更と問い合わせ」で書く

保守の経験は、法改正や社内の制度変更への対応の件数と中身、問い合わせの種類で書くと伝わります。年末調整の時期の運用や、組織改編の一括反映を担った経験は具体的に書いておきましょう。

SuccessFactorsのリリース対応と資格の書き方

SuccessFactorsはクラウドのため、新しいリリースが定期的に提供されます。新機能の影響を確かめて取り入れるかを判断した経験は、運用の案件で読まれやすい項目です。認定資格は、資格欄に名称と取得時期を書き、維持の状況も添えておきましょう。資格の位置づけはSAP認定コンサルタントの記事で解説しています。

よくある質問

オンプレミスとSuccessFactorsの両方の経験があります。どう書き分けますか？

プロジェクトごとに環境の行で製品を明記し、機能もそれぞれの製品の名前で書きます。移行案件の場合は、旧環境の機能と新環境の機能を並べて書くと、両方を知っていることが伝わりやすくなります。

人事の実務経験はどこに書けばよいですか？

職務経歴の冒頭の要約に、人事・給与の実務の年数と担当業務を短く書き、プロジェクト欄ではSAPでの経験を中心に書きます。実務経験が設定のどの判断に生きたかを、プロジェクトの「工夫・成果」に一言添えると、強みとして伝わります。

担当した従業員数は書いてもよいですか？

「数千名規模」「グループ会社複数」のように、会社が特定されない程度のおおまかな幅であれば、規模感を伝える材料になります。正確な人数や、社名を推測できる組み合わせは避けましょう。