「スキルシートを出したのに、なぜか書類落ちが続く」——その原因、書き方にあるかもしれません

「技術力には自信があるのに、なぜか書類選考を通過できない」「エージェントから『スキルシートをもう少し整えてください』と言われたけど、何をどう直せばいいのかわからない」——こうした悩みを抱えたまま、転職活動が長期化しているITエンジニアは少なくありません。

スキルシートは、職務経歴書とは異なり、エンジニア特有の技術スタック・プロジェクト経験を伝えるための専用ドキュメントです。しかし多くのエンジニアが「使ったことのある技術を列挙すればいい」と誤解したまま、本来の力を伝えられずに終わっています。

この記事では、採用担当者やエージェントが実際にスキルシートを見るときの視点を正直に解説し、あなたが今すぐ書き直せる具体的な方法をお伝えします。職務経歴書の書き方ではなく、スキルシートに特化した実践的な改善手順が、この記事の価値です。

採用担当者は「スキルシートの何を」見ているのか：裏側の評価基準

最初の10秒で「候補者の絵」を描いている

採用担当者がスキルシートを開いてから最初にやることは、「この人はどんなエンジニアか」を10秒程度でつかもうとすることです。全文を精読する前に、技術スタックの並び順・プロジェクト数・年数のバランスをざっと眺めて、「フロントよりかバックよりか」「マネジメント経験はありそうか」「特定ドメインの専門家か、あるいはジェネラリストか」を素早く判断します。

つまりスキルシートは「読まれる文書」である前に、「スキャンされる文書」です。いくら詳細に書いても、この10秒の印象で「読み進めようか」が決まります。ここでつまずくと、どれだけ内容が充実していても採用担当者の目に入らないのです。

「何ができるか」より「何をどのくらい深くやったか」を見ている

エージェントが口を揃えて言うのが、「技術名を並べるだけのスキルシートは、見ていて怖い」という感覚です。たとえば「Python / Java / Go / AWS / GCP / Docker / Kubernetes / React / Vue.js / TypeScript」と並んでいるだけでは、採用担当者には「どれが本当に得意なのかわからない」と映ります。

採用側が知りたいのは「使ったことがある」という事実ではなく、「それを業務レベルで使いこなせるのか」「どの技術を中心に動いてきたエンジニアなのか」です。スキル一覧に経験年数や習熟度を添えるのはそのためです。しかし習熟度の表現も「★★★☆☆」のような記号だけでは伝わりません。後述する具体的な書き方で補う必要があります。

エージェントが「推薦しにくい」と感じるスキルシートのパターン

転職エージェントは、クライアント企業への推薦文を書くときにスキルシートを使います。このとき「この人をひと言で説明できない」スキルシートは推薦しにくいと感じています。具体的には以下のようなケースです。

• 関わったプロジェクトの規模感（チーム人数、期間、システムの規模）がまったく書かれていない
• 自分が何の役割を担ったのか（設計者か、実装担当か、レビュアーか）が不明瞭
• 成果や工夫した点の記載がなく、「参加しただけ」に見える
• 最新のプロジェクトが何年も前のもので、直近の活動が見えない

これらはどれも、「技術力がない」という問題ではなく、「書き方」の問題で損をしている典型例です。

よくある失敗パターン5つと、それぞれの具体的な直し方

失敗①：技術スタックをアルファベット順・思いついた順に並べている

悪い例：「AWS / Docker / Git / Go / Java / Kubernetes / Python / React / TypeScript / Vue.js」

良い例（カテゴリ別・得意順）：

• バックエンド：Go（5年・主力）、Java（3年・業務レベル）、Python（2年・スクリプト・自動化）
• インフラ・クラウド：AWS（4年・本番運用経験あり）、Docker（4年）、Kubernetes（2年）
• フロントエンド：TypeScript / React（1年・補助的に参加）

