フリーランスのスキルシートの書き方｜基本の構成とプロジェクト欄の例
公開 2026-10-29 監修：株式会社エージェントベスト
フリーランスのスキルシートは、「基本情報」「得意分野の要約」「スキル一覧」「プロジェクト経歴」の4つで組み立てるのが基本です。読み手は「この人に、この案件の何を任せられるか」を短時間で判断したいので、プロジェクト1件ごとに役割・担当工程・使った技術・成果をそろえて書くことが大切です。
この記事では、構成の並べ方と、プロジェクト欄の書き方の型を、架空の例を使って紹介します。
スキルシートは誰が、どう読むのか
業務委託の案件では、スキルシートは面談の前に発注側の担当者が読みます。多くの場合、読むのは現場のプロジェクトリーダーやマネージャーで、複数の候補者のシートを並べて比べます。1人あたりにかける時間は長くありません。
そのため、スキルシートで求められるのは「読みやすさ」と「案件との結び付けやすさ」です。正社員の転職で使う職務経歴書のように自己PRを長く書くよりも、どの工程で何をしてきたかが一目で分かる形が向いています。
読み手が見ているのは、主に次の点です。
- 案件で必要な技術・業務知識を、実務で使ったことがあるか
- どの工程（要件定義・設計・開発・テスト・運用）を担当できるか
- チームの中でどの立場だったか（メンバー、リーダー、PM、PMOなど）
- 直近の経験か、何年も前の経験か
- 期間の長さと、途中で終わった案件が多くないか
基本の構成と並べ方
スキルシートの形式は案件紹介サービスや発注元ごとに指定があることも多いですが、どの形式でも中身の順番はおおむね同じです。
| 順番 | 項目 | 書くこと |
|---|---|---|
| 1 | 基本情報 | イニシャル、年代、最寄り駅（エリア）、稼働開始日、希望の稼働日数・働き方 |
| 2 | 得意分野の要約 | 3〜5行で「何ができる人か」をまとめる |
| 3 | スキル一覧 | 言語・フレームワーク・クラウド・DB・ツール・業務知識と、それぞれの経験年数 |
| 4 | 資格 | 案件に関係するものを中心に |
| 5 | プロジェクト経歴 | 新しい順に1件ずつ。役割・工程・技術・成果 |
基本情報は「提案の可否」に関わる項目を落とさない
稼働開始日、週何日働けるか、リモート希望か出社可能か、といった項目は、スキルの中身より先に確認されます。条件が合わなければ提案自体ができないためです。氏名は、提案の段階ではイニシャルで出されるのが一般的です。
得意分野の要約は、案件ごとに書き換える
要約は、スキルシートの中で最もよく読まれる部分です。経歴を年代順に並べ直すのではなく、「自分が一番価値を出せる領域」を先に書きます。
架空の例（バックエンドエンジニアの場合）：
- Java・Spring Bootを中心に、業務系Webシステムの設計・開発に8年従事
- 直近3年は、5名規模のチームのリーダーとして基本設計からリリースまでを担当
- 金融系の決済まわりの業務知識あり。AWS上での構築・運用経験あり
応募する案件で求められている経験を、上の行に持ってくるだけでも読み手の印象は変わります。
プロジェクト欄の書き方の型
プロジェクト経歴は、1件ごとに同じ項目をそろえて書くと比べやすくなります。次の型を基本にすると、抜け漏れが出にくくなります。
| 項目 | 書き方のポイント |
|---|---|
| 期間 | 年月で書く（例：2024年4月〜2025年9月）。複数案件の並行は分かるように |
| 業種・案件概要 | 社名は書かず「保険会社向け」「EC事業者向け」など業種で書く |
| 規模 | チーム人数、自分の立場（メンバー／リーダー／PMなど） |
| 担当工程 | 要件定義・基本設計・詳細設計・開発・テスト・運用保守のどこか |
| 使用技術 | 言語、フレームワーク、DB、クラウド、ツール |
| 担当した内容 | 具体的な作業を2〜4行で |
| 工夫・成果 | 自分の行動で何が変わったか |
架空の記入例
期間：2024年4月〜2025年9月（1年6か月）
案件概要：小売業向け 受発注システムの刷新
規模・立場：開発チーム6名（うち自分はサブリーダー）
担当工程：基本設計、詳細設計、開発、結合テスト
使用技術：Java 17、Spring Boot、PostgreSQL、AWS（ECS、RDS）、GitHub Actions
担当内容：発注・在庫引当の機能の設計と実装。メンバー3名のレビューとタスクの割り振り
工夫・成果：夜間バッチの処理を分割して並列化し、処理時間を短くした。レビューの観点を一覧にまとめ、手戻りを減らした
これは記入の型を示すための架空の例です。実際に書くときは、ご自身の経験に置き換えてください。
「担当内容」と「成果」を分けて書く
よくあるのは、担当内容の欄に「設計・開発を担当」とだけ書いてしまう形です。これだけでは、どの機能を、どの深さで担当したのかが伝わりません。
- 担当内容：何を、どの範囲で、誰と行ったか
- 成果：その結果、何が良くなったか
と分けると、読み手は「任せられる範囲」を判断しやすくなります。成果は、数字で書けるものは数字で書きます。ただし、守秘義務に触れる数字（売上、取引先の件数など）は書かないでください。書いてよい範囲の考え方はスキルシートと守秘義務の記事で解説しています。
スキル一覧の書き方
スキル一覧は、技術の名前を並べるだけでなく、経験年数と使い方の深さを添えると読み手の判断が早くなります。
| 区分 | 記入例（架空） |
|---|---|
| 言語 | Java（8年・設計から担当）、Python（2年・スクリプト作成） |
| フレームワーク | Spring Boot（5年）、Django（1年） |
| DB | PostgreSQL（5年・設計とチューニング）、Oracle（3年・SQL作成） |
| クラウド | AWS（3年・ECS、RDS、Lambdaの構築と運用） |
| 業務知識 | 小売の受発注・在庫管理、決済 |
経験年数は、実務で使った期間で数えます。学習しただけの技術を同じ欄に並べると、面談で深く聞かれたときに答えに詰まり、ほかの記載の信頼まで下がることがあります。学習中の技術は「学習中」と分けて書くほうが誠実です。
古い経歴・短い経歴の扱い
10年以上前の経歴は短くまとめる
経歴が長い方は、すべてのプロジェクトを同じ分量で書くと、シートが長くなり、直近の経験が埋もれます。直近5年程度をくわしく、それより前は「期間・業種・役割・主な技術」を1〜2行にまとめる形が読みやすくなります。
短期間で終わった案件は、事実を簡潔に
数か月で終わった案件も、隠さずに期間どおり書きます。プロジェクトの終了や体制の変更など、理由が明確であれば一言添えておくと、面談で聞かれたときに説明しやすくなります。期間を実際より長く書くことはしないでください。経歴の確認で食い違いが分かると、信頼を大きく損ないます。
提出前に見直したいチェックリスト
- 基本情報に、稼働開始日・稼働日数・働き方の希望が入っているか
- 要約の1行目に、応募する案件で求められる経験が来ているか
- プロジェクトは新しい順に並んでいるか
- 各プロジェクトに、立場・担当工程・使用技術がそろっているか
- 社名・製品名・未公開の数字など、守秘義務に触れる情報が入っていないか
- 誤字や、技術名の表記ゆれ（例：「Postgres」と「PostgreSQL」）がないか
- ファイル形式と名前が、提出先の指定どおりか
職種によって厚く書くところ
同じ型でも、職種によって読み手が重視する欄が違います。
- エンジニア：使用技術とバージョン、担当した機能の範囲、設計にどこまで関わったか
- PM・PMO：プロジェクトの規模（人数・期間）、管理した対象（進捗・課題・品質・予算）、関係者の範囲
- ITコンサル：テーマ（業務改革、システム選定、構想策定など）、作成した成果物、顧客側のどの層と向き合ったか
PM・PMOの方はPMのスキルシートの記事、PMOのスキルシートの記事もあわせてご覧ください。
よくある質問
スキルシートは何枚くらいが適切ですか？
決まった枚数はありませんが、読み手が短時間で判断できる分量が目安です。経歴が長い場合は、直近の経験をくわしく書き、古い経歴は1〜2行にまとめると読みやすくなります。提出先から形式や分量の指定がある場合は、それに従ってください。
正社員時代の経歴もプロジェクトとして書いてよいですか？
書いてかまいません。会社員として関わったプロジェクトも、役割・担当工程・使用技術・成果は同じ型で書けます。社内の業務改善や社内システムの担当なども、案件に関係する経験であれば記載すると判断材料になります。
経験の浅い技術は書かないほうがよいですか？
実務で使った技術であれば、期間や使い方の深さを添えて書くとよいでしょう。学習しただけの技術は、実務経験と区別して「学習中」と書くほうが、面談で質問されたときに食い違いが起きません。