SESスキルシートの書き方｜面談通過率を上げる7つのコツとNG例

スキルシートを提出してから面談に呼ばれない——この経験があるエンジニアは多い。

SESの案件参画では、書類審査（スキルシート）を通過しないと面談すら始まらない。面談を通過しないと案件が決まらない。スキルシートの質は「次の仕事に入れるかどうか」を直接左右する。

Heyday営業担当の篠田は、月約20件・累計2,400件超の面談に同席してきた。その経験から言えることがある。「通らないスキルシートには共通点がある。技術力の差ではなく、書き方の差で落ちているエンジニアが圧倒的に多い」。

代表の小川も同様の実感を持っている。SES事業6期目、エンジニア100名以上の単価交渉に直接関与してきた中で、スキルシートの書き方一つで単価に月10〜20万円の差が生まれる場面を繰り返し目にしてきた。

この記事では、Heydayの面談同席経験と実案件データをもとに、面談通過率と単価を同時に引き上げるスキルシートの書き方を具体的に解説する。

SESスキルシートと職務経歴書の違い

スキルシートは転職市場で使われる職務経歴書と似ているが、SES特有の流通経路を理解していないと本質的なズレが生まれる。

3つの構造的な違い

1. 読まれる人数が多い

一般的な職務経歴書は採用担当者1〜2名が読む。SESのスキルシートは、自社営業→取引先（元請け）営業→エンドクライアントの面談官、という複数のステークホルダーを順番に通過する。営業が「この人は売れる」と判断しないとクライアントに提案すらされない。つまりスキルシートは、エンジニア本人に届く前に営業フィルターを通過している。

2. 「売れるか」の文脈で読まれる

職務経歴書は「この会社に合うか」の視点で読まれる。スキルシートは「このプロジェクトで即戦力になるか」「この単価に見合うか」という文脈で読まれる。人柄や志望動機より、技術スタックと業務経験の具体性が優先される。

3. プロジェクト単位での記述が基本

職務経歴書は会社ごとにまとめることが多いが、スキルシートはプロジェクト単位で記述する。「A社に3年勤めた」ではなく、「A社勤務中にBシステムの開発（期間・規模・担当フェーズ・使用技術）」という書き方が基本だ。

SES特有の注意点

商流が深い（複数会社を経由する）場合、スキルシートは何度もコピーされて転送される。特殊なフォーマットや複雑な表は崩れやすい。Excelかスプレッドシートで崩れないシンプルなレイアウトにしておくことが実用上重要だ。

採用担当者が30秒で判断するポイント（経営者視点）

篠田が面談同席を重ねる中でわかったことがある。面談官がスキルシートを開いてから30秒で確認していることは、ほぼ3点に絞られる。

1. 技術スタック（使える技術が何か）

面談官が最初に確認するのは、求めている技術スタックとマッチするかどうかだ。言語・フレームワーク・DB・インフラ・開発ツールが一覧で把握できること。

落とされやすいのは「Java、Python、JavaScript、AWS、Docker、Kubernetes、TypeScript...」と羅列しているだけのパターンだ。「使えます」と「実務で設計・構築できます」は評価が全く異なる。実務レベルで使ったものと、学習程度のものを分けて書く必要がある。

採用担当の本音（小川代表）：「技術羅列系のスキルシートを見ると、面談官は全部に疑問符を付ける。『本当にAWSを使えるのか？』と面談で確認作業になり、エンジニアへの印象が防御的になる。逆に『実務3年・本番ECSの構築経験あり』と書いてあれば、その前提で話が始まる。」

2. 業務規模（どの規模のプロジェクトか）

プロジェクト規模は面談官にとって重要な判断材料だ。チーム人数・システムの規模（ユーザー数・リクエスト数など）・開発期間がわかると、「この人はこの規模の案件を経験している」という判断ができる。

Heydayで扱う案件では、「大規模プロジェクト（20名以上）の経験があるか」「数百万ユーザーのシステムを扱ったか」が条件になるケースが一定数ある。これを書いていないと、経験があっても伝わらない。

