データアナリストの職務経歴書の書き方｜事業判断につながる実績・改善例を解説

SQL、Python、BIを使った案件でも、採用側が知りたいのは分析がどの事業判断に使われたかです。プロダクト分析、マーケティング分析、BI、事業企画に近い経験を主な対象とし、機械学習モデルの開発・運用を主責任とするデータサイエンティストとは分けて解説します。

本記事のポイント

職務経歴書の案件欄は、「誰のどの判断を変えるために、何を定義し、分析し、どの行動へつなげたか」の順で書きます。分析手法の難しさより、事業課題を測定可能な問いへ変えた過程と、結果が利用された証拠を先に見せるのが要点です。

確認項目	職務経歴書に残す内容	提出前の判断
事業課題	意思決定者、困っていたこと、優先したKPI	分析テーマではなく、決めるべきことから始まっているか
データと分析	定義、粒度、除外条件、仮説、比較、手法選択	ツール名だけで終わっていないか
判断と実装	提示した選択肢、採用された施策、担当範囲	分析結果の提出後に何が起きたか
利用定着	利用部署、会議・業務への組み込み、更新責任	作って終わりではなく、使われ方を説明できるか
成果検証	観測期間、変化、他要因、次の判断	チーム成果を個人の成果にしていないか

最初に、担当案件ごとに「課題設定→データ定義→分析設計→判断→実装→定着→検証」の7点を一行ずつ棚卸ししてください。空欄になる工程があれば、経験がないのか、書類に書き落としているのかを分けると、応募先とのギャップを判断しやすくなります。

職務要約は分析対象と判断相手を先に書く

職務要約の冒頭では、経験年数やツールの一覧より、どの事業領域で誰の判断を支えてきたかを先に示します。たとえば、プロダクト責任者の機能改善、営業責任者の案件優先順位、マーケティング担当者の施策配分では、同じSQL分析でも求められる速さ、粒度、説明の仕方が異なるためです。

続けて、扱ったデータ、得意な分析工程、判断後の関与範囲を一つずつ置きます。「会員行動ログと契約データを用いたKPI設計・施策検証を担当し、プロダクト部門の定例会議で改善案の採否まで支援」のように、対象、行動、利用場面をつなぐ構造です。実際の数値や固有名詞は、守秘義務と社内規定に沿って記載してください。

職務要約の要素	確認する内容	避けたい書き方
分析対象	顧客、商品、プロダクト行動、営業活動、業務工程	各種データを分析
判断相手	事業責任者、PdM、営業企画、マーケティング、現場部門	関係者へ報告
担当工程	課題設定、抽出、検証、提案、実装支援、効果確認	分析業務全般
利用場面	施策会議、KPIレビュー、業務改善、プロダクト開発	意思決定に貢献

案件欄はデータの定義と品質まで残す

分析結果の信頼性は、手法だけでなく元データの定義で決まります。案件欄には、分析対象の粒度、期間、除外条件、結合したデータ、欠損や重複への対応を、判断に影響した範囲で書きます。SQL文の複雑さを説明するのではなく、数字の意味をそろえるために何を確認したかを示すのが目的です。

KPIの名称が同じでも、受注日と契約開始日、アクティブユーザーの期間、解約の判定時点が違えば結果は変わります。営業企画と受注定義を合わせた、プロダクト部門と利用イベントを決めた、基盤担当と更新遅延の許容範囲を定めた、といった合意の相手と論点は職務上の証拠です。

タイミーの募集要項は事業課題の解決にSQLを使う経験を、カプコンは分析基盤の要件定義や品質管理を職務に含めています。GA technologiesも事業部へのヒアリングからKPI定義、改善提案、効果検証までを挙げており、抽出から判断までの間を分断せず書く根拠になります。

技術スキル欄は使用場面と自立度を添える

技術スキル欄には、SQL、Python、R、BI、データウェアハウスなどを羅列せず、何に使い、どこまで自分で進められるかを添えます。同じSQLでも、既存クエリの修正、複数テーブルの集計設計、データマートの要件整理では責任が異なるからです。

