パーソルキャリアの職務経歴書｜RA・CA・企画職別の書き方を解説

パーソルキャリア向けの職務経歴書は、会社単位ではなく応募職種単位で作ります。営業職だけでもRA、CA、PA、HA、CS、RCなど役割が分かれ、クリエイティブやアシスタントでは成果の示し方がさらに変わるためです。

パーソルキャリア向けは職種を先に決める

職務要約の冒頭には、応募先の顧客と役割を置きます。「人材業界で貢献したい」だけでは、法人採用を支援するのか、個人の転職を支援するのか、プロダクトを改善するのかが分かりません。

公式の営業職紹介だけでも、RA、CA、PA、HA、CS、RC、HiPro系など複数の役割が示されています。略称が似ていても、担当顧客や支援の完了条件は同じではありません。応募求人の仕事内容を読み、過去経験との対応を職務要約の冒頭へ集約します。

複数ポジションへ関心がある場合も、提出書類は一つにまとめないほうが明確です。法人向けの提案実績をCA応募の先頭に置いたり、個人支援の経験をクリエイティブ応募で長く説明したりすると、採用側が知りたい経験へ到達しにくくなります。

応募領域	主な対象	職務経歴書の中心
RA・法人営業	採用企業	採用・経営課題、提案、採用成果
CA・個人支援	転職希望者	意思決定支援、求人提案、継続支援
クリエイティブ	サービス利用者・顧客	課題設定、設計、検証、改善
アシスタント	営業・CA・顧客	正確性、調整、業務設計、改善

共通して伝える3要素

顧客の状態、自分が行った判断、結果の3要素を分けるのが基本です。支援件数や制作物だけで終えると、本人がどの課題を見つけ、どの働きかけで変化を生んだかが伝わりません。

成果を書くときは、チーム全体の実績と本人の担当を切り分けます。たとえば部門で採用決定を生んだ場合、候補者本人が担当した求人要件の調整、候補者への情報提供、面接後の意向確認を明記するのが適切です。結果の大きさより、同じ状況で再び実行できる仕事の範囲が伝わる書き方です。

数字が開示できない実績は、推測値で埋めません。担当社数や決定数の代わりに、対象顧客の種類、変更した業務、意思決定に使われた資料、改善前後で確認できた事実を記載できます。守秘義務がある場合は、顧客名を伏せても業界・部門・課題の種類を残す形です。

• 法人・個人・社内の誰を支援したか
• 着手前にどの課題や不一致があったか
• 自分が選んだ提案・支援・設計
• 結果と、その後に残った課題

RA・法人営業向けの書き方

RAは採用活動への支援を通じ、企業の人事・経営課題を扱う形です。求人受注や売上だけでなく、採用背景、必要人材、採用上の障害、提案後の結果を一続きにします。

求人要件を変えた経験は理由まで書く

採用要件の見直しに関わった場合は、「条件を緩和した」と短く書かず、事業計画上必要な役割、当初の要件で採用が進まなかった理由、現場責任者と合意した変更点を示す形です。要件変更後に応募者の質や選考の進み方をどう確認したかも、本人の提案力を示す事実です。

複数サービスの提案は選択理由を残す

人材紹介、求人広告、採用支援など複数の選択肢を扱った経験は、商材名の一覧にしません。採用人数、期限、対象職種、社内体制を踏まえ、なぜその方法を優先したかを書きます。提案しなかった選択肢と理由も説明できれば、顧客課題から考えたことが伝わる構成です。

項目	記載内容
顧客	業界、規模、採用部門、決裁者
課題	採用人数だけでなく、事業計画や組織上の背景
提案	求人要件、選考、訴求、チャネルの変更
成果	採用決定、選考改善、継続取引など確認できる結果

CA・個人支援向けの書き方

面談件数や決定数の前に、相談者の判断をどう支えたかを書くのが基本です。希望条件の確認、経験の言語化、求人の比較、選考準備、意思決定のどこを担当したかを示します。

求人提案の基準を説明する

求人を何件紹介したかだけでは、提案の質は判断できません。相談者が転職で変えたいこと、維持したい条件、許容できる不確実性をどう確認し、候補を絞ったかを書きます。本人の希望と市場の状況が合わないときに、何を説明し、どの選択肢を残したかも具体的な支援経験です。

選考準備は個別化した内容を示す