3. 担当フェーズ（どこまでやったか）

要件定義・基本設計・詳細設計・開発・テスト・運用保守のどこを担当したかは単価に直結する。上流工程を担当したことがある場合、それを明確に示すだけで単価の交渉余地が生まれる。

Heydayの2026年Q1データでは、要件定義・基本設計の経験があるエンジニアの案件単価は、開発・テストのみ経験者と比べて平均10〜15万円高い。この経験がスキルシートに書かれていないと、そもそも面談にすら至らない。

経験年数別スキルシートの書き方

スキルシートの書き方は経験年数によって戦略が異なる。篠田の面談同席経験から、年数別の重点ポイントをまとめた。

経験0〜2年：「具体性」と「ポテンシャル」で勝負

年数が短い段階で最もやりがちな失敗は「何もアピールできない」と思い込んで記述が薄くなることだ。

重点ポイント

• 担当した機能を具体的に列挙する（「ユーザー認証機能の実装」「決済APIとの連携実装」など）
• 業務外の学習・個人開発を「学習中」として明記する
• プロジェクト内での積極的な行動（ドキュメント整備・コードレビュー参加・OJT補助）を書く
• チームコミュニケーションに関するエピソードを1行加える

NG: 「Javaの研修を受講。ECサイトの開発に参加した。」 OK: 「社内研修でJava/Spring Bootを6ヶ月習得。ECサイトのカート機能・注文確認メール送信APIを担当（5名チーム・メンバー）。レビュー指摘で習得したUTの書き方をチームのナレッジドキュメントにまとめた。」

篠田コメント：「0〜2年の方で面談に呼ばれやすいのは、規模の大小より『自分が何に関わったか』を具体的に書けている人。担当機能を細かく書くだけで印象が変わる。」

経験3〜5年：「専門性」と「役割の深さ」を見せる

3〜5年になると、面談官は「何かの専門家か」「チームでどんな役割を担えるか」を確認し始める。

重点ポイント

• 得意技術を1〜2本に絞り、「深さ」を示す記述を加える（バージョン・使ったサービス・設計した内容）
• リード・サブリードの経験があれば役割を明記する
• 上流工程（設計レビュー参加・仕様調整）への関与があれば1行加える
• クラウド経験がある場合は独立セクションで強調する

NG: 「AWS（EC2、S3）の経験あり。」 OK: 「AWS（EC2/ECS/RDS/S3/CloudFront）経験3年。本番環境のEC2→ECSコンテナ化移行を主担当として実施（Terraformでインフラコード化）。月間200万リクエストの環境でのパフォーマンスチューニング経験あり。」

経験5年超：「判断と設計ができる」を証明する

5年を超えると、面談官は「この人はリードできるか」「上流から入れるか」を最重要視する。

重点ポイント

• 設計した内容・判断した内容を具体的に書く（「〇〇を採用した理由」を一言加えると深みが出る）
• チームへの関与（レビュー・1on1・採用面接参加）を数字で示す
• 要件定義・基本設計フェーズの担当内容を詳述する
• 「なぜそのアーキテクチャを選んだか」を1行加えると、設計思考が伝わる

NG: 「要件定義〜運用保守まで担当。PL経験あり。」 OK: 「月間PV 500万のECサイトリニューアルでPLを担当。要件定義フェーズでは業務ヒアリング・WBS策定・UI設計レビューを実施。マイクロサービスへの移行判断でモノリスの技術的負債コストを試算し、経営層へ移行提案（採用）。12名チームの週次レビューリード。」

プロジェクト経験の書き方：「課題→行動→成果」の三段構成

スキルシートのプロジェクト記述で最もよく見るのは、「何をしたか」だけを書いているパターンだ。これでは面談官に「それで？」という印象しか残らない。

三段構成の型

課題: プロジェクトが抱えていた問題・背景 行動: 自分がどのように対応・解決したか 成果: 定量的・定性的な結果

実際の書き方例を比較する。

改善前（よくある書き方）

ECサイトのバックエンドAPI開発を担当。Javaを使用し、新機能の実装とバグ修正を行った。

