フリーランスエンジニアのスキルシートの書き方｜記入例とExcelフォーマット無料ダウンロード

スキルシートとは｜履歴書・職務経歴書・ポートフォリオとの違い

スキルシートとは、保有スキル・資格・職務経歴をまとめた技術職向けの経歴書です。応募先に対して「この案件で何ができるか」を伝えることが目的で、決まった形式はありません。

よく混同される3つの書類との違いを整理します。

職務経歴書との差は小さく、スキルシートは技術職向けの職務経歴書と考えて差し支えありません。ただし、使用言語・データベース・OS・開発体制・担当工程まで踏み込む点が違います。この使い分けは「職務経歴書とスキルシートの違い｜フリーランスエンジニアの使い分けと書き方」で詳しく整理しています。

ポートフォリオは制作物そのものを見せる書類で、デザイナーやフロントエンド寄りの職種で併用されます。コードで見せたい場合は「GitHubポートフォリオの作り方｜フリーランスエンジニアの案件獲得につなげる見せ方」も参考になります。

なぜスキルシートで選考結果が決まるのか

案件に応募すると、クライアントが最初に見るのはスキルシートです。ここで案件にマッチしていると判断されなければ、面談には進めません。

さらに、面談に進んだ場合も面談官はスキルシートを読んだうえで臨みます。質問の内容そのものがスキルシートによって決まるため、書き方は面談の難易度にも影響します。書いていないことは聞かれず、書いたことは深掘りされる、と考えておくと準備しやすくなります。

面談で何を聞かれるかは「フリーランスエンジニアの面談で聞かれる質問と回答例｜職種別Q&Aと逆質問まで解説」にまとめています。

スキルシートに記載する項目と書き方

必須の項目は5つです。まず全体像を押さえます。

基本情報

氏名はイニシャル表記で運用されることが多い項目です。業務委託の選考では個人が特定できる情報をマスキングして提出する商流が多いためです。ただし提出先やエージェントによって扱いは異なるため、指定がある場合はそちらに従ってください。

意外と抜けやすいのが最寄り駅と稼働可能開始日です。常駐案件では通勤時間が判断材料になり、開始日は稼働調整に直結します。この2つがないだけで確認の往復が発生し、他の候補に先を越されることがあります。

職務要約

冒頭に3〜5行の要約を置きます。読み手はまずここで「読む価値があるか」を判断します。

書き方は、経験年数・主戦場の領域・得意な技術・直近の役割の4点を1文ずつ並べる形が安定します。型と職種別のテンプレートは「スキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレ」で解説しています。

職務経歴

スキルシートの中核です。案件ごとに次の5点を書きます。

• 期間：西暦で年月まで。「2024年4月〜2025年9月（1年6か月）」のように合計期間も添える

• 業務内容：システムの種類・目的・自分の担当範囲。案件名は伏せて業界とシステム種別で示す

• 役割・規模：チーム人数と自分の立場（PL、SE、PGなど）

• 言語・DB・OS・ツール：実際に触れたものを網羅的に

• 担当工程：要件定義から運用保守までのどこを担当したか

粒度で迷ったときの考え方は「スキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度」を参照してください。案件数が多く1件ずつ書くと膨らみすぎる場合は、「SESスキルシートの書き方｜案件数が多い時の集約術と粒度」の集約の考え方が使えます。

スキル・資格

言語やフレームワークは、名前を並べるだけでは判断材料になりません。経験年数と、どのレベルで使えるかを添えます。

「Java：5年（Spring Bootでの新規開発・設計から担当）」「Python：1年（データ整形バッチの実装のみ）」のように差をつけて書くと、過大にも過小にも見えません。資格は技術系だけでなく、語学系も記載します。オフショア案件や外資系の案件では評価されることがあります。

自己評価のレベル感を言葉にしづらいときは、IPAのITスキル標準（ITSS）が参考になります。ITSSは職種を11に分類し、それぞれの専門分野ごとに7段階のレベルを定義したものです。この区分をそのまま書く必要はありませんが、「独力で遂行できる」「後進を指導できる」といった表現の目安として使えます。

資格名は正式名称で書きます。情報処理技術者試験であれば、IPAの試験区分一覧にある呼称に合わせてください。略称や旧称のままだと、読み手が区分を判別できないことがあります。資格をどう扱うかは「フリーランスエンジニアの資格は案件獲得に効くのか｜評価される場面とスキルシート・面談での使い方」で整理しています。

自己PR

強みを1つに絞り、それを裏づける事実を添えます。「コミュニケーション能力があります」だけでは何も伝わりません。