書類添削や面接対策を担当した場合は、一般的な助言をした事実ではなく、応募先の職務要件と相談者の経験のどこに差があり、何を確認したかを示します。伝えていない経験を作ったように見せず、本人が持つ実績の順序や具体性を変えた範囲に限定するのが適切です。

売上目標がある業務でも、数字だけでは支援品質が分かりません。短期の応募促進ではなく、相談者が条件の優先順位を決めた過程や、入社後の不一致を避けるために確認した内容を補足します。

クリエイティブ向けの書き方

公式職種紹介では、同社のサービスでプランニング、UI/UX、ディレクション、プロデュースなどを担うと説明しています。制作物の見た目より、利用者の課題、仮説、検証、改善結果を中心に置くのが基本です。

新規開発と既存改善を分ける

新規サービスでは、不確実な課題をどう確かめ、最初の提供範囲をどう決めたかを書きます。既存サービスでは、利用データや問い合わせから見つけた問題、改善案、検証結果を示す形です。「0から作った」「改善を続けた」だけでは、本人の設計判断が見えません。

他職種との合意形成を記載する

UI/UXの改善は、デザイナーだけで完結しない場合があります。企画、エンジニア、マーケティング、法務などと調整した論点を示し、利用者価値と実装・事業上の制約をどう両立したかを書くのが基本です。成果物の担当範囲も、企画、情報設計、画面設計、検証の単位で分けるのが基本です。

ポートフォリオと職務経歴書の役割も分けます。ポートフォリオは成果物と過程を見せ、職務経歴書は事業上の目的、自分の責任範囲、他職種との合意形成を説明する形です。

アシスタント向けの書き方

「サポートしました」で終えず、誰のどの業務を、どの品質で支えたかを書くのが基本です。一般事務・営業事務、CA支援、採用代行では、扱う情報、期限、関係者が異なります。

正確性を示すときは、「ミスなく対応」だけでなく、チェック項目、ダブルチェックの対象、例外処理、期限管理の方法を書くのが基本です。問い合わせの種類を分類して回答時間を短縮した、入力ルールを統一して手戻りを減らしたなど、業務の仕組みを変えた経験も有効です。

営業やCAとの連携では、指示を待った事実だけでなく、優先順位を確認した場面や、情報不足を見つけて確認した場面を示します。担当者の代わりに判断したようには書かず、支援職として自分が担った確認・調整の範囲を守るのが原則です。

• 処理件数と、正確性を保つ仕組み
• 営業・CA・顧客との調整範囲
• 手順を変更した業務改善
• 引き継ぎやマニュアル整備の結果

経歴別の補強方法

人材業界未経験者は、近い顧客課題と不足する業務知識を分けるのが基本です。法人営業経験者は経営・人事課題への提案、接客経験者は個人の意思決定支援、Web制作経験者はユーザー検証、事務経験者は品質と改善を対応させます。

完全に同じ仕事をしたように言い換える必要はありません。たとえば採用経験がない法人営業なら、顧客の事業課題から提案条件を組み立てた経験は近接しますが、採用市場や労働条件の知識は不足点として残ります。職務経歴書では近い経験を示し、志望動機や面接準備では学ぶべき点を明確にする必要があります。

社内異動や兼務がある人は、時系列だけでなく役割ごとに実績をまとめる方法もあります。ただし在籍期間との対応が分からなくならないよう、各役割に期間と所属を付けます。複数の顧客接点を経験した強みは、法人・個人・プロダクトのどの応募先で使うかを選ぶのが基本です。

抽象表現を直すBefore／After

Before	Afterの構造
企業の採用を支援	採用背景→要件上の課題→提案→選考・採用結果
求職者に寄り添った	迷っていた条件→比較方法→意思決定→結果
UI/UXを改善	利用者課題→仮説→設計→検証→改善結果
営業を幅広く支援	対象業務→処理品質→調整→業務改善

面接と整合する提出前確認

公式案内では面接は2〜4回程度で、職種・事業によって変動します。書類に記載した成果について、対象、役割、判断理由、結果を同じ内容で説明できるかを確認する必要があります。

面接前には、主要実績ごとに「なぜその課題を優先したか」「別の方法は検討したか」「自分一人では決められなかった点は何か」を整理する必要があります。公式案内では選考途中に適性検査やリファレンスチェックを行う場合もあるため、職務経歴書の役割や在籍情報は事実に合わせます。

