データサイエンティストのスキルシートの書き方|面談で評価される実績の見せ方
公開 2026-10-29 監修:株式会社エージェントベスト
データサイエンティストのスキルシートは、使った手法の名前を並べるより、分析の工程(問いの設定・データの準備・分析・報告・業務への定着)のどこを担ったかと、結果が何の判断に使われたかを書くのが基本です。分析の成果は、モデルの精度や売上への効果を社外に出せないことが多いため、数字の代わりに「どの判断が、どう変わったか」で示します。期待した結果が出なかった分析も、書き方しだいで実績になります。
全体の構成はスキルシートの基本をご覧ください。案件で求められるスキルの中身はデータサイエンティストの案件で求められるスキル、経験の棚卸しと独立の準備はデータサイエンティストがフリーランスになるにはで扱っています。ここでは、シートへの書き方と見せ方に絞って説明します。
「担当工程」を分析の工程に置き換える
一般的なスキルシートの「担当工程」は、要件定義・設計・開発・テストといったシステム開発の工程を前提にしています。データサイエンティストの経験をこの枠に当てはめると、「開発」や「テスト」のどこに分析が入るのかが分かりにくくなります。
そこで、担当工程の欄を、分析の工程に置き換えて書きます。
| 分析の工程 | 書き方の例 |
|---|---|
| 問いの設定 | 依頼者と話し、検証する問いと判断の基準を決めた |
| データの準備 | 必要なデータを洗い出し、SQLで抽出して分析用に整えた |
| 分析・モデル | 比較の方法を設計し、効果を推定した/予測モデルを作り評価した |
| 報告 | 結果と、結論をどこまで信じてよいかを報告資料にまとめた |
| 業務への定着 | 分析の手順を担当者が月次で出し直せる形にした |
これは書き方を示すための例です。発注側の読み手は、「依頼を受けて分析だけをする人」か「問いの設定から入れる人」かを見ています。問いの設定や業務への定着を担った経験は、工程の欄で目立つように書きましょう。
「データの準備はデータエンジニアが担当」のように、自分が担当しなかった工程も書いておくと、チームの中での立ち位置が正しく伝わります。
手法は「目的」ごとにまとめる
スキル一覧に「重回帰、ロジスティック回帰、決定木、ランダムフォレスト、勾配ブースティング…」と手法を並べると、何に使えるのかが伝わりません。手法は目的ごとにまとめて書きます。
| 目的 | 書き方の例 |
|---|---|
| 施策の効果検証 | 無作為に分けた比較の設計、差の差分法(前提の確認を含む) |
| 予測 | 需要の予測、解約の予測(評価の基準の設計から) |
| 分類・優先順位づけ | 対応の優先度を決めるためのスコアの作成 |
| 顧客や商品の分け方 | クラスタリングによる顧客のグループ分け(施策への反映まで) |
| 集計・可視化 | ダッシュボードの設計、定例の報告資料の作成 |
言語と道具は、目的とは別の行にまとめます。「Python(pandas、scikit-learn)、SQL、R(統計の検定のみ)」のように、使った範囲を括弧で添えると、面談で深く聞かれる範囲を自分で示せます。
成果は「どの判断に使われたか」で書く
データサイエンティストのシートで最も悩むのが、成果の欄です。モデルの精度の数値や、施策による売上の変化は、参画先の業績に関わる情報で、社外に出せないことがほとんどです。
数字の代わりに、分析の結果がどこまで届いたかを段階で書きます。
- 報告した:結果を依頼者に報告した
- 判断に使われた:会議で、施策を続けるか止めるかの判断材料になった
- 施策が変わった:対象の絞り方や、配信のタイミングが変わった
- 業務に組み込まれた:モデルや集計が、日々の業務の中で使われるようになった
たとえば「販促の効果を検証し、効果の小さい対象への配信を止める判断に使われた」と書けば、金額がなくても、分析が意思決定を動かしたことが伝わります。段階が上がるほど、問いの設定や関係者との調整に関わっていることが読み手に伝わります。
数字を出せる場合も、売上や人数ではなく「既存のルールと比べて、見逃しが少なくなった」のような比較の向きで書くと、守秘義務に触れにくくなります。
「出なかった結果」も実績として書く
効果検証をすると、施策に効果が見られない、という結果になることがよくあります。こうした分析を、成果がなかったものとしてシートから外してしまう方がいますが、書き方しだいで実績になります。
- 「施策の効果を検証し、差が見られないことを報告。費用をかけて続けるかどうかの判断材料になった」
- 「予測モデルを試作したが、既存のルールを上回らないことを確かめ、導入を見送る判断に使われた」
「効果がない」と根拠を持って示すことは、無駄な施策を止める判断につながる仕事です。期待と違う結果を、前提の確認とあわせて報告できる人は、発注側にとって安心して任せられる人です。面談でも「結果が期待と違ったときにどうしたか」はよく聞かれるので、シートに1件書いておくと話のきっかけになります。
依頼者と報告先を書く
分析の仕事は、誰から依頼され、誰に報告したかで、求められる力が変わります。プロジェクト欄の規模・立場の行に、依頼者と報告先の層を添えます。
- 「依頼者:マーケティング部門の担当者/報告先:部門の責任者」
- 「依頼者:経営企画の担当者/報告先:役員が出る会議の資料として」
部署名や人の名前は書かず、役割と層で書きます。報告先が上の層になるほど、結論を短く伝える力が求められるため、読み手にとっての判断材料になります。
試作と運用を分けて書く
予測モデルを作った経験は、試作で終わったのか、業務で使われ続けたのかを書き分けます。試作で終わった経験も価値がありますが、運用まで続いたように書くと、面談で運用の話を聞かれて食い違いが起きます。モデルを本番で動かし続ける仕組みまで担った方は、機械学習エンジニアのスキルシートの書き方、データの取り込みや加工が中心の方はデータエンジニアのスキルシートの書き方もあわせてご覧ください。
資格の書き方
データサイエンスの資格は、知識の範囲を示す補足として書きます。2026年10月時点の各公式サイトの案内では、次のようになっています。
- 統計検定(統計質保証推進協会):1級から4級までの区分のほか、データサイエンス基礎・発展・エキスパートの区分があります。合格の証としてオープンバッジを付与する制度があるとされています
- データサイエンティスト検定 リテラシーレベル(データサイエンティスト協会):見習いレベルの実務能力や知識の証明とされています
統計検定は区分が多いため、「統計検定2級」「統計検定 データサイエンス発展」のように区分まで正確に書きます。1級は「統計数理」「統計応用」の区分に分かれているので、合格した区分も添えます。
プロジェクト欄の記入例
ここでは、販促の効果検証を担当した場合を想定しています。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。
期間:20XX年X月〜20XX年X月(8か月程度)
案件概要:小売業向け 販促施策の効果検証と配信対象の見直し
規模・立場:分析担当2名(自分は主担当)。依頼者はマーケティング部門の担当者、報告先は部門の責任者
担当工程:問いの設定、データの準備、分析、報告、業務への定着(データの取り込みはデータエンジニアが担当)
使用技術:SQL、Python(pandas、statsmodels)、BIツール
担当内容:無作為に分けた比較を設計し、施策ごとの効果を推定。無作為に分けられない施策は差の差分法で推定し、前提の確認結果とあわせて報告した
成果(判断への使われ方):効果の小さい対象への配信を止める判断に使われた。一部の施策は効果が見られないことを示し、見直しの対象になった。分析の手順をコードで残し、担当者が月次で出し直せる形にした
この例では、分析の工程、依頼者と報告先、結果がどの判断に使われたか、出なかった結果を書いています。
よくある質問
分析の結果が採用されなかったプロジェクトは書かないほうがよいですか?
書いてかまいません。採用されなかった理由が分かっていれば、それも含めて書きます。たとえば、前提の確認で結論を強く言えないと分かり、追加のデータを取る判断になった、という経験は、分析の進め方を説明できる材料になります。
社内向けの集計やレポート作成の経験しかありません。どう書けばよいですか?
集計の経験も、何の判断のための集計だったか、定義をどう決めたかを書けば、分析の実績として読まれます。毎月の報告を自動化した、指標の定義を関係者とそろえた、といった経験は、問いの設定や業務への定着に近い経験として書けます。
Kaggleなどのコンペの成績は書いたほうがよいですか?
予測の手法の理解を示す補足として書くことはできます。ただし、データサイエンティストの案件では、問いの設定や結果の伝え方も見られるため、実務の経験とは分けて書きます。実務のプロジェクトを上に置き、コンペの成績は「そのほかの活動」としてまとめると読みやすくなります。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。