技術領域	使用場面	自立度を示す項目	案件欄との接続
SQL	抽出、集計、データ品質確認	要件整理から検算まで、レビューを受けて実装など	どの判断に必要なデータを整えたか
Python・R	統計解析、前処理、可視化、自動化	手法選択、実装、結果の解釈の担当範囲	比較設計と結果の限界をどう扱ったか
BI	KPI監視、探索、定例会議	要件、権限、更新、利用教育の範囲	誰がどの頻度で判断に使ったか
データ基盤	データマート、品質、定義管理	分析側と基盤側の分業	分析の速度や再利用性がどう変わったか

GA technologiesの募集要項は、事業部へのヒアリングからKPIを定義し、改善策の提案と効果検証まで主導した経験を挙げています。GOの募集要項では、データエンジニアとの分業のもと、企画・設計から効果分析までを担当します。応募先が重視するのが分析実装、事業提案、基盤との連携のどこかを見極め、該当する案件の具体例を技術欄の直後に置いてください。

データアナリストの職務経歴書で見られるポイント

企業の募集要項を横断すると、データアナリストの役割は集計や可視化に閉じていません。タイミーは目的から逆算した課題設定から意思決定まで、カプコンは分析プランニングに加えてデータ品質や社内展開、GA technologiesはKPI定義から改善策の効果検証まで、レバレジーズは他職種と進める改善提案を挙げています。

したがって、採用側へ示すべきなのは「分析できる人」という抽象像ではありません。曖昧な依頼を分析可能な問いに変え、データの意味を合意し、判断できる形にした経験です。次の表で、案件欄に必要な証拠を確認しましょう。

評価軸	書くべき証拠	弱く見える記載
課題設定	依頼者、意思決定、事業上の制約、優先順位	売上分析を担当
KPI・データ定義	指標の定義、粒度、対象・除外条件、合意した部署	データを抽出
分析設計	仮説、比較対象、手法を選んだ理由、限界	Pythonで分析
意思決定支援	提示した選択肢、推奨、採用・見送りの判断	示唆を報告
実装・利用定着	施策、ダッシュボード、定例運用、教育、更新体制	BIを作成
検証	観測指標、期間、変化、他要因、次の打ち手	KPI改善に貢献

成果の帰属も明確にします。自分が設計から検証まで主担当だったのか、分析が他部署の判断に使われたのか、抽出・可視化で判断を支援したのかを分けてください。「売上を改善した」より「分析結果を根拠に営業企画が施策を採用し、自分は検証設計まで担当した」の方が、責任範囲を面接で説明可能です。

経歴別に強調すべき実績

同じデータアナリスト求人でも、現在の経歴によって先頭に置く実績は変わります。リメディの見解では、応募先との距離を職種名より、課題設定・分析・判断接続のどこまでを実務で担ったかで見る方が明確です。

現在の経歴	先頭に置く実績	不足しやすい証拠	補強方法
現役データアナリスト	事業課題から施策・検証までを担った案件	ダッシュボード後の利用と判断	利用部署、会議、施策採用、継続観測を書く
BI・レポーティング	KPI定義、集計ロジック、更新運用の標準化	仮説設定と改善提案	依頼を受ける前後で何を提案したかを加える
マーケティング・CRM	顧客定義、セグメント、施策検証、次の打ち手	データ品質と再現可能な抽出	SQLの範囲、対象条件、比較設計を明示する
事業企画・経営企画	KPI設計、意思決定者との合意、事業判断	自分でデータを扱った範囲	抽出・検証を自分と他者の担当に分ける
エンジニア・データ基盤	品質やデータマートが分析利用をどう変えたか	事業仮説と施策への接続	利用者、判断、手戻りの変化まで書く

肩書がデータアナリストでなくても、事業課題を指標へ変え、データで選択肢を比較し、関係者の判断を支えた経験は記載対象です。一方、分析実務がない場合は、学習成果を実務経験のように見せず、現職でのデータ活用と自主学習を別欄に分ける必要があります。

書類選考で伝わりにくい書き方と改善例

職務経歴書が弱く見える原因は、成果が小さいことより、課題・行動・判断の関係が読めないことです。以下の改善例は文章構造を示すもので、数値や事実は必ず自分の実績へ置き換えてください。

