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

データエンジニアのスキルシートは、使った製品の名前を並べるより、プロジェクトごとに「どこから取り込み、どう加工し、どこに置き、誰が使ったか」というデータの流れを1行で要約し、規模・頻度・鮮度をぼかして添えるのが基本です。データ基盤の案件は、製品の組み合わせが現場ごとに違うため、読み手は製品名の一致より「同じ形の流れを作ったことがあるか」を見ています。処理が失敗したときの扱いも、短く書いておくと評価が安定します。

全体の構成はスキルシートの基本をご覧ください。案件で見られるスキルの中身はデータエンジニアの案件で求められるスキル、経験の棚卸しと独立の準備はデータエンジニアがフリーランスになるにはで扱っています。ここでは、シートへの書き方に絞って説明します。

プロジェクトの冒頭に「データの流れ」を1行で置く

データエンジニアのプロジェクト欄では、案件概要の次に、データの流れを矢印でつないだ1行を置くと、読み手が全体像をすぐにつかめます。

• 「業務DB・外部のファイル → 日次で取り込み → データウェアハウスで加工 → 分析担当とBIのダッシュボードが利用」
• 「アプリのイベントログ → 準リアルタイムで取り込み → 集計テーブル → 社内の推薦機能が利用」
• 「オンプレミスのデータウェアハウス → クラウドのデータウェアハウスへ移行（テーブルと定期処理を移す）」

製品名はこの行には入れず、使用技術の欄に分けて書きます。流れの形が分かれば、読み手は自分の案件の流れと重ねて読めるため、製品が違っても検討の対象になりやすくなります。

最後の「誰が使ったか」を落とさないことが大切です。分析の担当者向けか、経営の報告向けか、アプリの機能から使われるのかで、求められる鮮度や品質が変わります。利用者を書いておくと、なぜその作りにしたのかを面談で説明しやすくなります。

規模は「量・頻度・鮮度・数」の4つでぼかす

データの仕事は、規模を書かないと難しさが伝わりません。ただし、正確な件数や容量は、参画先の事業の大きさを推測させる情報になります。次の4つを、桁や幅でぼかして書きます。

これは書き方を示すための例です。4つを全部書く必要はなく、そのプロジェクトの難しさが出ているものを選びます。たとえば、量は多くないが取り込み元が多く定義の調整が大変だった、という場合は「数」を前に出します。

売上の金額や顧客の人数など、事業の数字そのものは書きません。取り込み元のシステム名や、テーブルの実際の名前も書かないようにします。

技術欄は「層」ごとに分ける

データ基盤の技術は、取り込み・加工・保存・処理の管理・利用の層に分かれます。層ごとに行を分けて、関わり方を添えると、読み手は案件で足りない部分と重なる部分を見つけやすくなります。

SQLは、データエンジニアの技術欄で最も読まれる行です。「SQL ○年」だけでなく、モデリングから担当したのか、決まったテーブルに対してクエリを書いていたのかを書き分けましょう。Pythonで処理を書いた経験が中心の方は、Pythonエンジニアのスキルシートの書き方も参考になります。

「失敗したときの扱い」を1行で書く

データの処理は、取り込み元の遅れや、想定外のデータで止まることがあります。読み手は、作った人が失敗をどう扱ったかを気にします。工夫・成果の欄に、次のような1行を入れておくと伝わります。

• 「失敗したタスクだけを、同じ結果になる形で再実行できるようにした」
• 「件数と重複の検査を入れ、問題があれば後続の更新を止めるようにした」
• 「取り込み元の遅れを検知し、利用者に通知する仕組みを作った」

再実行や品質の検査の考え方そのものはデータエンジニアの案件で求められるスキルで解説しています。シートでは、自分が作った仕組みを1行で書くことに絞りましょう。

個人データの扱いは「触れた範囲」と「守り方」を書く

データエンジニアは、顧客の情報など、個人を特定できるデータに触れることのある職種です。この経験は、書き方に気をつければ、むしろ判断材料になります。

• 触れた範囲：個人を特定できる列を含むデータを扱ったか、加工済みのデータだけを扱ったか
• 守り方：列を分けて閲覧を申請制にした、仮名に置き換えてから分析用に渡した、など

扱ったデータの中身（どの業界の、どんな顧客の情報か）は具体的に書かず、「顧客の属性を含むデータ」のように種類でとどめます。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないこと、参画時の秘密保持の取り決めはNDA（秘密保持契約）の記事をご覧ください。

認定資格の書き方

データエンジニアの認定は、使っているクラウドに合わせて書きます。正式名称と取得年月に、有効期限を添えます。

• AWS Certified Data Engineer - Associate：2026年10月時点のAWSの案内では、有効期間は3年間で、最新の試験に合格すると更新できるとされています
• Professional Data Engineer（Google Cloud）：2026年10月時点のGoogle Cloudの案内では、標準試験で取得した場合の有効期間は2年間、Google Skillsでの更新の場合は1年間とされています

更新の方法によって期限までの長さが変わる認定もあるため、取得年月から計算せず、実際の有効期限を確かめて書きましょう。

例：AWS Certified Data Engineer - Associate　20XX年X月取得（有効期限20XX年X月）

プロジェクト欄の記入例

ここでは、分析用のデータ基盤の整備を担当した場合を想定しています。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年程度）
案件概要：小売業向け 分析用データ基盤の整備
データの流れ：業務DB・外部のファイル → 日次で取り込み → データウェアハウスで加工 → 分析担当とBIのダッシュボードが利用
規模：取り込み元は十数システム、テーブルは数百。翌朝の業務開始までに更新
規模・立場：データチーム数名（自分は取り込みと加工の主担当）
担当工程：設計、開発、テスト、運用
使用技術：SQL、dbt、Airflow、クラウドのデータウェアハウス、Python
担当内容：全件の入れ替えだった取り込みを差分の取り込みに変更。部門ごとに違っていた売上の定義を分析担当とそろえ、利用者向けのテーブルを作成
工夫・成果：件数と重複の検査を入れ、問題があれば更新を止めて通知する形にした。処理の時間が短くなり、更新の遅れによる問い合わせが減った

この例では、データの流れ、規模（4つの観点のうち数と鮮度）、失敗したときの扱いを、それぞれ独立した行で書いています。

分析や機械学習の経験と並べるとき

データ分析やモデル作成の経験もある方は、スキル一覧で「データ基盤」と「分析」の行を分けます。データエンジニアの案件に応募するなら、基盤の経験を上に置き、分析の経験は「利用者の事情が分かる経験」として添えると読みやすくなります。分析を軸にする方はデータサイエンティストのスキルシートの書き方、モデルの運用が中心の方は機械学習エンジニアのスキルシートの書き方をご覧ください。

よくある質問

案件で求められている製品の経験がありません。どう書けばよいですか？

使った製品はそのまま書き、データの流れの形と、モデリングや再実行の設計を厚く書きます。同じ形の流れを別の製品で作った経験は、製品が違っても判断材料になります。求められている製品を個人の環境で試したことがあれば、実務とは分けて添えましょう。

運用だけを担当していたデータ基盤の経験は、どう書けばよいですか？

運用の中で自分が判断したことを書きます。失敗した処理の原因を調べて取り込み元と調整した、遅れを検知する仕組みを足した、処理の時間を短くした、といった経験は、開発の案件へ広げる材料になります。

データの件数をまったく書けない場合はどうすればよいですか？

件数の代わりに、頻度・鮮度・取り込み元やテーブルの数で規模を示します。「毎時更新」「十数システムから取り込み」のように書けば、件数がなくても難しさは伝わります。