SIer→データエンジニアの職務経歴書｜通過率30%→70%の翻訳例とテンプレ【2026年】

※本記事には広告（PR）を含みます。後半で紹介する転職サービスは、筆者が転職時に実際に利用したサービスのPRです。市場価値を一次情報で確かめる手段の一つとして挙げています。

「書類が全然通らない…」

SIerからデータエンジニアへの転職活動で、最初にぶつかる壁がこれです。私（SIer出身→事業会社のデータエンジニア→現在はデータアーキテクト）も、転職活動の序盤は書類でかなり落ちました。

原因のひとつは単純で、SIerの職務経歴書をほぼそのまま出していたからです。

SIerで「当たり前」に使う言葉は、事業会社の採用担当には馴染みがありません。「JP1でバッチ処理を運用」と書いても、データエンジニアを採用する人事には価値が伝わりにくいのです。

正直に言うと、書類が通り始めた要因は「書き方を直したこと」だけではありません。私はIT特化のエージェントを3社使い、応募社数も増やし、最初の担当がSnowflakeを知らずに3ヶ月遠回りした末に乗り換えています。だから「翻訳すれば一発で通る」とは言えません。それでも、用語の翻訳は誰でもすぐ着手できて、効果も実感しやすい一手でした。この記事では、SIerの経験を「データエンジニアの言葉」に翻訳する具体的な方法を、Before/After例＋テンプレート付きで解説します。

なぜSIerの職務経歴書では通らないのか（3つの理由）

理由は3つあります。

理由1：使っている言葉が違う。 SIerで「バッチ処理」と呼んでいるものは、データエンジニアの世界では「ETLパイプライン」と表現されることが多いです。実態は近いのに、言葉が違うだけで経験を見落とされる（=未経験寄りに読まれる）ことがあります。

理由2：プロジェクト記述が「作業」に見える。 SIerの職務経歴書でよくある書き方が「基本設計・詳細設計・製造・テストを担当」。これは何をやったかは書いてあるけれど、どんな価値を生んだかが書かれていません。

理由3：技術スタックの書き方が古い。 「Oracle Database 12c、JP1、Eclipse」と書かれた職務経歴書は、モダンなデータ基盤を構築したい企業には刺さりません。本質的なスキルは共通しているのに、見え方で損をしています。

採用側がチェックしている3つの観点

逆に、データエンジニアを採用する企業の人事・エンジニアが何を見ているのかを知っておくと、書く内容の優先順位が決まります。

この3点を意識して書くと、SIerの経験が「同じ仕事の言い換え」ではなく「評価対象になる経験」として伝わります。

Before / After で見る翻訳術

プロジェクト概要の書き方

Before（SIer的な書き方）: > 大手小売業向け基幹システムのリプレイス案件にて、Oracle Databaseの基本設計・詳細設計・開発・テストを担当。JP1によるバッチ処理の設計・開発・運用を実施。

After（データエンジニア的な書き方）: > 大手小売企業のデータ基盤刷新プロジェクトにおいて、データモデリング（スタースキーマ設計）からETLパイプラインの設計・構築、ワークフローオーケストレーションの設計・運用まで一貫して対応。日次バッチで約500万レコードを処理するパイプラインを設計・実装。

ポイント:

• 「基幹システム」→「データ基盤」に言い換え
• 「基本設計・詳細設計」→「データモデリング（スタースキーマ設計）」と具体化
• 「バッチ処理」→「ETLパイプライン」に翻訳
• 処理件数などの数字を追加

スキルセクションの書き方

Before: > – Oracle Database 12c（設計・開発・運用 5年） > – SQL（ストアドプロシージャ、パフォーマンスチューニング） > – JP1（バッチジョブ設計・運用） > – Excel VBA（データ集計ツール開発）

After: > – RDB設計・運用（5年）：データモデリング、パフォーマンスチューニング、RBAC設計 > – SQL（5年）：複雑なJOIN、Window関数、CTE、集計クエリの設計・最適化 > – ETLパイプライン設計・運用（3年）：日次/月次バッチの設計、エラーハンドリング、リカバリ設計 > – データ品質管理：整合性チェック、異常値検知の仕組み構築 > – クラウドDWH：Snowflake（トライアルで学習中）

