データサイエンティストの職務経歴書・自己PRの書き方｜評価される実績とNG例

本記事のポイント

データサイエンティストの選考に出す書類では、SQL、Python、機械学習などの技術名を並べるだけでは評価が伝わりにくくなります。採用側が知りたいのは、どの事業課題を、どのデータで、どう分析し、どの意思決定や改善につなげたかです。応募前の方は、以下の観点で書類を見直してください。

確認項目	職務経歴書で見るポイント
評価される経験	課題定義、データ理解、分析設計、統計・機械学習、効果検証、実装・運用、関係者説明
成果指標	KPI改善、業務効率、モデル評価、データ品質、意思決定支援、運用改善など
弱く見える書き方	技術名だけ、分析テーマだけ、チーム成果だけ、面接で説明できない数値だけを書く
相談タイミング	応募先の募集要項との対応、面接深掘り、企業タイプ、年収交渉材料を提出前に確認したいとき

特にデータサイエンティストは、企業によって役割が大きく変わります。プロダクト改善型、AI・数理最適化型、事業会社DX型、マーケティング分析型では、同じ経験でも前面に出す実績が違います。応募先の募集要項から逆算して、見せる成果の順番を変えましょう。

本記事は、データサイエンティストの職務経歴書を「採用側の評価軸」から逆算して整理するための実務ガイドです。厚生労働省のjob tag、データサイエンティスト協会が示す3つのスキル領域、IPAのスキル標準、そして実際の公式募集要項を突き合わせると、評価のされ方には共通の型が見えてきます。読み進めながら、自分の経験をその型に沿って書き直す前提で確認してみてください。

なお、本文に出てくる例文や指標は、書き方の構造を示す汎用サンプルです。「需要予測で精度を改善」「継続率が向上」といった表現は、読者ご自身が実際に担当した範囲と数値に必ず置き換えてください。経験していない成果をサンプルのまま貼ると、面接の深掘りで説明が崩れます。逆に、地味でも自分が手を動かした範囲を正確に書いた方が、選考では一貫性が伝わりやすいでしょう。

データサイエンティストの職務経歴書で見られるポイント

厚生労働省のjob tagでは、データサイエンティストについて職業分類に対応する統計情報が示されています。ただし、同ページでは統計がその職業のみを表すものではないという注記もあります。職務経歴書では、職種名だけでなく、どの業界、どの事業、どのデータを扱ったかまで具体化しましょう。

データサイエンティスト協会やIPAの整理を見ると、評価軸はデータサイエンスだけに閉じません。課題定義、データ理解、データエンジニアリング、分析評価、価値創造までが関係します。そのため、職務経歴書では「モデルを作った」だけでなく、なぜ作り、どう使われ、何を改善したかまで書きましょう。

データサイエンティスト協会は、求められる力をビジネス力・データサイエンス力・データエンジニアリング力の3領域として整理しています。職務経歴書がツールの羅列で終わってしまうのは、このうちデータサイエンス力やデータエンジニアリング力（=手法やSQL・Python）だけを書き、ビジネス力（=どの事業課題に、どんな意思決定のために取り組んだか）が抜け落ちているケースが多いためです。採用担当が最初に探すのは、むしろこのビジネス力の証跡だと考えておくと外しにくくなります。

具体的な書き分けのコツは、1つのプロジェクト記述を「課題→データ→手法→検証→活用」の5要素に分解することです。たとえば「解約予測モデルを構築した」と一行で書く代わりに、(1)どの事業のどのKPIを動かすための分析だったか、(2)どんなデータをどう前処理したか、(3)なぜその手法を選び何と比較したか、(4)どの指標でどう評価したか、(5)結果が誰のどの判断に使われたか、を順に書きます。5要素のうち1つでも空欄になる経験は、面接で深掘りされたときに詰まりやすい箇所だと自覚しておくとよいでしょう。

