フリーランスエンジニアの職務経歴書｜ポートフォリオとセットで案件獲得につなげる

「エージェントにスキルシートを送っても、面談に進む割合が伸びない」「ポートフォリオはGitHubのリンクを貼っただけで、面談で『もう少し具体的に見たい』と言われた」――フリーランスエンジニアとして独立した直後、または副業から本格的にフリーランスへ移行しようとしている段階で、こうした書類選考の壁にぶつかる方は少なくありません。

その原因の多くは、職務経歴書（スキルシート）とポートフォリオを「別々の書類」として整備していることにあります。職務経歴書は「経験は伝わるが、何ができるかピンとこない」と読まれ、ポートフォリオは「コードはあるが、業務でどう活かしたか分からない」と読まれてしまう。それぞれ単体では十分な評価を得られず、結果として「経験はそれなり、でも決め手に欠ける」候補者として扱われてしまいます。

この問題を解決する鍵は、職務経歴書とポートフォリオを「同じ実績を別角度で補強するセット」として運用することです。職務経歴書で「どのプロジェクトで何を成果として残したか」を言語化し、ポートフォリオでその「動く証拠」を見せる。発注側はこの2つを行き来しながら「この人に頼んで大丈夫か」を判断します。

本記事では、フリーランスエンジニアが案件獲得につながる「職務経歴書＋ポートフォリオ」をセットで整備する方法を、発注側の評価軸から逆算して解説します。具体的には、プロジェクト経歴を構造化するPARモデル、スキルシートのテンプレ流用で評価を落とさないコツ、NDA下でも書ける4要素抽象化テンプレ、副業エンジニアからフリーランス独立への書類切り替え、そして案件単価を継続的に伸ばすための運用サイクルまで扱います。

書類を一度書いて満足するのではなく、「育てて使い続ける資産」として整備しなおすイメージで読み進めてください。

職務経歴書とポートフォリオは「セット」で評価される

最初に、検索意図の本丸である「両方必要なのか」「どう違うのか」を整理します。職務経歴書とポートフォリオは役割が違うため、片方だけでは案件獲得が伸びにくい構造になっています。

職務経歴書とポートフォリオの役割の違い

ざっくり言えば、職務経歴書は「あなたの仕事の説明書」、ポートフォリオは「その仕事を裏付ける証拠資料」です。

• 職務経歴書: 関わったプロジェクトの背景・課題・自分の役割・成果を文章で説明する書類。発注側は「業務でどんな問題をどう解いてきた人か」をここで把握します
• ポートフォリオ: 実際に作ったプロダクト・書いたコード・スクリーンショット・公開URLなど、成果物そのものを見せる資料。発注側は「説明書に書かれていることが本当に実装できるか」をここで検証します

職務経歴書が「営業資料」だとすれば、ポートフォリオは「サンプル動画」のような関係です。営業資料だけでは「本当にできるの？」と疑問が残り、サンプル動画だけでは「これを業務でどう使ったの？」が伝わりません。両方が揃って初めて、発注側は「業務遂行能力 × 実装力」の両面で安心感を得られます。

発注側が「両方」を要求する理由

発注側（クライアント・エージェント）が職務経歴書とポートフォリオの両方を見る理由は、書類選考と面談で評価軸が違うからです。

書類選考の段階では職務経歴書のテキスト情報が中心ですが、面談以降は「本当に書いてあるとおりに動けるか」の検証フェーズに入ります。このときポートフォリオが薄いと、せっかく書類選考を通過しても「実装力が見えない」という理由で見送られる可能性が高くなります。逆に、ポートフォリオは充実していても職務経歴書が雑だと、書類選考で弾かれて面談まで進めません。

つまり「片方だけでも何とかなる」のではなく、「両方の評価軸を別々に突破する必要がある」と捉えるのが正確です。

スキルシートとの関係

ここで混乱しやすいのが「スキルシート」と「職務経歴書」の違いです。結論から言えば、スキルシートは職務経歴書を「案件マッチング用に再編集した書類」と捉えるのが実態に近いです。