働き方は、出社中心、リモート中心、フルリモートの区分があり、部署・求人で同一ではありません。過去のリモート経験を強みとして書く場合は、勤務場所そのものより、非対面での情報共有、進捗確認、顧客対応の質を保った方法を示す形です。

• 応募職種と顧客区分が冒頭で分かる
• チーム成果と自分の行動を分けた
• 支援・制作・事務の対象を具体化した
• 個別求人の雇用条件を確認した
• 面接回数を固定情報として書いていない

職種一覧から応募先をさらに絞る

公式職種一覧には、営業、企画、IT／テクノロジー、マーケティング、クリエイティブ、コーポレート、管理職、アシスタントが示されています。同じ人材サービス企業への応募でも、顧客へ直接支援する仕事、サービスを企画・開発する仕事、組織を支える仕事では成果の届け先が同一ではありません。

職種群	最初に示す経験	避ける書き方
営業・CA	法人・個人の課題、提案・支援、結果	売上・決定数だけ
企画	事業課題、戦略、業務・機能の設計	資料作成だけ
IT／テクノロジー	利用者課題、設計判断、品質・運用	技術名だけ
マーケティング	対象、仮説、施策選択、事業への還元	媒体・施策名だけ
クリエイティブ	利用者理解、体験設計、検証	制作物の見た目だけ
コーポレート	経営・組織課題、制度・統制、定着	処理件数だけ
管理職	組織目標、配分、育成、成果	部下人数だけ
アシスタント	正確性、業務設計、改善、支援先の変化	依頼処理だけ

第一志望の職種を決めたら、個別求人でサービス、顧客、配属、主な責任、必須経験を確認する必要があります。職種紹介は仕事の全体像であり、個別求人の要件を置き換えるものではありません。

企画職向けは戦略から運用までを分ける

公式の企画職紹介は、事業企画・営業企画・その他企画を挙げ、事業成長を支える戦略、ビジネスプロセス、サービス・機能や仕組みの企画開発を示しています。職務経歴書では「企画を担当」とせず、何を決める企画だったかを明確にする必要があります。

• 対象事業・サービスと解くべき課題
• 課題を確認したデータ・顧客・現場の声
• 比較した戦略・業務・機能の選択肢
• 営業、開発、管理部門との合意
• 実装・運用まで担った範囲
• 結果と次に変更した判断

事業企画では事業全体の判断、営業企画では営業プロセスや現場実行、機能企画では利用者と開発の合意が中心になります。複数を担当した場合も一括りにせず、主要案件ごとに本人の権限と成果を分けるのが基本です。

企画書の提出や会議承認を最終成果にせず、運用開始後に誰の行動や判断が変わったかを確認します。導入後を担当していない場合は、引き継ぎ条件までを本人の成果として狭めてください。

IT／テクノロジー向けは利用者の仕事へ接続する

人材サービスのシステムでは、求職者、企業、営業・CA、社内運用など複数の利用者が関わります。技術職の案件は、使用言語やクラウドだけでなく、どの利用者のどの業務を対象に、何を設計・実装し、品質と運用をどう確認したかを書くのが基本です。

• 対象サービスと利用者
• 利用者が完了・判断できなかったこと
• 既存構成と変更時の制約
• 比較した設計案と採用理由
• 本人の実装・レビュー・運用範囲
• 公開後の品質・利用・業務の変化

社内システムと顧客向けサービスでは、成果の確認方法が同一ではありません。社内向けなら業務手順、入力品質、問い合わせ、処理の変化、顧客向けなら利用行動、完了、継続、品質など、自分が確認できる指標を選びます。

受託開発出身者は納品までの責任と、事業会社で求められる継続改善・運用の責任を分けるのが基本です。運用後の改善に関わった経験があれば、障害や要望を次の設計へどう反映したかを補う形です。

マーケティング向けは求職者・企業のどちらを動かしたかを書く

マーケティング経験は、広告、コンテンツ、CRM、イベントなどの施策名を並べるだけでは対象が分かりません。求職者の登録・利用を支えたのか、企業の採用活動やサービス理解を支えたのかを先に示し、顧客層ごとに仮説と成果を分けます。

• 対象顧客と検討段階
• 行動を妨げていた課題の根拠
• チャネルやメッセージの選択理由
• 営業・CA・企画・制作との連携
• 継続・停止・配分変更の基準
• 結果から次の施策へ反映した学び