もう一つ意識したいのが、職務要約（サマリー）の役割です。書類の冒頭3〜4行は、採用担当が全体を読むかどうかを判断する場所になります。ここに技術名を並べるより、どの業界・事業領域で、どんな課題を、どの評価軸で解いてきたかを1段落で示した方が、続きを読む動機につながります。「Python・SQL・機械学習が使えるデータサイエンティスト」ではなく、「EC事業の継続率改善を、行動ログ分析とA/Bテスト設計を軸に担当」のように、扱った領域と貢献の型が伝わる要約を先頭に置きましょう。

評価軸	職務経歴書に書くこと	弱い書き方
事業課題	対象事業、KPI、課題の背景、優先した理由	データ分析を担当
データ理解	データの定義、粒度、欠損、前処理、品質課題	SQLで抽出
分析設計	仮説、比較対象、評価指標、手法選定の理由	機械学習を実施
効果検証	検証設計、結果の解釈、施策や改善への接続	精度を改善
実装・運用	パイプライン、監視、再学習、運用改善、利用部門	モデルを構築
関係者説明	事業部門、開発、経営、顧客へどう説明したか	レポートを作成

経歴別に強調すべき実績

データサイエンティストの職務経歴書は、現在の経歴によって見せ方を変えます。経験者は課題設定から成果までの再現性、データ分析やBIの経験者は意思決定への接続、MLエンジニアはモデル運用と事業課題、データエンジニアは基盤が分析や意思決定をどう変えたかを前面に出します。

現在の経歴	強調すべき実績	弱く見えやすい書き方	補うべき情報
データサイエンティスト経験者	課題定義、分析設計、モデル評価、意思決定支援、運用改善	担当案件名だけを並べる	自分の役割、成果、再現性
データ分析 / BI	SQL、可視化、KPI設計、施策効果の分析	集計・ダッシュボード作成で止まる	分析後に何が変わったか
MLエンジニア	モデル設計、評価指標、実装、運用、品質改善	モデル名や精度だけを強調する	事業課題との接続、利用者、運用制約
データエンジニア	データ基盤、品質改善、パイプライン、利用部門支援	基盤構築だけに見える	分析や意思決定への貢献
ITコンサル / 事業企画	業務課題、要件定義、KPI、関係者調整	企画や調整だけで分析実装が弱い	自分で扱ったデータ、手法、検証
完全未経験	業務改善、データ活用、学習、分析補助の接点	意欲や資格だけを書く	実務データに触れた証拠と入口職種

経歴別の見せ方で共通する原則は、「自分の現職で一番強い1点を先頭に置く」ことです。データサイエンティスト経験者なら課題設定から運用までの再現性、BI・分析経験者なら意思決定への接続力、MLエンジニアならモデルを事業に乗せた運用力、というように、書類の各プロジェクト記述の冒頭一文で「何の専門家か」が伝わるようにします。応募先がプロダクト改善型かAI企業かによって、どの強みを先頭に出すかも入れ替えてください。

逆に注意したいのは、複数の役割を横断してきた人が「何でもできる」と書こうとして、どの軸も浅く見えてしまうケースです。分析・基盤・企画を経験している場合でも、応募職種に最も効く軸を主役にし、残りは「その軸を支えた経験」として従属させると、強みがぼやけません。職務経歴書は経歴の網羅資料ではなく、応募職種への適性を示す資料だと割り切るのがコツです。

完全未経験の場合は、上位求人にそのまま応募できるように見せるより、隣接経験をどう作るかまで整理した方が現実的です。分析補助、BI、データ基盤、業務改善、事業企画などの経験を、データサイエンティストの評価観点に合わせて整理しましょう。

書類選考で落ちやすい書き方

書類選考で弱く見える職務経歴書には、技術名が多いのに課題が見えない、分析結果が施策や意思決定につながっていない、成果がチーム全体なのか自分の担当なのか分からない、という共通点があります。データサイエンティストでは、分析の正しさだけでなく、使われる形にした経験が見られます。