改善例1：ダッシュボード作成で止めない

Before：SQLとTableauを用いて営業ダッシュボードを作成。

Afterの構造：営業責任者が週次で判断したかった論点を示し、受注段階・顧客属性・除外条件を営業企画と合意したことを書く。さらに、どの会議で使われ、どの施策判断につながり、自分が更新運用のどこまで担ったかを続けます。

改善例2：「分析して提案」を分解する

Before：ユーザー行動を分析し、改善施策を提案。

Afterの構造：対象ユーザー、離脱地点、比較した行動、仮説、追加で確認した定性情報を示す。そのうえで、提示した選択肢、採用された施策、観測した指標を分けます。施策実装が他部署なら、自分は分析設計と効果検証を担当したと境界を置きます。

改善例3：「KPI改善に貢献」を検証可能にする

Before：データ分析により主要KPIの改善に貢献。

Afterの構造：KPIの定義、観測期間、比較条件、同時期の他施策、自分の担当を示す。数値を開示できない場合は、「継続・見送りの判断に採用された」「定例会議の共通指標になった」など、確認できる利用事実へ置き換えます。

成果数値は計測条件と担当範囲をセットにする

改善率や削減時間を書く場合は、数値だけを強調せず、対象、期間、比較基準、同時期の変更、自分の担当を続けます。「継続率が上昇」だけでは、対象ユーザー、観測期間、季節性、別施策の影響が分からず、面接で説明が崩れやすいためです。

数値の種類	併記する条件	担当範囲の書き方
率・割合	分母、対象者、期間、比較時点	指標定義、分析、施策実装、検証のどこを担ったか
金額	売上・利益・コストの区分、集計範囲	分析が判断材料になった範囲までを記載
時間	1回当たりか月間合計か、対象人数、計測方法	自動化、運用変更、利用定着の分担を明記
件数	母集団、重複除外、異常値、集計単位	抽出だけか、定義合意や施策判断までかを区別

成果を一つの指標に絞れない案件では、先行指標と最終指標を分けます。たとえば、施策実装直後は利用開始や操作完了を観測し、その後に継続や売上との関係を確認したのであれば、観測順序をそのまま書くと分析判断の過程が伝わります。途中で施策を見送った場合も、見送りの根拠となった検証条件を実績として扱えます。

守秘義務で実数を出せないときは、無理に概数を作りません。利用部署、定例会議への導入、定義の統一、更新頻度、再利用された分析、見送れた施策など、社内で確認できる非金額の事実へ置き換えます。「約」「大幅」だけでぼかすより、何が変わったかを具体化する方が説明しやすくなります。

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

求人票の要件をそのまま自己PRへ写すのではなく、自分の案件で証明できる項目へ変換します。企業の募集要項では、SQLやBIに加えて、課題設定、KPI設計、他職種連携、データ品質、施策完遂まで確認可能です。

募集要項で求められる経験	職務経歴書で書く項目	成果指標	伝わりにくい表現	改善方向
目的から逆算した課題設定	意思決定者、事業課題、仮説、優先順位	採用された問い、見送れた選択肢、判断までの期間	依頼された分析を実施	依頼をどう再定義したかを書く
SQLによる事業課題解決	ソース、粒度、結合、除外、検証	定義統一、手戻り、更新時間、再利用	SQLが得意	複雑さではなく判断に必要な品質を示す
KPI・BI設計	KPIツリー、定義、利用者、更新、権限	利用部署、定例運用、判断頻度、問い合わせ	ダッシュボードを作成	誰が何を決めたかまで続ける
施策・効果検証	仮説、比較、観測期間、限界、次の打ち手	採否、継続・撤回、行動変化	分析で成果を出した	他要因と自分の担当範囲を分ける
データ品質・要件設計	欠損、重複、定義差、要件、監視	手戻り、更新遅延、利用可能範囲	データ基盤を整備	分析利用がどう変わったかを書く
部門横断の推進	関係者、対立点、合意、役割分担	合意した定義、導入範囲、定着した運用	巻き込み力を発揮	誰と何を合意したかを具体化する

