フリーランスエンジニアにとって、スキルシートは「案件に通るかどうか」を左右する最重要書類です。同じ経験でも、書き方ひとつで案件先に届く印象は大きく変わります。実際、実力があるのに伝わっていない、というケースは珍しくありません。この記事では、スキルシートの基本から、案件に“伝わる”ように整えるコツ、よくある失敗の直し方までを一気に整理します。
各論はそれぞれの記事で深掘りします。まずこのガイドで全体像をつかんでください。この記事は、次のような順番で読み進められる構成にしています。
| 知りたいこと | 読む場所 |
|---|---|
| そもそもスキルシートとは何か | この記事の前半 |
| 何を書けばいいか（項目） | この記事の「基本項目」 |
| どう書けば伝わるか（原則） | この記事の「3原則」 |
| 工程・自己PR・翻訳などの各論 | それぞれの専門記事（リンクで案内） |
スキルシートとは｜「何ができるか」を伝える書類
スキルシートは、エンジニアが案件を獲得する際に、自分の経験・スキル・担当できる工程を案件先に伝えるための書類です。職務経歴書が「何をしてきたか」を時系列で示すのに対し、スキルシートは「何ができるか」を一覧で見せます。
案件紹介の現場では、案件先の担当者はまずスキルシートを見て「この案件に合いそうか」を判断します。つまりスキルシートは、あなたと案件をつなぐ最初の接点です。
そして、この判断は思っているより速く行われます。案件を紹介する側は多くのシートを見るため、最初の数十秒で「どの案件に出せそうか」の見立てをつけます。だからこそ、ぱっと見て担当範囲が分かる状態になっているかどうかが効いてきます。
もうひとつ大事なのが、スキルシートは後の面談の土台にもなる点です。案件先との面談は、基本的にスキルシートを見ながら進みます。書いてあることがそのまま質問になるので、シートが正確に書けていれば、面談の準備はほぼ終わっているとも言えます。
スキルシートの基本項目
一般的なスキルシートには、次のような項目を記載します。
- 基本情報 … 氏名（またはイニシャル）・年齢・最寄駅・稼働開始時期・希望条件
- 得意領域 / 保有スキル … 言語・フレームワーク・クラウド・DB・ツールなど
- 業務経歴 … 参画期間・案件概要・担当工程・規模（人数や対象規模）・使用技術・成果
- 自己PR … 強み、得意な進め方、関われる工程の幅
とくに業務経歴は、「参画期間・業務内容・担当工程・使用技術」を具体的に書くことが重要です。担当工程を要件定義・設計・実装・テスト・運用保守のどこまで書き分けるかは スキルシートの担当工程の書き方 に工程別の記入例をまとめています。
項目ごとに、案件を紹介する側が特に見ているポイントは次のとおりです。
| 項目 | 見られているところ |
|---|---|
| 稼働開始時期 | いつから動けるか。現在稼働中か、終了済みか ここが空欄だと確認の連絡が必要になり、紹介が遅れます。 |
| 業務経歴（直近） | 今どのあたりにいる人か。最初に目が行く項目です |
| 参画期間の並び | 短期が続いていないか、空白が長くないか |
| 担当工程 | どこまで任せられるか。「実装」だけか、設計から入れるか |
| 自己PR | 複数案件にまたがる強み（自己PR欄の書き方） |
逆に、資格欄や意欲を述べた文章は、案件の要件に直結しない限り、じっくり読まれないことが多いです。限られたスペースは、担当範囲が伝わる情報に使うほうが効きます。
“伝わる”スキルシートの3原則
1. 箇条書き・言い切りで、読みやすく
採用担当者は多くのシートに目を通します。一文を短く、箇条書きで読みやすくまとめ、文末は「です・ます」ではなく「設計・実装」「障害対応」のように言い切りにすると、スキャンしやすくなります。決まった枚数はありません。長さを気にするより、担当工程と成果がひと目で分かることを優先してください。
2. 具体的に、できれば数字で
評価を分けるのは具体性です。「バックエンドを開発」より「会員基盤APIの設計・実装（月間〇〇万リクエスト規模）」のように、担当工程・規模・成果を具体的に。可能な範囲で数字を添えると、案件先がイメージしやすくなります。
数字は、必ずしも派手なものである必要はありません。「◯名のチーム」「◯万件のデータ移行」「応答を◯秒→◯秒に改善」といった、業務の規模感が伝わるもので十分です。数字が入ると、同じ内容でも具体性が一段上がります。
数字が出しにくい場合は、担当した範囲を明確にするだけでも効果があります。「テストを担当」より「単体テストの設計から実施まで担当」のように、どこからどこまでを書くと、任せられる幅が伝わります。
3. 盛らない。やった工程を“翻訳”する
立派に見せるために事実を盛る必要はありません。大切なのは、やったことを案件先に伝わる言葉へ「翻訳」して粒度を整えること。たとえば「ユーザーと打ち合わせした」は、案件先には「要件ヒアリング・仕様調整」と書いたほうが、何を担当したかが正確に伝わります。詳しくは 経験を“伝わる言葉”に翻訳するスキルシートの書き方 で解説します。
よくある失敗と、その直し方
案件を紹介する側から見て、もったいないと感じるシートには共通点があります。いずれも実力の問題ではなく、書き方で直せるものです。
| よくある失敗 | 直し方 |
|---|---|
| 見せたい案件ほど薄い | いちばん見られる直近の案件が「開発業務」の一言で終わっている状態。直近・関連の強い案件は詳しく、古い案件は要点だけに絞る（くどくならない範囲で） |
| 担当工程が抜けている | やったのに書いていない工程を埋める。運用保守や障害対応は特に漏れやすい |
| 終了時期が空欄 | 「現在稼働中」または終了年月を書く。確認の連絡を減らせます |
| 更新が止まっている | 直近の経験を反映する（いつ更新すべきか） |
| 広げて書きすぎ | 面談で崩れるので、やったことを正確に。盛らないことが結局は近道です |
特に多いのが、いちばん見られる直近の案件ほど薄くなっているケースです。すべてを同じ濃さで書く必要はありません。直近や、取りたい案件に関連の強いものを詳しく書き、古い案件は要点だけで構いません。ただし、直近の案件が一言で終わっていると、そこが何だったのか分からず、判断しづらくなります。詳しく書くべきところと、絞ってよいところを分けるのがコツです。
職種別の書き方
同じスキルシートでも、職種によって強調すべき点は変わります。
| 職種 | 強調するとよい点 |
|---|---|
| バックエンド | 担当した工程の範囲、設計判断、性能・信頼性への対応 |
| フロントエンド | UIの実装範囲、設計の共通化、パフォーマンスやUXへの配慮 |
| インフラ・SRE | 構築と運用の両面、自動化した範囲、障害対応の経験 |
| PM・PMO | 管理した規模（人数・期間）、調整した相手、進め方の工夫 |
職種別の記入例は職種別スキルシートの記入例にまとめています。まずは自分の担当工程を、上の3原則に沿って具体化することから始めてください。
テンプレートを使って形から整える
ゼロから作るのが大変な方は、テンプレートを使うのが近道です。Relayでは、案件先に伝わる項目があらかじめ並んだスキルシートのExcelテンプレートを無料配布しています。まずは形を埋めてから、3原則に沿って言葉を整えていきましょう。
テンプレートを使う利点は、項目の抜けが防げることです。自由に作ると、担当工程や稼働開始時期といった、案件先が見たい項目が抜けがちです。枠が用意されていれば、埋めるだけで必要な情報が揃います。
進め方としては、次の順番がおすすめです。まず枠を全部埋める（この時点では雑でよい）。次に3原則に沿って言葉を整える。最後に案件先の視点で読み返す。一度に完璧を目指すより、段階を分けたほうが手が止まりません。テンプレートの入手と使い方は無料テンプレート（Excel）にまとめています。
書いたスキルシートを、案件につなげる
スキルシートは「提出して終わり」ではなく、案件紹介の起点です。Relayにご登録いただければ、ご提出のスキルシートをもとに、経験に合う案件を担当者がメールでご紹介します。登録時の必須面談やしつこい営業電話はありません。
「次の一本を切らさない」ためには、稼働中の早い段階からスキルシートを整えておくのがおすすめです。書き方に迷ったら、本ガイドと各記事を行き来しながら、少しずつ“伝わる”形に近づけてください。
もっと詳しく知りたいときは
各テーマは、それぞれの記事で深掘りしています。
| テーマ | 記事 |
|---|---|
| 経験を伝わる言葉に変える | 経験を“伝わる言葉”に翻訳する書き方 |
| 担当工程の書き分け | 担当工程の書き方（工程別の記入例） |
| 職種別の記入例 | 職種別スキルシートの記入例 |
| 自己PR欄の書き方 | 読まれる自己PRと、読み飛ばされる自己PR |
| いつ更新すべきか | スキルシートはいつ更新すべきか |
| 履歴書との違い | スキルシート（職務経歴書）と履歴書の違い |
| 単価を上げる見せ方 | 単価を上げるスキルシートの見せ方 |
どこから読んでも構いませんが、まずは担当工程の書き分けから手をつけると、効果を実感しやすいはずです。工程が具体的になるだけで、任せられる範囲の見え方が大きく変わるためです。