はじめに
フリーランスになって半年。
何が一番辛かったかって、面談のたびに作るスキルシートだった。
エージェントに見せても「いい感じですね！」としか言われない。
でも面談で落ちる。なんで？
5回転職して、今フリーランス。
経歴だけ見たら、どう見てもジョブホッパーのヨワヨワの部類。
そんな自分が、なぜか今は高単価の案件をフルリモで受注できている。
振り返ると、スキルシートの書き方を根本から変えたのがターニングポイントだった。
この記事では、落ちまくった黒歴史から学んだ「刺さるスキルシートの書き方」を全部書く。
目次
- スキルシートで落ちまくった黒歴史
- エージェントの「いいですね」を信じてはいけない
- 採用側は何を見ているのか
- スキルシートのアンチパターン5選
- 刺さるスキルシートの書き方
- 実際のフォーマットを公開
- おわりに
スキルシートで落ちまくった黒歴史
正直に言う。
フリーランスになりたての頃、3連続で面談に落ちた。
当時の自分のスキルシートを思い出すと、こんな感じだった：
- とりあえず経歴を時系列で羅列
- 使った技術を全部書く（バージョンまで細かく）
- 「コミュニケーション能力があります」という謎の自己PR
- A4で3枚
今見ると、読む側の気持ちを1ミリも考えてなかった。
忙しい現場のPMやリーダーが、知らないエンジニアの5枚のスキルシートを熟読してくれると思っていた。甘かった。
エージェントの「いいですね」を信じてはいけない
エージェントさんは味方だ。でも、スキルシートのフィードバックは期待しない方がいい。
なぜか？
エージェントのビジネスモデルを考えればわかる。
彼らは「マッチング成立」で報酬が発生する。つまり、たくさんの案件にエントリーしてもらった方が確率が上がる。
だから基本的に「いいですね、出しましょう」になる。
悪気はない。構造上そうなる。
スキルシートの良し悪しを本気でフィードバックしてくれるエージェントがいたら、その人は神だ。大事にした方がいい。
自分のスキルシートは、自分で磨くしかない。
採用側は何を見ているのか
ここが一番大事。
面談する側（PM、リーダー、時には経営層）が知りたいのは、突き詰めると3つだけだ：
1. この人は「何ができる」のか
技術スタックの羅列じゃない。
「Reactできます」じゃなくて、**「Reactで何を作って、どう貢献したか」**が知りたい。
2. この人は「どう働く」のか
チームにフィットするか。コミュニケーション取れるか。
自走できるか、それとも指示待ちか。
これはスキルシートの行間に出る。
3. この人を採用して「失敗しないか」
採用する側もリスクを取っている。
ハズレを引いたら、自分の評価に関わる。
だから「この人なら大丈夫そう」という安心感が欲しい。
スキルシートのアンチパターン5選
自分の黒歴史と、周りのエンジニアのスキルシートを見てきて気づいた「やっちゃダメ」をまとめる。
❌ 1. 長すぎる
3枚以上は読まれない
忙しい人が、会ったこともない人の経歴を5枚も読むと思う？
読まない。流し読みして終わり。
理想は2枚以内。どうしても経歴が多い場合は、直近3〜5年に絞る。
❌ 2. 技術の羅列だけ
【使用技術】
Java, JavaScript, TypeScript, Python, Go, PHP, Ruby,
React, Vue.js, Angular, Next.js, Nuxt.js,
MySQL, PostgreSQL, MongoDB, Redis,
AWS, GCP, Azure, Docker, Kubernetes...
これ、何も伝わらない。
「で、何が得意なの？」 がわからない。
全部書くな。強みにフォーカスしろ。
❌ 3. 成果・実績がない
【担当業務】
- 画面開発
- API開発
- テスト
これだけ書かれても、「だから何？」 としか思えない。
- 何人のチームで
- どんな課題があって
- どう解決して
- 結果どうなったか
数字があると最強。なくても「Before → After」は書ける。
❌ 4. コピペ感がすごい
テンプレをそのまま使ってる人、バレてる。
「コミュニケーション能力を活かして〜」
「チームワークを大切に〜」
「新しい技術のキャッチアップが得意〜」
全員同じこと書いてる。差別化にならない。
❌ 5. 自己PRが抽象的
【自己PR】
私は責任感を持って業務に取り組むことができます。
チームワークを大切にし、コミュニケーションを密に取りながら
プロジェクトを成功に導くことができます。
何も言ってないのと同じ。
具体的なエピソードがないと、信用されない。
刺さるスキルシートの書き方
アンチパターンの逆をやればいい。
✅ 1. 2枚以内にまとめる
どうしても入らない場合は、古い経歴を捨てる勇気を持つ。
10年前にやったCOBOLの経験、今の案件に関係ある？
ないなら書かなくていい。
✅ 2. 強みを3つに絞る
自分の「これだけは負けない」を3つ選ぶ。
自分の場合：
- フロントエンド開発（React/Vue.js）
- レガシーシステムのモダナイズ
- 顧客折衝・要件整理（営業出身）
全部できる風に書くより、尖った方が刺さる。
✅ 3. 成果は数字で語る
数字がなくても、工夫次第で書ける：
Before:
画面開発を担当
After:
会員向けマイページ（15画面）のフロントエンド開発を担当。
レスポンス改善のためコンポーネント設計を見直し、初期表示速度を40%改善。
「何を」「どのくらい」やったかを具体的に。
✅ 4. 自己PRは「エピソード」で語る
抽象的な強みじゃなくて、実際にあったことを書く。
Before:
コミュニケーション能力があります
After:
前職では、仕様が曖昧なまま開発が進んでいた案件にアサイン。
顧客との定例MTGを週1から週2に増やすことを提案し、
認識齟齬による手戻りを月平均5件→0件に削減しました。
事実は強い。
✅ 5. 「なぜ御社か」を意識する
同じスキルシートを全案件に出すのは効率的だけど、刺さらない。
案件ごとに、関連する経験を前に持ってくるだけでも印象が変わる。
金融系の案件なら、金融系の経験を目立たせる。
スタートアップなら、少人数での開発経験を目立たせる。
実際のフォーマットを公開
自分が今使っているスキルシートの構成を公開する。
1ページ目：サマリー
| 項目 | 内容 |
|---|---|
| 基本情報 | 氏名（イニシャル可）、年齢、最寄駅、稼働可能時期 |
| スキルサマリー | 得意技術TOP5（経験年数付き） |
| 強み・得意領域 | 3〜5行で簡潔に |
| 自己PR | 具体的エピソード込みで10行以内 |
ポイント: 1ページ目だけで「この人に会ってみたい」と思わせる。
2ページ目：職務経歴
| 項目 | 内容 |
|---|---|
| 期間 | 2024/01 〜 現在（1年） |
| プロジェクト名 | ○○系Webサービス開発 |
| 役割/チーム規模 | SE / 8名 |
| 担当フェーズ | 要件定義 → 基本設計 → 実装 → テスト |
| 業務内容 | 箇条書きで3〜5項目 |
| 成果・実績 | 数字込みで2〜3項目 |
| 使用技術 | カテゴリ分け（言語/FW/DB/インフラ） |
ポイント: 直近の経歴を厚く、古い経歴は薄く。
自分のスキルを可視化する重要性
ここまで読んで「めんどくさい」と思った人もいると思う。
でも、スキルシートを真剣に作ると、自分自身の棚卸しになる。
- 自分は何をやってきたのか
- 何が得意なのか
- 次はどこに進みたいのか
これが言語化できると、面談でも自然と話せるようになる。
スキルシートは「書類」じゃない。
自分を知るためのツールだ。
おわりに
複数回転職して、フリーランスになって、散々落ちて、ようやく気づいた。
スキルシートは「自分の価値を言語化する作業」だった。
技術の羅列じゃない。
自分が何者で、何ができて、どう貢献できるかを伝えるもの。
これに気づいてから、面談の通過率が明らかに変わった。
スキルシート作成を楽にするために、自分でWebアプリを作った。
このアプリのスキルシートのテンプレがいろいろ考えながら
話す導線も考えて作りました。
自信もフリーランスエンジニアである私が本気で使いたいって思うフォーマットです。
- プロジェクト経歴を入力すると、スキルの経験年数を自動計算
- 選んだ経歴だけでスキルシート生成
- 完全無料
※下記はデモ用のデータです。
自分が欲しかったものを形にしたやつ。
よかったら使ってみてください。
経歴に自信がなくても、書き方次第で刺さるスキルシートは作れる。
この記事が、同じように悩んでいるエンジニアの参考になれば嬉しい。
参考
- 自分のnote: 【完全無料】僕の考えた最強のスキルシート管理webアプリ
- X: @taka_ton19z