スキルシートを提出してから面談に呼ばれない——この経験があるエンジニアは多い。
SESの案件参画では、書類審査（スキルシート）を通過しないと面談すら始まらない。そして面談を通過しないと案件が決まらない。スキルシートの質は単純に「次の仕事に入れるかどうか」を左右する。
Heydayを運営して6年、数百件の案件マッチングに関わってきた。その中で見えてきた「通るスキルシート」と「落とされるスキルシート」の差は、技術力の差より書き方の差であることが多い。同じ経験を持つエンジニアでも、スキルシートの書き方次第で面談通過率が変わる場面を何度も見ている。
この記事では、SES特有のスキルシートの構造と、面談通過率を上げるための具体的な書き方を解説する。
SESスキルシートと一般的な職務経歴書の違い
スキルシートは、転職市場で使われる職務経歴書と似ているが、SES特有の流通経路を理解していないと本質的なズレが生まれる。
職務経歴書との3つの違い
1. 読まれる人数が多い
一般的な転職の職務経歴書は採用担当者が読む。SESのスキルシートは、自社の営業→取引先の営業→エンドクライアントの面談官、という複数のステークホルダーを通過する。営業が「この人は売れる」と判断しないとクライアントに提案すらされない。
2. 「売れるか」の文脈で読まれる
職務経歴書は「この会社に合うか」の視点で読まれる。スキルシートは「このプロジェクトで即戦力になるか」「この単価に見合うか」という文脈で読まれる。人柄や志望動機よりも、技術スタックと業務経験の具体性が優先される。
3. プロジェクト単位での記述が基本
職務経歴書は会社ごとにまとめることが多いが、スキルシートはプロジェクト単位で記述する。「A社に3年勤めた」ではなく、「A社勤務中にBシステムの開発（期間・規模・担当フェーズ・使用技術）」という書き方が基本だ。
SES特有の注意点
商流が深い（複数の会社を経由する）場合、スキルシートは何度もコピーされて転送される。そのため、特殊なフォーマットや複雑な表は崩れやすい。シンプルな表構成、Excelかスプレッドシートで崩れないレイアウトにすることが実用上重要だ。
面談官が見ているポイント3つ（技術スタック・業務規模・担当フェーズ）
面談官がスキルシートを開いてから30秒で何を確認するか。Heydayの案件マッチング経験から整理すると、次の3点に絞られる。
1. 技術スタック（使える技術が何か）
面談官が最初に確認するのは、求めている技術スタックとマッチするかどうかだ。言語・フレームワーク・DB・インフラ・開発ツールが一覧で把握できること。
落とされやすいのは「Java、Python、JavaScript、AWS、Docker、Kubernetes、TypeScript...」と羅列しているだけのパターンだ。「使えます」と「実務で設計・構築できます」は全然違う。実務レベルで使ったものと、学習程度のものを分けて書く必要がある。
2. 業務規模（どの規模のプロジェクトか）
プロジェクト規模は面談官にとって重要な判断材料だ。チーム人数・システムの規模（ユーザー数・リクエスト数など）・開発期間がわかると、「この人はこの規模の案件を経験している」という判断ができる。
Heydayで扱う案件では、「大規模プロジェクト（20名以上）の経験があるか」「数百万ユーザーのシステムを扱ったか」が条件になるケースが一定数ある。これを書いていないと、経験があっても伝わらない。
3. 担当フェーズ（どこまでやったか）
要件定義・基本設計・詳細設計・開発・テスト・運用保守のどこを担当したかは単価に直結する。上流工程を担当したことがある場合、それを明確に示すだけで単価の交渉余地が生まれる。
Heydayの2026年Q1データでは、要件定義・基本設計の経験があるエンジニアの案件単価は、開発・テストのみ経験者と比べて平均10〜15万円高い。この経験がスキルシートに書かれていないと、そもそも面談にすら至らない。
プロジェクト経験の書き方：「課題→行動→成果」の三段構成
スキルシートのプロジェクト記述で最もよく見るのは、「何をしたか」だけを書いているパターンだ。これでは面談官に「それで？」という印象しか残らない。
三段構成の型
課題: プロジェクトが抱えていた問題・背景 行動: 自分がどのように対応・解決したか 成果: 定量的・定性的な結果
実際の書き方例を比較する。
改善前（よくある書き方）
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の経験は、技術スタックの羅列に埋もれさせると価値が伝わらない。以下のように独立したセクションを作るか、プロジェクト記述内で強調する。
クラウド経験（独立セクション例）
| クラウド | 経験年数 | 主な使用サービス | 実績 |
|---|---|---|---|
| AWS | 3年 | EC2, ECS, RDS, S3, CloudFront | 本番環境のコンテナ化移行・Terraformでインフラ管理 |
| GCP | 1年 | BigQuery, Cloud Functions, GCS | データ基盤構築・バッチ処理自動化 |
Heydayで案件を扱う中で、AWS経験者とそうでない場合の単価差は経験3年以上で月10〜20万円に達するケースがある。この経験を正しく見せているかどうかは、単価に直結する。
上流工程経験は明示的に書く
「担当フェーズ：要件定義・基本設計・詳細設計・開発・テスト」と書いてあっても、どの案件で何をやったかが不明確だと信憑性が薄れる。上流経験がある場合は、そのプロジェクトで「何を定義・設計したか」を1〜2行で具体的に書く。
要件定義フェーズでは、業務ヒアリングシートの作成・顧客との要件調整・WBS策定を担当。PL（プロジェクトリーダー）補佐として5名のチームをサポートした。
「要件定義を担当した」ではなく「何を・どのように・誰とやったか」が書かれていると、面談官の評価が変わる。
複数案件の経験を横断して強みをまとめる
スキルシートの冒頭または末尾に「強みのサマリー」を置くと、複数のプロジェクトを読まずに強みが把握できる。
【強み】Java（8年）を主軸とした大規模Webシステムの設計・開発。AWS（EC2/ECS/RDS）を用いたクラウドインフラ構築・Terraform管理の経験あり。直近2プロジェクトでは要件定義・基本設計から参画。チーム規模は5〜15名のプロジェクトを多く経験。
このサマリーひとつで、面談官が「この人がどういう人か」を30秒で把握できる。