フリーランスエンジニアのスキルシート 副業版の書き方

副業エージェントに登録しようとして、「スキルシートを提出してください」と言われたところで手が止まっていませんか。開発スキルには自信があっても、いざ書き始めると「本業の実績はNDAで具体的に書けない」「副業の実績がまだ1〜2件しかない」「本業の会社にバレずに稼働できる時間も伝えなければならない」と、次々に壁が出てきます。

世の中のスキルシートの書き方の記事は、ほとんどが「フリーランスとして独立する人」を前提に書かれています。独立する人なら、過去の本業も含めた経歴を堂々と書けますし、フルタイムで稼働できることも前提です。けれども副業を続けたいだけのあなたにとっては、その前提がそのまま当てはまらず、かえって書き方に迷ってしまいます。

副業継続者のスキルシートには、独立向けにはない固有の制約が3つあります。1つ目は、本業の実績をNDA（秘密保持契約）の都合で詳しく書けないこと。2つ目は、副業の実績がまだ少ないこと。3つ目は、本業バレを避けながら稼働できる時間や条件を伝える必要があること。この3つを同時にクリアしないと、せっかくスキルがあっても選考でうまく評価されません。

この記事では、副業を続ける会社員エンジニアが、副業エージェントに安心して提出できるスキルシートを1枚仕上げるための具体的な書き方を解説します。NDAで書けない本業実績を抽象化する手順、少ない副業実績を厚く見せる方法、本業を守る稼働条件の伝え方、そして複数エージェントへの提出管理まで、記入例つきで整理しました。読み終えるころには、どの副業エージェントにも出せるマスター版のスキルシートを作る道筋が見えているはずです。

副業のスキルシートが「独立向け」と違う3つの理由

スキルシートの書き方を調べると多くの情報が見つかりますが、その大半はフリーランスとして独立する人を想定しています。副業を続けたいあなたが同じ書き方を使うと、どこかでつまずきます。まずは、副業のスキルシートが独立向けと何が違うのかを整理しておきましょう。

スキルシートとは何か／副業エージェントが何を見るか

スキルシートとは、エンジニアの技術スキル・経験・実績を1〜2枚程度にまとめた、案件選考用の書類です。職務経歴書が「どの会社でどんな役割を担ってきたか」という経歴の証明に重きを置くのに対し、スキルシートは「この人にこの案件を任せられるか」を判断するための実務情報に特化しています。

副業エージェントの担当者やクライアント企業がスキルシートで見ているのは、おおむね次のポイントです。

• 使用できる言語・フレームワーク・ツールと、その習熟度
• 担当できる工程（要件定義・設計・実装・テスト・運用など）
• これまで関わった案件の規模感・チーム構成・役割
• 稼働できる時間帯と稼働量
• どんな関与形態（スポット支援・継続参画など）に対応できるか

つまり企業側は、スキルシート1枚から「自社の案件にどう貢献してくれそうか」を読み取ろうとしています。記載が具体的であるほど、案件とのマッチングがスムーズになります。

独立向けの書き方をそのまま使うとつまずく3場面

独立を前提とした書き方をそのまま流用すると、副業継続者は次の3つの場面でつまずきます。これは多くの人が経験する「あるある」です。

場面1：本業の実績を書こうとして、NDAで手が止まる。 独立する人なら退職した過去の会社の実績も書けますが、現職のあなたは秘密保持契約の都合で、プロダクト名や社名、固有の数値を書けないことがほとんどです。「一番アピールしたい実績が、一番書けない」というジレンマに直面します。

場面2：副業実績の欄がスカスカになる。 独立者は本業のフルタイム実績で経歴を埋められますが、副業を始めたばかりだと案件は1〜3件程度。実績欄が寂しく見えてしまい、「これでは選考に通らないのでは」と不安になります。

場面3：稼働条件をどう書けばいいか分からない。 独立者はフルタイム稼働が前提なので稼働条件の悩みは小さいですが、副業継続者は「平日夜と土日だけ」「本業に支障が出ない範囲で」といった条件を、本業バレを避けつつ正確に伝えなければなりません。この欄を曖昧にすると、ミスマッチの原因になります。

この3つの制約は、副業継続者であれば誰もがぶつかるものです。裏を返せば、この3つさえ正しく処理できれば、副業仕様のスキルシートは完成します。次の章から、ひとつずつ具体的な対処法を見ていきましょう。

