この用語をシェア
スキルシートとは（概要）
スキルシートとは、ITエンジニアが保有する技術スキル・保有資格・実務経験・担当したプロジェクトの詳細（体制、工程、使用技術、役割、期間）を一覧化した書類のことです。英語表記は一般に "Skill Sheet" と表記されますが、これは日本のSES・フリーランスIT業界特有の呼び方（和製英語）で、海外のIT業界では同じ役割を果たす書類として "Resume" や "Technical CV" が使われることが多く、スキルシートとまったく同一の書式が海外標準として存在するわけではありません。
一言でいえば「エンジニア版の職務経歴書兼・技術棚卸表」です。フリーランスエンジニアや常駐型のSES案件では、フリーランスエージェントやSIer（システムインテグレーター）などの仲介事業者を通じて、案件の発注側担当者（プロジェクトマネージャーやプロジェクトリーダー）にスキルシートが提出され、案件とのマッチング資料・面談（技術力確認のためのオンライン面談、いわゆる「面談」または「顔合わせ」）の判断材料として使われます。正社員の転職活動における職務経歴書と似ていますが、スキルシートは「案件単位での技術スタックと実務経験の粒度」に強く寄せて作られる点が特徴です。
スキルシートは提出したら終わりの書類ではなく、フリーランスエンジニアとしての活動期間全体を通じて何度も見直し・更新していく「生きた資産」として扱うのが実務上の考え方です。案件が変わるたびに内容を書き足していくことで、数年単位で振り返ったときに自分がどの技術領域にどれだけの深さで関わってきたかを俯瞰でき、次にどの技術を伸ばすべきかという中長期的なキャリア戦略の材料にもなります。
スキルシートの仕組み・詳細解説
記載する主な項目
スキルシートに決まった全国共通フォーマットは存在しませんが、フリーランスエージェント各社や取引先SIerが用意するExcel・Word・Googleスプレッドシート形式のテンプレートに沿って作成するのが一般的です。同じ経歴であっても、提出先が求めるテンプレートによって項目の並び順や粒度が微妙に異なるため、まずは自分用のマスターデータを作り、そこから各テンプレートへ転記するという二段階のフローで運用するのが効率的です。記載される主な項目は次のとおりです。
| 項目 | 内容 |
|---|---|
| 基本情報 | エンジニア経験年数、稼働可能時期、稼働率（週何日・何時間）、勤務形態（フルリモート／一部出社／常駐） |
| 保有スキル一覧 | プログラミング言語（Java、Python、TypeScript等）、フレームワーク、DB、クラウド（AWS／GCP／Azure）、コンテナ技術（Docker／Kubernetes）ごとの経験年数・習熟度の自己評価 |
| プロジェクト経歴 | 案件の業種・規模（体制人数）、期間、担当工程（要件定義〜運用保守のどこを担当したか）、役割（PL／SE／実装担当等）、使用技術、定量的な成果 |
| 資格・認定 | IPA区分の情報処理技術者試験（基本情報技術者、応用情報技術者、高度区分等）、AWS認定、PMP等のベンダー・業界資格 |
| 稼働条件・単価感 | 希望単価レンジ、契約形態の希望（準委任／請負／業務委託）、稼働開始可能日 |
商流の中でどう流通するか
スキルシートは、フリーランスエンジニア本人 → フリーランスエージェント（1社専属で活動する場合もあれば、複数社に同時登録して案件の間口を広げる「マルチエージェント運用」を行う人も少なくありません）→ 元請けSIerや二次請け企業 → エンドクライアント、という多重下請け構造の商流を通過しながらエンドクライアントの選考担当者まで届きます。この過程でエージェント側がテンプレートを統一したり、守秘義務に触れる案件名・社名を匿名化（「大手通信キャリア様向け」等の表現に置き換え）した上で転送することが一般的です。したがって、同じ実務経験でも提出先のフォーマットに合わせて都度書き直しが必要になる点は、フリーランスエンジニアにとって地味に手間のかかる作業です。
書き方の実務的なポイント
実務では、実績を「〜を担当した」という定性的な記述だけで終わらせず、「レスポンスタイムを50%改善」「月間障害件数を30%削減」「新規メンバー3名のオンボーディングを主導」のように定量的な成果を添えるのが定石とされています。また、直近1〜2年の案件は工程・役割・使用技術を厚めに書き、5年以上前の案件は簡潔にまとめてページ全体のバランスを取るのが読みやすいスキルシートの共通点です。近年は生成AI・LLM活用経験を独立した項目として設けるケースが増えており、単なる「経験あり／なし」ではなく、どのフレームワークで何を構築したか（RAG構築、プロンプト設計、社内業務の自動化等）まで具体的に書くことで差別化につながります。
スキルシートの構成例
実際にどのような構成でまとめるか、テキストベースの構成例を示します。エージェントごとに指定フォーマットがある場合はそちらを優先しつつ、自分用のマスターデータとして以下のような構成を1本持っておくと、提出用フォーマットへの転記作業が格段に楽になります。
【基本情報】
氏名（またはハンドルネーム）／経験年数／稼働可能時期／稼働率／勤務形態
【保有スキル】
言語 ：Java(5年)、Python(3年)、TypeScript(2年)
フレームワーク：Spring Boot、React、FastAPI
クラウド ：AWS(EC2/Lambda/RDS)、GCP(Cloud Run)
生成AI関連：LangChain、RAG構築、OpenAI/Anthropic API連携
資格 ：応用情報技術者、AWS認定ソリューションアーキテクト
【プロジェクト経歴】(直近から時系列で)
2024/10〜現在 業種：金融 規模：20名体制
役割：バックエンド開発リーダー 工程：詳細設計〜運用保守
技術：Java, Spring Boot, AWS 成果：API応答速度を50%改善
【稼働条件】
希望単価／契約形態の希望／備考このように「基本情報」「保有スキル」「プロジェクト経歴」「稼働条件」の4ブロックに分けてマスターデータを作っておけば、エージェントAには表形式、エージェントBには箇条書き、といった提出先ごとの体裁変更にも短時間で対応できます。案件が完了するたびにプロジェクト経歴の最上段に追記していく運用にすると、更新漏れを防ぎやすくなります。
具体例・ユースケース
スキルシートが実際にどう使われるか、代表的な2つの場面を挙げます。
ケース1：常駐型SES案件での選考
金融系の基幹システムリプレース案件など、常駐型のSES契約が中心の現場では、スキルシートがそのまま客先PM・PLの一次選考資料になります。書類選考を通過すると、客先担当者との「顔合わせ」と呼ばれる技術面談が設定され、スキルシートに記載した内容と実際の受け答えの整合性が確認されます。ここで実績を誇張していると、面談での深掘り質問（「その改善はどう測定したか」等）で矛盾が露呈しやすいため注意が必要です。
ケース2：フルリモート業務委託案件での即応
ECサイトのマイクロサービス化や社内向け生成AIチャットボット導入といったスタートアップ・中堅企業のフルリモート案件では、スキルシートとGitHub等のポートフォリオを合わせて提出し、オンライン面談1回で発注が決まることも珍しくありません。こうした案件では常駐型よりもスピード感が重視されるため、スキルシートは簡潔かつ最新スキルが一目でわかる構成が好まれる傾向があります。
ケース3：複数エージェント経由での単価交渉
同じスキルシートを複数のフリーランスエージェントに同時登録し、それぞれの経由で異なる案件に応募するマルチエージェント運用も一般的です。この場合、同一の経歴・スキルであっても、紹介するエージェントや商流の階層数（元請け直請けか、二次請け・三次請けを経由するか）によって提示される単価が変わることがあります。スキルシートの内容自体は同じでも、どの商流を通すかによって条件が変わりうる点は、フリーランスとして活動するうえで理解しておくべき実務知識です。
メリット・デメリット（注意点）
| 観点 | 内容 |
|---|---|
| メリット | 学歴や年齢よりも「何ができるか」という技術的な事実ベースで評価されやすく、選考プロセスが正社員採用より短期間で進みやすい。一度整備すれば複数のエージェント・複数案件で使い回せる。 |
| デメリット・注意点 | エージェント・提出先ごとにフォーマットが異なり、その都度体裁を整える手間が発生する。実績を誇張すると技術面談で見抜かれ信頼を損なう。前案件の守秘義務（NDA）に抵触するため、具体的な社名・案件名は原則として書けず、業種や規模のレベルまで抽象化する必要がある。 |
| 情報の陳腐化 | 更新を怠ると直近の技術動向（生成AI活用等）が反映されないまま古い内容で提出してしまい、実力を過小評価されるリスクがある。案件が完了するたびに更新する運用が望ましい。 |
| フォーマット差異のコスト | マルチエージェント運用をすると、同じ経歴でも提出先ごとにレイアウトや文字数制限が異なり、その都度調整する時間コストが発生する。マスターデータを1本作っておき転記する運用でこの負担は軽減できる。 |
混同されやすい用語・類似書類との違い
| 用語 | スキルシートとの違い |
|---|---|
| 職務経歴書 | 主に正社員としての転職活動で使われ、所属企業単位での実績・キャリアの流れを重視した文書構成。スキルシートは案件単位での技術スタックと工程担当範囲を重視する点で粒度が異なる。企業によっては両者を1つの書類にまとめて提出を求める場合もある。 |
| ポートフォリオ（GitHub等） | ポートフォリオは実際に動くプロダクトやソースコードそのものを提示する「成果物ベース」の資料。スキルシートは経歴・スキルをテキストで一覧化した「申告ベース」の資料であり、両者は補完関係にある。 |
| 提案書・見積書 | 提案書・見積書は特定の案件に対する作業範囲・金額の提示文書であり、業務委託契約の締結プロセスで使われる。スキルシートはその前段階、案件マッチングの入口で使われる書類という点で役割が異なる。 |
| レジュメ（英文Resume） | 海外企業や外資系プロジェクトへの応募では英文レジュメが使われることが多いが、日本国内のSES商流特有の「工程」「体制人数」「役割」といった項目立てはレジュメには馴染まないため、単純な翻訳では代替しにくい。海外案件志向の場合は英文レジュメとスキルシートを別々に用意するのが実務的である。 |
実務ポイント：提出後の契約・税務との関わり
スキルシートは単独で完結する書類ではなく、その後に続く契約形態（準委任契約・請負契約・業務委託契約）や税務手続きと密接に関わります。実務上の落とし穴として、以下の点は特に押さえておく必要があります。
インボイス制度との関係：2023年10月に開始した適格請求書等保存方式（インボイス制度）は2026年時点でも継続しており、フリーランスが免税事業者のままだと発注元（エージェントやSIer）の仕入税額控除に影響するため、スキルシート提出と前後して「インボイス発行事業者として登録済みか」を確認されるケースが一般化しています。登録の有無は単価交渉にも影響しうるため、フリーランス活動を本格化する前に登録要否を検討しておくのが望ましいとされています。
電子帳簿保存法との関係：スキルシートや契約書はメール添付やクラウドストレージ経由でやり取りされることが多く、こうした電子取引データについては電子帳簿保存法が定める保存要件（改ざん防止のための真実性の確保、検索可能性を含む可視性の確保）の対象になり得ます。紙に印刷して保管するだけでは要件を満たさないため、やり取りしたPDFやスクリーンショットをフォルダ・命名規則を決めて電子データのまま保存しておく運用が実務上は無難です。
フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）との関係：2024年11月に施行されたこの法律により、業務委託を行う発注事業者には、契約内容（業務内容・報酬額・支払期日等）を書面または電磁的方法で明示する義務や、報酬の支払期日を給付を受けた日から原則60日以内とする義務などが課されています。スキルシート提出後にこうした明示が適切に行われているかは、フリーランス自身が確認すべき実務ポイントです。口頭や簡単なチャットのやり取りだけで契約条件が曖昧なまま稼働を開始してしまうトラブルは今なお発生しやすいため、契約書面の内容確認は軽視できません。
スキルシートの更新頻度と管理：実務上の落とし穴として多いのが、稼働中の案件が長期化するほどスキルシートの更新を後回しにしてしまうケースです。案件終了直後は担当工程や成果を具体的に思い出せますが、数か月〜1年経ってから振り返って書こうとすると、定量的な成果の記憶があいまいになり、説得力のある記述が書けなくなります。案件の区切り（契約更新のタイミングや案件終了時）ごとに5分でもよいのでマスターデータへ追記する習慣をつけておくと、次にスキルシートが必要になったときの手戻りが大きく減ります。
契約書レビューとの連動：スキルシートを提出して選考が通過した後は、業務委託契約書（準委任契約または請負契約のいずれかの形態）の内容を必ず確認します。特に、契約不適合責任の範囲、秒単位・月単位いずれの精算方式か（精算幅、いわゆる「精算幅」の設定：例えば140〜180時間の範囲で単価を固定し、上下に外れた場合は追加精算・控除を行う方式）、契約解除条項、知的財産権の帰属について、スキルシートの内容と実際の契約条件に齟齬がないか照らし合わせておくことが望ましいとされています。
2025〜2026年の最新動向
生成AI・LLM関連プロジェクトの経験を持つエンジニアの需要が高まり続けており、スキルシートのフォーマットにも「生成AI活用経験」「LLM関連スキル」を独立した欄として設ける動きが業界で広がっています。従来の言語・フレームワーク欄だけでは、RAG構築経験やプロンプトエンジニアリング、ベクトルDB活用といった経験を十分に表現しきれないためです。
また、依然としてExcel形式のスキルシートが主流ではあるものの、Notionやポートフォリオサイトを使ったオンライン形式での情報提示を併用するエンジニアも増えつつあります。フリーランスエージェント各社でも、提出されたスキルシートをAIで要約・タグ付けし、案件とのマッチング精度を上げる取り組みが進みつつあり、記載内容が構造化されている（見出しや箇条書きが整理されている）スキルシートほど、こうした自動処理との相性が良い傾向があります。
制度面では、2024年11月施行のフリーランス新法の運用が本格化し、契約条件の書面明示や報酬支払期日の順守といった実務が徐々に浸透してきています。スキルシート提出後の契約プロセスがより明確になることで、フリーランスエンジニア側も自身の権利を確認しやすい環境が整いつつあると言えます。
稼働形態の面では、フルリモート案件の比率が高い水準で定着し、常駐必須の案件でも「週1〜2出社＋残りリモート」のようなハイブリッド型が一般化しています。この結果、スキルシートの「勤務形態」欄に「フルリモート可」「一部出社可（頻度）」を明記することが、案件マッチングの初期スクリーニングで重視されるようになってきました。あわせて、単価水準についても、生成AI・クラウドネイティブ関連の技術を持つエンジニアとそうでないエンジニアとの間で提示される単価に差が生まれやすい傾向が続いており、スキルシートでどの技術をどの深さで経験しているかを明確に伝えられるかどうかが、単価交渉の出発点として一段と重要になっています。
よくある質問（FAQ）
Q1. フリーランスのスキルシートはどう書けばよいですか？
使用技術・フレームワーク・バージョン、プロジェクトの規模、担当した工程、担当した役割、そして可能な限り定量的な成果（応答速度50%改善等）を具体的に記載します。最新技術（生成AI・LLM、Kubernetes等）を経験している場合は独立した項目として明記すると、案件とのマッチング精度が上がりやすくなります。加えて、直近の案件を厚めに、古い案件は簡潔にまとめてページ全体の分量を読みやすく保つことも意識するとよいでしょう。
Q2. GitHubポートフォリオはスキルシートの代わりになりますか？
補完材料としては非常に有効です。活発なコミット履歴、充実したREADME、実際に動くプロダクトは実力の証明になります。ただし、日本の商流を通す常駐型SES案件などでは書式が整ったスキルシートも別途求められることが多いため、両方を用意しておくのが実務上は無難です。
Q3. 生成AI・LLMエンジニアのスキルシートに書くべきことは？
利用したLLM・フレームワーク（LangChain等）、RAGシステムの構築経験、ベクトルDBの活用経験、MLOpsツール、GPU活用経験、精度改善の実績などが評価されやすい項目です。単に「生成AIを使った経験がある」と書くのではなく、どのような課題をどう解決したかまで具体的に書くことが重要です。例えば「社内問い合わせ対応の一次回答をLLMで自動化し、対応工数を月間20時間削減した」のように、対象業務・使用技術・成果をセットで記載すると説得力が増します。
Q4. スキルシートと職務経歴書は何が違うのですか？
職務経歴書は主に正社員転職向けで、所属企業単位のキャリアの流れを重視します。一方スキルシートは案件単位の技術スタックと工程担当範囲に焦点を当てた書類で、フリーランス・SES案件のマッチングに特化しています。提出先によっては両者をまとめた書式を求められることもあるため、応募先の指示を事前に確認しておくとよいでしょう。
Q5. スキルシートに前案件の案件名や取引先名を書いてもよいですか？
多くの場合、前案件の契約に守秘義務（NDA）条項が含まれているため、具体的な社名・案件名をそのまま記載するのは避けるべきです。「大手通信キャリア向け」「金融系基幹システム」のように業種・規模のレベルまで抽象化して記載し、契約書に定められた秘密保持の範囲を超えないよう注意する必要があります。判断に迷う場合は、案件終了時に交わした契約書の秘密保持条項を読み返し、どこまでの情報開示が許容されているかを確認してから記載するのが安全です。