データアナリストのスキルシートの書き方｜面談で評価される実績の見せ方

データアナリストのスキルシートは、使ったツールの名前を並べるより、依頼の受付から定例化までのどこを担い、どんな指標を扱い、出した数字が何の判断に使われたかを書くのが基本です。データアナリストの経験は「SQL、BIツール、スプレッドシート」と書くと、誰のシートも似た見た目になります。差がつくのは、どんな依頼に、どう答えたかの中身です。

全体の構成はスキルシートの基本をご覧ください。求められるスキルの中身はデータアナリストの案件で求められるスキルで扱っています。ここでは、データアナリストの経験をシートに書くときの工夫に絞って説明します。

「担当工程」を分析の流れに置き換える

一般的なスキルシートの担当工程は、要件定義・設計・開発・テストといったシステム開発の流れを前提にしています。データアナリストの仕事はこの枠に当てはまりにくいため、分析の流れに置き換えて書きます。

これは書き方を示すための例です。発注側の読み手は、「抽出を代行する人」か「依頼の意図から考えられる人」かを見ています。依頼の受付と定例化を担った経験は、目立つ位置に書きましょう。

自分が担当しなかった部分（「データの取り込みはデータエンジニアが担当」「ダッシュボードの構築はBI担当が実施」など）も書いておくと、チームの中での立ち位置が正しく伝わります。

SQLの力は「何ができるか」で書く

「SQL（5年）」とだけ書くと、単純な抽出なのか、複雑な集計なのかが伝わりません。できることを具体的な動作で書きます。

• 複数のテーブルを、粒度を確かめたうえで結合して集計できる
• ウィンドウ関数を使い、会員ごとの前回購入からの日数や順位を出せる
• 登録月ごとの継続率など、コホートの集計を書ける
• データ量の多いテーブルで、読む範囲を絞った書き方ができる
• 既存のレポートの数字と突き合わせ、ずれの原因を説明できる

使ったデータウェアハウスやデータベースの名前は、別の行にまとめます。案件ごとに環境が違うため、複数の環境で書いた経験があれば、それぞれの名前を並べておくと、読み手は立ち上がりの早さを判断しやすくなります。

ツールは「使う側」か「作る側」かを書き分ける

BIツールやアクセス解析のツールは、使い方の深さによって意味が大きく変わります。

作る側の経験が中心の方は、BIエンジニアのスキルシートの書き方も参考になります。実際より深く書くと、面談で設計の話を聞かれて食い違いが起きます。スプレッドシートも同じで、「関数での集計」「ピボットでの分析」「マクロやスクリプトでの自動化」のように、使った範囲を括弧で添えると、読み手が任せられる作業を判断しやすくなります。

扱った指標と業界を書く

データアナリストの読み手が知りたいのは、「うちのデータにすぐ慣れられるか」です。プロジェクトごとに、扱った指標と業界を書きます。

• 「ECの会員データで、購入回数・客単価・継続率を扱った」
• 「アプリの行動データで、登録から課金までのファネルを扱った」
• 「SaaSの契約データで、解約と継続の指標を扱った」

指標の定義を自分で決めたり、部門の間でそろえたりした経験があれば、「定義の策定」として別に書きます。指標の管理を任される案件では、この1行が強い材料になります。

成果は「判断」と「手間」で書く

売上や会員数などの数字は、参画先の業績に関わる情報で、社外に出せないことがほとんどです。数字の代わりに、次のどちらかで書きます。

• 判断に使われた：「施策の前後の集計をもとに、配信の対象を見直す判断に使われた」
• 手間が減った：「手作業で作っていた週次レポートを自動で更新される形にし、担当者が集計に使う時間を減らした」

数字を出せる場合も、売上や会員数ではなく、レポートの作成にかかる手順がどれだけ減ったかのように、自分の作業の変化で書くと、守秘義務に触れにくくなります。書いてよい範囲の考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

依頼の進め方も1行で書く

データアナリストの案件では、依頼をどう受け、どう返してきたかも見られます。プロジェクト欄の担当内容に、進め方を1行加えておくと、面談で話を広げやすくなります。

• 「依頼の受付の様式を作り、目的・期限・使い道を確かめてから着手する形にした」
• 「急ぎの依頼が重なったときは、依頼者と優先順位を決めて期限を調整した」
• 「回答した数字ごとに、クエリと抽出日時を共有の場所に残した」

リモートの案件や、週2〜3日の稼働の案件では、この進め方の行が特に読まれます。依頼の量が多かった案件では、どの程度の頻度で依頼を受けていたかを、「毎日複数件」「週に数件」のようにぼかして書くと、働き方の想像がつきやすくなります。

資格の書き方

資格は、知識の範囲を示す補足として書きます。統計検定は、1級から4級までの区分のほか、データサイエンス基礎・発展・エキスパートの区分があるため（2026年10月時点の公式サイトによる）、「統計検定2級」「統計検定 データサイエンス基礎」のように区分まで正確に書きます。資格の位置づけは統計検定の記事をご覧ください。

プロジェクト欄の記入例

ここでは、EC事業の分析担当として参画した場合を想定しています。以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（10か月程度）
案件概要：EC事業における会員・購買データの分析と定例レポートの整備
規模・立場：分析チーム3名（自分は分析担当、依頼の窓口を兼務）。依頼者はマーケティング部門と商品部門の担当者、報告先は部門の責任者
担当工程：依頼の受付、データの抽出、集計・分析、可視化・報告、定例化（データの取り込みはデータエンジニアが担当）
使用技術：SQL（クラウドのデータウェアハウス）、BIツール（既存ダッシュボードの利用と見方の追加）、スプレッドシート
扱った指標：購入回数、客単価、登録月ごとの継続率、販促ごとの購入率
担当内容：部門ごとに異なっていた「継続会員」の定義を関係者と話してそろえ、文書に残した。販促の前後で購入率を比べ、季節の影響を除いて報告した。繰り返し来る依頼を週次レポートにまとめた
成果（判断と手間）：販促の対象の見直しの判断に使われた。週次レポートを自動で更新される形にし、担当者の手作業を減らした

この例では、分析の流れのどこを担ったか、ツールの使い方の深さ、扱った指標、成果の書き方を示しています。

よくある質問

定例レポートの更新しか経験がありません。どう書けばよいですか？

定例レポートでも、何の判断のための数字か、定義をどう確かめたか、ずれに気づいて直したことがあるかを書けば、分析の実績として読まれます。手作業を減らす工夫をした経験があれば、定例化の実績として書きましょう。

社内の指標の名前はそのまま書いてよいですか？

社内だけで使われている名前は、そのまま書かないほうが安全です。「継続率」「客単価」のような一般的な言葉に置き換え、どんな指標だったかが伝わるように書きます。

個人で作った分析の成果物は書いたほうがよいですか？

公開データを使った分析などは、SQLや可視化の力を示す補足として書けます。実務の経験とは分けて「そのほかの活動」としてまとめ、実務のプロジェクトを上に置くと読みやすくなります。発注元のデータを使ったものは載せないでください。