キャリアメディア / 職務経歴書

データアナリストの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：データアナリスト ｜更新日 2026/7/4

データアナリストの職務経歴書は、「何を分析したか」よりも「分析によって何が変わったか」を伝えるドキュメントです。採用担当者や現場マネージャーが知りたいのは、ツールの習熟度や分析手法の列挙ではなく、ビジネス課題の文脈でその人のスキルがどう機能したかという一点に集約されます。本記事では、書類通過率を高めるための構造的な考え方から、具体的な記述の型、よくある落とし穴まで、実務視点で解説します。

データアナリストの職務経歴書が一般職と異なる理由

職務経歴書の基本的な原則は職種を問わず共通していますが、データアナリストには特有の課題があります。

第一に、スキルの証明が難しいという点です。エンジニアであればGitHub上のコードが一定の証拠になりますが、アナリストの成果は多くの場合、社内ダッシュボードや機密性の高いレポートに埋め込まれています。職務経歴書の文章だけで、「課題設定→分析設計→実行→意思決定への貢献」というプロセスを可視化する必要があります。

第二に、ツール・スキルの多様性と陳腐化速度が速いという点です。SQL、Python、BIツール、統計手法、機械学習の基礎知識など、記載すべき要素が多岐にわたる一方で、採用側が本当に評価したいのは「そのスキルを使ってどんな判断を引き出したか」という文脈です。スキルの羅列だけでは評価の粒度が粗くなりがちです。

第三に、ポジションによってアナリストに求める役割が大きく異なります。事業会社のインハウスアナリストとコンサルティングファームのアナリストでは、期待されるアウトプットや関係者との関わり方が異なります。職務経歴書はその差異を踏まえて書き分けることが求められます。

構成の全体像：5ブロック設計

職務経歴書は以下の5ブロックで構成するのが一つの基準です。

特にデータアナリストの場合、③と④を分離することを推奨します。社歴ベースの職務経歴だけでは、どの案件が最も貢献度が高かったかが伝わりにくい傾向があるためです。「プロジェクト詳細」を独立ブロックとして設けることで、自分が最も評価されたい実績をハイライトできます。

「成果の書き方」：数字の使い方と文脈設計

職務経歴書における最も一般的な改善余地は、成果の記述粒度にあります。典型的な失敗パターンと改善例を見てみましょう。

典型的な失敗パターン

「SQLとPythonを用いて売上データの分析を実施。ダッシュボードを作成しレポーティングした。」

この記述では、何のために分析したのか、誰が何を決めたのか、どんな変化が生まれたのかが一切見えません。採用担当者は「この人が自社に来ても同じような作業をするのだろうか」という印象を持ちやすくなります。

改善後の記述例

「EC事業部の購買行動分析を担当。既存顧客の継続購入率低下という課題に対し、RFM分析とコホート分析を組み合わせ、離脱リスクの高いセグメントを特定した。施策立案チームへの分析結果の提供を通じて、対象セグメントへのリテンション施策を設計するインプットを提供。施策実施後3か月で対象セグメントの購入頻度が改善傾向に転じたことを確認。」

この記述には「課題の文脈」「分析アプローチの選択理由」「アウトプットの使われ方」「結果の確認」という4要素が含まれています。全案件でここまで書く必要はありませんが、代表的なプロジェクトについては、このレベルの解像度を目指すことが書類通過率に直結する傾向があります。

数字の扱い方の原則

数字は「変化量」または「規模感」のどちらかで使うのが適切です。

• 変化量の例：「対象施策の購入転換率が施策前比で約15ポイント改善」「分析レポートの作成時間を週8時間から2時間に短縮」
• 規模感の例：「月次ユーザー数100万超のサービスを担当」「数十億円規模の商品ラインを対象に分析」

なお、機密情報に該当する具体的な売上額や顧客数をそのまま記載することは企業の情報管理規定上問題になるケースがあります。規模感を「数十億規模」「約〇万件のトランザクションデータ」のように表現する書き方は、採用側も理解している慣行です。

スキル一覧の書き方：「できる」の粒度を揃える