Before	After
Pythonを用いて需要予測モデルを構築	対象事業の需要変動課題に対し、利用データ、前処理、比較した手法、評価指標、業務側への説明、導入後の改善を分けて記載する。数値は読者自身の実績に置き換える。
SQLでデータ抽出と可視化を担当	誰の意思決定を支援するために、どの指標を定義し、どの粒度で集計し、可視化後にどの施策や判断へ使われたかを書く。
A/Bテストを実施	仮説、対象ユーザー、比較条件、評価指標、解釈、次の改善方針を記載し、テスト実施だけで終わらせない。
データ基盤を改善	データ品質、処理時間、利用部門、分析速度、運用負荷など、自分が改善した範囲と利用者への影響を示す。

落ちやすい書き方には、もう少し細かいパターンもあります。よく見られるのが、手法名を成果のように書くクセです。「XGBoostを用いた」「BERTで分類した」という記述は手段の説明であって成果ではありません。採用側が知りたいのは、その手法で何が良くなったか、なぜ別の手法ではなかったかです。手法名は1行に収め、その分の行数を課題と結果の説明に回した方が、限られた書類スペースを有効に使えます。

次に多いのが、数値の使い方に関する弱点です。「精度を大幅に改善」「売上に貢献」といった形容詞だけの成果は、検証できないため評価につながりにくくなります。一方で、根拠を説明できない数値を盛るのも逆効果です。数値を書くときは、それが「自分の担当範囲で・どの指標を・どの期間で動かしたか」を面接で言える範囲に限定しましょう。チーム全体の成果を個人の成果のように書くと、面接で役割を聞かれた瞬間に矛盾が出ます。

分量配分の失敗も見落としがちです。直近のプロジェクトを薄く、数年前の研究や学習を厚く書いてしまうと、現在の実力が伝わりません。書類の8割は直近2〜3年の実務に割き、応募職種に効く経験ほど行数を増やすのが基本です。古い経験や学習歴は、応募職種に直結する場合だけ簡潔に残しましょう。

Afterの文章は、そのまま実績として貼るものではありません。職務経歴書では、自分が担当していない範囲まで書くと面接で説明が崩れます。担当範囲、判断した内容、成果指標を自分の実績に合わせて置き換えてください。

各社の募集要項から逆算する成果指標

データサイエンティストの職務経歴書は、各社の募集要項から逆算して作ると精度が上がります。LINE Digital Frontierは事業課題分析、KPI設計、効果検証、SQL、BI、統計を示しています。グリッドはAI・数理最適化と顧客課題理解、カカクコムは課題特定からMLモデル構築、カウシェはA/BテストやML基盤、インテージグループはモデル開発・運用までの技術責任。求める軸は各社で異なります。

募集要項で求められる経験	職務経歴書で書く項目	成果指標	弱い表現	改善方向
事業課題分析・KPI設計	対象事業、課題、KPI、仮説、関係者	意思決定、施策化、利用率、継続率、業務効率	分析を担当	誰のどの判断を支援したかを書く
SQL・BI・可視化	指標定義、データ抽出、粒度、ダッシュボード、利用部門	可視化後の意思決定、更新工数、利用定着	SQLが使える	データ定義と利用場面を示す
統計解析・A/Bテスト	仮説、比較条件、評価指標、解釈、次の施策	検証結果、施策判断、改善サイクル	テストを実施	設計と解釈まで書く
機械学習・数理最適化	モデル目的、特徴量、評価指標、比較手法、制約	予測精度、業務適用、運用改善、制約下での最適化	モデルを構築	なぜその手法を選んだかを書く
ML基盤・運用	パイプライン、監視、再学習、品質、障害対応	安定運用、処理時間、再現性、利用部門の負荷軽減	基盤を整備	運用後の変化まで示す
技術責任・育成	品質基準、レビュー、技術選定、メンバー支援	品質、標準化、技術負債解消、チーム生産性	リード経験あり	責任範囲と判断基準を書く