獲得数だけを成果にすると、対象の質やその後の利用との関係が見えません。営業やCAへ渡した後の状態を確認できた場合は、その範囲まで書き、確認できない場合は獲得時点までに責任を狭めます。

コーポレート・管理職向けは組織の変化を示す

コーポレート職は、採用、人事、経理、法務などの業務名や処理量だけでなく、どの経営・事業課題を支えたかを示す形です。制度や統制を作った場合は、設計、事業部との調整、導入、運用、見直しのどこまで担ったかを明確にする必要があります。

管理職では、本人の専門業務と組織成果を分けるのが基本です。目標設定、業務配分、意思決定、育成、他部門との調整のうち何を担い、メンバーや組織の行動がどう変わったかを書きます。部下人数や会議回数だけでは管理責任を示せません。

制度を導入しただけで定着とせず、利用、問い合わせ、例外対応、現場の行動など本人が観測した結果を記載します。運用を他部署へ渡した場合は、引き継ぎ後の成果を自分だけの実績にしません。

主要案件を法人・個人・プロダクト・組織で選ぶ

パーソルキャリアの職種は成果の届け先が広いため、案件数を増やす前に、誰へ価値を届けた経験かを整理します。応募職種に直接対応する案件を中心にし、異なる成果先の経験は補助案件へ置くのが基本です。

成果先	主要案件で答える問い
法人	採用・組織課題をどう把握し、何へ合意したか
個人	意思決定をどう支え、本人の選択をどう尊重したか
プロダクト	利用者課題をどう設計・実装・検証へつないだか
組織	制度・業務・人の行動をどう変え、定着を確認したか

一つの案件で複数の成果先を扱った場合は、関係を説明しつつ本人の責任を分けるのが基本です。たとえば法人向け提案をプロダクト改善へ還元したなら、顧客から得た情報、企画部門へ渡した判断材料、改善後に確認できた結果を別々にします。

パーソルキャリアの職務経歴書でよくある質問

RAとCAへ同じ職務経歴書を使えますか？

職歴の事実は同じでも、RAは法人の採用課題と提案、CAは個人の意思決定支援を中心に、職務要約と案件順を変えるのが基本です。両方の経験がある場合も一案件内で混ぜず、対象と成果を分けるのが基本です。

選考回数は職務経歴書に影響しますか？

公式共通要項は面接回数に幅があり、職種・事業で変わると案内しています。回数を前提に書類を変えるのではなく、どの面接でも主要案件の役割と成果を一貫して説明できる状態にします。

複数サービスの経験がないと不利ですか？

応募可否は個別求人の必須要件で判断するのが適切です。サービス数を増やして見せるより、一つの顧客・利用者課題を深く理解し、判断から結果まで担った経験を具体化する必要があります。

成果数字を開示できない場合は？

確認できない数字を作らず、対象、期間、本人の判断、実施前後の状態を記載するのが適切です。割合を出す場合は分母、比較期間、確認元を説明できる範囲に限ります。

働き方と選考情報を職務経歴書へ混ぜない

公式共通募集要項は、求人ごとに異なる働き方のパターンを案内しています。希望する働き方は応募前に個別求人で確認し、職務経歴書の自己PRを「リモートでも働ける」といった環境適応だけにしません。離れた関係者と成果を出した経験がある場合は、情報共有、判断、支援の事実として案件内に書きます。

選考は書類後の面接回数に幅があり、職種・事業で変動し、適性検査やリファレンスチェックを行う場合があると案内されています。固定した選考順を想定せず、職務要約、案件詳細、面接で役割と成果の表現をそろえるのが基本です。

書類の数字を面接で再確認する

RA・CAの決定数、マーケティングの獲得、プロダクトの利用、アシスタントの処理や改善など、数字には対象期間、分母、集計元、本人の寄与を添えます。数字だけを覚えるのではなく、なぜ変化したと判断できるのかを説明できる状態にします。

法人・個人双方に関わった成果は、片方の数字だけで全体成功としません。企業が採用できたこと、個人が意思決定できたこと、サービスが利用されたことのうち、本人が確認した結果を分けます。

失敗・変更の説明を主要案件に加える