スキル一覧は、カテゴリ別に整理し、習熟度を端的に示すのが基本です。以下は記載の型の一例です。

「使用経験あり」と「業務で日常的に使用」は意味が大きく異なります。採用側が最も確認したいのは、業務上の判断を支えられる水準かどうかです。習熟度の表現は正確に書くことが、後の面接での信頼性にも影響します。

ケーススタディ：転職背景別の書き方の変え方

ケースA：事業会社内でのキャリアアップ転職（アナリスト→シニアアナリスト・マネージャー）

強調すべきは「課題の複雑さ」と「関係者を巻き込んだ経験」です。分析の技術的な側面よりも、事業インパクトとリーダーシップの萌芽を前面に出します。職務要約には「ビジネス課題の構造化と分析設計を主導」「経営層・事業責任者への報告経験」といった記述が有効です。

ケースB：コンサル・SIerからのインハウス転職

コンサル出身者はプロジェクト型の経歴が多いため、「社内横断的な業務経験が少ない」と誤解されやすい傾向があります。職務経歴書では、複数クライアント・複数業界への対応経験と、ゼロからの課題設定能力を強調します。また、インハウスアナリストの役割に対する理解（施策実行まで関与したい、プロダクトデータに向き合いたい等）を職務要約で自然に示せると評価されやすくなります。

ケースC：エンジニア・データエンジニアからの転向

技術的な素地は強みになる一方で、「ビジネス文脈を読む力があるか」という点が問われます。職務経歴書では、データパイプライン構築やインフラ側の業務に加えて、分析やレポーティングに関わった経験を意識的に拾い上げます。たとえ業務の主軸でなかったとしても、「利用部門のKPI設計に関与した」「分析要件の定義を担った」といった記述が、ビジネス視点を持つアナリスト像の裏付けになります。

よくある質問

Q. 在職期間が短い職歴がある場合、どう記載すべきですか？

短期在籍を意図的に隠す必要はありませんが、書類上で過度に目立たせる必要もありません。担当業務と成果を簡潔に記載した上で、面接での補足説明を準備しておくことが実際的な対応です。理由が明確であれば（プロジェクト終了・会社都合・明確なキャリア上の意思決定）、面接の場で説明する方が誠実な印象を与える場合が多い傾向にあります。

Q. データ分析の成果が定量化しにくい業務の場合、どう書けばよいですか？

すべての成果を数値化する必要はありません。「〇〇の意思決定に分析インプットを提供し、施策が実行された」「レポートの定期配信によって、週次レビュー会議の質が向上した」のように、プロセスへの貢献や仕組みの変化を言語化する方向で記述できます。重要なのは「自分がいなければ何が変わっていたか」を示唆できるかどうかです。

Q. SQLやPythonのレベルをどこまで詳しく書くべきですか？

職務経歴書の段階では、「業務で使用している」「自律的に書ける」「レビューを受けながら使用できる」程度の粒度で十分です。詳細な技術スタックの確認は面接やスキルチェックの場で行われる傾向があるため、書類では「対応できる業務の範囲が伝わる表現」を優先させます。

Q. 職務経歴書の分量の目安はありますか？

A4用紙で2〜3枚が標準的な範囲です。経験年数が3年未満であれば2枚以内、5年以上であれば3枚程度でまとめるのが一つの目安です。分量より密度を優先し、読み手の時間コストを意識した構成にすることが、書類としての質につながります。

まとめ

データアナリストの職務経歴書は、スキルの列挙ではなく「ビジネス文脈の中でどう機能したか」を可視化するドキュメントです。課題・アプローチ・インパクトという構造を意識した成果記述と、習熟度を正確に伝えるスキル一覧の組み合わせが、書類通過率の改善に直結しやすい傾向があります。転職背景によって強調すべき要素は異なるため、応募先の求める役割に合わせた書き分けが重要です。一般的な改善ポイントは共通していても、実際の職歴を踏まえた構成の最適化は個別の判断が必要です。自身の市場価値や職務経歴書の方向性に迷いがある場合は、専門領域に精通したキャリアアドバイザーへの相談が、具体的な指針を得る近道になるでしょう。