フリーランスエンジニアのスキルシートの書き方｜案件紹介で伝わる7項目

フリーランス向けの案件へ応募するとき、技術名を多く並べれば評価されるとは限りません。募集側が知りたいのは、JavaやAWSを「知っているか」だけではなく、どの規模の環境で、どの役割として、どこまで担当したかです。

その照合に使われるのがスキルシートです。正社員の転職で使う職務経歴書と似ていますが、案件単位で必要な経験を探しやすくする役割が強くなります。

この記事では、フリーランスエンジニアのスキルシートにそろえたい項目を7つに整理します。実績を誇張せずに具体化する方法と、守秘義務のために書いてはいけない情報もあわせて確認します。

先に結論

• 案件ごとに同じ7項目を並べる。 案件概要、期間、体制と役割、担当工程、技術環境、成果、希望条件の順にすると比較しやすい。
• 技術名には利用場面を添える。 「AWS」だけでなく、「TerraformでVPCとIAMを構築」のように担当作業まで書く。
• 成果は売上だけではない。 障害件数、作業時間、手戻り、属人化など、変更前後の差で表せる。
• 公開できない情報は匿名化する。 顧客名、内部URL、IPアドレス、構成図、認証情報は書かない。
• 応募先に近い経験を厚くする。 すべての案件を同じ文字量で書く必要はない。

職務経歴書とスキルシートの違い

どちらも経歴を伝える資料ですが、読み手が探す情報の順序が違います。

資料	主な目的	読み手が確認すること
職務経歴書	転職候補者としての経歴と強みを伝える	所属企業、役割の変化、実績、志望先で再現できる強み
スキルシート	募集中の案件と経験が合うか照合する	担当工程、技術環境、経験期間、役割、稼働条件

職務経歴書ではキャリア全体の流れが重要です。一方、スキルシートでは「基本設計の経験があるか」「AWSの構築を自分で担当したか」「チームリーダー経験があるか」といった条件を、案件ごとに短時間で確認できることが重要です。

正社員向けの職務経歴書をすでに持っている場合は、ゼロから書き直す必要はありません。インフラ／クラウド職の職務経歴書で整理した案件・役割・実績を、これから説明する7項目へ並べ替えると土台になります。

項目1 案件概要

最初に、何のための案件だったかを1〜2行で書きます。ここで顧客名や社内のプロジェクト名を出す必要はありません。

書き方の例

製造業向けの社内システムをオンプレミスからクラウドへ移行するプロジェクト。既存環境の調査とAWS基盤の設計・構築を担当。

「クラウド移行案件」とだけ書くより、対象と目的が伝わります。固有名詞を伏せても、業界、システムの用途、変更の内容は説明できます。

案件概要に入れたいのは次の3点です。

• 対象となる業界や利用者
• システムやサービスの用途
• 新規開発、移行、更改、運用改善など案件の目的

項目2 参画期間

期間は年月でそろえます。複数案件を並行していた場合は、期間が重なっていても事実どおりに記載し、兼務だったことを補足します。

期間から見られるのは、単なる在籍年数ではありません。

• 立ち上げからリリースまで経験したか
• 運用だけでなく更改や改善も経験したか
• 同じ技術を複数案件で使ったか
• 短期間の案件が続く場合、その理由を説明できるか

「AWS経験3年」と合計だけを書くより、どの案件で何をした3年なのかを分けたほうが、実務の範囲が伝わります。

項目3 チーム体制と自分の役割

同じ作業でも、1人で担当したのか、10人のチームで一部を担当したのかでは経験の意味が変わります。人数を開示できる場合は、おおよその規模と自分の役割を書きます。

曖昧な書き方	判断しやすい書き方
インフラを担当	5名の基盤チームでAWS設計・構築を担当
リーダーとして参画	基盤チーム3名の進捗管理と設計レビューを担当
顧客対応を経験	要件確認会へ参加し、非機能要件の確認と課題管理を担当

「リーダー」「PM」といった肩書だけでは、実際の担当範囲が分かりません。メンバーの作業割り当て、レビュー、進捗管理、顧客との調整など、行った作業へ分解します。

項目4 担当工程と作業内容

要件定義、基本設計、詳細設計、構築、テスト、移行、運用のうち、実際に担当した工程を記載します。プロジェクト全体で存在した工程ではなく、自分が担当した工程だけを書くことが重要です。

たとえば「設計・構築」だけでは、何を設計したのかが分かりません。

改善前

AWSの設計・構築、テストを担当。

改善後

VPC、サブネット、ルートテーブル、Security Groupの基本設計と構築を担当。CloudWatch Logsを使ったログ収集を設定し、結合テスト項目を作成・実施。