応募先の要件すべてに経験がある必要はありません。経験がない項目を埋めたように書くより、近い経験、チーム内の担当境界、入社前に補っている内容を分けた方が、面接との整合性を保てます。

企業タイプ別に変える実績の見せ方

データアナリストは企業によって職務範囲が異なります。求人票の職種名だけで決めず、分析の利用者、意思決定の時間軸、データ基盤の分業、施策実装への関与を確認してください。

企業・組織タイプ	前面に出す実績	確認する募集項目	避けたいずれ
プロダクト分析	ユーザー行動、KPI、仮説検証、施策採用、継続観測	プロダクトチームとの分業、実験、担当領域	レポート作成だけに見せる
マーケティング・CRM	顧客定義、セグメント、施策反応、再利用可能な分析	広告・CRM・営業との接続、データ粒度	媒体指標の報告だけにする
全社BI・大規模事業会社	定義統一、品質、権限、部門横断合意、利用定着	基盤チームとの分業、ガバナンス、利用部署	調整業務だけに見せる
分析支援・コンサル型	顧客課題を業務要件に直す経験、分析設計、説明、顧客内利用	提案と実分析の比重、導入後の責任	資料作成だけに見せる

予測モデルの設計・評価・運用が主な強みなら、データサイエンティスト求人との比較も必要です。一方、意思決定者との距離、KPI設計、施策接続が強みなら、難しいモデルを無理に前面へ出すより、データアナリストとしての判断支援を具体化した方が職務の一致を示せます。

未経験・隣接経験者が補強すべき項目

「未経験」を一つにまとめると、準備の優先順位を誤ります。完全未経験、業務でデータを使う隣接経験、分析実務がある経験者では、職務経歴書に書ける証拠が異なります。

現在地	書類で使える証拠	先に補うこと	注意点
完全未経験	現職の業務課題、数値を使った改善、自主学習を別欄で記載	実務データに触れる改善案件、SQL、指標設計	学習課題を業務成果のように書かない
マーケ・企画など隣接経験	KPI、施策検証、顧客・業務理解、意思決定支援	抽出条件、比較設計、再現可能な分析工程	分析担当者の成果を自分の実績にしない
BI・データ基盤寄り	定義、品質、データマート、利用部署、運用定着	課題設定、仮説、施策判断への接続	ツール導入だけで終えない
分析実務経験者	判断の連鎖を完走した案件、複数部署、再現性	応募先固有のドメインと不足工程	案件数を増やすより強い案件を深く書く

自主分析のポートフォリオを載せる場合も、見栄えの良いグラフだけでは不十分です。問いを選んだ理由、データの制約、比較方法、得られた結果で何を決められるか、何は決められないかまで説明すると、実務に近い思考を示せます。

面接で深掘りされる項目

職務経歴書は面接の質問設計図になります。強い言葉や大きな成果を書くほど、定義、比較、担当範囲、限界まで説明できる準備が必要です。

書類の表現	深掘りされる論点	準備する証拠
KPIを設計した	なぜその指標か、先行・遅行、操作可能性、定義の対立	KPIツリー、定義書、合意した論点
施策効果を検証した	比較対象、観測期間、他施策、偏り、限界	検証設計、除外条件、解釈メモ
売上改善に貢献した	自分の担当、施策実装者、他要因、再現性	役割分担、意思決定、時系列
ダッシュボードを定着させた	利用者、会議、更新責任、使われない指標の整理	運用フロー、利用場面、改善履歴
部門を巻き込んだ	対立点、合意形成、譲れない品質、判断者	関係者一覧、論点、決定事項

特に、相関を見つけたことと施策の効果を確かめたことは分けて説明します。厳密な因果推論を使っていない案件でも、比較できる範囲、同時に変わった要因、結果から言えないことを説明できれば、分析の限界を管理した経験として示せます。

年収交渉につながる責任範囲の書き方

職務経歴書だけで年収が決まるわけではなく、データアナリスト単独の公的な平均値をそのまま交渉材料にはできません。年収交渉の材料は、ツールの数ではなく、どの責任を任され、どの判断を動かし、別の環境でも再現できるかに分解します。