• 職務経歴書: 主に正社員転職や直案件の応募で使う、自分のキャリア全体を語る書類
• スキルシート: エージェント経由のフリーランス案件で標準的に使われる、案件マッチングに特化したフォーマット

エージェント各社（レバテックフリーランス や プロエンジニア など）にはそれぞれ独自のスキルシートテンプレートがありますが、いずれも「プロジェクト経歴・スキル要約・自己PR」という骨格は職務経歴書と共通しています。素材は同じで、見せ方を案件マッチングに最適化したものがスキルシートだと理解しておけば十分です。本記事では、職務経歴書とスキルシートはまとめて「経歴書類」として扱い、それぞれの違いに触れる場面では明示的に区別します。

案件獲得につながる職務経歴書の書き方

ここからは、メインの「職務経歴書（スキルシート）」をどう書くかに踏み込みます。多くの方が「書く項目」までは分かっているのですが、案件獲得につながるかどうかは「プロジェクト経歴の書き方」でほぼ決まります。

職務経歴書の必須項目

フリーランスエンジニア向けの職務経歴書は、最低限以下の4要素で構成します。

最初に職務要約とスキル要約で「全体像」を見せ、プロジェクト経歴で「個別の実績」を見せ、自己PRで「これからの方向性」を伝える、という流れです。発注側は1ページ目で読むのをやめるかどうかを判断するので、職務要約とスキル要約の密度が薄いと「以降を読む価値がない」と判定されます。

職務経歴書全体のページ数は3〜5枚に収めるのが目安です。10枚を超えると読み手の集中力が続かず、肝心のプロジェクト経歴に目を通してもらえないリスクが上がります。

プロジェクト経歴の書き方（PARモデル）

職務経歴書の評価を分ける最大のポイントが、プロジェクト経歴の書き方です。多くの方が「プロジェクト名・期間・使用技術・担当業務」だけを羅列していますが、これだと発注側に「何をやってきたか」は伝わっても「何ができる人か」が伝わりません。

ここで効果を発揮するのが、コンサル・面接対策の世界で使われる PARモデル（Problem → Action → Result） です。

• Problem（課題）: そのプロジェクトで自分が直面した課題は何だったか
• Action（行動）: 課題に対して自分が取った行動・採用した技術選定・実装方針
• Result（成果）: 行動の結果、どんな成果が出たか（できれば数値で）

PARの考え方は採用面接やコンサル業界で広く使われている枠組みで、フリーランスエンジニア向けには TechSpace の解説記事 などで紹介されています。プロジェクト経歴の各案件をこの3つに沿って書くことで、「経験」を「再現可能なスキル」として伝えられるようになります。

PARモデルを適用した記述例を示します。

■ プロジェクト: ECサイトのバックエンドリプレイス（2024年4月〜2024年12月）
規模: 月間アクティブユーザー約30万人、開発チーム8名
使用技術: Ruby on Rails / PostgreSQL / AWS（ECS, RDS, ElastiCache）

【課題（Problem）】
レガシーPHPで構築された既存ECサイトが、ピーク時にレスポンスが10秒以上かかり、
カゴ落ち率が上昇していた。バックエンドのリプレイスが急務だった。

【行動（Action）】
Ruby on Rails への段階的リプレイス方針を立案。ストラングラーパターンで
旧PHPと新Railsを並行稼働させ、エンドポイント単位で順次切り替えを実施。
特にカート・決済周りのN+1クエリ解消とRedisキャッシュ層を担当した。

【成果（Result）】
カート画面の平均レスポンスタイムを9.2秒から1.8秒に短縮（約80%改善）。
カゴ落ち率は約25%低下し、月間売上が前年同月比で約15%向上した。

「使用技術: Rails / PostgreSQL」とだけ書かれた経歴書と、上記のように課題・行動・成果まで書かれた経歴書では、発注側が受け取る印象が大きく変わります。前者は「Railsを書いたことがある人」、後者は「パフォーマンス課題を技術選定と実装で解決した人」として記憶されます。

NG例とOK例の比較

PARモデル適用前後でどう変わるか、フリーランスエンジニアでありがちな書き方を比較します。

