500人のスキルシートを見てきて気づいた、エンジニアの"もったいない"5選

3年間、SESエージェントとして約500人のエンジニアのスキルシートを見てきた。 そこで気づいたことがある。 スキルが足りないエンジニアは少ない。見せ方がもったいないエンジニアが圧倒的に多い。

技術力はある。経験もある。 でもスキルシートがそれを伝えきれていない。 結果、書類で落ちる。面談に呼ばれない。 本人は「自分のスキルが足りないんだ」と思い込む。 違う。見せ方の問題だ。

この記事では、500人のスキルシートに繰り返し現れた「もったいない」パターンを5つ紹介する。 一つでも心当たりがあれば、今日直すだけで書類通過率が変わる。

---

もったいない①：自己PRが簡素すぎる——テンプレ文では差がつかない

一番多い。そして一番もったいない。

自己PR欄が完全に空欄のエンジニアは実はほとんどいない。 みんなちゃんと何か書いてはいる。 問題は書いてあるのに何も伝わらないことで、体感8割がこのパターンだ。

典型的なのがこういう自己PRだ。

バックエンドエンジニアです。エンジニアとして3年目です。Pythonが好きです。最近はGoを勉強しています。コミュニケーションを大切にしています。フルスタックで貢献できるエンジニアになりたいです。

一見ちゃんと書いてあるように見える。 でもこの文面からは、「この人だけの情報」が何も読み取れない。 好きな言語と勉強中の技術と抱負。これは誰にでも書ける。

エージェント側はスキルシートの自己PRを見て「このエンジニアをどう推薦するか」のストーリーを組み立てる。 簡素すぎる自己PRだと、推薦の材料がない。 結果、**案件票が来ても「推しポイントが見つからないから他の人を出そう」**となる。 あなたのスキルが足りないのではなく、伝える材料を渡していないだけだ。

「何を書けばいいかわからない」という人は、まず生成AIに壁打ちしてみてほしい。 以前「生成AIでスキルシートの自己PRを壁打ちする——コピペで使えるプロンプト5選」で紹介したプロンプトを使えば、5分で叩き台が作れる。

---

もったいない②：案件概要が「やったこと」の羅列——そもそも案件を理解していない

次に多いのがこのパターンだ。

【案件概要】ECサイトのバックエンド開発。Spring Bootを使用。REST APIの設計・実装・テストを担当。

事実としては正しい。でも、この書き方だと同じ案件を経験した全員が同じ文面になる。読み手は「で、この人は何を考えて動いたの？」がわからない。

そしてもっと根深い問題がある。そもそも自分が携わっていたサービスを語れないエンジニアが本当に多い。

そのサービスはどういうもので、どんな価値があって、誰がどう使っているのか。 その中で自分がどんな役割を持って、何に責任を持っていたのか。 ここを聞かれて詰まるエンジニアが、500人中の大半だった。

これは面談で致命傷になる。 「従事していたサービスすら語れないなら、うちの案件でも同じスタンスなんだろうな」——面談官は必ずこう判断する。 技術力の問題ではなく、仕事に対する解像度の問題だ。

ただし「案件を語る」の切り口は、案件の種類によって変わる。 BtoCのWebサービスやアプリ開発なら「そのサービスがどんな価値を持ち、誰がどう使っているか」を語れればいい。 一方で、**基幹業務系（会計・人事・在庫管理など）の場合は、「業務のワークフロー全体と、自分が担当したモジュールの責務」**を語れるかどうかが問われる。 要するに、自分のコードが業務のどこに位置していて、何に影響するかを理解しているかどうかだ。

案件概要はこう書き換えるだけで印象が変わる。

NG：

ECサイトのバックエンド開発。REST APIの設計・実装・テストを担当。

OK：

月間利用者数50万人のアパレルECサイトにおけるバックエンド開発。商品検索APIのレスポンス改善を主導し、平均応答時間を800ms→200msに短縮。設計判断としてElasticsearchの導入を提案・実装。

「このサービスは○○のために使われており、その中で自分は○○を担当した」——サービスの文脈と自分の判断を加えるだけで、まったく別の人材に見える。 以前「AIがコードを書く時代、エンジニアに残る価値は『判断と決断力』だけだ」でも書いたが、AI時代のスキルシートで差がつくのは、**「何を判断し、何を決断したか」**だ。

---