改善後（三段構成）

月間PV 500万のECサイトのバックエンドAPI開発を担当（Java / Spring Boot / PostgreSQL）。注文処理のボトルネックを特定し、SQLクエリ最適化とキャッシュ実装で処理速度を40%改善。ピーク時の障害件数を月平均3件→0件に削減した。

改善後には、業務規模（月間PV 500万）・使用技術（具体的スタック）・課題（ボトルネック）・行動（SQLクエリ最適化・キャッシュ実装）・成果（処理速度40%改善・障害件数削減）がすべて含まれている。面談でこのプロジェクトについて掘り下げられても、具体的に答えられる。

数字が出ない場合の対処

「成果を数字で示せない」という声をよく聞く。数字を無理に作る必要はないが、規模感を示す数字は探せば出てくることが多い。

• ユーザー数・リクエスト数・データ量（「月間10万件のトランザクションを処理するシステム」）
• 開発チームの人数・期間（「10名チームで6ヶ月のプロジェクト」）
• 担当した機能・コードの規模（「機能追加15本・コードレビュー週10件」）

数字がどうしても出ない場合は「業界・領域・システムの規模感」を言葉で補う。「大手小売企業の基幹システム」「公共交通機関向けの予約システム」など、プロジェクトの背景を書くだけで実績の重みが伝わる。

単価を上げるスキルシートの見せ方（クラウド・上流経験の強調）

スキルシートは「何ができるか」の整理だが、単価交渉の観点では「何が希少か」を見せることが重要だ。

クラウド経験は独立させて目立たせる

AWSやAzure、GCPの経験は、技術スタックの羅列に埋もれさせると価値が伝わらない。独立したセクションを作るか、プロジェクト記述内で強調する。

クラウド経験（独立セクション例）

Heydayの2026年Q1実案件データでは、AI・クラウド系案件の単価は97〜106万円/月に対し、保守・CRUD系案件は68万円/月前後だ。40%の差がある。クラウド経験が正しく見えているかどうかは、単価に直結する。

小川代表コメント：「AWS経験者とそうでない場合の単価差は経験3年以上で月10〜20万円に達するケースがある。しかしこれは経験があることが前提ではなく、スキルシートにその経験が正しく書かれていることが前提だ。経験があってもスキルシートに埋もれていれば、面談官には見えない。」

上流工程経験は明示的に書く

「担当フェーズ：要件定義・基本設計・詳細設計・開発・テスト」と書いてあっても、どの案件で何をやったかが不明確だと信憑性が薄れる。上流経験がある場合は、そのプロジェクトで「何を定義・設計したか」を1〜2行で具体的に書く。

要件定義フェーズでは、業務ヒアリングシートの作成・顧客との要件調整・WBS策定を担当。PL（プロジェクトリーダー）補佐として5名のチームをサポートした。

「要件定義を担当した」ではなく「何を・どのように・誰とやったか」が書かれていると、面談官の評価が変わる。

複数案件の経験を横断して強みをまとめる

スキルシートの冒頭または末尾に「強みのサマリー」を置くと、複数のプロジェクトを読まずに強みが把握できる。

【強み】Java（8年）を主軸とした大規模Webシステムの設計・開発。AWS（EC2/ECS/RDS）を用いたクラウドインフラ構築・Terraform管理の経験あり。直近2プロジェクトでは要件定義・基本設計から参画。チーム規模は5〜15名のプロジェクトを多く経験。

このサマリーひとつで、面談官が「この人がどういう人か」を30秒で把握できる。

項目別NG例→OK例対比表（篠田の面談同席2,400件から）

篠田が累計2,400件超の面談に同席してきた中で、「ここが原因で通らなかった」と判断できる記述パターンがある。項目ごとにNG→OKの対比で整理する。

篠田コメント：「面談官が最初の30秒でパスする決め手は、ほぼ技術スタックと担当フェーズの2点。この2項目が具体的でないスキルシートは、そもそも面談に呼ばれないケースが多い。」

「この書き方で単価が上がった」実例（篠田経験から）