NDAで書けない本業実績を「抽象化」して記載する方法

副業エンジニアのスキルシートで最も悩ましいのが、本業の実績の扱いです。本業で培った技術こそ最大の武器なのに、NDAのせいで具体的に書けない——。この壁は、情報を「抽象化」することで乗り越えられます。社名やプロダクト名といった特定につながる情報は伏せたまま、技術スタック・役割・規模感・成果の方向性だけを取り出して記載する方法です。

書ける情報・書けない情報の切り分け

抽象化の第一歩は、何が書けて何が書けないのかを切り分けることです。一般的に、NDAに抵触しやすいのは次のような情報です。

書けない（NDA抵触の可能性が高い）情報の例

• 企業名・サービス名・プロダクト名などの固有名詞
• 公開されていない売上・ユーザー数・取引額などの具体的な数値
• 未公開の事業計画・新機能・社内体制に関する情報
• クライアント企業の社名（受託開発の場合）

書ける（一般化すれば問題になりにくい）情報の例

• 使用した言語・フレームワーク・クラウド・ツール
• 担当した役割・工程（設計・実装・レビューなど）
• チームの人数や開発体制の規模感
• 「パフォーマンスを改善した」「処理時間を短縮した」といった成果の方向性

判断に迷うときの基本ルールは、「その記述から特定の企業やプロダクトが推測できてしまうか」を基準にすることです。推測できてしまうなら伏せる、できないなら書く——この線引きを意識すると、抽象化の精度が上がります。なお、NDAの文面は契約ごとに異なるため、不安な場合は契約書の秘密情報の定義を確認しておくと安心です。

抽象化の記入例（Before→After）

実際にどう書き換えるのか、Before（NG例）とAfter（OK例）で見てみましょう。

例1：決済機能の実装

• Before（NG）：「〇〇株式会社のECサイト『△△』の決済機能を実装。月間流通額10億円のサービス」
• After（OK）：「Web系事業会社の決済機能の設計・実装を担当（Go / Stripe、チーム4名）。決済処理の信頼性向上に貢献」

例2：基盤刷新プロジェクト

• Before（NG）：「□□社の社内基幹システムをAWSへ移行。〇〇業界向けの受発注管理システム」
• After（OK）：「既存システムのクラウド移行を担当（AWS / ECS / Terraform）。インフラ構成の見直しにより運用負荷を軽減」

例3：実績の成果

• Before（NG）：「リリース後3か月でユーザー数が5万人増加した新機能を開発」
• After（OK）：「新機能の開発をフロントからバックエンドまで担当（TypeScript / React / Node.js）。ユーザー数の増加に寄与」

ポイントは、固有名詞と未公開の具体的な数値を落としつつ、「技術スタック・役割・体制・成果の方向性」という、企業がスキルを判断するうえで本当に必要な情報は残すことです。数値を出せない場合でも、「処理時間を短縮」「運用負荷を軽減」のように成果の方向性を示せば、貢献の中身は十分に伝わります。

本業バレを避ける追加の伏せ方

抽象化はNDA対策であると同時に、本業バレを防ぐ手段でもあります。ただし、業種や会社規模の書き方によっては、それだけで勤務先が特定されてしまうことがあるので注意が必要です。

たとえば、ニッチな業界で国内に数社しかないような領域だと、「〇〇業界の事業会社」と書くだけで勤務先が推測されかねません。このような場合は、業種をさらに広いカテゴリに言い換える（例：「BtoB SaaS事業会社」を「Web系事業会社」とする）か、業種そのものに触れない判断も検討しましょう。

伏せるかどうかの判断基準は、「自分の周囲の人がこのスキルシートを見たとき、勤務先が分かってしまうか」です。同僚・取引先・業界内の知人が見ても特定できないレベルまで抽象化できていれば、本業バレのリスクは大きく下げられます。スキルシートを提出する前に、第三者の目線で読み返してみることをおすすめします。

副業実績が1〜3件でも通るスキルシートの組み立て方

副業を始めたばかりだと、書ける副業案件は1〜3件程度かもしれません。それでも、書き方次第で十分に説得力のあるスキルシートは作れます。大切なのは「件数」ではなく「1件あたりの情報の濃さ」です。

1件を「参画期間・担当・技術・成果」で厚く書く

案件数が少ないときほど、1件1件を丁寧に掘り下げて書きましょう。1つの案件を次の5要素で分解すると、情報の密度が上がります。

