データエンジニアの年収交渉、オファー面談で伝える基盤構築経験

「そのバッチ処理、なぜその設計にしたんですか」——オファー面談でそう聞かれた瞬間、Rさん(37歳・データエンジニア)は資料をめくる手を止め、「運用を担当していました」としか答えられませんでした。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、データエンジニアのオファー面談で年収が伸び悩む相談の多くは、技術力の不足ではなく実績の語り方に原因があります。今回は、パイプライン基盤構築の経験を年収交渉の根拠に変える伝え方を、実際のやり取りを交えてお伝えします。

目次

1. データエンジニアの年収交渉、オファー面談で見られる評価軸
2. 「運用しました」で止まる実績説明、面接官には何も伝わらない
3. 職務経歴書の段階から、意思決定を書けているか
4. 実例、基盤リプレイスの判断を語れず提示額が伸びなかったRさん
5. Before/After、意思決定を主語つきで語り直す
6. オファー面談で使える、基盤構築経験を根拠に変える質問と伝え方
7. 金額を切り出すときの伝え方の例
8. 面接官のタイプによって、語るべき意思決定の粒度は変わる
9. データエンジニアとデータアナリストで評価軸が違うことを面談前に理解する
10. 年収以外にも交渉できる条件を知っておく
11. よくある質問
12. まとめ、パイプラインの意思決定を語れるかが年収の分かれ目

データエンジニアの年収交渉、オファー面談で見られる評価軸

データエンジニアのオファー面談で面接官が本当に見ているのは、扱ったツールの種類やデータ量の大きさではありません。パイプラインの設計をどう判断したか、その意思決定に自分がどう関与したかです。これはデータアナリストの評価軸とは別物で、混同したまま面談に臨むと、実績があっても正しく伝わりません。

データアナリストが「事業側に示唆をどう出したか」で評価されるのに対し、データエンジニアは「基盤という仕組みそのものをどう作り、どう壊れにくくしたか」で評価されます。この職種間の評価軸の違いは求人票の文言にも表れていて、面談で聞かれる質問の質にもそのまま反映されます。

厚生労働省の職業情報提供サイト(job tag)によると、データエンジニアの全国平均年収は約610万円、スキルレベルによって420万〜950万円まで幅があるとされています(出典:job tag「データエンジニア」)。この幅の広さは、担当ツールの多さより、基盤構築の意思決定にどこまで関わってきたかで決まっていると私は見ています。

具体的に言うと、面接官が確認したいのはパーティショニング設計をどう決めたか、スキーマ変更のときに既存データをどう移行したか、コストとレイテンシのどちらを優先してアーキテクチャを選んだか、といった判断の連続です。これらは求人票のスキル要件欄には現れにくく、面談で口頭で確認するしかない部分だからこそ、面接官はそこに時間を割きます。

私が同席してきたオファー面談を振り返ると、技術スタックの一致度が高い候補者ほど、かえって設計判断の話を省略してしまう傾向があります。「この会社と同じツールを使っていたので即戦力です」という説明は、ツールの操作経験を証明できても、判断力の証明にはならないという点を見落としがちです。

企業の規模によっても、見られる意思決定の幅は変わります。数百人規模の事業会社であれば、既存の基盤をどう改善したかという運用寄りの判断で十分評価される場面が多いのですが、社員数十人規模のスタートアップになると、基盤をゼロから設計する場面自体を経験しているかどうかが問われます。応募先の規模に応じて、語るべき意思決定の粒度を変える準備も欠かせません。

「運用しました」で止まる実績説明、面接官には何も伝わらない

職務経歴書の実績欄に「日次バッチ処理の運用・保守を担当」とだけ書かれているケースを、私はこれまで数えきれないほど見てきました。この一文自体は嘘ではないのですが、面接官が知りたいのは運用していた事実ではなく、その運用の中で何を判断したかです。

「運用しました」という言葉は、担当していた事実の報告であって、実績の説明にはなっていません。障害が起きたときにどう原因を切り分けたか、既存の設計に無理があると気づいてから何を提案したか——その意思決定の過程こそが、年収交渉の根拠になる材料です。ここを言語化しないまま面談に臨むと、面接官は「運用はできるが設計判断はできない人」という評価で止まってしまいます。

