SESエンジニアのスキルシートを「脱・作業者」で書き直す：正社員転職で年収を上げる実践リライト術
「スキルはあるのに書類で落ちる」——その本当の理由
転職活動を始めたばかりの頃、こんな経験はないでしょうか。「現場ではそれなりに評価されているし、スキルも積んできた。でも書類選考を出しても出しても、通過の連絡が来ない」。
特にSES（システムエンジニアリングサービス）で働いてきたエンジニアに多いのが、この「スキルと書類評価の乖離」問題です。SES現場では客先に提出するためのスキルシートを日常的に使いますが、それをそのまま転職活動に流用してしまうケースが後を絶ちません。
しかし、SESのスキルシートと転職用スキルシートは、根本的に目的が異なります。SES向けは「どの案件にアサインできるか」を判断するための技術カタログ。一方、転職市場で求められるのは「この人が自社に入ったら何を解決してくれるか」を想像させるストーリーです。この違いを理解せずに書き続けても、書類通過率は上がりません。
この記事では、5〜10年のSES経験を持ち「そろそろ自社サービス企業や事業会社に移りたい」と考えているエンジニアを対象に、スキルシートを「作業者の記録」から「即戦力の証明」へと書き直す具体的な方法を解説します。ビフォー/アフターの実例も交えながら、読み終わったらすぐに手を動かせる内容にしています。
採用担当者・エンジニアリングマネージャーは「何秒で」「何を見ているか」
書類は最初の10秒が勝負
採用担当者が初回スクリーニングで1枚のスキルシートに費やす時間は、最初の確認だと数十秒程度と言われています。この短時間で「続きを読むかどうか」が決まります。では最初に目が止まる場所はどこか。それは冒頭の「職務要約（サマリ）」と「技術スキル一覧」の2か所です。
採用担当者が職務経歴書やスキルシートを評価する際の4つの軸として、「実務経験（経験年数・担当フェーズ）」「技術スキル（言語・FW・クラウドの習熟度）」「プロジェクト規模と役割（チーム人数、担当範囲、リーダー経験の有無）」「自己研鑽（資格・学習・技術発信のキャッチアップ姿勢）」が挙げられており、このうち「担当フェーズ」と「役割」が最も重視されます。
つまり、どの言語を何年使ったかよりも、「プロジェクトの中でどのフェーズに責任を持ち、どんな判断をしたか」の方が採用側には刺さるのです。
現場エンジニア（技術面接官）が見るポイントは別にある
採用プロセスが進むと、現場のテックリードやエンジニアリングマネージャーがスキルシートを読む段階になります。ここで彼らが見るのは「技術スタックが自社と合うか」だけではありません。
スキルシートの主な読み手がエンジニア・PM・CTOである場合に評価されるポイントは「スキルの網羅性・即戦力性」であるのに対し、採用担当・人事・マネージャーが読む職務経歴書では「ストーリー性・再現性・成長プロセス」が評価される。つまり、スキルシートと職務経歴書はそれぞれ異なる読者に向けて書くものであり、技術面接官には即戦力の根拠を、人事には成長の文脈を伝える構成が必要です。
現場エンジニアが特に気にするのは「習熟度の解像度」です。言語名を並べるだけでは、実務で使えるのか触ったことがあるだけなのかが判別できないため、経験年数と習熟レベルをセットにすることが求められます。「Python 3年」ではなく「Python 3年・機械学習パイプライン構築経験あり、本番運用済み」のように粒度を上げると、一気に信頼度が増します。
SESエンジニアが陥る3大失敗パターンとリライト実例
失敗パターン①：スキルの羅列で終わる「カタログ型」
スキル・経験を単に並べただけのスキルシートは採用担当者に魅力的に映らず、自分の強みを伝えられていないことがほとんどです。これがいわゆる「カタログ型」の問題です。
よくあるビフォーはこうです。
- 【ビフォー】「Java / Spring Boot / MySQL / AWS / Git / Jenkins 使用経験あり」
- 【アフター】「Java（Spring Boot）を用いたREST API開発5年。AWS（EC2・RDS・S3）でのインフラ構築・運用経験あり。MySQLのインデックス設計・クエリチューニングまで担当。CI/CDはJenkins + Gitで整備し、デプロイ頻度を週1回から日次に改善。」
技術名は同じでも、「何ができるか」ではなく「何を改善したか」まで書くことで、採用側が入社後の姿をイメージしやすくなります。
失敗パターン②：SESのスキルシートをそのまま流用する
SESで使っている「スキルシート」の使い回しは絶対NGです。SES向けシートはアサイン判断のための技術カタログであり、転職市場に出すものとは目的が根本的に異なります。
SES現場で提出するシートには「担当業務：テスト・バグ修正・ドキュメント作成」といった記述が並びがちです。これをそのまま転職用に使うと、採用担当者の目には「指示を受けてこなしていただけ」に映ります。
- 【ビフォー】「担当業務：単体テスト・結合テスト・バグ票起票・修正確認」
- 【アフター】「品質保証フェーズのリードとして、テスト計画書の策定から実施・報告まで一貫して担当。バグ傾向を分析し、再発防止策として静的解析ツール（SonarQube）の導入を提案・実施。テスト工数を前フェーズ比で約3割削減。」
同じ業務でも、「提案」「判断」「改善」のキーワードが入るだけで、評価される人材像に変わります。「指示された作業をこなした」ではなく「課題を自分で発見して解決した」と書く方が、自走力の証明になります。再現性のある思考プロセスが書かれているかが重要です。
失敗パターン③：全プロジェクトを均等に書こうとする
10年のキャリアがあれば、プロジェクト数も多くなります。しかしすべてを同じ分量で書こうとすると、シートが長大になりすぎて「肝心のアピールポイント」が埋もれます。文章が冗長だったり、情報量が多すぎたりすると枚数が増えて読み手の負担になり、肝心なアピールポイントが伝わりにくくなります。記載した情報が読み手にとって必要かどうかを考え、本筋と関係の薄い情報や重複している記述は思い切って削除しましょう。
戦略的に書くなら、「直近3プロジェクトを詳しく」「古いプロジェクトは技術スタックのみ」という構成が王道です。応募先の求人票にある技術・業務ドメインに近いプロジェクトは分量を増やし、関係の薄いプロジェクトはコンパクトにまとめる。応募企業の業種・プロダクトに関連するプロジェクトを先に記載し、要件にマッチした技術スタックを優先的に強調するカスタマイズがポイントです。
「担当フェーズ」と「役割」の書き方で市場価値が決まる
上流経験を正確に伝えるための書き方
事業会社・自社サービス企業への転職で最も差がつくのが、「担当フェーズ」の記述です。要件定義や基本設計の経験があるのに「開発・実装」とだけ書いているエンジニアは非常に多い。これは非常にもったいない。
具体的には、各プロジェクトの記述に以下のチェックリストを使ってください。
- □ 担当フェーズ：要件定義／基本設計／詳細設計／実装／テスト／運用保守のどれか明示
- □ チーム構成：人数・自分のポジション（メンバー／リーダー／PL／PMなど）
- □ 自分が「判断」した場面：技術選定・設計方針・課題解決策など
- □ アウトカム：その判断の結果どうなったか（品質改善、工数削減、納期達成など）
マネジメント経験がある場合は、リーダーやPMとしての役割を具体的に書くことが重要です。進捗管理やメンバー教育、クライアントとの交渉などは、技術以外の強みとして評価されます。たとえ「チームリーダー」の肩書きがなくても、メンバーのコードレビューをしていた、新人の質問対応をしていた、という事実があれば、それは「メンター的役割」として書く価値があります。
技術選定の理由を書くと、一段上の評価になる
技術的なスキルの説明よりも「なぜその技術を選んだか」という判断軸が評価される傾向にあります。これが書けているエンジニアは、採用担当者から見て「自走できる人材」に映ります。
- 【ビフォー】「フレームワーク：React使用」
- 【アフター】「フロントエンドはReact（TypeScript）を採用。選定理由はコンポーネントの再利用性と型安全性を重視したため。チームの学習コストを考慮しNext.jsは見送り、シンプルなCRAベースでスタート。後のリプレイス時にもスムーズに移行できるよう設計した。」
「何を使ったか」ではなく「なぜ使ったか・どんなトレードオフを判断したか」まで書ける人は、シニアエンジニアやテックリードポジションの書類評価で明確に差がつきます。
スキルシートを「転職先別」にカスタマイズする戦略
応募型とスカウト型では最適解が違う
スキルシートは「1つ作れば完成」ではありません。転職の形態によって最適な構成が変わります。
ITエンジニアの職務経歴書（スキルシート）は、応募型とスカウト型で書き方が変わる理由があり、それぞれで評価される記述も異なります。
- 応募型（求人に自ら応募する場合）：求人票のキーワードに合わせて、マッチする経験を前面に出す。技術スタックの表現を求人票の言葉に寄せることで、スクリーニングを通過しやすくなる。
- スカウト型（Findy・LAPRASなどを使う場合）：特定の求人に絞らず、自分の強みが最大限見えるよう網羅的に記述する。企業がどんな人材を求めているかを想定し、技術的な深みや自己研鑽のエピソードを厚めに書く。
「スキルの活用実績」を証明できるかどうかが決め手
スキルは「取得」だけでなく「活用実績」をセットで示すことが重要であり、AI活用・クラウド運用・プロジェクトリードなど各カテゴリで具体的な成果指標を示すことが市場価値の証明につながります。
生成AIやクラウドの経験を書く際も同様です。「ChatGPT API使用経験あり」ではなく、「生成AI（OpenAI API）を活用した社内ナレッジ検索ツールを開発・本番リリース。問い合わせ対応の一部を自動化し、担当チームの対応工数を削減」のように、業務課題とアウトカムをセットで記述することで、技術トレンドへの対応力と実務能力を同時にアピールできます。
書き直す前に必ずやる「棚卸し作業」の手順
過去のプロジェクトを「5W1H」で整理する
スキルシートを書き直そうとしたとき、多くのエンジニアが最初につまずくのが「書くネタが思い浮かばない」という状態です。これは記憶力の問題ではなく、整理の方法の問題です。以下の手順で棚卸しをしてみてください。
- Step 1：参加したプロジェクトをすべて時系列で書き出す（社名・期間・業務内容を箇条書きで）
- Step 2：各プロジェクトに対して「自分が担当していなかったら困ったこと・変わっていたこと」を1つ書く
- Step 3：Step 2で書いたエピソードを「背景→自分の判断・行動→結果」の3行構造に落とし込む
- Step 4：3行構造を、転職先に合わせてどのキーワードで強調するかを選ぶ
実績を表す際には、売上や納期、担当したシステムの運用年数、その中で自らが携わった年数など具体的な数値を盛り込みましょう。記憶の中の「なんとなく改善した」というエピソードも、「〇〇日かかっていた処理が〇〇分に短縮」「〇名チームの進行を管理」のように数字と人数で表現すると、一気に説得力が増します。
第三者にレビューしてもらうことが最短の改善策
スキルシート作成で最も大切なのは、第三者に評価してもらうことです。数字を意識して詳細に記載することで、採用担当者は自社で活躍する姿をより鮮明にイメージできるようになります。
自分で書いたシートは「自分には当たり前のこと」が説明不足になりがちです。転職エージェントへの登録は、書類添削を無料で受けられる機会でもあります。完璧に仕上げてから登録するのではなく、「7割の完成度で持ち込んで、プロの目でフィードバックをもらいながら磨く」という使い方が実は効率的です。
まとめ：今日からできるアクション
スキルシートの書き直しは、転職活動の中で最もROIが高い作業のひとつです。スキルを新たに身につけるより、すでに持っている経験を正しく言語化する方が、書類通過率への即効性があります。
- アクション①：「棚卸し作業」を今週中に実施する
参加した全プロジェクトをリスト化し、各プロジェクトに「背景→自分の判断・行動→結果」の3行構造を書き出す。まず書けるプロジェクト1つから始めること。 - アクション②：技術スキル一覧の「習熟度」を書き直す
現在の技術スタック表から「使用経験あり」という曖昧な表記を削除し、「経験年数・実務での役割・習熟レベル（参照しながら使える／主導できる／設計・選定できる）」を3列で記載し直す。 - アクション③：最も自信のある1プロジェクトを「ビフォー/アフター」で書き換える
現在のSESシートの記述を「カタログ型」のビフォーとして、「課題→自分の判断→アウトカム」を含むアフター版に書き直してみる。これ1つが完成すれば、他のプロジェクトも同じフォーマットで書けるようになる。