NG例（テンプレ流用そのまま）

■ 業務系Webシステム開発（2024年4月〜2024年12月）
担当: バックエンド開発
使用技術: Ruby on Rails, PostgreSQL, AWS
業務内容: 既存システムの改修、新機能の追加、コードレビュー

「やったこと」は分かりますが、「どんな問題をどう解いたか」が一切伝わりません。同じ書き方をしている候補者が100人いれば、発注側はスキル要約と単価だけで足切りを始めます。

OK例（PARモデル適用）

■ 業務系Webシステム リプレイス案件（2024年4月〜2024年12月）
規模: 利用者約1万人、開発チーム5名
担当: バックエンドリード（実装＋技術選定＋若手レビュー）
使用技術: Ruby on Rails 7 / PostgreSQL 14 / AWS（ECS Fargate, RDS）

課題: バッチ処理が深夜帯に7時間かかり、翌朝の業務開始に間に合わないリスクがあった。
行動: バッチ処理を関数分解し、Sidekiqで並列化。ボトルネックだったDBクエリを
      インデックス再設計とバルクUPDATEで最適化した。
成果: バッチ完了時間を7時間から1.5時間に短縮（約78%削減）。
      翌朝業務に間に合わないインシデントが半年で0件になった。

書く時間は2倍程度かかりますが、書類選考通過率と面談での印象は数倍変わります。「すべての案件をPARで書くのが大変」という場合は、直近2〜3年の主要案件だけPARモデルにし、それ以前は簡略表記でも構いません。

職種別アピールポイント

プロジェクト経歴の「成果」として何を強調するかは、得意領域によって変えると刺さりやすくなります。

自分の得意領域でどの数値を取りやすいか考えながらプロジェクト経歴を書くと、自然と「強み」が浮き上がる職務経歴書になります。

スキルシートの書き方とテンプレートの使い方

エージェント経由でフリーランス案件にエントリーする場合、職務経歴書ではなく「スキルシート」というフォーマットで提出を求められることが一般的です。

スキルシートと職務経歴書の関係

すでに触れたとおり、スキルシートは「職務経歴書を案件マッチング用に再編集した書類」と捉えるのが実態に近いです。情報の素材（プロジェクト経歴・スキル一覧・自己PR）は同じで、見せ方を以下のように最適化したものがスキルシートです。

• 案件の必須スキル・歓迎スキルとマッチングしやすいよう、技術スタックを最上部に配置
• プロジェクトごとの「課題・成果」よりも「使用技術・役割・期間」の一覧性を優先
• 直近の経験ほど詳しく、古いものは簡略化

職務経歴書とスキルシートを別々にゼロから書く必要はありません。職務経歴書を「マスター原稿」として整備しておけば、スキルシートはそこから抜粋・再配置するだけで作れます。

スキルシートの標準フォーマット

エージェント各社で書式は微妙に違いますが、おおむね共通する標準フォーマットは以下です。

1. 基本情報: 氏名・年齢・最寄り駅・稼働可能日数・希望単価レンジ
2. スキル要約（テクニカルスキル）: 言語・フレームワーク・DB・クラウド・ツール・OS。経験年数と習熟度を併記
3. 業務経歴（プロジェクトごと）: プロジェクト名・期間・規模・役割・使用技術・担当業務・成果
4. 資格・自己PR: 関連資格、強み・志向性

エージェント独自のExcel/PDFテンプレートが配布される場合は、それに従って記入しますが、「マスター原稿」さえ整っていれば1案件分のスキルシート作成は1〜2時間で完了します。

経験年数と習熟度の書き分け

スキル要約の「経験年数」と「習熟度」の書き分けは、書類選考の精度に直結する地味だが重要なポイントです。

特に気をつけたいのが、「学習中」のスキルを「使える」と書いてしまうケースです。書類選考は通過しやすくなりますが、面談で深掘りされたときに答えられず、結果として「経歴を盛る人」という印象が残ってしまいます。長期的な信頼関係を考えるなら、習熟度は実態どおりに書く方が得策です。

テンプレ流用で評価が下がる落とし穴