これは一般的な内定後の年収交渉の準備(たとえばオファー面談で失敗する3つのパターンで扱った「根拠のない金額を切り出す」失敗)とは別の階層の問題です。金額の切り出し方以前に、根拠となる実績そのものが面接官に伝わる形になっていないという構造的なつまずきが、データエンジニアには起きやすいと感じています。

職務経歴書の段階から、意思決定を書けているか

実績の言語化は、面談の場だけで急にできるようになるものではありません。私は求職者に職務経歴書を見せてもらうとき、まず動詞に線を引くところから始めます。「担当」「対応」「運用」で終わる文がどれだけ多いか、逆に「提案した」「選定した」「見直した」といった能動的な動詞がどれだけ入っているかを数えると、面談での説明のクセがかなり正確に予測できます。

職務経歴書の実績欄が動詞止まりの人ほど、面談本番でも同じ言葉遣いのまま話してしまいます。書類の段階で意思決定の主語を「自分」に戻しておくと、面談での受け答えも自然と変わるというのが、これまで見てきた実感です。書類選考を通すための書き直しと、面談で語るための棚卸しは、実は同じ作業の延長線上にあります。

実例、基盤リプレイスの判断を語れず提示額が伸びなかったRさん

Rさんは経験11年のデータエンジニアで、大手SIer系のデータ基盤子会社に在籍していました。担当していたのは、食品・飲料メーカー数社向けの受発注データ分析基盤の構築と、その後の運用です。夜間バッチが月に十件以上失敗する状態を引き継ぎ、原因調査からジョブの分割まで一人で対応していました。

自社開発のtoC旅行予約サービス企業からオファー面談の連絡が来たとき、Rさんは「運用経験が長いので大丈夫だろう」と特に準備をせずに臨みました。面接官の質問は「そのバッチ処理、なぜその設計にしたんですか」というものでしたが、Rさんは「前任者から引き継いだ設計を、そのまま運用していました」としか答えられませんでした。

面談の空気が変わったのをRさん自身も感じたそうです。その後のオファー通知書には、求人票に書かれていたレンジ650万〜880万円の下限をさらに35万円下回る615万円という数字が並んでいました。運用の継続性は評価されても、設計判断の主体性は評価されなかったという結果でした。

私のところに相談に来たRさんに最初に聞いたのは、「バッチが月に十件失敗していた状態から、実際に何を変えましたか」という一点でした。話を聞いていくと、原因調査の末にジョブの依存関係が複雑に絡み合っていることを突き止め、Airflowへの移行を自ら上長に提案し、移行後は失敗件数が月平均十二件から二件まで減っていたことが分かりました。この経緯こそ、面談で語るべき実績だったのです。

なぜこの経緯が職務経歴書にもオファー面談の説明にも出てこなかったのか、Rさん自身に振り返ってもらうと、理由は単純でした。受託の現場では、自分の提案が通ったことより、クライアントに障害を出さなかったことの方が評価される構造があり、Rさんの中でも「無事に運用できていること」が実績の基準になっていたのです。障害を未然に防いだ判断は、クライアント向けの報告書には残っても、自分自身の転職活動用の実績としては言語化されないまま埋もれていました。

もう一つ見えてきたのは、Rさんが面談の準備そのものを軽視していたわけではないという点です。技術書を読み込み、Airflowの新しいバージョンの機能も予習していました。ただし準備の方向が「聞かれそうな技術トレンドへの回答」に偏っていて、自分の過去の判断を振り返る準備には時間を割いていなかったのです。この偏りは、データエンジニアの転職相談でとてもよく見る傾向です。

面談の再現をRさんと一緒にやってみると、もう一つの課題も見つかりました。面接官が「なぜその設計に」と聞いた直後、Rさんは数秒沈黙したあと「特に大きな問題はなかったので、そのまま引き継ぎました」と付け加えていたのです。問題がなかったこと自体は事実ですが、面接官からすれば「判断を避けた」という印象にしかなりません。事実を守りながらも、判断の跡を残す言い方に変える必要がありました。

Before/After、意思決定を主語つきで語り直す

Rさんの職務経歴書とオファー面談での説明を、私と一緒に書き直しました。変えたのは実績そのものではなく、同じ経験をどの主語で語るかという一点です。

書き直した直後、Rさんは半信半疑だったそうです。「事実は変えていないのに、こんなに印象が変わるのか」というのが本人の感想でした。実際、やったことを増やしたわけではなく、伝える順番と主語を変えただけで、面接官が拾える情報量が変わったのだと思います。