1. 参画期間：いつからいつまで、どれくらいの期間関わったか（例：2024年4月〜継続中）
2. 役割・関与形態：どんな立場で参画したか（例：バックエンド開発の継続支援メンバー）
3. 担当フェーズ・範囲：どの工程を担当したか（例：API設計・実装・コードレビュー）
4. 使用技術：使った言語・フレームワーク・インフラ（例：Ruby on Rails / PostgreSQL / AWS）
5. 成果・貢献：何を改善・実現したか（例：既存APIのレスポンス改善に貢献）

記入例で見ると、次のようになります。

副業案件A（2024年4月〜継続中）

• 関与形態：スタートアップのバックエンド開発を継続支援（週末中心）
• 担当範囲：新規APIの設計・実装、既存コードのリファクタリング、コードレビュー
• 使用技術：Ruby on Rails / PostgreSQL / Docker / AWS
• 成果：機能追加のリードタイム短縮に貢献。テストコードの整備でデプロイの安定性を向上

このように1件を厚く書けば、案件数が少なくても「何ができる人か」がはっきり伝わります。逆に、件数を増やそうとして1件あたりの記述が薄くなると、かえって評価しづらいスキルシートになってしまいます。

本業スキルを副業向けに翻訳する

副業実績が少なくても、あなたには本業で日々磨いているスキルがあります。これを副業向けに「翻訳」して載せることで、スキルシートの説得力は大きく増します。

前の章で解説した抽象化の手法を使えば、本業の実績もNDAに抵触しない形でスキルシートに反映できます。ここで意識したいのは、本業で扱っている技術や工程のうち、副業案件でも活かせるものを前面に出すことです。たとえば本業で大規模トラフィックを扱っているなら「高負荷環境での設計・運用経験」、レビュー文化の強いチームにいるなら「コードレビュー・品質改善の経験」といった形で、副業先が求めそうな強みに翻訳します。

スキルシートの「使用技術」や「得意分野」の欄は、副業実績だけでなく本業で培ったスキルも含めて書いて構いません。実務で使えるスキルであれば、それが本業由来か副業由来かは問われません。

個人開発・OSS・学習プロジェクトの実績化の可否

副業の案件実績が乏しい場合、個人開発やOSSへの貢献、学習プロジェクトを実績として載せてよいか迷うところです。結論から言うと、書き方を工夫すれば実績として有効に使えます。

• 個人開発・公開サービス：実際に動いているプロダクトやリポジトリがあれば、技術スタックと工夫した点を添えて記載できます。URLを出せるものは、技術力の裏付けになります。
• OSSへの貢献：プルリクエストやコミットの実績は、コードの品質や協働姿勢を示す材料になります。貢献したプロジェクト名と内容を簡潔に書きましょう。
• 学習プロジェクト：チュートリアルをなぞっただけのものは実績になりにくいですが、自分でテーマを設定して設計から実装まで行ったものなら、案件実績の補完として記載する価値があります。

ただし、これらはあくまで案件実績を補うものとして位置づけ、「実務経験」と「個人開発・学習」は欄を分けて書くのが誠実です。混同して書くと、かえって信頼を損ねる場合があります。実務でできることと、学習段階のことを正直に区別して示しましょう。

本業を守る「稼働条件」のスキルシートへの書き方

副業継続者にとって、稼働条件の書き方は本業を守るための生命線です。ここを曖昧にすると、本業に支障が出る案件を受けてしまったり、対応できない時間帯の連絡を期待されたりと、ミスマッチの原因になります。一般的なスキルシート記事ではあまり触れられない論点ですが、副業を長く続けるうえでは最も重要なポイントのひとつです。

稼働可能時間・対応時間帯のテンプレート文例

稼働条件は、相手が「いつ、どれくらい関われる人か」を一目で把握できるように、具体的な数字で示すのが基本です。次のようなテンプレート文例を参考に、自分の状況に合わせて調整してみてください。

テンプレート文例1：平日夜＋土日型

稼働可能時間：平日19:00〜22:00、土日の日中 月間稼働目安：40〜60時間 ※本業があるため、平日日中の対応は原則できません。緊急時はチャットで翌朝までに返信します。

テンプレート文例2：土日中心型

稼働可能時間：土日・祝日の日中を中心に対応 月間稼働目安：30〜40時間 ※平日は夜間に短時間のチャット対応が可能です。