スキルシートのテンプレートはエージェント各社が無料で配布しており、コピペで埋めれば見た目は整います。しかし、テンプレ流用には以下の落とし穴があります。

• 個性が消える: 全員が同じフォーマットで書くため、「使用技術・期間・役割」の組み合わせが似ている候補者の中で埋もれてしまう
• 強みが見えなくなる: テンプレの自由記述欄は狭く、PARモデルで書き込もうとすると枠に収まらない
• 更新が雑になる: テンプレに沿って一度書くと「完成」した気になり、案件終了後の追記が抜けがちになる

対策としては、テンプレの構造は維持しつつ、「業務経歴」セクションの主要案件だけはPARモデルで詳述する、自己PRには「数値で語れる強み」を1つ必ず入れる、といった「テンプレ＋差し色」の運用が有効です。テンプレ提出が必須のエージェントでも、自由記述欄や備考欄を活用して差別化の余地を作れます。

ポートフォリオで「動く証拠」を見せる

職務経歴書のプロジェクト経歴がどれだけ充実していても、「文章でそう書いているだけかもしれない」という疑念を発注側は完全には拭えません。その疑念を解消する役割を担うのが、ポートフォリオです。

本記事ではポートフォリオを「職務経歴書との連動」の観点に絞って解説します。ポートフォリオ単体の作り方・必須項目・サイト構築方法については、別記事のフリーランスエンジニアのポートフォリオ作り方で詳しく解説していますので、ポートフォリオを一から作りたい方はそちらも併せてご覧ください。

ポートフォリオの最低限の構成要素

「セット運用」の観点から見たとき、ポートフォリオに最低限あるべき要素は以下です。

1. プロフィール: 氏名（または屋号）・得意領域・連絡先
2. 実績一覧: 公開できる案件・個人開発・OSS活動。職務経歴書のプロジェクト経歴と紐づけられる粒度で
3. スキル一覧: 職務経歴書のスキル要約と整合する内容
4. GitHub・コード: 自分が書いたコードの公開リポジトリへのリンク
5. 連絡フォーム・案件依頼導線: 直案件を受ける場合は必須

ポートフォリオを最小構成で立ち上げる手順はフリーランス・複業エンジニアのポートフォリオ作り方｜最小限で受注する基準で解説しています。最初から完璧を目指さず、職務経歴書と連動する「実績一覧」だけでも整えると効果が出やすいです。

職務経歴書と実績を連動させる方法

ここが本記事で最も伝えたいポイントです。職務経歴書とポートフォリオを別々に作って終わりにすると、両者で同じ案件に言及していても情報がリンクせず、発注側が頭の中で結びつけてくれません。

連動させる具体的な方法は以下のとおりです。

• 案件番号またはタグでひも付ける: 職務経歴書の各プロジェクトに「Project A」「Project B」のような識別子を振り、ポートフォリオの実績一覧でも同じ識別子を使う
• 同じ要約文を使う: 職務経歴書のプロジェクト経歴の冒頭1行と、ポートフォリオの実績カードの説明文を同じ文言にすると、「同じ案件の話だ」と読み手が即座に認識できる
• PARの「成果」を共通指標で揃える: 職務経歴書では「カゴ落ち率25%低下」、ポートフォリオでは「コンバージョン改善のグラフ画像」のように、同じ事実を異なる形式で提示する

特に「同じ要約文を使う」は、地味ですが効果が大きい運用です。発注側は職務経歴書とポートフォリオを別々のタブで開いて行き来します。このとき同じフレーズが両方に出てくると、「説明書（職務経歴書）」と「サンプル（ポートフォリオ）」が同じ案件を指していることがひと目で分かります。

GitHubの見せ方

ポートフォリオの中でも、エンジニアの評価で最も重視されやすいのがGitHubアカウントです。職務経歴書に「GitHub: github.com/yourname」と1行入れるだけでは、見に行った発注側が何を見ればいいか分からず、せっかくのアピール機会を逃します。

GitHubを職務経歴書と連動させる工夫は以下です。