逆算の実務手順は単純です。まず応募予定の募集要項の「必須要件」と「歓迎要件」を書き出し、それぞれに対して自分の職務経歴書に対応する記述があるかを照合します。必須要件に対応する実績が書類の上部に出ているか、歓迎要件のうち満たせるものが具体例とともに書かれているかを確認すると、応募先ごとに直すべき箇所が見えてきます。要件すべてを満たす必要はなく、必須の中核を押さえ、歓迎要件で差別化できれば書類選考を通過しやすくなります。

注意したいのは、募集要項の文言が同じ「機械学習」でも、企業によって期待値が違うことです。研究色の強い企業では手法の理解の深さ、事業会社では実装して運用に乗せた経験、コンサル型では顧客に説明して意思決定を動かした経験、というように重心が変わります。同じ実績でも、応募先がどの重心かを読み取ってから、前面に出す一文を書き換えると効果的です。求人を実際に見比べると、この重心の差は要件文の語彙から読み取れます。

企業タイプ別の見せ方

データサイエンティストは、企業タイプによって評価される経験が変わります。プロダクト改善型で伝えたいのはKPI、A/Bテスト、UI/UX改善、レコメンド。AI・数理最適化型ではモデル設計や制約条件、事業会社DX型では業務理解やデータ品質、マーケティング分析型では顧客理解と施策化が前面に出る実績です。

企業タイプ	前面に出す実績	整理しやすい観点	注意点
Webサービス / SaaS	KPI、ユーザー行動、A/Bテスト、施策効果	分析結果がプロダクト改善に使われたか	ダッシュボード作成だけにしない
AI / 数理最適化企業	モデル設計、評価指標、制約条件、実装、運用	技術が顧客課題をどう解いたか	研究テーマだけに寄せすぎない
事業会社DX	業務データ、部門横断、基盤、ガバナンス、定着	現場で使われる形にした経験	社内調整だけに見せない
マーケティング / リサーチ	顧客理解、広告効果、需要予測、生活者分析	分析結果を施策へつなげた経験	レポート提出で止めない
コンサル型	顧客ヒアリング、要件定義、分析設計、説明	手を動かした分析と提案の両方	資料作成だけに見せない

企業タイプ別に見せ方を変えるとき、書類そのものを毎回ゼロから作り直す必要はありません。職務要約の一文と、各プロジェクトの先頭一文を応募先に合わせて差し替えるだけでも、伝わり方は大きく変わります。たとえば同じレコメンド改善の経験でも、Webサービス企業向けにはKPIとA/Bテストを、AI企業向けにはモデル設計と評価指標を先頭に置くと、求める軸に直接刺さります。本体の事実は変えず、強調順だけを入れ替えるのが安全なやり方です。

企業タイプを見極めるときは、求人票の「業務内容」だけでなく「選考フロー」も手がかりになります。課題選考やコーディングテストがある企業は実装力を、ケース面接やプレゼンを課す企業はビジネス力と説明力を重視している、と読み替えられます。選考形式から逆算するのが要点です。選考形式から逆算して、書類のどの実績を厚くするかを決めると、書類と面接の準備を一貫させやすくなります。

SaaSやWebサービス企業を検討する場合は、企業研究も合わせて進めると書類の調整がしやすくなります。たとえば、データサイエンティストの年収相場やIT企業の比較・ランキングは、企業タイプや報酬水準を比較する材料になるでしょう。

未経験・隣接経験者の補強方法

未経験・隣接経験者は、「データサイエンティストになりたい」という意欲だけでは弱く見えます。各社の募集要項では、SQL、BI、統計、Python/R、機械学習、A/Bテスト、関係者連携、意思決定支援などが求められます。職務経歴書では、すでに持っている経験をデータ職の評価観点に合わせて整理することが必要です。