テンプレート文例3：柔軟調整型

稼働可能時間：週10〜15時間程度（曜日・時間帯は相談のうえ調整可能） ※定例ミーティングは平日夜または土日であれば参加可能です。

ポイントは、稼働できる時間帯と月間の稼働量の目安をセットで示すことです。さらに「平日日中は対応できない」という制約を正直に書いておくと、相手も期待値を調整しやすく、結果としてミスマッチが減ります。制約を隠すよりも、明示したほうが信頼につながります。

対応できる関与形態・フェーズの示し方

稼働時間が限られる副業では、「どんな関わり方ができるか」を明示しておくと、相手が案件を任せやすくなります。関与形態とフェーズの両面から示しましょう。

関与形態の例

• スポットでの技術相談・コードレビュー
• 特定機能の設計・実装を切り出して担当
• 継続的なバックエンド開発メンバーとしての参画
• 設計レビューやアーキテクチャ相談のアドバイザー

対応できるフェーズの例

• 要件定義・技術選定への参加
• 設計・実装
• テスト・コードレビュー
• リリース後の改修・運用サポート

副業で稼働時間が限られる場合は、「フルタイムでの常駐は難しいが、設計・実装を切り出した形なら対応できる」といったように、自分の稼働スタイルに合う関与形態を明示しておくと、相手もアサインを判断しやすくなります。できることとできないことを正直に書くほうが、結果として相性のよい案件に出会いやすくなります。

本業バレを避ける実務上の注意

稼働条件とあわせて、副業を続けるうえで知っておきたい実務上の注意点にも軽く触れておきます。スキルシートそのものの書き方からは少し離れますが、本業を守りながら副業を続けるための前提知識として押さえておきましょう。

副業が本業の会社に知られるきっかけとして、住民税の通知がよく挙げられます。副業の所得が業務委託（雑所得・事業所得）にあたる場合は、確定申告の際に住民税の徴収方法を「自分で納付（普通徴収）」に選択することで、副業分の住民税が本業の給与天引きに合算されるのを避けられます（マネーフォワード クラウド確定申告）。

また、副業の所得が年間20万円を超える場合は確定申告が必要です。20万円以下であっても住民税の申告は別途必要になる点に注意してください（freee 副業所得20万円以下でも確定申告と住民税の申告は必要？）。なお、税務の取り扱いは個々の状況によって異なるため、判断に迷う場合は税理士や所轄の税務署に確認することをおすすめします。

そもそも会社の就業規則で副業が認められているかも、事前に確認しておきましょう。これらの実務面を整えておくことが、安心して副業を続ける土台になります。

複数の副業エージェントへ提出するときの管理術

副業案件を安定して獲得するために、複数の副業エージェントに登録する人は少なくありません。ただし、エージェントごとに別々のスキルシートを毎回ゼロから作っていると、管理が煩雑になり、内容にも食い違いが生まれます。ここでは効率的な運用方法を紹介します。

マスター1枚＋出し分けの運用ルール

おすすめは、すべての情報を盛り込んだ「マスター版」のスキルシートを1枚作り、それを元に各エージェント向けに微調整する運用です。

1. マスター版を作る：これまで解説してきた内容（抽象化した本業実績・副業実績・稼働条件）をすべて反映した、フルバージョンのスキルシートを1枚用意します。これが運用の起点になります。
2. エージェントごとに出し分ける：エージェントによっては指定フォーマットがあったり、求められる案件の傾向が異なったりします。マスター版から必要な部分を抜き出し、案件の傾向に合わせて強みの見せ方を微調整します。
3. 変更は必ずマスター版に反映する：スキルや実績が増えたときは、まずマスター版を更新し、それから各エージェント向けの版に展開します。マスター版を「正」とすることで、内容の食い違いを防げます。

この運用なら、毎回ゼロから作る手間がなくなり、どのエージェントにも一貫した内容を提出できます。

提出履歴・案件状況の記録テンプレート

複数のエージェントとやりとりしていると、「どのエージェントに、どの版を、いつ出したか」「今どの案件が進行中か」が分からなくなりがちです。簡単な記録表を1つ作っておくと、状況をひと目で把握できます。

スプレッドシートなどで、次のような項目を管理するのがおすすめです。