2社目のオファー面談では、同じ質問に対して「バッチが月12件失敗する状態から、依存関係を洗い出してAirflowに移行することを自分から提案しました」と即答できました。結果として提示額は705万円、1社目より90万円高い数字で着地しました。求人票のレンジ上限に近い金額で、Rさん自身も「同じ経験でここまで変わるとは思わなかった」と話していました。

オファー面談で使える、基盤構築経験を根拠に変える質問と伝え方

Rさんのケースからも分かる通り、意思決定を語れるかどうかは、面談前にどれだけ自分の経験を棚卸ししたかで決まります。私が求職者に必ず確認してもらっているのは、次のような掘り下げ方です。

面談の場では、面接官から技術選定の理由を聞かれたときに「〜という制約があったので、〜を選びました」という制約と選択をセットで語る型が効きます。制約を語らずに「Airflowを使っていました」とだけ答えると、単なるツール経験の報告になってしまい、判断力までは伝わりません。

もう一つ有効なのが、面談の終盤で聞かれる「懸念点はありますか」に対して、自分から意思決定の場面を掘り下げる逆質問を返すことです。「御社の現在の基盤で、意思決定に一番時間がかかっている部分はどこですか」と聞き返すと、自分が入社後にどこで裁量を発揮できるかを確認できると同時に、面接官にも「この人は設計判断に関心がある」という印象を残せます。

金額を切り出すときの伝え方の例

意思決定の実績を語り終えたあとの、金額の切り出し方もRさんの2社目の面談を例に紹介します。「お声がけいただいた御社にぜひ入社したいと考えています。その上でご相談ですが、前職では月12件の障害原因を分析してAirflow移行を主導し、失敗件数を月2件まで減らした実績があります。求人票のレンジを拝見すると、この経験は上限に近い水準で評価いただけるのではと感じているのですが、いかがでしょうか」——感謝と入社意欲を先に伝え、意思決定の実績を数字で示してから、レンジのどのあたりを希望するかを尋ねる順番です。

金額の水準そのものより、根拠として提示した実績と、希望するレンジの位置づけが矛盾していないかを面接官は見ています。運用の継続性しか語れない実績で上限を求めると違和感が残りますが、設計判断とその効果を数字で示せていれば、上限寄りの希望も自然に響きます。

面接官のタイプによって、語るべき意思決定の粒度は変わる

オファー面談に同席する面接官は、現場のデータエンジニアや技術責任者であることが多いのですが、企業によっては事業側の責任者やCTOが同席することもあります。この二者では、同じ「意思決定」でも聞きたい粒度が違います。

現場のエンジニアが面接官の場合は、Airflowへの移行をなぜその設計にしたか、依存関係をどう洗い出したかという技術的な判断の妥当性を確認してきます。

一方で事業側の責任者やCTOが同席する場合は、その判断がビジネスにどう跳ね返ったかを聞いてきます。たとえば障害対応にかかっていた工数がどれだけ削減され、他の開発にどれだけ時間を回せるようになったか、という事業インパクトへの翻訳を求められる場面です。

この構図は、以前現場エンジニア面接官と人事・役員面接官で評価軸が違う理由でも取り上げた面接一般の傾向と同じ構造です。データエンジニアの場合はここに「技術的な意思決定」という要素が加わる分、面談前の準備がもう一段階複雑になります。Rさんの2社目の面談では、技術責任者からの質問には設計の妥当性で、途中から同席した事業責任者からの質問には工数削減の数字で答え分けたことが、提示額の上振れにもつながったと私は見ています。

データエンジニアとデータアナリストで評価軸が違うことを面談前に理解する

もう一つ、データエンジニアの求職者がよく陥る誤解があります。求人票や面談の中で「分析にも関わっていました」という実績を強調しすぎて、かえって基盤構築の専門性がぼやけてしまうケースです。

分析の話をすること自体は悪くありませんが、データエンジニアの求人で評価してほしいのは分析の示唆ではなく基盤の設計判断です。面談で聞かれてもいないダッシュボード改善の話を長く語ってしまうと、面接官には「専門性がどちらつかず」という印象を与えかねません。求人票の職種名と自分の強みがどちらに寄っているかは、応募前の段階である程度見極めておく必要があります。

この見極め方については、以前データエンジニアとデータアナリストの求人票の違いで、求人票の「動詞」と「成果物」から職務範囲を読み分けるチェックリストを紹介しました。オファー面談に進む前の応募段階でこの見極めができていると、面談での語り方もぶれにくくなります。