• READMEで自己紹介する: GitHubのプロフィールページに「経歴・得意領域・公開している主要リポジトリへのリンク」を整理する
• 公開リポジトリを絞り込む: 50個のリポジトリのうち見せたいのは3〜5個、という場合はピンで上位固定にする
• コミットログを見せる: 個人開発でも、コミットメッセージで「何を解決したか」が伝わるよう書いておく
• OSSコントリビューションを目立たせる: PRやIssueへの貢献はGitHubの「Contribution graph」で可視化される

GitHubは「コードの質」だけでなく、「コミットメッセージの書き方」「PRの粒度」「Issueでの議論姿勢」も見られます。日常的なコミットで雑なメッセージを残していると、業務でも同じ姿勢だと判断されかねません。

ポートフォリオサイトのツール選び

ポートフォリオサイトを作るツールは多数あります。Notion、Wantedly、Wix、自作（Next.js等）など選択肢が多く、迷うことが多いポイントです。

ツール選びの詳細な比較はフリーランスのポートフォリオサイト作成ツール5選比較｜状況別に1つ選べるで解説していますが、職務経歴書との連動という観点では、以下の点を重視してください。

• 更新が継続できるか: 案件終了ごとに追記するため、編集の手軽さが最も重要
• PDF・印刷に対応しているか: エージェントから「ポートフォリオもPDFで送ってください」と言われるケースがある
• コードを綺麗に見せられるか: シンタックスハイライトやコードブロックの表現

凝ったデザインのオリジナルサイトを作ることに時間をかけるより、職務経歴書のプロジェクト経歴とリンクした「実績ページ」を素早く整備する方が、案件獲得への寄与は大きくなります。

NDA下で本業の実績をどう書くか

フリーランスエンジニア、特に企業常駐型の案件経験がある方が必ずぶつかるのが、NDA（秘密保持契約）で本業の実績を細かく書けない問題です。「書けることがほぼなくて、職務経歴書がスカスカになってしまう」という相談を受けることが多いポイントです。

NDA抵触の典型パターン

NDAで書いてはいけない典型パターンは以下です。

• 顧客企業の特定: 「A社（社名公開可）」と明示的に許諾を得ていない限り、社名は伏せる
• プロダクト・サービス名の特定: 「A社の決済サービス『〇〇Pay』」のような固有名詞も避ける
• 具体的な数値の開示: 売上・ユーザー数・トランザクション数など、企業の機密に該当する数値
• アーキテクチャの詳細: 認証フロー・データベース設計など、攻撃の手がかりになる詳細

ここまで全部書けないとなると「本当に何も書けない」と感じるかもしれません。しかし、「これらを抽象化したうえで、抽象化された情報だけでも十分にアピールできる」のがNDA対応の核心です。

4要素抽象化テンプレ

職務経歴書とポートフォリオの両方で使える、NDA下の実績記述テンプレートとして以下の4要素抽象化が有効です。

業界はカテゴリまで、技術スタックは具体名まで、役割は機能名まで、数値は丸めて「規模感が伝わる範囲」まで。この4要素を組み合わせれば、社名・サービス名を出さなくても「何のプロジェクトで何ができる人か」は十分に伝わります。

職務経歴書での書き方

NDA配慮の典型的なNG例とOK例を比較します。

NG例（社名・プロダクト名を出してしまっている）

■ A社の「〇〇Pay」決済基盤リプレイス（2023年6月〜2024年3月）
担当: 決済処理API実装
使用技術: Go / DynamoDB / AWS Lambda
業務内容: 月間取引額1,200億円規模の決済処理APIを新規実装。
         ピーク時2,000 TPSを処理。

社名・プロダクト名・具体的な取引額が記載されており、NDA違反のリスクが高いです。

OK例（4要素抽象化を適用）

■ 大手金融サービスの決済基盤リプレイス（2023年6月〜2024年3月）
業界: フィンテック（決済）
規模: 月間取引額 数千億円規模、ピーク時数千TPS
担当: 決済処理API設計・実装（バックエンドリード）
使用技術: Go / DynamoDB / AWS Lambda / API Gateway