この記録があれば、提出済みの版やそれぞれの選考状況を取り違えることがなくなり、フォローのタイミングも逃しません。複数エージェントを併用するときほど、こうした記録が安定した案件獲得の支えになります。

副業エンジニアのスキルシートに関するよくある質問

副業を続ける会社員エンジニアが、スキルシートを書くときに詰まりやすい疑問をまとめました。

Q1. 本業の会社名を書かずに実績をアピールできますか？

できます。社名やプロダクト名といった固有名詞は伏せたまま、「技術スタック・担当した役割・体制の規模感・成果の方向性」を記載すれば、スキルは十分に伝わります。「NDAで書けない本業実績を『抽象化』して記載する方法」で解説したBefore→Afterの記入例を参考に、特定につながる情報だけを落として書き換えてみてください。企業側が本当に知りたいのは社名ではなく「何ができる人か」なので、抽象化してもアピール力は損なわれません。

Q2. 副業実績が1件でもスキルシートを提出していいですか？

提出して問題ありません。件数の少なさは、1件を「参画期間・役割・担当範囲・使用技術・成果」の5要素で厚く書くことで補えます。さらに、本業で培ったスキルを抽象化して反映したり、個人開発やOSSへの貢献を実績欄とは分けて記載したりすれば、説得力のあるスキルシートになります。大切なのは件数ではなく、1件あたりの情報の濃さです。

Q3. 稼働時間が少ないと不利になりますか？

必ずしも不利にはなりません。副業エージェントの案件には、稼働時間が限られる人を前提としたスポット支援や継続的な部分参画も多くあります。むしろ稼働条件を曖昧にするほうがミスマッチを招きます。「平日夜＋土日で月40〜60時間」のように稼働できる時間帯と量を具体的に示し、対応できる関与形態もあわせて書いておくと、相性のよい案件に出会いやすくなります。

Q4. 複数のエージェントに同じスキルシートを使い回してもよいですか？

基本の内容を使い回すのは問題ありませんが、すべての情報を盛り込んだマスター版を1枚作り、エージェントごとに強みの見せ方を微調整する運用がおすすめです。エージェントによって指定フォーマットや得意な案件領域が異なるため、案件の傾向に合わせて出し分けると選考の通過率が上がります。スキルや実績が増えたときは、まずマスター版を更新してから各版に反映すると、内容の食い違いを防げます。

Q5. 職務経歴書やポートフォリオも用意した方がいいですか？

案件や提出先によっては、スキルシートに加えて職務経歴書やポートフォリオの提出を求められることがあります。スキルシートが「何ができるか」を端的に示す書類なのに対し、職務経歴書は経歴の流れを、ポートフォリオは成果物そのものを示す役割を持ちます。書類を一通り整えておくと、より幅広い案件に対応できます。それぞれの書き方はフリーランスエンジニアの職務経歴書・ポートフォリオの書き方で詳しく解説しているので、あわせてご覧ください。

まとめ｜副業仕様のスキルシートで継続的に案件を得る

副業を続ける会社員エンジニアのスキルシートには、独立向けにはない3つの固有の課題があります。この記事で解説した対処法を、最後に振り返っておきましょう。

• NDAで書けない本業実績：社名・プロダクト名・未公開の数値といった固有情報は伏せ、「技術スタック・役割・体制の規模感・成果の方向性」に抽象化して記載します。第三者が読んでも勤務先が特定できないレベルまで伏せれば、本業バレも防げます。
• 少ない副業実績：1件を「参画期間・役割・担当範囲・使用技術・成果」の5要素で厚く書き、本業スキルの翻訳や個人開発・OSSの実績で補強します。件数より1件あたりの濃さを重視しましょう。
• 本業を守る稼働条件：稼働できる時間帯と月間の稼働量を具体的に示し、対応できる関与形態もあわせて明示します。制約を正直に書くほうが、相性のよい案件に出会えます。

これら3つを反映したマスター版のスキルシートを1枚作り、複数のエージェントへ出し分けながら、提出履歴を記録表で管理する——この流れを作れば、本業を守りながら継続的に副業案件を獲得できる土台が整います。

次のアクションとしては、まずマスター版のスキルシートを1枚仕上げることから始めてみてください。スキルシートと並行して職務経歴書やポートフォリオも整えておくと、対応できる案件の幅がさらに広がります。書類一式の準備についてはフリーランスエンジニアの職務経歴書・ポートフォリオの書き方を参考にしてみてください。