「開発と運用の間に立ち、障害の一次切り分け手順を整備してエスカレーション件数を減らした」のように、行動と結果をセットで書くと読み手が評価しやすくなります。

通るスキルシートに共通する5つのポイント

書き方の原則は5つに集約できます。

具体的かつ定量的に書く

最も効くのがこれです。「大規模システムの開発」ではなく「会員数約80万人のECサイトのバックエンド開発（10名チーム）」と書きます。

数字が出せない場合でも、システム種別・利用者の性質・チーム構成のいずれかで具体性を出せます。抽象的な表現が続くと、経験が浅いのか、書くのが苦手なだけなのかを読み手が判別できません。定量表現の作り方は「スキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳」で掘り下げています。

応募する案件に合わせて出し分ける

スキルシートは1枚を使い回すものではありません。応募案件で求められている技術と工程を前に出すよう並べ替えます。

全案件を同じ詳しさで書く必要もありません。関連の薄い案件は行数を減らし、関連する案件に紙面を割きます。

情報を最新に保つ

年齢、直近の稼働状況、追加した資格は更新漏れが起きやすい箇所です。

更新されていないスキルシートは、実務でも記録や更新が雑なのではという印象につながります。直近の経歴が抜けていると、ブランクがあると誤解されることもあります。

見やすさを整える

文字サイズ、フォント、列幅、余白を揃えます。内容が良くても、読みにくいと最後まで読まれません。

A4で2〜4枚程度に収まると読み手の負担が小さくなります。10枚を超えるようであれば、古い案件を集約する段階に来ています。

短期終了の案件には理由を添える

1〜3か月で終わっている案件は目に留まりやすい箇所です。長期で参画してもらいたい側からすると、早期終了のリスクとして見えるためです。

「案件側の予算縮小のため」「開発フェーズ完了に伴う契約満了」のように、やむを得ない事情であることが分かる一言を添えるだけで印象が変わります。空白期間の書き方は「スキルシートの空白期間の書き方｜フリーランスエンジニアの表現例と粒度」を参考にしてください。

NG例とOK例｜そのまま使える書き換え表

抽象的な表現を具体化するだけで、伝わる情報量は大きく変わります。よくある書き方を並べます。

書き換えのコツは、形容詞を数字か固有名詞に置き換えることです。「大規模」「多数」「幅広く」といった語が出てきたら、置き換えられないかを疑ってください。

通らない原因をもう少し体系的に確認したい場合は「フリーランスのスキルシートが通らない7つの原因｜書類選考の改善策」も併せてどうぞ。

担当工程・役割の書き方｜粒度を間違えないための対応表

担当工程は、書きすぎても書かなすぎても評価を落とします。実際にどこまで関与したかで表現を変えます。

前提として、工程の呼び方は現場ごとにばらつきます。「基本設計」と「外部設計」、「詳細設計」と「内部設計」はほぼ同義で使われることが多い言葉です。読み手と用語がずれると経験が正しく伝わらないため、迷ったらIPAの共通フレーム（ソフトウェアライフサイクルプロセス）で使われる、企画・要件定義・システム方式設計・ソフトウェア方式設計といった標準的な呼称に寄せると安全です。社内固有の工程名をそのまま書くのは避けてください。

「対応可能」は経験の有無をぼかす表現として読まれます。未経験の工程は書かず、面談で意欲として伝えるほうが、結果的に信頼されます。

経歴を実態より大きく見せると、面談での深掘りで整合が取れなくなります。この失敗パターンは「経歴・スキルの盛りすぎで落ちるフリーランス面談｜NG例と信頼される自己PR」で具体的に扱っています。

職種別の書き分け

同じスキルシートでも、職種によって読み手が見る箇所が変わります。

実績がまだ少ない段階では、書ける範囲が限られます。その場合の組み立て方は「実績が少ないフリーランスエンジニアでも通るスキルシートの書き方」を参照してください。

生成AIを使った開発経験を書く機会も増えました。下書きの作成にAIを使う場合の注意点も含め、「スキルシートをAIで作る手順｜下書き活用と情報漏えい対策」で扱っています。

案件名・企業名のマスキングと守秘のルール

結論として、具体的な企業名・システム名・サービス名は原則として伏せて書きます。多くの案件で守秘義務が課されているためです。ただし、公開実績として公表されている案件や、契約上開示が認められている場合は例外になります。

伏せたうえで具体性を保つには、次の3点に置き換えます。

• 業界：金融、通信、EC、公共、製造など

• システムの種類：基幹システム、会員向けWebサービス、社内業務システムなど