提案が採用されなかった、候補者の希望が変わった、機能が想定どおり使われなかった、業務改善が定着しなかった経験も、削る必要はありません。事前の仮説、確認した事実、変更した対応、残課題を示すと、状況に応じた判断が伝わります。

失敗を成功へ言い換えず、本人の責任範囲で得た学びを次の案件へどう反映したかを書くのが基本です。RAなら求人要件や提案、CAなら支援方針、企画・技術なら優先順位、アシスタントなら確認手順の変更へつなげられます。

主要案件を七つの問いで監査する

• 応募職種と対象サービスが決まっているか
• 法人・個人・利用者・社内組織の誰への成果か
• 課題を知ったデータや対話を示せるか
• 本人の判断とチーム・顧客の判断を分けられるか
• 比較案と支援・設計の理由を説明できるか
• 実行後の状態と残課題を確認できるか
• 数字の期間・対象・分母・確認元を説明できるか

RA、CA、クリエイティブ、アシスタント、企画、IT、マーケティング、コーポレートでは成果先が同一ではありません。応募職種へ直接対応する案件を中心にし、異なる顧客・利用者への経験は補助案件として位置づけます。

人材サービスの実績では、法人と個人双方の成果を一つにまとめがちです。本人が直接確認した結果と、他部門が担った結果を分けると、支援範囲を正確に示せます。

サービス名や職種名の知名度を借りず、自分が確認した課題、選んだ行動、結果を動詞で書くのが基本です。面接で説明できない責任や数字は削るか、実際に担った範囲まで狭めてください。

一ページ目で顧客と職種を伝える

一ページ目だけを読んでも、応募する職種・サービス、法人・個人・利用者・組織の誰へ成果を届けてきたか、本人が担った責任が分かるかを確認します。サービス名や職歴年数だけで要約を終えません。

RAなら法人の採用課題、CAなら個人の意思決定、クリエイティブなら利用者体験、アシスタントなら支援業務の正確性と改善を中心にします。企画・IT・マーケティング・コーポレートでは、それぞれ事業、プロダクト、顧客獲得、組織への成果を先に置くのが基本です。

案件欄に一ページ目の主張を裏づける事実がなければ、強みを言い換えるか案件を入れ替えるのが適切です。最後に、チーム・顧客の判断を本人の判断へ広げていないか、数字の期間と確認元を説明できるかを見直します。

まとめ

自分の実績は、確認できない数字や責任へ置き換えず、説明できる事実に限定するのが適切です。RAは法人課題、CAは個人の意思決定、クリエイティブは利用者体験、アシスタントは支援業務の正確性と改善を中心にします。

企画職では戦略・業務・機能のどこを担ったか、IT／テクノロジーでは利用者課題から運用までのどこを担ったかを示す形です。マーケティングとコーポレートも、施策・業務名より成果先と本人の判断を先に置きます。

選考回数や働き方は個別求人で変わるため、職務経歴書の実績へ混ぜません。どの選考段階でも主要案件の役割、数字、結果を同じ強さで説明できるかを確認します。

最後に、法人・個人・利用者・社内組織の誰への成果かを案件ごとに確認する必要があります。複数の成果先がある場合も、本人が直接確認した結果と他部門が担った結果を分けてください。

提出用PDFへ変換した後は、職種比較表と主要案件の折り返しを確認します。顧客、課題、本人の判断、結果がページをまたいで読みにくい場合は、サービス説明を減らし、応募職種に直接つながる責任を優先します。

ファイル名には応募職種と氏名を入れ、別職種向けの職務要約を取り違えないよう最終版を固定する形です。

最終確認では、個別求人の業務と主要案件を一つずつ照合します。RA、CA、企画、技術など職種名が近くても、法人・個人・利用者・組織の誰への成果かが違えば同じ経験とはいえません。

主要案件が同じ強みを繰り返している場合は、一方を入れ替えます。顧客支援と業務改善、企画判断と部門合意など、応募職種で異なる責任を示せる組み合わせにします。

顧客・候補者・サービスの情報を伏せる場合も、対象、課題、本人の判断、結果を公開可能な粒度で残す形です。守秘を守りながら、責任範囲まで曖昧にしないことが重要です。

パーソルキャリア向けの職務経歴書は、応募職種の顧客と成果責任に合わせて作ります。RAは企業の採用課題、CAは個人の意思決定、クリエイティブは利用者課題と検証、アシスタントは処理品質と業務改善を前に出すのが基本です。