【課題】
レガシーPHPの決済基盤がピーク時にレスポンス遅延を起こし、機会損失が発生していた。
【行動】
Go言語で決済処理APIをマイクロサービスとして切り出し、DynamoDB + Lambda 構成で再構築。
冪等性を保証する分散トランザクション設計を担当した。
【成果】
ピーク時レスポンスを約70%改善し、決済成功率が3pt向上。月次の機会損失額を大幅に削減。

社名・サービス名は出していませんが、「フィンテックの決済基盤」「数千億円規模」「Go + DynamoDB + Lambda」「冪等性を保証する分散トランザクション設計」と書かれていれば、発注側は「金融業界の経験があり、高負荷の決済処理を設計できる人」と十分に評価できます。

数値の丸め方は、桁を1段ぼかすのが目安です。「月間取引額1,200億円」→「数千億円規模」、「2,000 TPS」→「数千TPS」のように、規模感は伝わるが特定の企業が分かるレベルにはしない、というバランスです。

ポートフォリオでの見せ方

ポートフォリオも同じく、本業案件についてはNDA配慮が必要です。

• GitHubはプライベートリポジトリ運用: 本業のコードを誤って公開リポジトリに置かないよう、組織アカウントとプライベートリポジトリで管理する
• スクリーンショットはモック化: 本業プロダクトのUIスクリーンショットをそのまま載せず、Figmaなどで類似のモックを作って差し替える
• アーキテクチャ図の抽象化: 「決済処理サービス」「在庫管理サービス」など、機能単位の抽象名で図を描き、社内固有の用語を消す

本業の実績を載せられない場合の代替手段としては、「個人開発」「OSSコントリビューション」「副業案件で公開許諾を得たもの」を厚くする方針が有効です。本業を抽象化して職務経歴書に書きつつ、公開可能な個人開発をポートフォリオで補強する、という棲み分けで対応します。

副業エンジニアからフリーランス独立への書類切り替え

副業エンジニアからフリーランスへ独立する段階では、書類の「主役」が大きく変わります。会社員時代の本業経歴中心の履歴書・職務経歴書から、フリーランス向けの「案件マッチング型」スキルシート・ポートフォリオへの切り替えが必要です。

副業時代の実績はフリーランス用書類で「主役」になる

会社員時代は副業の実績を「サブ」として扱っていた方が多いと思います。しかしフリーランス独立後は、副業時代の実績こそが「主役」になります。

理由はシンプルで、副業案件は本業と違って「外部の顧客に対して納品した実績」だからです。発注側から見ると、「会社の看板や上司のサポート抜きで、外部顧客に対して成果を出した経験」は、フリーランスとして案件を任せられるかの直接的な判断材料になります。

副業時代の実績を主役にするためには、副業段階から以下を意識しておくのが理想です。

• 案件ごとに「課題・自分の役割・成果」を案件終了直後にメモしておく
• 公開可能な案件は、許諾を取ったうえでポートフォリオに掲載する
• 顧客からのフィードバック（メール文・チャットの抜粋）を保存しておく

副業エンジニアとしてスキルを積み上げる段階で、案件選びと並行して「将来フリーランス用の書類で何を語るか」を意識すると、独立時の書類整備が大幅に楽になります。副業段階でのスキル設計は複業エンジニアのスキルアップとキャリア設計｜スキルマップ作成4ステップ、案件と技術スタックの選び方は副業エンジニアのスキルセット｜週10時間で月10万円に届く技術と案件の選び方も併せて参考にしてください。

独立直前にやる書類の再構築

会社員からフリーランスへ独立する直前のタイミングで、書類を一度「再構築」することをおすすめします。具体的には以下の作業です。

1. 履歴書中心から職務経歴書・スキルシート中心へ: 会社員転職用に作っていた履歴書は、フリーランス案件では志望動機欄などが不要になります。職務経歴書・スキルシートをマスター原稿として整備し直します
2. プロジェクト経歴をPARモデルで書き直す: 会社員時代の経歴も含めて、直近2〜3年の主要案件はPARモデルで再構築します
3. NDA配慮の見直し: 在職中は気にしていなかったNDA・退職時の競業避止義務を改めて確認し、書ける範囲を再定義します
4. ポートフォリオの整備: 副業案件・個人開発・OSSコントリビューションを整理し、ポートフォリオサイトを立ち上げます
5. 屋号・連絡先の統一: 個人事業主として活動するなら、屋号と連絡先（メール・SNS）を職務経歴書・ポートフォリオ・名刺で統一します