サービス名と作業内容が結びつくと、募集要件との照合がしやすくなります。ただし、実際にはレビューだけを担当した設計を「設計した」と書くなど、担当範囲を広げてはいけません。

項目5 技術環境

技術環境はカテゴリをそろえて書くと読みやすくなります。

• OS
• クラウド
• 言語・スクリプト
• ミドルウェア・データベース
• IaC・CI/CD
• 監視・運用ツール
• バージョン管理・チケット管理

経験年数を付ける場合は、学習期間と実務期間を混ぜないようにします。個人学習で構築した環境は「自己学習」「個人開発」と明記すれば、実務経験とは別の補足材料になります。

資格も同様です。取得した資格は知識の範囲を示しますが、実務で設計・構築した証明にはなりません。資格と案件経験を別々に書くと、誤解を避けられます。

項目6 成果と改善

成果は売上や利用者数だけではありません。機密情報のため数値を出せない案件でも、変更前の課題と変更後の状態は書けます。

次の型を使うと整理しやすくなります。

1. 変更前に何が問題だったか
2. 自分が何を担当したか
3. 変更後に何を確認できたか

例

手作業で実施していた環境構築をTerraformへ移行。コードレビューと実行手順を整備し、担当者ごとに異なっていた構築作業を同じ手順で再現できる状態にした。

数値を使える場合も、根拠のある範囲に限定します。「作業時間を50%削減」と書くなら、変更前後の計測方法を説明できる必要があります。測っていない数字を推定で置くより、「月次作業を自動化し、手作業の工程をなくした」と事実を具体化するほうが安全です。

項目7 希望条件と稼働可能時期

最後に、案件選びに必要な条件を書きます。希望条件を曖昧にすると、紹介を受けてから条件が合わないことが分かり、双方の確認工数が増えます。

• 稼働開始できる時期
• 希望する稼働日数
• 常駐、リモート、併用の希望
• 対応できる時間帯
• 希望する業務領域
• 避けたい条件

単価は経験、担当範囲、稼働日数、商流などで変わるため、スキルシートだけで固定せず、案件の条件を見て確認する方法があります。希望条件に優先順位を付けておくと、単価と働き方のどちらを優先するか判断しやすくなります。

1案件分を表にするとどうなるか

以下は書式を示すための架空例です。実在する案件や管理人の経歴ではありません。

項目	記載例
案件概要	製造業向け社内システムのクラウド移行
期間	2024年4月〜2025年3月
体制・役割	基盤チーム5名、メンバーとして設計・構築を担当
担当工程	基本設計、詳細設計、構築、結合テスト、移行
技術環境	AWS、Linux、Terraform、GitHub、CloudWatch
担当内容	ネットワークとIAMの設計・構築、監視設定、テスト項目作成
成果	Terraform化とレビュー手順の整備により、同じ構成を再現できる手順を確立

この粒度で案件を並べると、技術環境と担当範囲を切り離さずに読めます。応募先に近い案件は担当内容と成果を詳しくし、古い案件や関連が薄い案件は短くまとめます。

募集要件に合わせて並べ替える手順

スキルシートの原本は1つで構いませんが、すべての応募先へ同じ版を送ると、今回の案件に関係する経験が埋もれます。経歴そのものを変えるのではなく、説明の順序と詳しさを調整します。

1. 募集要件を3つに分ける

案件情報に書かれている条件を、次の3つへ分けます。

分類	意味	スキルシートでの扱い
必須	満たさなければ参画が難しい条件	該当する案件・期間・担当内容をすぐ見つけられるようにする
歓迎	あれば評価材料になる条件	実務経験か学習経験かを分けて補足する
業務条件	稼働日数、場所、開始時期など	希望条件欄で回答する

たとえば「AWSでの基盤構築3年以上」が必須なら、AWSを使った案件を数えるだけでは不十分です。各案件で構築を担当したのか、運用だけだったのかを確認し、構築を担当した案件の説明を厚くします。

一方、「コンテナ経験歓迎」に対して個人学習しかない場合は、「Dockerを使った個人開発」として別に記載できます。歓迎条件を満たそうとして実務経験の欄へ混ぜると、面談で担当範囲を確認されたときに説明が崩れます。

2. 必須条件の根拠を案件へひも付ける

必須条件ごとに、根拠になる案件へ印を付けます。

• AWS設計：案件AでVPC・IAMの基本設計
• Terraform：案件Aと案件Bでモジュール作成・レビュー
• リーダー経験：案件Cで3名の進捗管理
• 顧客折衝：案件Cで要件確認と課題管理

この対応関係が作れない条件は、スキルシート上でも読み手に伝わりません。「経験あり」とだけ書いていた技術に、利用場面を足す必要があります。

