面談に呼ばれるスキルシートと、書類で落ちるスキルシートの違い

2026年3月27日に note で公開した内容を、SkillSheet-Port の記事形式へ再構成した。

エンジニアの案件獲得は、スキルシートから始まる。

面談にたどり着く前に、まず書類で選考される。エージェントの営業がスキルシートを見て「この人を紹介できるか」を判断し、その次にクライアントの PM や購買担当が見て「面談に呼ぶか」を決める。

つまり、どれだけ技術力があっても、スキルシートが伝わらなければ面談にすら呼ばれない。

自分は SES エージェントとして、これまで数百人のスキルシートを見てきた。正直に言うと、中身を読む前に「あ、これはダメだ」とわかるスキルシートがある。逆に、「この人は会わせたい」と思わせるスキルシートにも共通点がある。

今日はその違いを率直に話す。

---

書類で落ちるスキルシートの共通パターン

まず、NG パターンから。心当たりがある人は、ここを直すだけで通過率が変わる可能性がある。

自己PRが淡白すぎる、または空欄

意外に思われるかもしれないが、自己PRが空欄のスキルシートは実際に存在する。そこまでいかなくても、書いてあっても内容が淡白すぎるケースは本当に多い。

「与えられた業務を責任をもってこなします」「コミュニケーションを大切にしています」「チームワークに自信があります」。こういう一般論しか書かれていないスキルシートは、エージェントの段階でまず弾かれる。

なぜか。この自己PRからは「この人に頼むと何が良いのか」がまったく読み取れないからだ。

ここでひとつ重要な視点を共有したい。自己PRには大きく分けて 2 種類ある。

• 利己的な自己PR: 「自分はこれができます」「自分はこんな経験があります」「自分はこうなりたいです」と、主語が全部「自分」になっている
• 利他的な自己PR: 「チームの開発効率を上げるために○○を導入した」「PMとクライアントの間に入って要件の齟齬を解消した」「後輩のコードレビューを通じてチーム全体の品質を底上げした」のように、主語が「チーム」や「プロジェクト」に向いている

どちらが好まれるかは言うまでもない。

クライアントが知りたいのは「この人がうちのチームに入ると何が良くなるか」だ。「自分ができること」の羅列ではなく、「自分が入ることで周りにどんな価値を提供できるか」が伝わる自己PRは、それだけで面談に呼ばれる確率が跳ね上がる。

経歴が「やったこと」の羅列で、「できること」が見えない

次に多いのが、プロジェクト経歴を時系列で並べているだけのパターンだ。

「○○システムの開発に参画。Java を使用。製造〜テストを担当。」

これだけでは、この人が何をどのレベルでできるのか判断できない。何人のチームだったのか、どの工程を主導したのか、どんな課題をどう解決したのか。読む側が知りたい情報が抜けている。

スキルシートは履歴書ではない。「過去にいた場所」ではなく、「そこで何ができるようになったか」を書く書類だ。

技術スタックの書き方が雑

「Java、PHP、Python、Ruby、JavaScript、C#」と横並びで書いてあるだけのスキルシートも多い。

これだと、どの言語がメインでどの言語がサブなのかわからない。実務で 3 年使った Java と、研修で触っただけの Python が同列に見える。

クライアントが探しているのは「Java で設計から実装までできる人」であって、「なんとなく 6 言語知っています」ではない。経験年数やレベル感が伝わらない技術スタックの記載は、むしろマイナスになる。

体裁がバラバラ

Excel のセル結合が崩れている。フォントサイズが統一されていない。古いプロジェクトと新しいプロジェクトで記載粒度が違う。

「たかが見た目」と思うかもしれないが、スキルシートの体裁は、その人の仕事の丁寧さの映し鏡だ。体裁が雑なスキルシートを出してくるエンジニアに、丁寧なコードは期待しにくい。少なくとも、書類を見る側はそう感じる。

「要求」と「要望」が多すぎる

これはスキルシート本体というより、案件希望欄や備考欄の話だ。だが、ここで弾かれるケースが意外なほど多い。

「フルリモート必須」「週4日以下」「単価○○万以上」「特定の技術スタック以外は NG」。要望を持つこと自体は悪くない。だが、それをスキルシートや希望条件欄に前面に出すのは戦略として間違っている。条件交渉は信頼を築いてからやるものだ。

要求が多いスキルシートは、案件元に届く前にエージェントの段階で弾かれている。この事実を知らないエンジニアは多い。

フォーマットがエージェントごとにバラバラ

SES 業界特有の問題がこれだ。エージェントを変えるたびにスキルシートのフォーマットが変わり、前の会社の Excel テンプレ、次の会社の Word 形式と、コピペで作り直すたびに情報の抜け漏れが起きる。

古いフォーマットのまま更新が追いつかない。「どれが最新版かわからない」状態になっているエンジニアも少なくない。

スキルシートが自分の手元で一元管理されていない時点で、情報の品質は担保できない。これは体裁の問題であると同時に、キャリア管理の構造問題だ。

ここまで挙げた NG パターン、心当たりがあった人も多いと思う。大事なのは、これらは「技術力の問題」ではなく「伝え方の問題」だということ。直す気になれば今日から直せる。

---

面談に呼ばれるスキルシートの共通点

では逆に、「この人には会いたい」と思わせるスキルシートは何が違うのか。

自己PRに「具体的な強み × 実績」が書かれている

面談に通るスキルシートの自己PRは、抽象的な性格アピールではなく、具体的なスキルと実績のセットになっている。