• 規模の指標：利用者数、取引件数、サーバ台数、チーム人数

「大手金融機関向け勘定系システムの周辺サブシステム開発」のように書けば、企業名を出さずに難易度と性質が伝わります。

判断に迷う場合は、前の案件の契約書にある守秘条項を確認するのが確実です。エージェント経由であれば、担当者に確認するのが早く済みます。

実際の記入例とフォーマット

ここからは実際の記入例を画像で示します。前述の書き方と照らし合わせながら確認してください。

基本情報・得意分野・自己PRの記入例

業務委託の選考では個人が特定できる情報がマスキングされるため、氏名や学歴の書き方には一定の工夫が必要です。

職務経歴の記入例

参画期間、実施した業務、立場を具体的かつ定量的に記載しています。工程と使用技術が一目で追えることを確認してください。

Excelテンプレート（フォーマット）のダウンロード

そのまま使えるスキルシートのテンプレートを配布しています。会員登録は不要で、ボタンからそのままダウンロードできます。

ファイルは2枚のシートで構成しています。

• 「フォーマット」シート：基本情報・スキル・資格・自己PR・職務経歴の欄が並んだ入力用のシート。案件ごとに行を増やして使います

• 「サンプル」シート：記入見本が入ったシート。表現に迷ったときの参照用です

埋め方の順番としては、職務経歴を古い案件から並べたあとに職務要約を書くと、全体像がぶれません。要約を先に書くと、経歴の実態とずれた表現になりがちです。

書き上がったら、記入例の画像と見比べて情報の粒度が近いかを確認してください。粒度がそろっていれば、読み手が求める判断材料はおおむね満たせています。

スキルシートは単価にも影響する

同じ経験でも、書き方によって提示される単価が変わることがあります。読み手が判断できる情報が多いほど、上位の役割で評価されやすくなるためです。

特に効くのは、上流工程の関与と、体制の中での立場です。実装のみが読み取れるスキルシートと、設計から関与しチームをまとめた経験が読み取れるスキルシートでは、同じ年数でも見え方が違います。

いま自分がどのくらいの単価を狙えるかは、無料のフリーランスエンジニア単価診断で目安を確認できます。単価を体系的に上げる考え方は「フリーランスエンジニアの単価相場と単価の上げ方」に、経験年数ごとの水準は「経験年数別フリーランスエンジニアの単価相場｜1-3年・3-5年・5年以上」にまとめています。

提示された案件を比較する段階に進んだら、「案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位」の6軸スコアリングが使えます。実際の募集条件はフリコンの案件一覧で確認できます。

提出前チェックリスト

提出前に次の項目を確認してください。抜けが多い箇所から並べています。

• 最寄り駅と稼働可能開始日を書いたか

• 冒頭に3〜5行の職務要約があるか

• 各案件に期間・業務内容・役割と規模・使用技術・担当工程の5点がそろっているか

• 「大規模」「多数」「幅広く」などの形容詞が残っていないか

• 担当していない工程を「対応可能」と書いていないか

• 企業名・システム名を伏せたうえで、業界と規模で具体性を出しているか

• 言語・フレームワークに経験年数と習熟度を添えたか

• 短期終了の案件に理由を添えたか

• 直近の経歴と年齢を更新したか

• フォント・文字サイズ・列幅が揃っているか

• A4で2〜4枚程度に収まっているか

• 誤字脱字、半角と全角の混在がないか

• 応募案件で求められる技術が前に来る並びになっているか

• ファイル名に氏名や日付が入っているか

• PDFで開いてレイアウトが崩れないか

まとめ

スキルシートは、経験の量よりも記述の解像度で評価されます。同じ経歴でも、書き方しだいで読み手の受け取り方は変わります。

• スキルシートは技術職向けの職務経歴書。案件との適合性が伝わるかがすべて

• 職務経歴には期間・業務内容・役割と規模・使用技術・担当工程の5点を必ず書く

• 「大規模」「多数」などの形容詞は、数字か固有名詞に置き換える

• 担当していない工程を「対応可能」と書かない。面談での深掘りで整合が取れなくなる

• 企業名は伏せたうえで、業界・システム種別・規模で具体性を出す

• 応募案件ごとに並び順を変える。1枚を使い回さない

• 上流工程の関与と体制内での立場は、単価の評価にも影響する

次の一歩は、この記事で配布しているExcelフォーマットに直近3案件を書き出してみることです。書けない項目が出てきたら、そこが情報の不足している箇所になります。書き上がったら、提出前チェックリストで15項目を確認してください。