もったいない③：技術スタック全部盛り——答えられない技術が混ざっている

技術スタック欄に10個も20個も技術名が並んでいるスキルシートがある。本人は「多い方がアピールになる」と思っている。

逆だ。答えられない技術が1つ混ざっているだけで、面談の印象は一気に下がる。

面談官はスキルシートの技術欄を見て「この技術について聞いてみよう」と質問を決める。書いてある以上、聞かれる前提で書くべきだ。「少しだけ触った」程度の技術を並べておくと、自分で地雷を埋めることになる。

以前「面談で必ず聞かれるスキルシートの行間」でも書いたが、スキルシートは面談の「台本」だ。聞かれたい技術だけを書き、聞かれたくない技術は外す。これが基本戦略だ。

書くならメインで使った技術5〜8個に絞る。補助的に使った技術は「経験あり」と注記を添えるか、思い切って外す。少ない方が一つ一つの技術に対する深掘りに答えやすくなる。

---

もったいない④：成果に数字がゼロ——全部が「〜しました」で終わる

「効率化しました」「品質を向上させました」「スムーズに進行しました」——こういう抽象的な表現だけのスキルシートが本当に多い。

数字がないと何が起きるか。エージェント側がクライアントに推薦するとき、「このエンジニアを入れるとどのくらいの成果が出るか」を説明できない。 結果、数字を持っている別のエンジニアが優先される。

「テスト工数を約40%削減」 「バグ発生件数を月10件から3件に減らした」 「問い合わせ対応時間を15分から5分に短縮」 ——正確な計測値でなくていい。 「約」「推定」で十分だ。数字が入っているだけで、あなたのスキルシートは他の候補者より一歩前に出る。

「生成AI活用をスキルシートにどう書く？」で紹介した型②「Before/Afterで変化を数字にする」がそのまま使える。直近2案件について、各3つずつ数字を用意するだけで見違えるほど変わる。

---

もったいない⑤：最後に更新したのが半年以上前

これは地味だが、実はかなり深刻だ。

エージェントに登録したときに一度スキルシートを作って、そのまま放置しているエンジニアが本当に多い。 半年前、1年前の情報のまま案件にエントリーする。 直近案件の情報がない。技術スタックが古い。自己PRが当時のまま。

面談官は直近で何をしていたかを一番知りたがっている。 スキルシートが半年前で止まっていると「この人は最近何をしていたんだ？」という不安が生まれる。それだけで不利だ。

更新が止まるのには二つの原因がある。 一つは純粋に面倒なこと。 もう一つは、エージェントを変えるたびにスキルシートを一から作り直すこと。 エージェントごとにフォーマットが違うから、移るたびにゼロからやり直しになる。これが「もういいや、前のまま出そう」に繋がる。

「自分に合ったエージェントの選び方」でも触れているが、エージェントは変わっても自分のスキルシートは一つ。 自分専用のマスターデータを持っておけば、エージェントが変わっても差分を調整するだけで済む。

以前「自分が携わった案件を説明できないエンジニアが多すぎる」でも書いたが、記憶は驚くほど早く消える。 案件が終わった直後なら10分で書けることが、半年後には30分かかる。 1年後にはもう思い出せない。更新は鮮度が命だ。

差分だけ更新してワンクリックで再出力できるツールもある。仕組みで解決してしまうのが一番楽だ。

---

まとめ——スキルが足りないんじゃない、見せ方がもったいないだけだ

5つのもったいないをまとめておく。

1. 自己PRが簡素すぎる → AIで壁打ちして叩き台を作る
2. 案件概要が「やったこと」の羅列 → サービスの文脈と「判断したこと」を加える
3. 技術スタック全部盛り → 答えられる5〜8個に絞る
4. 成果に数字がゼロ → 直近2案件×3つ＝6つの数字を用意
5. 半年以上更新していない → 案件が終わった直後に差分更新

どれも今日から直せることばかりだ。技術力を上げるには時間がかかるが、見せ方を変えるのは今日できる。

まずはスキルシートを開いて、この5つに一つでも当てはまるものがないか確認してみてほしい。

---

※関連記事：生成AIでスキルシートの自己PRを壁打ちする / 生成AI活用をスキルシートにどう書く？ / 面談で必ず聞かれるスキルシートの行間 / AIがコードを書く時代、エンジニアに残る価値は「判断と決断力」だけだ