たとえば、「Java での開発経験 5 年。直近 3 年は Spring Boot を用いた API の設計・実装をリードし、チーム 4 名の PL 経験あり。パフォーマンスチューニングで応答速度を 40% 改善した実績がある。」のような書き方だ。

これだけで、この人が「何を」「どのレベルで」「どんな成果を出して」できるのかが伝わる。面談で深掘りしたいポイントも見える。クライアントが「会ってみたい」と思う理由が生まれる。

経歴を「ストーリー」で語れている

通るスキルシートは、プロジェクト経歴に必ず「自分の役割」と「チーム規模」が明記されている。

さらに差がつくのは、経歴がストーリーとして読めるかどうかだ。ポイントは 4 つある。

1. どこで: どんなプロジェクトだったか
2. 何をどのように: 自分の役割と責任範囲
3. どうなったか: 成果や貢献
4. なぜその技術を選んだか: 技術選定の理由

この 4 つが揃っている経歴は、読むだけで「この人はこういう場面でどう動けるか」が面談前に理解できる。スキルシートに書かれた経歴がストーリーとして通っていれば、面談の場でも同じように話せる。

技術スタックに「メイン / サブ」の濃淡がある

通るスキルシートは、技術スタックに優先順位がついている。

「メイン: Java（5年） / Spring Boot（3年）」「サブ: Python（1年） / AWS（2年）」のように、どの技術がどのレベルかが一目でわかる。クライアントが案件要件と照合しやすい。

経験年数だけでなく、「設計〜実装〜テスト」「運用・保守」「技術選定・レビュー」など、各技術で担当した工程まで書かれていると、さらに評価は上がる。

最新の情報に更新されている

意外と見落とされがちだが、スキルシートが最終更新から 1 年以上放置されているケースは多い。

直近のプロジェクトが反映されていないスキルシートは、「この人は今何をやっているのか」がわからない。最新の案件が 3 年前で止まっていると、「ブランクがあるのか？」と不安材料になる。

スキルシートは作って終わりではない。案件が変わるたびに更新するものだ。

スキルシートの更新が面倒で後回しになっている人は多い。エージェントが変わるたびにフォーマットが違って作り直し、というのもよくある話だ。SkillSheet-Port ならフォーム入力で体裁が自動統一され、差分更新もしやすい。更新のハードルが下がれば、棚卸しは習慣に変わる。

---

エージェント営業が「本音で」見ているポイント

ここからは、さらに踏み込んだ話をする。

見ているのは「直近2〜3件」だけ

10 年分の経歴が並んでいても、営業が最初に見るのは直近 2〜3 件、ここ 2〜3 年の動きだ。古い経歴は正直ほとんど見ない。

なぜか。クライアントが知りたいのは「この人が今何をできるか」だからだ。5 年前に COBOL をやっていた経歴は、今の React 案件には関係ない。直近の動きで「今のスキルセット」と「キャリアの方向性」を判断している。

「キーワードマッチ」でしか見ないエージェントも存在する

ここは正直に書く。エージェントの中には、スキルシートの中身を丁寧に読まず、案件要件のキーワードとの文字列マッチだけで判断している量産型の営業もいる。

「Java」「AWS」「PM 経験」。これらのキーワードがスキルシート上にあるかどうか。あれば紹介、なければスルー。経験の深さも文脈も関係ない。

だからこそ、案件で使われそうなキーワードをスキルシートにもれなく盛り込んでおくことは、最低限の自衛策になる。

エージェントとのやり取りの時点で、面談は始まっている

多くのフリーランスが見落としているが、面談は案件元の企業と会ったときに始まるのではない。エージェントの担当者と最初にやり取りした瞬間から、すでに選考は始まっている。

メールの返信速度、電話での受け答え、希望条件の伝え方、質問への対応。エージェントの営業はこれらすべてを見て、「この人をクライアントに紹介して大丈夫か」を判断している。

しかも、そのエージェントや担当者でしか繋がらない案件や企業が実在する。大手企業との独自パイプ、非公開案件、長年の取引関係。担当者に「この人は推したい」と思われるかどうかで、見える案件の景色は大きく変わる。

雑なスキルシートは、エージェントの対応も雑にする

「神は細部に宿る」とはよく言うが、スキルシートにもこれは当てはまる。

体裁が崩れている。誤字がある。更新が止まっている。こういうスキルシートを受け取ったエージェントは、「この人、仕事も雑なんだろうな」と感じる。

そう思われた瞬間、エージェントの対応の優先順位が下がる。紹介の熱量が下がる。結果として良い案件が回ってこなくなる。スキルシートの品質が、エージェントの対応品質に連鎖する。

逆に、整ったスキルシートを出すエンジニアには、エージェントも本気で向き合う。「この人はちゃんとしている。良い案件を紹介したい」と。

エージェントは敵ではない。味方につけるべき存在だ。

---

スキルシートは「最初の面談」だ

スキルシートは書類ではない。面談の前に行われる、無言の面談だ。

相手はあなたの顔も声もわからない状態で、スキルシートだけであなたを判断する。そこに書かれている内容、構成、体裁のすべてが「この人と一緒に仕事をしたいか」の判断材料になっている。

逆に言えば、スキルシートを整えるだけで、案件獲得の打率は確実に上がる。技術力を上げるには時間がかかるが、スキルシートの改善は今日からできる。

自分の技術力を正しく伝えるための「武器」を、まずは整えてみてほしい。

SkillSheet-Port なら、フォーム入力で体裁を自動統一し、AI 構成補助で自己PRの叩き台も作れる。無料で始められるので、まずは自分のスキルシートを見直すところから始めてみてほしい。

▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/