ポイント:

• 製品名ではなくスキルカテゴリで分類
• 「JP1」という製品名は外し、「ETLパイプライン設計・運用」という汎用スキルとして記載
• Snowflakeは「学習中」でもいいので記載する
• VBAは外す（データエンジニアには不要）

成果・実績の書き方

Before: > 品質管理として、バグ件数0件でリリースを達成。

After: > データパイプラインの品質担保として、リリース前のデータ品質テストを設計・導入。NULLチェック、ユニーク制約、参照整合性の自動テストにより、本番障害の発生を0件に維持。

ポイント:

• 「バグ件数0件」→「データ品質テストを設計・導入」と主体的な取り組みとして記載
• 具体的にどんなテストをしたかを記載

自己PR・志望動機の書き方

Before: > SIerで5年間、お客様の要件に応えるシステムを構築してきました。データエンジニアとしてさらに成長したいです。

After: > SIerでの5年間、RDBを中心としたデータ基盤の設計・運用に従事し、特に大規模データのモデリングと品質管理に強みがあります。一方で、SIerでは技術選定の自由がなく、モダンデータスタック（Snowflake、dbt等）の実務経験を積めない環境であったため、事業会社のデータエンジニアとして自分の手でアーキテクチャを設計・進化させていきたいと考えています。

ポイント:

• 強みを 具体的なスキル領域 で示す
• 転職理由を 環境の違い（受託 vs 自社）で説明（前職批判にしない）
• 入社後やりたいことを 技術スタック名 で具体化

翻訳に使える対応表（12項目）

職務経歴書テンプレート（コピペOK）

以下のテンプレートをベースにカスタマイズしてください。

【職務要約】
SIerにてRDBを中心としたデータ基盤の設計・構築・運用に[X]年間従事。
データモデリング、ETLパイプラインの設計・実装、RBACによるアクセス制御の設計を一貫して担当。
直近ではクラウドDWH（Snowflake）の技術キャッチアップを進めており、
データエンジニアとしてモダンデータスタックを活用した基盤構築に携わりたいと考えています。

【プロジェクト経歴】
■ [企業名/業界] データ基盤構築プロジェクト（[期間]）
[役割]: データモデリング〜ETLパイプライン設計・構築
[規模]: [チーム人数]名、[期間]
[担当]:
・[業務ドメイン]のデータモデリング（スタースキーマ設計、[テーブル数]テーブル）
・ETLパイプラインの設計・実装（日次[処理件数]レコード）
・RBACの設計・運用（[ロール数]ロール、[ユーザー数]ユーザー）
・データ品質テストの設計・自動化
[成果]:
・パイプラインの処理時間を[X]%短縮
・データ品質テスト導入により本番障害を[X]件→0件に削減

【スキル】
・データモデリング（スタースキーマ、正規化設計）：[X]年
・SQL（Window関数、CTE、パフォーマンスチューニング）：[X]年
・ETLパイプライン設計・運用：[X]年
・RBAC設計・権限管理：[X]年
・クラウドDWH：Snowflake（学習中）

やりがちな失敗パターン3選

自分の職務経歴書を直すなかで、また周囲のSIer出身者の書類を見ていて、よく見かける失敗パターンです。

失敗1：技術スタックを羅列するだけ > Oracle, JP1, Java, Eclipse, SVN, Excel…

→ 経験年数・習熟度・どんな場面で使ったかを必ず併記する。

失敗2：「複数案件を担当」で詳細を省く > 5年間で計10案件を担当。

→ 1〜3案件に絞って具体的に書く方が評価されます。

失敗3：成果が「定性的」 > プロジェクトを成功に導いた／メンバーから信頼を得た

→ 数字（%、件数、時間）で書けないか必ず見直す。

添削を他人に頼むなら（選択肢と注意点）

自分で翻訳しきれない部分は、第三者の目を入れると精度が上がります。主な選択肢は3つで、それぞれ一長一短です。