カテゴリ別に整理するだけで、「このエンジニアはGoとAWSが軸」という絵が一瞬で伝わります。採用担当者がスキャンしたときの印象がまったく変わります。

失敗②：プロジェクト概要が自社向けの内部言語で書かれている

「〇〇システムの△△機能改修」のように社内通称を使っても、外部の人には何のことかわかりません。採用担当者やエージェントが求めているのは、「業界・ドメイン・規模感・ユーザー像」が伝わるプロジェクト概要です。

悪い例：「社内基幹システムのバッチ改修プロジェクト」

良い例：「EC事業者向けの受注管理・在庫連携システム（日次バッチ処理）のリファクタリング。処理対象データ数は月間数百万件規模。パフォーマンス改善を主目的とした設計見直しを担当。」

規模感の数字は正確な数値でなくても「数百万件規模」「数十名が利用するシステム」のような表現で構いません。ゼロと数百万では印象がまったく異なります。

失敗③：役割欄に「メンバー」とだけ書いて終わり

「担当：メンバー」という記載は、情報として機能していません。採用担当者が知りたいのは、そのプロジェクトの中であなたが何を主体的にやったかです。

直し方：役割を動詞で書く

• 「API設計・実装を担当（3名チームのうち、バックエンド2名のうちの1人）」
• 「コードレビューを主導。チーム内のコーディング規約整備も兼任」
• 「テスト設計・実施を一手に担当。自動テスト導入の提案も行った」

これだけで「このエンジニアは実装だけでなく設計判断もできる」「主体的に動く人物だ」という印象が伝わります。

失敗④：古いプロジェクトほど詳しく書いている

キャリアの早い時期から書き始めて、最新のプロジェクトほど行数が少ない——これは多くのエンジニアが陥るパターンです。採用担当者は「直近の経験」を最も重視します。5年以上前のプロジェクトに3段落費やし、直近プロジェクトは2行、というスキルシートは優先順位が逆です。

直し方：時系列を逆順（新しい順）にして、直近2〜3プロジェクトに記述を集中させる。古いプロジェクトは技術名・期間・役割の3点セットに絞って簡潔にまとめます。

失敗⑤：成果欄がない、または「〜に貢献した」で終わっている

「パフォーマンス改善に貢献した」という記述は、読んでいる側には何も伝わりません。「具体的な数字を入れろ」とよく言われますが、NDAや機密の問題で数字を出せないケースもあるでしょう。そのときは比較構造を使うのが有効です。

悪い例：「バッチ処理のパフォーマンス改善に貢献した」

良い例（数字が出せない場合）：「SQLのN+1問題解消とインデックス再設計により、バッチ処理時間を大幅に短縮。翌月の本番リリース後、定時バッチが時間内に完了するようになり、夜間アラートが解消された」

「何をしたか（手段）」と「何が変わったか（結果）」の両方を書くことが成果の書き方の基本です。数字がなくても、「アラートが解消された」「リリース頻度が上がった」など状態の変化を書けば伝わります。

市場価値を高めるためのスキルシート戦略：業界動向をふまえた視点

「何でもできます」は最も市場価値が低い表現

現在のIT転職市場では、ポジションの要件がより細分化・専門化しています。「フルスタックで何でもできます」という打ち出し方は、「この人に任せられる具体的な仕事が思い浮かばない」という印象につながりやすくなっています。

エージェントの肌感として、「○○ならこの人」という軸が明確なエンジニアほど、ポジションへのマッチング精度が上がり、書類通過率も高い傾向があります。スキルシートの冒頭に「自己PR・キャリアサマリー」を1〜3文で入れ、「自分はこういうエンジニアだ」という軸を明示することが有効です。

生成AI・クラウドネイティブ関連の経験は積極的に書く

生成AIを活用した開発経験（LLM APIの利用、RAG構成の設計経験など）や、クラウドネイティブな構成（マイクロサービス、コンテナオーケストレーション）への関わりを問う求人は明らかに増えています。たとえ「補助的に関わっただけ」であっても、どのように活用したか・どこで使ったかをきちんと書くことで、採用担当者の目に留まりやすくなります。

