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

Workdayコンサルのスキルシートは、プロジェクトごとに領域・プロジェクトの種類・展開の範囲・連携先を1行で示し、担当した機能をWorkdayの言葉で書き、その機能に自分がどう関わったか（決めたのか、構成したのか、運用したのか）を動詞で書き分けるのが基本です。「Workday HCM担当」とだけ書くと、読み手は構成の方針から任せてよいのか、決まった設計の作業を任せる人なのかを判断できません。

経験の棚卸しの方法はWorkdayコンサルがフリーランスになるには、求められるスキルの中身はWorkdayコンサルのスキルの記事で扱っています。この記事では、棚卸しした経験をシートの上でどう見せるかに絞ります。

プロジェクト欄の冒頭に「前提」を1行で書く

Workdayの読み手は、担当内容を読む前に「どんな前提のプロジェクトだったか」を知りたいと考えています。同じビジネスプロセスの構成でも、一つの国だけの導入と、複数の国をまたぐ導入では難しさが違うためです。プロジェクトの最初に、次の要素を1行でまとめておきましょう。

例（架空）：「Workday HCM／新規導入／国内と海外の拠点／国内の給与システムと連携／導入を担う側」

規模は社名が特定されない程度のおおまかな書き方で十分です。どこまで書いてよいかはスキルシートと守秘義務の記事をご覧ください。

機能はWorkdayの言葉で、深さは動詞で書く

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

HCMもFinancialsも範囲が広いため、領域の名前だけでは担当の中身が伝わりません。「コアHCM（組織・ポジション）」「報酬」「タレント・評価」「休暇」「経費」「購買」のように機能の名前で書き、そのうえで横断の部分（ビジネスプロセス、セキュリティ、カスタムレポート、計算項目、EIB）を分けて書くと、読み手は案件の要件と照らし合わせやすくなります。

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

同じ機能でも、関わり方には深さの違いがあります。シートで使う動詞を決めておくと、面談で聞かれたときの説明と食い違いません。

書き換えの例（架空）：

• 書き換え前：ビジネスプロセス設定
• 書き換え後：異動・昇格のビジネスプロセスの承認の流れを人事部門と決め、構成。部門長の不在時の代理承認の条件を追加し、役割ごとにテスト

ビジネスプロセスとセキュリティの書き方

Workdayの面談では、ビジネスプロセスとセキュリティについて深く聞かれることがよくあります。シートでは、次の3点を書いておくと説明の土台になります。

1. どの業務の流れか：採用、異動、退職、報酬の改定、経費の申請など
2. 何を決めたか：承認者の決め方、条件による分岐、通知の相手
3. どう確かめたか：役割ごとのテスト、見えてはいけない情報が見えないことの確認

セキュリティは「権限設定」と一言で書かれがちですが、組織の階層と役割に沿って、どの情報を誰に見せるかを決めた経験として書くと、個人情報を扱う案件で信頼されやすくなります。

連携とレポートは「何と何をつないだか」で書く

連携の経験は、使った手段の名前だけでなく、何と何をつなぎ、どの向きにどんなデータを流したかを書きます。

• 国内の給与システムへ、従業員の基本情報と異動の結果を毎日渡す連携をEIBで構成
• 外部の勤怠システムから、休暇の取得結果を取り込む連携の仕様を決め、テスト
• 人件費の計上に必要な項目を、会計の担当と一緒に洗い出した

レポートは、作った本数より「誰が何を判断するためのレポートか」を書くと伝わります。計算項目を使った場合は、何の値を作るために使ったかを一言添えましょう。

記入例（架空）

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

期間：20XX年4月〜翌年9月（1年6か月）
前提：Workday HCM／新規導入／国内と海外の拠点／国内の給与システムと連携／導入を担う側
業種・概要：サービス業（中堅規模）の人事システム刷新
立場：HCMチーム4名のうち、コアHCMとセキュリティの担当
担当工程：要件の整理、構成、データ移行、テスト、稼働の支援
担当内容：組織・ポジションの持ち方の方針を人事部門と決め、構成。異動・昇格・退職のビジネスプロセスを構成し、条件による承認の分岐を設定。役割ごとの権限を設計し、管理職・人事担当・従業員の役割でテスト。従業員データの移行で、EIBを使った取り込みと照合を担当
工夫・成果：権限のテスト結果を役割ごとの表にまとめ、人事部門が自分で確かめられる形にした。稼働後最初の組織変更に立ち会い、構成の手順書を残した

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

運用・保守の経験の書き方

運用・保守の経験は、「問い合わせ対応」の一言で終わりがちです。次の3点に分けると、本番環境での力が伝わります。

1. 対応した問い合わせの種類：承認が止まった、見えるはずの情報が見えない、レポートの数字が合わない、など
2. 構成の変更：組織変更、制度の変更、新しい機能の取り込みで、自分が方針を決めたもの
3. 定期の作業：年度の切り替えや評価の時期に何を準備したか

同じ利用企業で導入から運用まで続けて担当した場合は、期間を分けて2件のプロジェクトとして書くと、導入の経験と運用の経験の長さがそれぞれ伝わります。

要約欄は「領域・段階・立場」で3行に

シートの冒頭の要約欄は、読み手が最初に目を通す場所です。Workdayの経験は、次の3行にまとめると伝わりやすくなります。

1. 領域と年数：HCM（コアHCM・報酬・休暇）の構成を約X年、など
2. 担える段階：方針を決めるところから担えるのか、構成とテストが中心か
3. 立場と強み：導入を担う側か利用企業の側か、得意な横断の領域（セキュリティ、連携など）

要約に書いたことは、プロジェクト欄のどこかで裏付けが取れるようにしておきましょう。

認定と英語の書き方

Workday Proの認定は、HCM、Financials、Integrations、Reporting and Analyticsなどの領域ごとに用意されています（2026年10月時点のWorkday Communityの公開ページ）。資格欄には、認定の正式な名称と取得した年月を書きます。案件では実務の経験が重視されるため、認定はプロジェクト欄の内容とあわせて読まれることが多くなります。

英語は「英語可」とだけ書かず、資料の読み書き、会議への参加、会議の進行のどこまでを担ったかを書き分けます。海外の拠点を含む導入では、対象の国や地域のおおまかな規模も添えましょう。

よくある質問

導入を担う側と利用企業の側の両方の経験があります。どう書き分けますか？

プロジェクトごとの「前提」の行に立場を書けば、読み手はどちらの経験かを区別できます。応募する案件が利用企業側の支援なら、利用企業側の経験を要約の上に置くと伝わりやすくなります。

他の人事システムの経験もシートに書くべきですか？

書いておきましょう。Workday以外のシステムで導入や運用を担った経験は、業務の理解やプロジェクトの進め方の裏付けになります。ただし、Workdayの経験と混ざらないよう、プロジェクトを分けて書くのがおすすめです。

守秘義務があり、利用企業の業種も書けません。どうすればよいですか？

業種を書けない場合は、「サービス業」「製造業」のような大きな分類にとどめるか、従業員数のおおまかな規模と展開の範囲だけを書きます。何をどこまで書いてよいかは契約の内容によるため、迷うときはスキルシートと守秘義務の記事をご覧ください。