3. 関連する案件を先に詳しくする

経歴は新しい順に並べるのが基本ですが、各案件の文字量は変えられます。応募先と同じ技術・工程・役割を含む案件は詳細にし、関連の薄い古い案件は概要だけにします。

ただし、案件の順番を入れ替えて時系列を分かりにくくする必要はありません。冒頭に「応募案件に関連する経験」として3〜5行の要約を置き、本文の該当案件へ誘導する方法もあります。

4. 面談で説明できるか確認する

提出前に、各行について次の質問へ答えられるか確認します。

• なぜその技術を選んだのか
• 自分で決めた範囲と、指示を受けて対応した範囲はどこか
• うまくいかなかった点と、どう修正したか
• チーム内で誰と連携したか
• 同じ条件でもう一度担当するなら何を変えるか

書類に短く書いた内容でも、面談では詳細を聞かれます。説明できない表現は削るか、実際の担当範囲に直します。スキルシートを大きく見せるより、書いた内容と口頭説明が一致しているほうが信頼を損ないません。

職種ごとに詳しくする場所

7項目の枠は共通ですが、職種によって読み手が詳しく見たい部分は変わります。

アプリケーションエンジニア

言語とフレームワークだけでなく、担当した機能と品質への関わりを書きます。

• API、画面、バッチなど、担当した機能
• 新規実装、改修、保守のどれか
• 単体テスト・結合テスト・コードレビューの範囲
• データベース設計や性能改善への関与
• CI/CD、監視、リリース作業の経験

「Javaを3年」より、「Spring Bootで業務APIの設計・実装・単体テストを担当」のほうが、案件で任せられる範囲が分かります。チーム開発では、Gitの運用やレビュー経験も別の判断材料になります。

インフラ・クラウドエンジニア

サービス名の羅列ではなく、設計・構築・運用のどこを担当したかを明確にします。

• ネットワーク、ID、コンピュート、監視など担当領域
• オンプレミス、クラウド、ハイブリッドの構成
• IaCで作成した範囲とレビュー方法
• 可用性、バックアップ、セキュリティの設計経験
• 障害対応、変更管理、運用改善の実績

クラウドの管理画面を操作した経験と、要件から構成を設計した経験は分けて書きます。運用担当でも、アラート設計を見直した、手順を自動化した、障害の再発防止策を実装したといった改善は成果になります。

PM・PMO・リーダー

役職名よりも、管理した対象と意思決定の範囲を書きます。

• チーム人数と関係者の範囲
• 進捗、課題、品質、予算のうち担当した管理領域
• 会議体の運営、報告資料、意思決定支援
• リスクを検知して対応した事例
• 技術チームと業務部門の間で調整した内容

「PMOとして支援」だけでは作業が分かりません。「週次進捗の集約、課題管理表の更新、遅延タスクの担当者調整」のように、日常の作業へ分解します。管理職ではなく技術リーダーだった場合も、その違いが分かるようにします。

セキュリティ・SRE・運用

障害や脆弱性の具体的な内部情報は伏せながら、検知・対応・改善の流れを書きます。

• 監視対象とアラート設計の担当範囲
• インシデント対応で担った役割
• 原因分析と再発防止の進め方
• パッチ、脆弱性、権限の管理方法
• SLI・SLOや運用指標を使った改善経験

守秘義務のために障害の詳細を出せなくても、「検知に時間がかかっていた状態から、監視項目と通知経路を見直した」のように課題と対応を説明できます。

経歴の空白や短期案件をどう書くか

経歴に空白期間や短期終了の案件があっても、期間を隠したり別の案件へ足したりしてはいけません。年月を事実どおりに記載し、必要なら理由を短く補足します。

空白期間に学習や個人開発をしていた場合は、実務案件とは別の欄にまとめます。

2025年1月〜3月：AWS認定資格の学習、Terraformを使った検証環境の構築

これで実務経験になるわけではありませんが、空白期間に何をしていたかは伝わります。家族の事情や療養など、応募先へ詳しく開示する必要がない個人情報まで書く必要はありません。

短期案件は、終了理由を説明できる形にします。

• 当初から3か月の移行支援として契約
• 担当工程の完了により契約終了
• プロジェクト方針の変更により終了

自分の都合で途中終了した場合も、事実と異なる理由に置き換えてはいけません。面談で確認されたときに、発生した問題と次に同じことを避けるための判断を説明できるようにします。

ファイル形式と更新履歴の管理

スキルシートは内容だけでなく、相手が開ける状態で渡す必要があります。提出先からテンプレートを指定された場合は、その書式を使います。指定がない場合は、編集用の原本と提出用のPDFを分けて管理すると安全です。