交渉材料	職務経歴書で示すこと	誇張を避ける書き方
責任範囲	課題設定、分析、提案、実装支援、検証の担当工程	チームと自分の担当を分ける
意思決定	誰にどの選択肢を提示し、何が採用されたか	「貢献」だけで終えない
利用定着	利用部署、会議、更新体制、教育、改善サイクル	作成物の数より使われ方を書く
再現性	課題を定義し、品質を確かめ、判断へ渡す手順	一度の成功を一般化しすぎない
リード経験	関係者、論点、役割分担、品質基準、育成	人数だけでなく判断責任を書く

守秘義務で金額や率を出せない場合は、担当工程、利用者、採用された判断、運用頻度、標準化した定義などを使えます。面接で根拠を説明できない数値を置くより、責任範囲が明確な非金額の証拠を選んでください。

データアナリストの職務経歴書を相談すべきケース

応募先の募集要項と自分の案件を一対一で対応づけられ、成果の担当範囲と分析の限界を説明できるなら、自分で提出準備を進められます。一方、次に当てはまる場合は、提出前に第三者と整理すると判断が早くなります。

自分で進めてよいケース

募集要項の職務内容と必須要件を読み、該当する自分の案件を根拠つきで選べるなら、まず自分で提出準備を進めてよいでしょう。課題設定、データ定義、分析設計、判断、実装支援、検証の担当範囲を一貫して説明でき、書類の数値を元資料や社内記録から確認できることも条件です。

さらに、書類に書いた一文ごとに「誰が決めたか」「比較対象は何か」「自分が実行した範囲はどこか」を口頭で答えられるか確認します。答えが案件によって変わるのは問題ありません。すべての案件を同じ成功パターンに見せず、採用、見送り、追加検証など実際の結論を分けて書けていれば、面接との整合を保てます。

提出前は案件・スキル・自己PRの整合を確認する

最後に見るべきなのは誤字だけではありません。職務要約で掲げた強みが案件欄に実例としてあり、技術スキル欄の自立度が案件の担当範囲と一致し、自己PRが同じ事実を別の角度から説明しているかを確認します。どこか一つだけ強く書くと、書類内で経験の大きさが食い違います。

確認箇所	照合する相手	不一致の例	直し方
職務要約	案件欄	施策検証が強みだが、検証案件の記載がない	根拠になる案件を先頭へ移す
技術スキル	担当工程	設計経験と書いたが、案件欄は既存集計の運用だけ	実際の自立度へ戻す
成果数値	計測条件	改善率はあるが、期間と比較基準がない	分母、期間、同時期の変更を追記
自己PR	面接回答	主体性を掲げるが、意思決定者と担当境界が曖昧	提案した選択肢と採否を具体化

案件名や顧客名を伏せる場合も、事業領域、分析対象、利用者、担当工程まで消す必要はありません。匿名化したうえで、判断の種類と自分の責任を残します。反対に、社外秘の数値や個人情報を推測で丸めて載せることは避け、開示できる非金額の証拠へ切り替えてください。

• SQL、Python、BIの記載が多く、事業判断との接続が薄い
• プロダクト分析、マーケティング分析、全社BIのどれを軸にするか決められない
• チームの成果と自分の担当を分けると、実績が弱く見えないか不安がある
• 守秘義務の範囲で使える成果指標を選びたい
• 書類に書いた検証設計やKPIを面接で説明できるか確認したい

求人を見るときは、職種名だけでなく、分析の利用者、施策実装への関与、基盤チームとの分業、求められるドメインを確認してください。自分の強い案件がどの求人で評価されるかを先に比較すると、職務経歴書の先頭に置く実績を選びやすくなります。

面接では分析条件と担当境界を説明する

書類では短くしたデータ条件や担当境界ほど、面接で深掘りされます。各案件について課題の定義、比較方法、結果の限界、施策の採否を口頭で説明できるか確認してください。職務経歴書の次に読むべき論点は、応募先に近い案件を短く説明し、追加質問では検算や意思決定の経緯まで話せる準備です。