「まだ大したことをやっていないから書けない」と思って省略してしまうエンジニアが多いですが、採用担当者は「業務で触れたことがある」というだけで評価を変えることがあります。経験の浅さは正直に書いた上で、「〇〇の場面で活用した」という事実を書きましょう。

スキルシートは「転職時にだけ書くもの」ではない

転職活動を始めてから慌ててスキルシートを書こうとすると、過去のプロジェクト詳細を思い出せなかったり、成果として書けることが出てこなかったりします。プロが意識しているのは「プロジェクト完了のタイミングで都度メモを残しておく」習慣です。

Notionや個人のGitHubリポジトリに、プロジェクトごとに「概要・技術スタック・自分の役割・やったこと・学んだこと」を箇条書きで残しておくだけで、いざ転職活動を始めたときに圧倒的に楽になります。これは今日から始められる、最もコスパの高いキャリアマネジメントです。

スキルシートの構成テンプレート：このフォーマットに沿って書き直す

推奨する構成（上から順に）

• ① キャリアサマリー（3〜5行）：自分がどんなエンジニアで、何を強みとしているかを端的に。採用担当者が最初に読む部分。
• ② スキル一覧（カテゴリ別）：バックエンド／フロントエンド／インフラ／DB／ツール等に分け、経験年数・習熟度を添える。
• ③ プロジェクト経歴（新しい順）：各プロジェクトに「期間・概要・チーム規模・自分の役割・使用技術・やったこと・成果」の7項目。
• ④ 保有資格・その他：業務に関連するものに絞る。多すぎると逆効果。

各プロジェクト記載の最小チェックリスト

1つのプロジェクトを書くとき、以下の項目が揃っているか確認してください。

• □ 期間（〇年〇月〜〇年〇月）が明記されている
• □ ドメイン・業種・システムの目的が外部の人に伝わる
• □ チーム規模（何名のチームで、自分は何名のうちの1人か）が書かれている
• □ 自分の役割が動詞で書かれている（「設計担当」「レビュー主導」など）
• □ 使用技術がカテゴリ別に整理されている
• □ 工夫した点・課題をどう解決したかが書かれている
• □ 結果・成果（状態の変化）が書かれている

このチェックリストを7項目すべて埋める必要はありません。古いプロジェクトは③〜⑤だけでも構いません。重要なのは直近プロジェクトほど全項目を丁寧に埋めることです。

まとめ：今日からできるアクション

スキルシートは「技術力の証明書」ではなく、「採用担当者があなたをイメージするための地図」です。どれだけ実力があっても、地図が読みにくければ目的地にたどり着いてもらえません。

• アクション①：スキル一覧をカテゴリ別に整理し直す（今日中に）
  バックエンド・インフラ・フロントなどのカテゴリに分け、各技術に「経験年数」と「業務利用か否か」を添える。これだけで採用担当者の10秒スキャンの印象が変わります。
• アクション②：直近プロジェクトを7項目チェックリストで書き直す（今週中に）
  上記のチェックリストを使い、直近2〜3件のプロジェクト記述を見直す。「役割が動詞で書かれているか」「成果に状態変化が書かれているか」の2点だけでも改善すると、読まれ方が大きく変わります。
• アクション③：プロジェクトメモの習慣をNotionやメモアプリで始める（今月から）
  転職活動を始めてからではなく、プロジェクトが終わるたびに「概要・役割・技術・学び・成果」を5分でメモしておく。これが半年後・1年後のスキルシート更新を劇的に楽にします。

スキルシートは一度書いたら終わりではありません。プロジェクトが変わるたびに更新し、「常に最新の状態を保てている」こと自体が、キャリアを自分でマネジメントしているエンジニアの証になります。