ファイル名には氏名または管理用の識別子と更新年月を入れます。

skill-sheet_engineer_202608.pdf

「最新版.xlsx」「最新版2.xlsx」のような名前は、どれを送ったか分からなくなります。応募先ごとに内容を調整した場合は、送付日と版を記録しておきます。

また、次のタイミングで更新すると情報が古くなりにくくなります。

• 案件が終了した直後
• 新しい工程や役割を担当したとき
• 資格を取得したとき
• 希望する稼働条件が変わったとき
• 次の案件を探し始める前

案件の終了直後なら、担当内容、成果、使用技術を正確に思い出せます。契約終了の直前になって数年分をまとめて書くより、原本を定期更新するほうが負担は小さくなります。

書いてはいけない情報

スキルを具体的に見せることと、顧客の情報を開示することは別です。次の情報は、公開してよいと確認できない限り書きません。

• 顧客名、担当者名、非公開のプロジェクト名
• IPアドレス、ホスト名、内部URL
• アカウント名、認証方式の詳細、鍵やパスワード
• 非公開の構成図、障害情報、脆弱性情報
• 契約上開示できない売上、予算、利用者数
• 社内文書をそのまま転記した作業手順

会社の端末や社内システムから資料を持ち出して作るのではなく、自分の担当内容を公開可能な粒度で書き直します。迷う場合は秘密保持契約と就業規則を確認し、所属先や発注元へ確認してください。

エージェントへ出す前のチェックリスト

提出前に、次の項目を確認します。

• [ ] 案件の期間が年月順に並んでいる
• [ ] すべての案件で自分の役割が分かる
• [ ] 技術名と利用場面が結びついている
• [ ] プロジェクト全体ではなく自分の担当工程を書いている
• [ ] 成果の数値には説明できる根拠がある
• [ ] 学習経験と実務経験を分けている
• [ ] 顧客名や内部情報を匿名化している
• [ ] 希望条件と稼働可能時期が現在の状況に合っている
• [ ] 誤字、年月の重複、技術名の表記揺れがない

スキルシートは一度完成させて終わりではありません。案件が終わった直後に担当内容と成果を追記しておくと、数年後に記憶だけで書き直す事態を避けられます。

実際の案件に合わせて見直す

自分だけでスキルシートを作ると、「何を書けるか」から考えがちです。案件紹介につなげるには、公開されている案件やエージェントから示された要件と見比べて、足りない情報を補う方法が現実的です。

Midworksは、フリーランスエンジニア向けの案件・求人サービスです。この記事でスキルシートを整えた人にとっては、現時点の経歴で紹介対象になり得る案件と、書類で追加説明したほうがよい経験を確認する次の行動につながります。案件や利用条件は変わるため、最新の内容は公式サイトで確認してください。

相談する前に、希望条件だけでなく「譲れる条件」も決めておくと話が進みやすくなります。エージェントを選ぶ観点はフリーランスエージェントの選び方、独立前の手続きはフリーランスエンジニアとして独立する前の準備で整理しています。

よくある質問

スキルシートは何ページにまとめるべきですか

ページ数だけで合否は決まりません。案件数が少ない人は無理に増やさず、案件数が多い人は古い案件を短くして、応募先に近い経験を詳しくします。読み手が募集要件との一致を探せる密度を優先してください。

ExcelとWordのどちらで作ればよいですか

提出先から形式を指定された場合は、その形式に従います。指定がなければ、表形式を保ちやすいExcelか、レイアウトが崩れにくいPDFが扱いやすい選択肢です。編集用の原本と提出用PDFを分けておくと更新しやすくなります。

実績を数値で書けない場合はどうすればよいですか

対象範囲、変更前の課題、自分が行った対応、変更後に確認できた状態の順で書きます。「手順を標準化し、担当者ごとの差を減らした」のように、数値がなくても変化が分かる表現にできます。

実務経験が浅くても提出できますか

提出できます。経験を大きく見せるのではなく、研修、自己学習、個人開発、実務を分けて書きます。実務で担当した範囲が狭い場合も、レビューを受けながら担当したのか、単独で完了したのかを事実どおりに書くと判断材料になります。

まとめ

フリーランスエンジニアのスキルシートは、技術名の一覧ではなく、募集案件と経験を照合するための資料です。

1. 案件概要
2. 参画期間
3. チーム体制と役割
4. 担当工程と作業内容
5. 技術環境
6. 成果と改善
7. 希望条件と稼働可能時期

この7項目を案件ごとにそろえ、応募先に近い経験を詳しくします。誇張せず、守秘義務を守りながら、担当した範囲と変化を具体的に書ければ、案件紹介の判断に必要な情報が伝わります。