私自身はIT特化のエージェントを3社使いましたが、最初に「とりあえず大手」で登録した担当はSnowflakeを知らず、噛み合うまで3ヶ月ほど遠回りしました。エージェントは「無料で実務知識が手に入る」反面、担当の専門性と相性に強く依存します。データ職に詳しい担当に当たれば「この経験はこう書いた方が刺さる」という具体的な指摘がもらえますが、外れたら遠慮なく担当変更・乗り換えをした方が早い、というのが実感です。営業色や連絡頻度が合わないと感じたら距離を取って構いません。

なお、添削が通過率を押し上げたのは事実ですが、私の場合は同時に応募社数も増やしているため、改善が添削だけによるものとは言い切れない点は付け加えておきます。

よくある質問（FAQ）

Q. 職務経歴書は何ページにすべきですか？ A. 経験5年なら 2〜3ページ が目安です。1ページに圧縮すると情報量が足りず、4ページ以上は読まれません。プロジェクト経歴を1〜3個に絞って深掘りするのが正解。

Q. 未経験のデータエンジニアスキル（Snowflakeなど）も書いていいですか？ A. 書いた方がいいです。「学習中」「個人プロジェクトで使用」と注記すれば誤解されません。むしろ書かないと「キャッチアップ意欲がない」と見られるリスクがあります。

Q. 顧客名・プロジェクト名は伏せるべきですか？ A. SIer出身者はNDA上、伏せるのが基本です。「大手小売企業」「金融業界の上場企業」など業界名・規模感だけ書きましょう。

Q. 書類通過率を上げるのに最も効くのは？ A. 数字の追加です。「日次500万レコード」「テーブル80本」「メンバー15名のチーム」など、定量情報があるだけで採用側の印象が大きく変わります。

Q. SIer特有の経験（顧客折衝、要件定義）は書かない方がいい？ A. 書きます。むしろ事業会社では「ビジネスサイドとの折衝経験」として高評価されることが多いです。「データ要件定義」「ステークホルダー調整」と翻訳して記載してください。

まとめ

SIerの職務経歴書がデータエンジニアの選考で通らない原因は、スキルが足りないのではなく「書き方」の問題です。

ポイントを再掲します。

• 用語を翻訳：バッチ処理→ETLパイプライン等、12項目の対応表を活用
• 数字を追加：処理件数・テーブル数・チーム人数で具体性を出す
• 意図を書く：「○○のため△△を選定」と意思決定の理由を明記
• 第三者の目を入れる：エージェント・有料添削・知人のいずれも一長一短。データ職に詳しい相手を選ぶ

書き方を整えると、少なくとも「価値が伝わらずに落ちる」パターンは減らせます。この記事のBefore/Afterと翻訳表を使って、まずは職務経歴書を自分で書き換えてみてください。

書き換えた職務経歴書を、市場で試したい人へ

職務経歴書を直したら、次は外からの反応で答え合わせをするのが手っ取り早いです。スカウト型サービスにプロフィールを登録しておくと、経歴に関心を持った企業から打診が届くことがあり、どの企業が・どのくらい反応するかが経歴書の出来を測る一つの目安になります。

下記は、私が転職時に実際に使ったサービスのひとつです。提示額（自分の経歴が企業からどう評価されるか）を一次情報で見られたのが、年収交渉のときの材料になりました。とはいえ複数のサービスを並行して見比べていたので「ここが一番」とは言いません。市場価値を一次情報で確かめる入口の一つとして、合いそうなら覗いてみてください（複数登録すると担当の当たり外れを比較しやすくなります）。

レバテックダイレクト（PR）：経歴書への企業の反応を見てみる

※上記はアフィリエイトリンク（PR）です。登録・利用は無理に勧めません。判断材料として挙げているだけで、合わなければ使わなくて問題ありません。

▼ 関連記事

• SIerを辞めて「事業会社のデータエンジニア」に転職した話
• データエンジニアの年収は400〜1000万円｜SIer→+100万の実体験【2026年】
• Snowflake未経験でもデータエンジニアに転職できた理由
• データエンジニアが転職エージェントを3社使って気づいた「選び方の正解」
• データエンジニアになるためのスキル・ロードマップ