実際に篠田が関与した案件で、スキルシートの書き方を修正したことで結果が変わった事例を2つ紹介する（本人同意のもと、特定情報を匿名化）。

事例1：クラウド経験の「埋もれ」を解消→単価+12万円

状況: Javaバックエンド経験5年のエンジニア。AWS経験2年があったが、技術スタックの羅列の中にAWSと一行書いてあるだけだった。

修正内容: AWSセクションを独立させ、使用サービス（EC2/ECS/RDS/S3/CloudFront）・経験年数・実績（本番環境のコンテナ化移行・Terraform管理）を明記。プロジェクト記述にもAWS活用の具体的な記述を追加。

結果: 修正前の希望単価65万円で面談が決まらなかった状況から、修正後に77万円の案件で面談通過。採用担当のフィードバックは「インフラ含めて設計できる人だとわかった」。

事例2：「担当しました」から「何を判断したか」へ→リード案件獲得

状況: 経験7年のエンジニア。実態は要件定義から関与していたが、スキルシートには「担当フェーズ：要件定義〜開発」の一行だけ。

修正内容: 要件定義フェーズの内容を具体化。「業務ヒアリング20社・WBS策定・システム方式選定（オンプレvsクラウド移行の比較試算・クラウド移行を提案・採用）」を加筆。

結果: PLポジションを求める案件で面談通過。単価は+8万円。面談官のコメントは「要件定義で判断できる人だとわかった」。

書いてはいけないNG5パターン

Heydayで数百件のスキルシートを見てきた中で、面談が決まらないパターンには共通点がある。

NG1: 技術の羅列だけで実務レベルが不明

「Java、Python、JavaScript、AWS、Docker、Kubernetes、Go、Rust」と書いてあっても、すべてを実務で使ったのか、学習レベルなのかがわからない。面談官は「本当に使えるのか？」という疑念を持つ。

対策: 「実務経験あり」「学習中」「個人プロジェクトで使用」を区別して記載する。

NG2: プロジェクト期間が全部「〜現在」

スキルシートを更新しないまま使い回すと、古いプロジェクトの期間が「2021年4月〜現在」になったままのケースがある。信憑性が大きく下がる。

対策: 更新するたびに全プロジェクトの期間を確認し、終了日を正確に記載する。

NG3: チーム内での役割が不明

「開発を担当した」では、リードしたのか・メンバーの一員として実装したのかが分からない。案件によっては「PL経験者が必要」という条件があり、書き方次第で失注する。

対策: 「メンバー」「リーダー」「PL（サブ）」「PL」と役割を明確に記載する。

NG4: 業務改善や課題解決の実績ゼロ

「〇〇システムの開発に参加しました」という受け身の記述だけが並んでいると、能動性が伝わらない。面談官は「このエンジニアは自分で考えて動けるか」を判断している。

対策: たとえ小さくても「改善提案した」「ドキュメント整備した」「後輩にOJTした」といった能動的な行動を加える。

NG5: スキルシートを「盛っている」

経験のないスキルを「経験あり」と書いたり、補助的な関与を「主担当」と書いたりするパターン。面談で深掘りされると詰まる。そのスキルで案件に入ると本人が最も苦しむ。

対策: 「深く使えるスキル」と「触れたことがあるスキル」を正直に区別する。自信を持って説明できることだけを「経験あり」とする。

コピペで使えるテンプレ構造

以下は、Heydayが推奨するスキルシートの構成テンプレートだ。そのまま使える形式にまとめた。

基本情報

スキルサマリー（冒頭必須）

【強み】Javaを主軸に8年のバックエンド開発経験。直近3年はAWS（ECS/RDS/CloudFront）を用いたクラウドインフラ設計・構築も担当。要件定義から開発まで上流から携わった経験あり。チームリードとして5〜10名の開発チームをまとめた実績がある。

スキルマトリクス（実務レベルを区別する）

プロジェクト実績

プロジェクト詳細記述（No.1の例）

プロジェクト概要 月間PV 500万のECサイトのバックエンドリニューアルプロジェクト。決済・注文・在庫の3システムをモノリスからマイクロサービスへ移行。