経験タイプ	補強する見せ方	職務経歴書で使う表現
完全未経験	学習だけでなく、業務改善やデータ活用の実務接点を作る	実務で扱ったデータ、改善テーマ、学習成果を分けて記載
BI / 分析補助	集計や可視化を、意思決定や施策改善へ接続する	KPI定義、可視化、利用部門、改善後の変化を書く
エンジニア	データ処理、品質、基盤、ML実装への接点を示す	実装範囲だけでなく、分析者や事業側への価値を書く
事業企画 / マーケティング	KPI、顧客理解、施策検証、仮説構築を示す	SQLや統計の深さが弱い場合は補強計画も書く
ITコンサル	業務課題、要件定義、関係者調整、データ活用支援を示す	提案だけでなく、自分で扱ったデータや検証を書く

未経験・隣接からの応募で効くのは、「実務でデータに触れた証跡」を具体的に書くことです。学習歴や資格だけでは、業務でデータを扱える人かどうかが判断できません。現職で売上やユーザーの数字を見て施策を決めた経験、Excelやスプレッドシートで集計・分析した経験、社内のダッシュボードを設計・改善した経験などは、すべてデータ職の入口として翻訳できます。「分析が好き」ではなく「業務でこのデータをこう使った」と書けるかどうかが分岐点です。

スキルの証明方法も補強材料になります。データサイエンティスト協会のDS検定や、日本統計学会の統計検定のような公開された検定は、独学でも統計やデータサイエンスの基礎を体系的に学んだことを客観的に示せます。ただし資格は実務経験の代わりにはならないため、「資格で基礎を固めつつ、現職でこの分析を実践した」という形で、学習と実務をセットで見せるのが現実的です。なお、合格率や難易度はここでは断定しません。詳細は各検定の公式情報で確認してください。

もう一つ大事なのは、足りない経験を隠さず、補う計画を添えることです。SQLや機械学習の実務が浅い場合でも、「現職で扱えるデータでこういう分析を進めている」「この領域はこう学習している」と書けば、伸びしろとして評価されることがあります。完璧に見せようとして経験を盛るより、現在地と次の一手を正直に書く方が、面接での会話が噛み合いやすくなります。

隣接経験者は、できないことを隠すより、応募先の募集要項との差分を整理した方が面接で説明しやすくなります。SQLや統計の実務が浅いなら、どの業務でデータに触れ、どの範囲を自分で分析し、どこからチームで補ったのかを明確にしましょう。

面接で深掘りされる表現

職務経歴書は、書類選考だけでなく面接の質問材料になります。LINE Digital Frontierでは書類選考後に課題選考と面接が示され、グリッドではプログラミングテストが公開されています。つまり、職務経歴書に書いた技術や成果は、面接や課題で説明できる粒度まで整理しておきましょう。

職務経歴書の表現	面接で深掘りされること	準備する内容
精度を改善した	評価指標、比較手法、データ分割、過学習対策、事業上の意味	モデル比較表、評価指標、改善前後の説明
事業貢献した	どのKPIに、どの施策を通じて、どの範囲で関与したか	KPIツリー、施策メモ、担当範囲
AIを活用した	なぜAIが必要だったか、代替案は何か、運用リスクをどう見たか	手法選定理由、制約条件、運用設計
データ基盤を整備した	データ品質、利用者、処理、監視、運用後の変化	データフロー、品質課題、利用部門の反応
関係者を巻き込んだ	誰と何を合意し、対立や制約をどう整理したか	関係者整理、意思決定ログ、説明資料

面接の深掘りに備えるには、職務経歴書に書いた各実績について「なぜそうしたか」を一段深く言える状態にしておくと安心です。手法を選んだ理由、別の選択肢を捨てた理由、うまくいかなかった点とその対処、もう一度やるなら変える点。これらは書類には書ききれませんが、面接で必ず問われる領域です。書類は要点、面接はその裏側、という役割分担を意識して準備しましょう。