独立してから書類を作り始めると、案件エントリーが遅れて初月の収入が立たないリスクがあります。退職予定日の1〜2ヶ月前から準備を始めるのが安全圏です。

案件1件ごとに追記する内容と頻度

書類は一度作って終わりではなく、案件1件ごとに追記していくのが基本です。最低でも以下のタイミングで更新します。

• 案件参画時: 開始日・チーム規模・自分の役割を職務経歴書に追記
• 案件終了直後（最重要）: PARモデルで「課題・行動・成果」を記述。記憶が鮮明なうちにやる
• 3ヶ月ごと: スキルセット全体の見直し・古い案件の整理・新しい技術の追加

特に「案件終了直後」のタイミングが重要です。終了から1ヶ月経つと、自分が何を成果として出したかの記憶が急速に薄れます。終了日に1時間だけ確保し、PARモデルで5〜10行書き残しておくと、後から書類を更新するときに大幅に楽になります。

案件単価を上げる書類の運用

書類を「育てて使い続ける資産」として捉える視点で、案件単価を上げるための運用ノウハウをまとめます。

案件別カスタマイズ

同じスキルシートを全案件に出すと、どの案件でも「ぴったりではない候補者」として扱われます。案件性質ごとに、職務経歴書・スキルシートの強調ポイントを切り替えるのが基本です。

すべてをゼロから書き直す必要はありません。「マスター原稿（職務経歴書）」から該当する案件を上に持ってきて、自己PRの1〜2文を案件向けに書き換える、というレベルのカスタマイズで十分です。所要時間は1案件あたり10〜20分が目安です。

3ヶ月ごとに見直すチェックリスト

書類は3ヶ月ごとに通しで見直すと、案件獲得の手応えが目に見えて変わります。以下のチェックリストを使ってください。

• 直近3ヶ月で関わった案件をプロジェクト経歴に追加したか
• 半年以上古い案件で、現在の単価帯と合わない簡単な案件は省略したか
• スキル要約で、最近使っていないスキルの経験年数を更新したか（または削除したか）
• 新しく学習・実務投入した技術をスキル要約に追加したか
• GitHub のピン留めリポジトリは、最新の主要プロジェクトに差し替えたか
• ポートフォリオの実績一覧と職務経歴書のプロジェクト経歴で、案件番号・要約文の整合が取れているか
• 自己PRに「数値で語れる強み」が最低1つ含まれているか
• 希望単価レンジは現在の市況・自分の成長度に合っているか

特に「古い案件の省略」は意識的にやらないと、書類がどんどん厚くなり、最新の実績が埋もれてしまいます。フリーランス3年目くらいから、5年以上前の案件は1行サマリーに圧縮するのがおすすめです。

単価交渉の根拠を書類に仕込む方法

単価交渉の場面で「もう少し上げてほしい」と言うときに、書類に根拠が仕込まれているかどうかで通過率が変わります。書類に仕込むべき要素は以下です。

• 成果の数値: 「レスポンスタイム80%改善」「コスト30%削減」など、改善率を必ず入れる
• チーム規模: 1人で完結したのか、10人チームの一員だったのか、20人チームのリードだったのか
• 影響範囲: 「月間アクティブユーザー10万人規模のサービス」「年商規模数十億円のEC」など、サービスの規模感
• 改善率と継続効果: 改善が一過性ではなく、継続的に効果を発揮していること

たとえば「ピーク時レスポンスを80%改善し、その後半年間障害ゼロを継続している」と書かれていれば、「同じことを別案件でもやれそう」と発注側は判断します。逆に「実装を担当した」とだけ書かれていると、「いくらが妥当か」の判断基準を発注側に渡せないため、単価は前提値（市場相場）でしか決まりません。

