エンジニアのスキルシートの書き方と基本ルールを徹底解説！
目次
フリーランスエンジニアが案件を獲得するとき、最初に見られるのがスキルシートです。書類の段階で面談に進めるかどうかが決まるため、内容の質がそのまま紹介される案件の幅と単価に影響します。
この記事では、スキルシートの位置づけと職務経歴書との違い、項目別の書き方と記入例、作成時の基本ルール、上流工程やマネジメント案件を狙う場合のポイント、生成AIを活用する際の注意点まで解説します。スキルシートのテンプレート（Excel）も無料でダウンロードできます。
スキルシートとは
スキルシートとは、エンジニアとしての経験・技術・実績を、参画したプロジェクト単位で詳細に記載した書類です。読み手は開発部門の責任者や技術担当者で、「この人にどの工程をどこまで任せられるか」を判断する材料として使われます。
フリーランスの場合、エージェントへの登録時に提出し、案件に応募するたびにエージェント経由でクライアント企業に提示されるのが一般的です。面談でも詳しい確認は行われますが、時間に限りがあるため、書類の時点で経験の範囲と深さが伝わっていることが前提になります。
スキルシートの質によって、紹介される案件の幅や提示される単価は変わります。同じ経歴でも、書き方次第で年収ベースで数十万円以上の差がつくこともあります。
職務経歴書との違い
| スキルシート | 職務経歴書 | |
|---|---|---|
| 主な読み手 | 開発部門の責任者・技術担当者 | 人事・採用担当者 |
| 目的 | 技術的な経験の範囲と深さを伝える | 経歴の概要と人物像を伝える |
| 主な内容 | プロジェクトごとの環境・担当工程・役割・成果 | 職務要約、実績、自己PR、志望動機 |
| 形式 | 表形式が中心（Excel・PDF） | 文章形式が中心（Word・PDF） |
| 主な場面 | フリーランス案件、SES、エージェント登録 | 転職活動、大手・公共系の案件、一部のエージェント登録 |
職務経歴書は経歴の概要とアピールポイントを人事向けにまとめる書類で、開発環境やプロジェクト概要には触れても、具体的な技術経験まで踏み込むことは多くありません。一方でスキルシートは、どの案件で、どの技術を使い、どの工程を、どの規模で担当したかを具体的に示します。
両方求められる場面と、職務経歴書の用意の仕方
フリーランス案件の選考で最優先されるのはスキルシートですが、エージェントへの登録時、大手企業や公共案件、正社員転換を視野に入れる場合は、職務経歴書もあわせて求められることがあります。スキルシートの内容を要約する形で作ると、2つの書類の間で経歴や時期に矛盾が出ません。
職務経歴書をこれから用意する場合は、質問に答えるだけで職務経歴書をPDFで作成できる無料サービス「サクレキ」のように、エンジニア向けテンプレートを備えたツールを使うと短時間で整えられます（PDFダウンロードには無料の会員登録が必要です）。正社員への転職も視野に入れている方は、「フリーランスから正社員への転職は可能？成功のポイントを解説します」もあわせてご覧ください。
スキルシートの書き方・見本
プログラマーやSE向けのスキルシートを例に、項目ごとに説明します。テンプレートは下記から無料でダウンロードできます。
基本情報
氏名、年齢、最寄駅、所属、保有資格、学歴などを記載します。フリーランスの場合、所属は「個人事業主」または屋号を書きます。エージェント経由でクライアント企業に提示する場合は、氏名をイニシャル表記にするのが一般的です（例：T.Y）。提出先の指定に従ってください。
稼働可能時期（例：2026年10月〜）や、リモート可否・週の稼働日数といった希望する働き方を求められることもあります。指定がなければ、エージェントとの面談で伝えれば十分です。
スキル一覧（言語・フレームワーク・クラウド・ツール）
技術ごとに経験年数と習熟度を一覧にします。経験年数だけでは深さが伝わらないため、「設計から対応可能」「保守・改修のみ」「個人開発のみ」など、実務でどこまで扱えるかを一言添えると評価しやすくなります。直近いつ使ったかも重要です。3年以上触っていない技術は、使用時期を明記しておきましょう。
| 分類 | 技術 | 経験年数 | 備考 |
|---|---|---|---|
| 言語 | Go | 4年 | 実務。API設計〜実装〜レビューまで対応（直近：2026年） |
| 言語 | Python | 2年 | 実務1年（バッチ処理）＋個人開発 |
| クラウド | AWS | 5年 | ECS・RDS・Lambda中心。Terraformによる構築経験あり |
| DB | PostgreSQL | 5年 | パフォーマンスチューニング経験あり |
| ツール | GitHub Copilot／Claude Code | 1年 | 実務で日常的に利用（実装、テストコード生成、レビュー補助） |
自己PR
スキルや経歴の一覧からは、人柄や仕事の進め方は読み取れません。そのため、自己PR欄には技術面の強み、チームでの役割、仕事で心掛けていることを3〜5行で書きます。「コミュニケーションを大切にしています」のような抽象的な表現ではなく、「週次の設計レビューを主導し、手戻りを減らした」のように行動と結果で示すと伝わります。
職務経歴詳細（プロジェクトごと）
参画したプロジェクトを新しいものから順に記載します。1件ごとに次の項目を揃えると、読み手が経験を把握しやすくなります。
- 期間：開始・終了年月（西暦）と参画月数
- 案件概要：業種、システムの種類、新規開発か改修かがわかる程度の説明
- 規模・役割：チーム人数と自分のポジション（メンバー、リーダー、PMなど）
- 担当工程：要件定義〜運用・保守のうち担当した工程
- 環境：OS、クラウド、言語、フレームワーク、DB、ツール
- 業務内容・成果：担当した機能や課題と、その結果
担当工程は、次のように●で示すと一目でわかります（●＝主担当、○＝一部担当）。
| 要件定義 | 基本設計 | 詳細設計 | 実装 | テスト | 運用・保守 |
|---|---|---|---|---|---|
| ○ | ● | ● | ● | ● | － |
プロジェクト1件分の記入例です。
| 期間 | 2025年4月〜2026年3月（12ヶ月） |
|---|---|
| 案件概要 | 大手小売業向けECサイトのリプレイス（モノリスからマイクロサービスへの段階移行） |
| 規模・役割 | 開発チーム8名／バックエンドリード |
| 担当工程 | 要件定義（一部）、基本設計、詳細設計、実装、テスト、リリース、保守 |
| 環境 | AWS（ECS・RDS・Lambda）／Go、TypeScript／PostgreSQL／GitHub Actions／Datadog |
| 業務内容・成果 | 注文・決済APIの設計と実装、コードレビュー体制の整備、既存バッチのパフォーマンス改善を担当。APIの平均レスポンスを約40%短縮し、移行期間中はリリース起因の障害ゼロを達成 |
業務内容には、担当した分野や習得したスキルだけでなく、プロダクトにどう貢献したかを数字や事実で示すことがポイントです。数字が出せない場合も、「レビュー体制を整備し、リリース前の指摘件数を減らした」のように、行動と変化の両方を書きましょう。
スキルシート作成の基本ルール
スキルシートの内容は人それぞれですが、書き方には共通のルールがあります。読み手である採用担当者に響くスキルシートにするために、次の点を押さえてください。
「箇条書き」と「体言止め」で簡潔に
スキルシートは、客観的な情報を短時間で読み取ってもらうための書類です。文章で説明するのではなく、箇条書きと体言止め（言い切り）を使い、無駄な記述は省きましょう。「〜を担当しました」ではなく「〜を担当」で十分です。
A4用紙2〜4枚におさめる
分量の目安は2〜3枚、多くても4枚です。分量が多すぎると読み手の負担になり、肝心の強みが埋もれます。履歴書と違い、スキルシートはPCで作成し、Excel（原本）とPDF（提出用）の両方を用意しておくと、提出先の指定に対応できます。
直近3年を厚く、古い経歴は圧縮する
採用担当者が重視するのは直近3年程度の経験です。経験年数が長い方ほど全案件を同じ粒度で書きがちですが、5年以上前の案件は期間・案件概要・環境・役割の数行にまとめ、直近の案件に紙面を割きましょう。古い経験でも、応募する案件に直結するもの（同じ業種、同じ技術）は詳しめに残します。
守秘義務を守る
退職した会社やすでに終了した案件であっても、守秘義務は守ります。企業名を開示できない場合は「大手自動車メーカー向け」「地方銀行向け」のように業種と規模で表現し、社外秘の数値や未公開のプロダクト名は書きません。守秘義務への意識は、それ自体が評価の対象になります。
レイアウトを見直す
プロジェクトごとに区切りをつけ、期間・環境・担当工程・役割・業務内容を項目ごとに配置します。フォーマットは自由ですが、表形式のほうが読み手は比較しやすくなります。誤字脱字の修正はもちろん、改行位置や列幅、印刷時の切れなど、細部を整えてから提出しましょう。
実績は規模・役割・結果まで具体的に
スキルシートは「何ができるか」ではなく「何を、どのように、どの規模でやってきたか」を示す書類です。「期間」「業務内容」「スキル」に加えて、チームの人数、自分の役割、開発環境、得られた結果を書きます。「ECサイトの開発を担当」ではなく「8名チームでバックエンドリードとして注文APIを設計・実装、レスポンスを約40%短縮」まで書けると、経験の再現性が伝わります。
求められるスキルに合わせて作成する
スキルシートは、自分の経験を並べるだけの書類ではありません。応募する案件が求めるスキルと経験に合わせて、強調する箇所を変えるのが基本です。Web系の開発案件なら開発環境と言語の経験が、PMやPMOの案件ならマネジメントの範囲と成果が見られます。雛形を1つ作り、案件ごとに調整する運用にすると手間を抑えられます。
開発・設計は特に詳しく記載する
開発・設計についての記述は、読み手が最も知りたい部分です。使用したフレームワーク、設計の方式、担当した機能、新規開発か既存システムの改修かなどを具体的に書きます。「読むだけで開発環境と役割がイメージできる」状態が理想です。
西暦で記載する
履歴書では和暦を使うこともありますが、スキルシートでは西暦が一般的です。特に指定がなければ西暦で統一し、期間は「2025年4月〜2026年3月」のように開始と終了を明記します。
ファイル名と更新日を整える
提出時のファイル名は「スキルシート_イニシャル_202609.pdf」のように、書類名・氏名・更新年月がわかる形にします。シートの冒頭にも更新日を記載しておくと、エージェントや企業側が最新版かどうかを判断しやすくなります。
上流工程・マネジメント案件を狙う場合の書き方
要件定義や基本設計、PM・PMO、テックリード、アーキテクトといった上流ポジションの案件では、「何を実装したか」よりも「何を決め、誰と調整し、どの規模を動かしたか」が見られます。実装中心のスキルシートのままだと、上流の経験があっても伝わりません。次の要素を各プロジェクトに加えてください。
- 意思決定の範囲：技術選定、アーキテクチャ設計、非機能要件の定義など、自分が決めたこと
- 規模：チーム人数、予算規模、期間、ステークホルダーの数
- 折衝相手：顧客の情報システム部門、事業部門、経営層、協力会社など
- マネジメントの内容：進捗・品質・コスト・リスク管理のうち担当した領域と、その結果（納期遵守、障害削減、コスト削減など）
- 担当工程の●：要件定義・基本設計まで●がついているか
記入例：「30名規模の開発プロジェクトでPMOとして進捗・課題管理を担当。週次で顧客の情報システム部門と調整し、要件変更による遅延を2週間以内に抑えて予定どおりリリース」
テクフリ（運営会社：アイデンティティー）では、開発案件に加えて、要件定義・PM/PMO・テックリード・アーキテクトといった上流ポジションの案件も扱っています。上流にキャリアを広げたい方は、スキルシートをこの形に整えたうえで相談してみてください。
生成AI時代のスキルシート：AI活用経験の書き方と作成時の注意点
AIツールの利用経験は「工程」と「使い方」で書く
GitHub CopilotやClaude Code、Cursorなどのコーディング支援ツールを実務で使っている場合は、ツール名だけを並べるのではなく、どの工程で、どう使い、何が変わったかを1行で書きます（例：「テストコードの生成とリファクタリングに活用し、実装工数を約2割削減」）。LLMを組み込んだ機能の開発経験（RAG、エージェント構築、プロンプト設計など）は、技術スタックと担当工程をほかの技術と同じ粒度で記載します。
生成AIでスキルシートを作るときの注意
下書きを生成AIに手伝わせること自体は問題ありませんが、次の点は必ず自分で確認してください。
- 事実と一致しているか：AIは経験を「それらしく」補完します。使っていない技術や担当していない工程が混ざっていないか確認する
- 面談で説明できるか：書いた内容はすべて面談で深掘りされます。説明できない表現は削る
- 個性が消えていないか：定型的な表現に均されると、強みが伝わりにくくなります。成果の数字や具体的なエピソードは自分の言葉で入れる
スキルシートのどこが評価されやすいのか
書く前に、採用担当者がどこを見ているかを知っておくことも大切です。見られているポイントは大きく次の3つです。
- 強みが明確にあるか
- キャリアに一貫性があるか
- 案件の必須条件に該当する経験が、すぐに見つかるか
応募者が多い案件ほど、この3点で絞り込まれます。まったく異なる分野の短期プロジェクトが並んでいると一貫性のある印象にはならず、色々なことを書きすぎると何が強みなのかわからなくなります。案件が求めているスキルに関連する経験に絞って具体的に書く、必須条件に対応する経験はスキル一覧や自己PRにも出して埋もれさせない、といった見せ方の工夫が必要です。
なお、急募の案件では書類選考がそこまで厳しくないこともありますが、単価交渉の材料になるのはスキルシートの内容です。急募案件でも手を抜かないようにしましょう。
書いたスキルシートは、第三者の目で確認する
スキルシートは自分の経験を自分で評価して書くため、どの経験が市場で評価されるのか、どこが伝わっていないのかを自分だけで判断するのは難しい書類です。同じ内容でも、案件側が求める言葉に置き換えるだけで通過率が変わることがあります。
テクフリ（運営会社：アイデンティティー）では、登録後のカウンセリングでスキルシートをもとに経験と希望条件を確認し、案件に合わせた見せ方や単価の目安を相談できます。マージン率10%の案件を公開しているほか、新規登録から参画までは最速2日・平均14日です。スキルシートを整えたら、まずは相談してみてください。
まとめ
スキルシートで最も大切なのは、案件で求められている経験と技術を把握し、それに合わせて自分の経験を見せることです。どれだけきれいに整えても、読み手が知りたい情報が書かれていなければ響きません。
まずは雛形となるスキルシートを1つ作り、案件ごとに強調する箇所を調整する運用にしましょう。プロジェクトごとに期間・規模・役割・担当工程・環境・成果を揃え、直近3年を厚く、守秘義務を守り、西暦で統一する。この基本を押さえたうえで、例えば、上流を狙うなら意思決定と折衝の範囲を、AI活用の経験があれば工程と使い方を加えれば、案件の選択肢は広がります。
よくある質問
Q. GitHubやポートフォリオがあればスキルシートは簡潔でよいですか？
A. スキルシートは最優先でチェックされる書類です。ポートフォリオやGitHubは技術力の証明になりますが、スキルシートはチームでの立ち回りや責任範囲、担当工程を短時間で把握するために欠かせません。GitHubのURLはスキルシートに記載しつつ、本記事の基本ルールに沿ったスキルシートも別途作り込みましょう。
Q. 経験が浅い技術を「使えます」と書いてもよいですか？
A. どの程度使えるかの注釈を添えるのがマナーです。実務未経験でも、独学や個人開発で触れた技術を書くことはプラスになります。ただし実務経験と混同されないよう、「個人開発で3ヶ月使用」「研修で基礎を習得」などの注釈をスキル一覧に入れましょう。
Q. スキルシートと職務経歴書は両方必要ですか？
A. フリーランス案件の選考ではスキルシートが最優先です。ただし、エージェントの登録時や大手企業・公共系の案件、正社員転換を視野に入れる場合は両方求められることがあります。職務経歴書はスキルシートの要約として作り、案件の時期や役割に食い違いが出ないよう揃えておきましょう。
Q. 企業名や自分の氏名はどこまで書くべきですか？
A. 企業名は守秘義務の有無を確認したうえで、原則として「大手通信キャリア向け」のように業種と規模で表現します。自分の氏名は、エージェント経由でクライアント企業に提示される場合はイニシャル表記が一般的です。提出先から指定があればそれに従ってください。
Q. 短期案件やブランクが多い場合はどう書けばよいですか？
A. 数ヶ月単位の短期案件が続いている場合は、同じ種類の案件をまとめて「保守・改修案件を3件（各2〜4ヶ月）」のように1つの行にすると、一貫性が伝わります。ブランク期間は空白のままにせず、学習・個人開発・資格取得など、その間の活動を1行添えておきましょう。空白があると面談で必ず聞かれます。
Q. スキルシートはどのくらいの頻度で更新すべきですか？
A. 案件が終わるごとに更新し、少なくとも半年に1回は見直すのが目安です。参画中の案件も「現在参画中」として記載しておくと、次の案件探しをスムーズに始められます。更新日を明記し、常に最新版を提出できる状態にしておきましょう。