データサイエンティストの選考では、技術面接やコーディングテストに加えて、過去プロジェクトを題材にした深掘り質問が多くなります。実際、公式の募集要項でも書類選考のあとに課題選考やプログラミングテストを設ける例が見られます。だからこそ、職務経歴書には「面接で語れる解像度」で書いた実績だけを載せるのが安全です。盛った成果は、深掘りされた瞬間に逆効果になります。

特に避けたいのは、職務経歴書では強く見えるのに、面接で説明すると曖昧になる表現です。自分の担当範囲、判断した内容、使ったデータ、結果の限界まで説明できる表現に直すと、書類と面接のズレを減らせます。

年収交渉につながる実績の書き方

本記事ではデータサイエンティストの年収水準を詳しく扱いません。ただし、職務経歴書の書き方は年収交渉にも影響します。年収交渉で見られるのは、技術名の多さではなく、任された範囲、意思決定への関与、成果の再現性、技術責任です。

交渉材料	職務経歴書での見せ方	注意点
担当範囲	分析のみか、課題設定、実装、運用、説明まで担ったかを明示する	チーム成果を自分だけの成果にしない
意思決定	手法選定、指標設計、施策判断、技術選定への関与を書く	「提案した」だけで終えない
成果	読者自身の実績に基づき、改善指標、利用部門、運用後の変化を示す	出典や説明がない数値を置かない
再現性	別の事業・企業でも使える進め方、判断基準、改善サイクルを整理する	一度きりの偶然に見せない
技術責任	品質基準、レビュー、運用設計、育成、技術負債への対応を書く	肩書だけで伝えない

年収交渉の場面で評価が分かれるのは、「任された範囲の広さ」です。分析だけを担当したのか、課題設定・実装・運用・関係者への説明まで一気通貫で担ったのかで、提示されるオファーの水準は変わりやすくなります。職務経歴書の段階で、自分がどこまで一人で進め、どこからチームで分担したかを正確に書いておくと、面接や条件交渉でも一貫した説明ができます。

なお、データサイエンティストの賃金水準は、企業規模・経験年数・役割によって幅があります。厚生労働省の賃金構造基本統計調査のような公的統計も、職種や属性ごとに分布を示すものであり、「この職種の平均はいくら」と一律に断定できるものではありません。交渉に臨む際は、特定の数字に固執するより、自分の実績で説明できる根拠を揃える方が建設的です。具体的な企業別の水準は、応募先の求人や個別の情報で確認してください。

年収交渉を意識する場合も、誇張は逆効果です。面接では「なぜその成果が出たのか」「同じことを別企業でも再現できるか」が問われます。職務経歴書では、成果の大きさだけでなく、成果が出た理由と自分の役割を説明できる形にしましょう。

データサイエンティストの職務経歴書を相談すべきケース

データサイエンティストの職務経歴書を相談すべきなのは、書き方に自信がない時だけではありません。応募先によって、プロダクト改善、AI・数理最適化、データ基盤、マーケティング、DX支援など評価される実績が変わります。応募前に、どの実績を先頭に置くかを整理しておきましょう。

1. SQL、Python、機械学習などの技術名が多く、事業成果が伝わらない
2. データ分析、BI、ML、データ基盤のどれを強みにすべきか迷っている
3. 応募先の募集要項に対して足りない経験をどう補うか整理したい
4. 面接で深掘りされる成果や数値の説明を準備したい
5. 年収交渉に使える実績と、書かない方がよい実績を分けたい

リメディでは、IT・SaaS・データ領域への転職を検討する方に向けて、求人票の読み解き、職務経歴書の整理、面接で伝える成果の設計まで一貫して支援しています。データサイエンティストへの転職を考えている方は、応募前に一度、自分の経験がどの企業タイプの評価軸に接続しやすいかを整理してみてください。