「求人票には『データを活用した意思決定支援』としか書かれていなかったのに、配属先で渡されたのはPythonのETLスクリプトだった」——データ関連職の求人に応募した方から、こういう戸惑いの声を聞くことが増えています。
私はIT・Web業界を中心に800名以上の転職支援に携わってきましたが、データエンジニア・データアナリスト・データサイエンティストの3職種は、求人票の段階で驚くほど言葉が混同されています。今回は、求人票の実際の記載パターンからこの3職種を見分ける方法と、入社後ギャップを防ぐために面談で確認すべき質問を、現場で見てきた実例を交えてお伝えします。
今回は、次の内容に沿ってご紹介します。
- 「データ」を冠する求人で職種名の混同が起きる構造的な理由
- 求人票の文言からデータエンジニア・データアナリスト・データサイエンティストを見分けるチェックリスト
- 求人票と実務のズレは法律上どこまで許されるか、職業安定法から見る境界線
- オファー面談・カジュアル面談で聞いておくべき具体的な質問
目次
データエンジニア・データアナリストの求人票、なぜ違いが曖昧になるのか
まず押さえておきたいのは、この3職種の境界は企業側にとってもあいまいだという事実です。厚生労働省の職業情報提供サイト(job tag)では、データエンジニアの仕事内容を「データの前処理」「情報基盤の構築・運用」「教師データの作成」などと整理していますが、実際の求人票ではこの範囲が企業ごとに大きくずれます。
理由は単純で、データ分析基盤を専門の人員で分業できるほど組織が大きい会社はまだ少数派だからです。私が担当してきた求人でも、従業員300人未満のIT企業では「データエンジニア」の求人でありながら、実質的にダッシュボード作成とレポーティングが業務の半分を占めるケースをよく見ます。逆に「データアナリスト」の求人票なのに、BigQueryのテーブル設計やAirflowでのバッチ処理構築が業務の中心という会社もあります。
採用担当者自身が3職種の違いを厳密に理解しないまま求人票を書いていることも珍しくありません。人事部門が現場のエンジニアやデータ組織の責任者にヒアリングして求人票を作る際、「分析もできて基盤もいじれる人が欲しい」という現場の要望をそのまま「データアナリスト」や「データエンジニア」という一つの肩書きに押し込めてしまう。求人媒体側も検索されやすい職種名を優先してタイトルをつけるため、実態と名称がさらに離れていきます。
さらに、求人媒体は検索ボリュームの大きい職種名でタイトルを立てる傾向があります。「データアナリスト」の方が「データ基盤エンジニア」より検索する求職者が多ければ、実際の業務が基盤構築寄りでも、応募数を稼ぐために「データアナリスト」と名付けられることがある。これは求人企業の悪意というより、採用マーケティング上の判断として起きている現象です。私が企業担当者から直接この事情を聞くこともあり、肩書きは検索されやすさで決まっていることがあるという前提で求人票を読む必要があります。
求人票の文言から3職種を見分けるチェックリスト
とはいえ、求人票の文言をよく読めば、ある程度は職務範囲を絞り込めます。私が求人票を精査するときに見ているのは、肩書きそのものではなく「動詞」と「成果物」の部分です。
求人票の文言パターンと、実際に近い職種の目安です。
- 「分析基盤の設計・構築・運用」「ETL/ELT開発」「DWH整備」→ データエンジニア寄り
- 「意思決定支援」「ダッシュボード作成・改善」「分析レポート提供」→ データアナリスト寄り
- 「機械学習モデルの開発・検証」「予測モデル構築」「A/Bテスト設計」→ データサイエンティスト寄り
- 「SQL必須」のみで技術要件が完結する→ アナリスト寄りの可能性
- 「AWS/GCP」「Airflow」「dbt」「Kafka」など固有名詞が並ぶ→ エンジニア寄りの可能性
厄介なのは、この動詞と成果物の記載が求人票の中で1〜2行しかなく、他の大半が「データドリブンな意思決定を推進」「事業成長に貢献」といった抽象的な文言で埋まっているケースです。抽象的な文言が多いほど、書いた採用担当者自身も業務範囲を明確にイメージできていない可能性が高いというのが、数百件の求人票を見てきた私の実感です。
もう一つ見ているのは、必須スキルと歓迎スキルの並び順です。SQLとExcel・BIツールが必須で、Pythonやクラウド基盤が「歓迎」止まりの求人は、実務でもその優先順位どおりに配分される傾向があります。反対にPythonでのコーディング経験が必須要件の筆頭に来ている場合、面談でどれだけ「分析寄りです」と説明されても、実際の業務の大半はコードを書く時間になると考えた方が現実に近いです。
以下は、私が求人票を見るときに大まかな目安として使っている整理です。あくまで傾向であり、会社ごとに例外は多いという前提で見てください。
| 観点 | データエンジニア | データアナリスト |
|---|---|---|
| 主な成果物 | パイプライン・DWH・分析基盤そのもの | レポート・ダッシュボード・示唆 |
| 主要言語/ツール | Python、SQL、クラウド基盤(AWS/GCP等) | SQL、Excel、BIツール(Tableau等) |
| 相手にする対象 | データそのもの、システム | 事業部門の意思決定者 |
| 求人票で近い距離感 | 「ビジネスから遠い」と表現されがち | 「ビジネスに近い」と表現されがち |
求人票の外側にある情報も手がかりになる
求人票の文言だけで判断がつかないときは、企業の採用サイトやテックブログ、Wantedlyのストーリーページも合わせて見るようにしています。データ組織の責任者が自社のブログで「分析基盤をどう作ってきたか」を発信している会社なら、エンジニアリング寄りの色が強いと分かりますし、逆に「事業インパクトをどう出したか」という発信が多い会社なら、意思決定支援に軸足があると推測できます。
求人票1枚だけで判断せず、その会社がデータ組織についてどんな言葉で発信しているかを数分でも眺めておくと、面談での質問の精度も上がります。
「アナリティクスエンジニア」という肩書きにも注意する
ここ数年、求人票で目にする機会が増えたのが「アナリティクスエンジニア」という肩書きです。dbtというツールの普及とともに広まった呼び方で、データエンジニアが構築した基盤の上で、SQLを中心に分析用のデータモデルを整える役割を指すことが多い職種です。
厄介なのは、この肩書きが会社によって指す範囲がまちまちな点です。ある会社では「データエンジニアの下流工程を切り出したポジション」として使われ、別の会社では「データアナリストのうち、SQLでのモデリングが得意な人向けの上位職」として使われています。どちらも間違いではないのですが、同じ肩書きでも会社によって基盤寄りか分析寄りかが逆転することがあるので、データエンジニア・データアナリストの2職種以上に、求人票の文言と面談での確認が欠かせません。
私の感覚では、求人票に「dbt」「Analytics Engineer」という単語が出てきたら、SQLでのデータ変換作業がかなりの比重を占めると考えてよいと思います。一方でPythonでのパイプライン構築や、インフラのプロビジョニングまで求められるかどうかは会社次第なので、この肩書きが出てきたときこそ、先ほどのチェックリストに立ち返って動詞と成果物を確認してほしいところです。
経理職からデータアナリスト求人に応募、実際はコードを書く日々だった
実際にあったケースを一つ紹介します。Nさんは35歳、経理・管理部門で9年働いてきた方で、EC事業を展開する中堅企業の経理として月次決算の数字を扱う中で、データ分析の仕事に興味を持ちました。応募したのは「データアナリスト」という肩書きの求人で、求人票には「売上データの可視化とBIツールを使ったレポーティング」と書かれていました。
入社して最初の1週間、Nさんに割り振られたタスクは、Pythonで書かれた400行ほどのETLスクリプトのバグ修正でした。それまでExcelの関数とTableauの画面操作しか経験がなく、Pythonのコードを見るのも初めてに近い状態です。配属先はデータ基盤チームで、上司からは「分析もするけど、まずはパイプラインを触れるようになってから」と告げられました。
Nさんが転職エージェント経由で私に相談してくれたのは、入社2ヶ月が過ぎた頃でした。「求人票に書かれていたことと、実際にやっていることが違いすぎる」というのが率直な訴えです。求人票の文面を一緒に見返すと、「BIツールを使ったレポーティング」という一文の直後に「データパイプラインの理解があると尚可」という小さな一文があり、この「尚可」が実際には業務の中心になっていました。
面談で確認できなかった原因を振り返ると、Nさんは面接で「分析業務のウェイトはどのくらいですか」とは聞いていましたが、「入社直後の数ヶ月は何を担当するか」までは聞いていませんでした。会社側にも悪意はなく、基盤が整っていない状態で分析だけを回せるチームではなかったというのが実情です。
Nさんが上司に相談したときに意識したのは、「業務が違う」と不満だけを伝えるのではなく、経理での9年間で培った数字の読み方をどう分析に活かせるかを具体的に示すことでした。月次決算で異常値を見つけていた経験を例に、「レポーティングの精度を上げる形で貢献できる」と伝えたところ、上司も配属の意図を再考してくれたそうです。半年かけて基盤構築とレポーティングを半々にする配分に調整してもらい、今は当初希望していたダッシュボード設計にも関われるようになっています。
求人票の曖昧さは法律上どこまで許されるか
ここまでは業界慣行の話ですが、求人票の記載には法律上の裏付けもあります。職業安定法第5条の3では、求人企業に対して業務内容・契約期間・就業場所など労働条件を書面などで明示する義務が課されています。厚生労働省の案内では、求人票そのものは「申込みの誘引」に過ぎず、原則として実際の労働契約の内容は別途確認・合意する必要があるとされていますが、ハローワークや職業紹介事業者に虚偽の条件で求人申込みをした者は、6か月以下の懲役または30万円以下の罰金の対象になると説明されています(出典:厚生労働省「求人票や求人広告に記載された条件が、実際の条件と違った場合の対処法」)。
明示が義務づけられている労働条件には、業務内容そのものも含まれています。求人票の業務内容欄が「データを活用した意思決定支援」の一文だけで終わっているとしたら、それは書式としては成立していても、応募者が実際の業務を判断できる情報量には達していないと私は見ています。書いていないことを責めるより、書かれていない部分こそ面談で埋める対象だと割り切って臨む方が現実的です。
2024年4月1日からは労働条件明示のルールも改正され、ハローワークへの求人申込みでは、業務内容に加えて「従事すべき業務の変更の範囲」「就業場所の変更の範囲」、有期契約の場合は更新の基準も明示が必要になりました(出典:山口労働局「求人申込み時の労働条件明示のルールが変わります」)。これはハローワーク求人の申込みに関する案内で、民間媒体の求人票すべてに同じ記載が出るわけではありません。ただ、ハローワーク経由の求人や、この欄を設けている求人であれば、「変更の範囲」を見ると、データアナリスト名義でも将来データ基盤の業務に就く可能性があるのかを読み取る手がかりになります。
ポイント: 求人票と実際の業務内容が食い違うこと自体は、ある程度は起こり得るという前提で読む必要があります。ただし「分析業務」とだけ書いておいて実態が丸ごとインフラ構築という場合のように、職務内容の中心が別物と言えるほどのズレがあれば、話は別です。厚生労働省のハローワーク求人ホットラインなど、相談窓口も用意されています。
私がこの問題を法的にどう見ているかというと、求人票の1〜2行の抽象的な表現だけで採用担当者を一方的に責めるのは酷だと思っています。組織が小さいうちは業務範囲自体が流動的で、書きようがないという実情もあるからです。一方で、面談の場で業務内容を尋ねたときの回答まで曖昧なまま入社を決めてしまうのは、応募者側にもリスクが残る、というのが率直なところです。求人票が抽象的なら、その分だけ面談での確認密度を上げる必要があります。
スカウト経由の求人ほど職種名があいまいになりやすい
求人票そのものよりさらに注意したいのが、スカウトメール経由でのアプローチです。スカウト文面は採用担当者が求人票の一部をコピーして送っていることが多く、職種名だけを見て「データアナリストの経験がある方にお声がけしました」と送られてくるケースがあります。実際には社内のデータ基盤エンジニアのポジションを、検索でヒットしやすい「データアナリスト」という言葉で括って一斉送信していただけ、ということも珍しくありません。
このパターンは、スカウト文面の個別性を見極める視点とも重なります。以前、スカウトメール一斉送信の見分け方で、データ基盤エンジニアとして働いていた方が、求人ページの年収・技術スタックとスカウト文面の実態が乖離していた例を紹介しましたが、データ関連職はこの手のズレがとくに起きやすい領域だと感じています。スカウトを受けたら、まず求人票の原本を自分で読み、そこに書かれている動詞と成果物を確認する。スカウト文面の肩書きだけを鵜呑みにしないことが、最初の防御線になります。
オファー面談・カジュアル面談で確認すべき質問
求人票の文言だけで職務範囲を確定させるのは難しいので、面談での質問がそのまま入社後ギャップの防止策になります。私が求職者に勧めているのは、次のような具体性の高い聞き方です。
面談で聞いておきたい質問の例です。
- 「入社後最初の3ヶ月、具体的にどんなタスクが多いですか」——直近入社した人の実例を聞く
- 「基盤構築とレポーティングの時間配分は、感覚としてどのくらいですか」——数字で答えられるか
- 「直近半年で対応したタスクを1〜2件教えてもらえますか」——具体例が出るか
- 「チームには何人いて、それぞれ何が専門ですか」——分業できる体制があるか
- 「使っている主要なツール・言語を頻度順に教えてください」——「歓迎スキル」欄が実は主業務ということも
- 「従事すべき業務の変更の範囲」欄に、データ基盤の構築・運用が含まれていないか——書面で確認する
これらの質問に対して面接官が言葉に詰まったり、「その時々で変わります」としか答えられない場合は、業務範囲がまだ社内でも固まっていないサインだと捉えた方がいいというのが私の見立てです。固まっていないこと自体が悪いわけではありませんが、その状態を認識しないまま「分析職として入る」つもりで入社すると、Nさんのようなギャップが起きやすくなります。
逆に、面接官が担当者の名前は出さずとも「先月入った人はまずこの範囲を担当してもらいました」と具体的に答えられる会社は、業務の輪郭がある程度できあがっていると見てよいと思います。求人票の抽象度が高いほど、面談での確認の重みが増すという構図は、職種を問わずIT・Web業界の求人全般に共通しています。
年収相場とキャリアパスの違い
職務範囲だけでなく、年収相場にも差があります。求人ボックス給料ナビの集計によると、データアナリストの平均年収は約723万円、月給ベースで約60万円、正社員の年収分布は約418万〜1,242万円と幅があります。都道府県別では最も高い東京都が749万円程度、最も低い大阪府が622万円で、差は約127万円です。いずれも2026年9月時点の求人ボックス掲載求人から算出された値です(出典:求人ボックス給料ナビ「データアナリストの仕事の平均年収」)。
一方、厚生労働省の職業情報提供サイトによると、データエンジニアの全国平均年収は約610万円、月額給与は32.7万円で、スキルレベルによって420万〜950万円まで幅があるとされています(執筆時点の掲載値。出典:job tag「データエンジニア」)。ただし出典によって水準には幅があり、転職エージェントの自社データベースでは、データエンジニアの平均が558万円という集計もあります(出典:ギークリー)。集計の母集団が異なるため単純比較はできませんが、基盤構築のスキルが積み上がるほど年収の伸びしろが大きくなるという傾向は、私が担当してきた求人でも実感としてあります。
キャリアパスの面でも違いがあります。データアナリストとして経験を積んだ人が事業側のPdMやマーケティング責任者へ横に広がっていくケースが多いのに対し、データエンジニアは基盤構築の経験を積んでMLOpsやプラットフォームエンジニアへ縦に深掘りしていくケースが目立ちます。どちらが優れているという話ではなく、自分が「事業側に近づきたいのか」「技術基盤を極めたいのか」で、選ぶべき求人票の読み方も変わってくるというのが実務上の分かれ目です。
在籍する会社の業態によっても水準は変わります。SES・受託で分析基盤の構築案件に入っている人と、自社サービスを持つ事業会社でデータエンジニアとして働く人とでは、後者の方が事業成果に直結する分だけ評価が上がりやすいと、私が担当してきた求人を振り返っても感じます。データアナリストも同様で、事業部門と近い距離で意思決定に関わっているかどうかが、レンジの上振れを左右します。
未経験からはどちらを目指しやすいか
異業種からのキャリアチェンジを考える方によく聞かれるのが、「未経験ならデータアナリストとデータエンジニア、どちらが目指しやすいか」という質問です。私が担当してきた実績ベースで言うと、入り口の広さはデータアナリストの方が明らかに広いというのが実感です。
Nさんのように経理・マーケティング・営業企画といった数字を扱う職種からは、ExcelやBIツールの操作経験を土台にしてデータアナリストへ横滑りできるケースが一定数あります。一方でデータエンジニアは、求人票に「未経験歓迎」と書かれていても、実際にはプログラミング未経験者を一から育てる余裕のあるチームは限られており、何らかの形でコードを書いた経験(社内SEでの簡単な自動化スクリプト、独学でのPython学習など)を持っている人が優先される傾向があります。
とはいえ、未経験可の求人票がすべて信用できないという話ではありません。「未経験可」の4文字だけでなく、教育体制や配属後の育成計画が具体的に書かれているかを見る視点は、データ関連職に限らずIT・Web業界の求人全般に共通します。この見方は「未経験可」求人票の言葉の温度差でも詳しく取り上げているので、あわせて読んでもらえると理解が深まると思います。
よくある質問
求人票に「データサイエンティスト」と書かれているのに、実態はデータアナリストに近い業務ということもありますか。
あります。とくにデータサイエンティストという肩書きが採用ブランディングとして使われている会社では、実際の業務が統計分析やBIツールでのレポーティングにとどまっているケースを見てきました。求人票の「機械学習モデルの開発」という一文が、実際には既存のライブラリを使った簡易的な予測にとどまることも珍しくありません。
未経験からデータエンジニアを目指す場合、どんな求人票に注意すべきですか。
「未経験歓迎」と「クラウド基盤構築経験必須」が同じ求人票に併記されているケースには注意が必要です。実務未経験でもポテンシャル採用する意図なのか、単に人事側が要件を精査せずテンプレートで書いているだけなのかは、面談で「未経験者に実際に任せている業務範囲」を具体的に聞かないと見分けがつきません。
入社後にギャップに気づいた場合、早期離職を検討すべきですか。
業務範囲のズレそのものより、会社側にそのズレを調整する意思があるかどうかで判断すべきだと思います。Nさんのケースのように、上司に希望を伝えて配分が変わる会社もあれば、伝えても変わらない会社もあります。放置されたまま数ヶ月が過ぎている場合の見極め方は、中途入社後に放置、早期離職すべきかの見極め方でも詳しく扱っています。
面接官によって業務内容の説明が食い違う場合は、どう判断すればいいですか。
一次面接の現場社員と最終面接の役員とで、業務範囲の説明の粒度が違うのはよくあることなので、それ自体は問題ありません。注意したいのは、説明の粒度ではなく方向性そのものが食い違う場合です。「分析中心です」と「基盤構築が中心です」のように主軸が真逆になっているなら、社内でも認識がすり合っていない可能性が高いので、両方の面接官が答えた内容をそのまま人事に伝えて、改めて整理してもらうよう依頼するのが安全です。
まとめ、求人票の職種名より「動詞」と「成果物」を見る
データエンジニアとデータアナリストの違いは、求人票の肩書きだけを見ていても分かりません。「データ」という言葉の周りにどんな動詞と成果物が並んでいるかを読み解くことが、入社後ギャップを避ける一番の近道だというのが、この記事で一番伝えたかったことです。
求人票が抽象的なままなら、それを面談で埋め合わせる質問を用意しておく。私はそのための質問リストを常に求職者と一緒に見直しています。肩書きに引きずられて「分析の仕事だと思っていたのに」と後から気づくのではなく、応募する前の数分間で、動詞と成果物を確認する習慣をつけてもらえたらと思います。