課題 注文処理のスループット低下（ピーク時レスポンス8秒）。テスト工程が手動中心で品質が不安定。

行動・担当内容

• アーキテクチャ設計（Spring Boot×ECS×Terraform構成）のリード
• SQLクエリ・インデックス最適化でDB負荷を60%削減
• JUnit + GitHub Actionsでの自動テスト環境構築（カバレッジ75%→92%）
• 後輩メンバー4名のコードレビュー・技術相談を週次で実施

成果 注文処理レスポンス：8秒→1.2秒（85%改善）。本番障害：月平均3件→0件（6ヶ月連続）。

クラウド経験詳細

小川代表コメント：スキルシートは「市場価値の証明書」

スキルシートについて、エンジニアの方によく話すことがある。

「スキルシートは自己申告書ではなく、市場価値の証明書として書いてください」

同じ3年のJava経験でも、「大手金融の基幹システムで設計から担当」と「業務系アプリのCRUD開発」では市場評価が全然違う。これはどちらが優れているという話ではなく、プロジェクトの性質・規模・難易度が単価に影響するという話だ。

Heydayでは案件紹介の前にスキルシートを一緒に確認する機会を設けている。理由は、書き方の問題で単価を取り損ねているエンジニアが少なくないからだ。たとえば、実際には要件定義に関与していたのに「開発担当」とだけ書いていたために、単価交渉の根拠を失っているケースを何件も見てきた。

面談通過率を業界平均で見ると、準備をしていないエンジニアは20〜33%程度だが、スキルシートを適切に整理し面談準備をしたエンジニアは30〜50%に改善する。この差は技術力ではなく、スキルシートの質と面談準備の差から来ている。

スキルシートは正直に書くべきだが、正直に書いたうえで「伝わる書き方」を意識することは欠かせない。自分がやってきたことを正確に・具体的に・読み手が判断しやすい形で書くことが、適正な単価を得るための第一歩だ。

あなたの市場単価を診断する →

よくある質問

Q. スキルシートと職務経歴書は別に用意する必要がありますか？

SESの場合、スキルシート（技術経歴書）が主に使われます。転職活動では職務経歴書が必要になるケースもありますが、SES案件参画では技術スタックとプロジェクト経験をまとめたスキルシートが中心です。自社の営業に「どちらの形式が必要か」を確認してください。

Q. 経験年数が短い（1〜2年）場合はどう書けばいいですか？

年数の短さを補うのは「具体性」です。期間が短くても、担当した機能・業務内容・チームでの役割を具体的に書くことで評価が変わります。また、業務外での学習・個人開発の実績も「学習中」として補足できます。篠田の経験では、0〜2年のエンジニアは「担当した機能を細かく列挙する」だけで面談通過率が大きく変わるケースが多いです。

Q. スキルシートを更新する頻度はどのくらいが適切ですか？

プロジェクトが終わるたびに更新するのが理想です。記憶が新鮮なうちに、担当した機能・使用技術・数字を記録しておくと、後から書くより精度が上がります。

Q. 複数の案件に並行して提案される場合、スキルシートを案件ごとにカスタマイズすべきですか？

基本構成は同じで問題ありませんが、案件の要件に合わせて強調するセクションを変えることは有効です。インフラ案件ならクラウド経験を冒頭に持ってくる、上流工程案件なら設計経験の記述を厚くするといった調整が効きます。

Q. 希望単価の書き方にコツはありますか？

「65〜80万円」のようにレンジで書くのが一般的です。単価は案件・条件・商流によって変わるため、幅を持たせた方が提案されやすい。「希望単価：〇〇万円〜（スキル・条件により応相談）」とする書き方も、硬直した印象を避けられます。単価の適正レンジを把握していない場合は、先に市場価値を診断してから設定することをすすめます。

関連記事

• SESの面談対策を完全解説
• SES単価の完全ガイド｜あなたの単価は適正か？
• SESエンジニアの年収交渉
• SES企業の選び方完全ガイド
• あなたの市場単価を今すぐ診断する