分析の実績に触れる場合も、ゼロにする必要はありません。「ダッシュボードの改善要望を受け、基盤側のテーブル設計を見直した」のように、分析の話を必ず基盤構築の判断に着地させる言い方に変えると、専門性がぶれずに伝わります。分析経験を独立した話として広げず、基盤側の意思決定を補強する材料として使う、という位置づけを崩さないことがポイントです。

年収以外にも交渉できる条件を知っておく

「何%まで交渉していいのか」という質問もよく受けますが、私はパーセンテージで区切る考え方自体を勧めていません。求人票のレンジ内であれば、意思決定の実績を語れる範囲で上限寄りを狙ってよく、レンジを超える希望は、その根拠となる実績が求人票の想定より明確に上回っている場合に限るべきだというのが率直な考えです。パーセンテージより、語れる実績の重みとレンジの位置が釣り合っているかを基準にしてください。

基盤構築の実績を語れるようになると年収の伸びしろは変わりますが、オファー面談で確認すべきは金額だけではありません。データエンジニアの場合、入社後の技術選定への関与度や、既存基盤の刷新プロジェクトへの参加可否は、翌年の評価・昇給の伸び方に直結します。

Rさんも2社目のオファー面談では、金額の交渉と並行して「入社後最初の半年でどの基盤に関わることになりそうか」を確認していました。保守だけで終わる配属だと、翌年に語れる実績が積み上がらないという懸念があったからです。金額の数字だけを見て決めるのではなく、次の意思決定の機会がどこにあるかまで確認しておくと、翌年以降の交渉材料にもつながります。

本番環境への権限は、特に見落とされがちな確認事項です。入社後しばらくは既存メンバーのレビューを経てからでないとデプロイできない会社もあれば、早い段階から裁量を渡す会社もあり、この差は翌年に「語れる意思決定」が積み上がる速度に直結します。オファー面談の場で、権限が広がっていく目安の時期まで聞いておくと、入社後の実績づくりの見通しが立てやすくなります。

よくある質問

基盤構築の実績が少ない場合、何を根拠に交渉すればいいですか。

大規模な刷新プロジェクトの経験がなくても、日々の運用の中で「なぜその対応を選んだか」を振り返れば、小さな判断の積み重ねが見つかることがほとんどです。パラメータチューニングの理由、監視のしきい値をどう決めたかなど、規模の大小より判断の理由を語れるかどうかが重要です。

オファー面談で交渉した結果、提示額が動かなかった場合はどうすればいいですか。

金額が動かない場合でも、次回の評価タイミングと評価基準を確認しておくことをお勧めしています。基盤構築の裁量が明確にある配属であれば、初年度の提示額が下限寄りでも、翌年の交渉材料が積み上がりやすいというのが実感です。

転職ドラフトなど、企業から先に金額を提示される場での交渉でも同じ考え方は通用しますか。

通用します。企業側が先に金額を示す場面ほど、提示理由を尋ねたときに設計判断の実績を補足材料として出せるかどうかが、後からの増額交渉の余地を左右します。指名理由が古い技術タグに基づいていたケースなど、提示額の根拠を確認する重要性は転職ドラフトの指名年収と実際のギャップでも取り上げています。

意思決定の経験と言っても、チームでの合議制だった場合はどう語ればいいですか。

合議制自体は珍しくないので、無理に「自分だけの判断」に書き換える必要はありません。むしろ「複数の選択肢のうち、自分がどの案を推し、どんな根拠を出したか」を具体的に語れれば十分です。最終決定者が別にいたとしても、判断材料を用意した過程は自分の実績として語れます。

まとめ、パイプラインの意思決定を語れるかが年収の分かれ目

データエンジニアのオファー面談で提示額が伸び悩む原因の多くは、技術力そのものより、実績を「運用しました」で止めてしまう語り方にあります。同じ経験でも、意思決定の主体性を主語つきで語り直すだけで、面接官が受け取る情報の質は大きく変わります。

Rさんの事例のように、やったことを増やす必要はありません。自分が既に経験している基盤構築の判断を、面接官が評価できる言葉に翻訳できるかどうか——それがデータエンジニアの年収交渉における最大の分かれ目だというのが、この記事で一番伝えたかったことです。次のオファー面談の前に、自分の実績を「運用」の言葉のまま残していないか、一度振り返ってみてください。