単価交渉は「交渉のスキル」ではなく、書類に書かれた「成果の証拠」で8割決まると考えてください。

よくある質問

Q1. 職務経歴書とポートフォリオはどちらが重要ですか？

両方必要で、どちらが重要かは応募フェーズで変わります。書類選考では職務経歴書のテキスト情報が中心、面談以降ではポートフォリオの「動く証拠」が決め手になります。先ほどの章で触れたとおり、両方の評価軸を別々に突破するイメージで整備しましょう。

Q2. スキルシートと職務経歴書は別に作るべきですか？

別に作る必要はありません。職務経歴書を「マスター原稿」として整備し、スキルシートはそこから抜粋・再配置して作るのが効率的です。エージェント各社のテンプレートに合わせる手間も最小化できます。

Q3. NDAで本業の実績をほとんど書けない場合はどうすればいいですか？

「業界・技術スタック・役割・成果」の4要素で抽象化すれば、社名・サービス名を出さずに十分アピールできます。社名は伏せ、業界はカテゴリまで、数値は桁を1段ぼかして規模感だけ伝えるのが基本パターンです。詳細は本記事の関連章で例文を紹介しています。

Q4. 副業エンジニアの経歴は「職歴」として書けますか？

書けます。フリーランス用書類では、副業時代の実績はむしろ「外部の顧客に対して納品した経験」として主役級の扱いになります。会社員時代の本業経歴と並べて、案件ごとにPARモデルで記述するのがおすすめです。

Q5. ポートフォリオに載せる実績は何件くらいあればいいですか？

3〜5件が目安です。質の低い実績を10件並べるより、PARモデルで深掘りした3件の方が評価されます。GitHubのピン留めも上位3〜6個までに絞り、見せたいものに集中させましょう。

Q6. 職務経歴書は何枚にまとめるのが適切ですか？

3〜5枚が目安です。直近2〜3年の主要案件をPARモデルで詳述し、それ以前は簡略表記にすると、自然とこの枚数に収まります。10枚を超えると読み手の集中力が続かず、肝心のプロジェクト経歴に目を通してもらえないリスクが上がります。

Q7. GitHubのリポジトリは何個くらい公開しておくべきですか？

公開リポジトリの総数より「ピン留めした上位3〜5個の質」が重要です。コミットメッセージが丁寧で、READMEが整っていて、動かして見せられるリポジトリが3つあれば十分です。空のリポジトリや学習途中のものは非公開にしておきましょう。

まとめ – 職務経歴書とポートフォリオを「セット」で育てる

本記事のキーメッセージを最後に整理します。

• 職務経歴書とポートフォリオは「セット」で評価される: 職務経歴書が「説明書」、ポートフォリオが「証拠資料」として補完し合い、発注側は両方を行き来して判断する
• プロジェクト経歴はPARモデルで書く: 「課題（Problem）・行動（Action）・成果（Result）」の構造に沿って書くことで、「経験」を「再現可能なスキル」として伝えられる
• NDA下でも4要素抽象化で十分書ける: 「業界・技術スタック・役割・成果」を抽象化すれば、社名を出さずにアピールできる
• 副業時代の実績はフリーランス書類の主役: 外部顧客への納品経験は、フリーランスとして案件を任せられるかの直接的な判断材料になる
• 書類は3ヶ月ごとに育てる: 案件終了直後にPARで書き残し、3ヶ月ごとに通しで見直すサイクルが、継続的な案件獲得と単価上昇の土台になる

書類整備は地味な作業ですが、フリーランスとして継続的に案件を獲得し、収入を安定させていくための「最も投資対効果が高いインフラ」です。一度この記事の手順に沿って書類を整備し直すと、その後の案件獲得・単価交渉のすべての場面で恩恵を受けることになります。

整備した書類は、エージェント経由のスカウト・直案件のエントリー・案件プラットフォームでの公開プロフィールなど、さまざまな場で実戦投入されます。書類を「育てて使い続ける資産」として運用しながら、自分に合った案件と継続的に出会える仕組みを作っていきましょう。