公開日
2026/04/15更新日
2026/08/30
フリーランスエンジニアが案件を獲得できるかどうかは、職務経歴書でほぼ決まります。エージェントもクライアントも、まず書類を見て「会うかどうか」を判断するからです。
とはいえ、何をどこまで書けばいいかは誰も教えてくれません。同じ経験をしていても、書き方ひとつで通過率は大きく変わります。
この記事では、案件が決まる職務経歴書の書き方を、例文と一緒に解説します。エージェント提出でそのまま使えるExcel版スキルシートとWord版職務経歴書も、記入例つきで配布しています。
読みながら書き進められる構成にしているので、まずはテンプレートを開いてみてください。
職務経歴書を書く前に知っておきたいこと
職務経歴書とスキルシート、どちらを出すのか
フリーランスエンジニアの場合、提出を求められる書類は主に2種類です。名前が混在していて紛らわしいので、先に整理しておきます。
| スキルシート | 職務経歴書 | |
|---|---|---|
| 主な提出先 | フリーランスエージェント、SES | 企業への直接応募、転職 |
| 形式 | Excel（表形式） | Word（文章形式） |
| 重視される点 | 技術スタックと担当工程が一覧で分かること | 経歴の流れと人物像が伝わること |
| 分量 | A4で1〜3枚 | A4で2〜3枚 |
エージェント経由で案件を探すなら、まず必要になるのはスキルシートです。担当工程や経験年数が一覧で見える形式が求められます。
一方、企業と直接契約する場合や、正社員への転換も視野に入れている場合は、文章形式の職務経歴書が向いています。
どちらも用意しておくのが理想ですが、迷ったらスキルシートから作ってください。案件応募で使う頻度が圧倒的に高いためです。
相手が知りたいのは「技術力」だけではない
書き始める前に、読み手の視点を押さえておきます。クライアントやエージェントは、書類から次の3点を見ています。
即戦力かどうか
募集ポジションに必要な技術を持っているか。類似プロジェクトの経験があるか。参画してすぐ動けるか。ここは技術スタックの一覧である程度伝わります。
自走できるかどうか
フリーランスに求められるのは、指示待ちではない動き方です。課題を自分で見つけ、解決策を提案し、実行できるか。ここが正社員の職務経歴書と最も違う点で、多くの人が書き漏らしています。
一緒に働けるかどうか
職務経歴書の基本構成
まず全体の骨格です。逆編年体式（新しい経歴から順に書く）を推奨します。直近のスキルが最初に目に入るため、案件参画の判断がしやすくなります。
| 項目 | 書く内容 | 分量の目安 |
|---|---|---|
| 日付・氏名 | 提出日と氏名を右上に記載。エージェント提出ならイニシャルでも可 | 1行 |
| 職務要約 | 強みと経験を凝縮したダイジェスト | 3〜5行 |
| 基本情報 | 稼働可能日、希望単価、稼働形態の希望 | 4項目程度 |
| スキル要約 | 言語・FW・DB・クラウドをカテゴリ分けして記載 | 10〜15行 |
| 職務経歴 | プロジェクト単位で担当業務と実績を具体的に記載 | 最重要・全体の6割 |
| 保有資格 | 取得年月と資格名 | 数行 |
| 自己PR | 職務経歴で伝えきれなかった強みや姿勢 | 5〜8行 |
| その他 | GitHub、ポートフォリオ、技術ブログのURL | 1〜3行 |
分量配分が重要です。職務経歴に全体の6割を割いてください。 スキルの羅列に紙面を使い、肝心のプロジェクト内容が数行しかない書類が非常に多く、これが通過率を下げています。
プロジェクト経歴の書き方【PARモデル】
ここが職務経歴書の核心です。「〇〇を開発しました」だけでは、あなたが何をしたのか伝わりません。
使うのはPARモデルという枠組みです。
- P（Problem） … プロジェクトの背景・課題
- A（Action） … 自分が担当した業務と、そこで判断・工夫したこと
- R（Result） … その結果どう変わったか
この順で書くと、技術が「どうビジネスに貢献したか」まで伝わります。
悪い例
〇〇株式会社 ECサイト開発 期間：2023年4月〜2024年3月 担当：バックエンド開発 内容：PHP（Laravel）を用いて、商品一覧機能、カート機能、決済機能などを開発。
技術名と機能名が並んでいるだけです。同じことが書ける人が何百人もいます。 これでは選ぶ理由になりません。
良い例（PARモデル適用）
新規ECサイトのバックエンド開発（小売・EC／自社ECサイトの刷新） 期間：2023年4月〜2024年3月（12ヶ月） 役割：バックエンドリード（メンバー5名／全体20名） 担当工程：基本設計・詳細設計・実装・テスト・保守運用
背景・課題 レガシーシステムからの脱却と、事業拡大を見据えたスケーラブルな基盤の構築が課題でした。特にセール時のアクセス集中によるサーバーダウンが頻発しており、パフォーマンス改善が急務となっていました。
担当業務・工夫した点 ・Laravel 10 を採用し、モダンな開発環境を構築。既存資産の移行方針を策定 ・N+1問題を解消するクエリチューニングと、Redis を用いたキャッシュ戦略を導入 ・Docker による開発環境のコンテナ化を推進し、新メンバーのオンボーディングを効率化 ・GitHub Actions で CI/CD パイプラインを構築し、デプロイを自動化 ・Stripe API を導入し、セキュリティ要件を満たす決済システムを実装
成果・実績 ・セール期間中のサーバーダウンを 0件 に（前年は月平均3件） ・商品一覧ページの平均表示速度を 2.5秒 → 0.8秒 に改善。離脱率が15%改善し、売上向上に貢献 ・デプロイ頻度が 週1回 → 1日複数回 に向上 ・新メンバーのオンボーディング所要時間を 50%削減
使用技術 PHP（Laravel 10）, TypeScript, MySQL, Redis, AWS（EC2 / RDS / S3 / CloudFront）, Docker, Nginx, Stripe API, Git, GitHub Actions
同じプロジェクトでも、伝わる情報量がまったく違います。
数値が思いつかないときの探し方
「成果を数値で」と言われても、手元にデータがない人がほとんどです。次の切り口で振り返ってみてください。
時間の変化 … 処理時間、ビルド時間、デプロイ所要時間、レビュー待ち時間
回数・頻度の変化 … 障害発生件数、問い合わせ件数、リリース頻度、手戻り回数
規模 … 対応ユーザー数、データ件数、リクエスト数、チーム人数
削減できたもの … サーバー費用、工数、手作業のステップ数
正確な数字が分からなければ「約」「およそ」で構いません。「体感で半分になった」なら「約50%短縮」と書いて問題ありません。 数値がひとつもない書類より、概算が入っている書類のほうが圧倒的に伝わります。
職種別の書き方のポイント
同じPARモデルでも、職種によって強調すべき点が変わります。自分に近いものを参考にしてください。
バックエンドエンジニア
書くべきこと … 設計判断の理由、パフォーマンス改善の具体策、扱ったデータ規模
見られている点 … 「なぜその技術を選んだか」を説明できるか。フレームワークを使えることより、選定の判断ができることが評価されます。
例 … 「Laravel を採用」ではなく「開発速度と保守性のバランスから Laravel 10 を採用。既存のPHP資産を活かせる点も判断材料とした」
フロントエンドエンジニア
書くべきこと … UI/UXへの関与度、パフォーマンス指標（Core Web Vitals）、デザイナーとの協業の仕方
見られている点 … 言われたものを作るだけか、体験の質まで踏み込めるか。Core Web Vitals の改善実績は数値で書きやすく、強いアピールになります。
例 … 「LCP を 4.2秒 → 1.8秒 に改善。画像の遅延読み込みとバンドルサイズの削減により、モバイルの直帰率が12%改善」
インフラ・SRE
書くべきこと … 可用性の数値、コスト削減額、障害対応の実績、IaC の適用範囲
見られている点 … 構築できるかだけでなく、運用を回せるか。インシデント対応の経験は具体的に書くほど評価されます。
例 … 「Terraform で本番環境をコード化。環境構築の所要時間を3日→2時間に短縮し、構成ドリフトを解消」
データエンジニア・機械学習
書くべきこと … 扱ったデータ規模、パイプラインの設計、精度改善の数値、ビジネス指標への貢献
見られている点 … モデルを作れるかより、運用に乗せられるか。PoC止まりの経験ばかりだと弱く見えます。
例 … 「日次1億レコードのETLパイプラインを構築。処理時間を6時間→40分に短縮し、翌朝のレポート提供を実現」
PM・PMO・テックリード
書くべきこと … 体制規模、予算規模、ステークホルダーの範囲、意思決定した内容
見られている点 … 管理していただけか、判断していたか。「〇名のチームを管理」より「〇〇の理由でスコープを縮小し、納期を死守」のほうが伝わります。
各項目の書き方とコツ
職務要約：3秒で読まれる部分
最初に読まれ、ここで印象が決まります。「何ができるエンジニアなのか」が一読で伝わることだけを考えてください。
約5年間、Web系開発企業にてバックエンドエンジニアとして従事した後、フリーランスとして独立。PHP（Laravel）を用いたWebアプリケーション開発を得意とし、特に大規模サービスのパフォーマンス改善と、0→1の新規開発における技術選定・アーキテクチャ設計に強みを持ちます。クラウドは AWS を中心に実務経験が豊富で、インフラ構築からアプリケーション開発まで一気通貫で対応可能です。
書き方のコツ … 「経験年数 → 得意領域 → 特に強い部分 → 対応できる範囲」の順で組み立てると、自然にまとまります。
スキル要約：経験年数とレベルを添える
技術名を並べるだけでは、どこまで使えるのか分かりません。経験年数と習熟度を併記してください。
言語：PHP（7年）, TypeScript（5年）, Go（2年） フレームワーク：Laravel（5年）, Next.js（3年）, Echo（2年） データベース：MySQL（7年）, PostgreSQL（3年）, Redis（4年） クラウド：AWS（5年／EC2, RDS, S3, Lambda, ECS, CloudFront）, GCP（2年／Cloud Run, BigQuery） その他：Docker, Kubernetes, Terraform, Git/GitHub, GitHub Actions
習熟度は3段階で示すと親切です。
- A … 設計から一人で対応できる。技術選定の判断ができる
- B … 指示や仕様があれば問題なく実装できる
- C … 学習中、または実務経験が浅い
触ったことがある程度の技術を書くかどうかは悩みどころですが、書いて構いません。ただし必ずレベルを添えてください。面談で深掘りされて答えられないと、書類全体の信頼が落ちます。
自己PR：自走力を具体的に示す
フリーランスで特に見られるのは自走力です。抽象的な決意表明ではなく、実際のエピソードで示します。
常に心がけているのは、単に実装するだけでなく「ビジネスの成功にどう貢献できるか」という視点を持つことです。前職のプロジェクトでは、エンジニアの立場から UI/UX の改善案を企画側に提案し、ABテストを実施。結果としてコンバージョン率を5%向上させました。
また、技術情報のキャッチアップを日課としており、技術ブログでの発信も継続しています。参画先においても、これまでに培った技術力と課題解決力を活かし、事業の成長に貢献したいと考えています。
GitHub・ポートフォリオ
ソースコードは、エンジニアにとって最も雄弁な成果物です。GitHubアカウントは必ず記載してください。
ただし、放置されたリポジトリだけが並んでいる状態は逆効果です。見せられるものがない場合は、無理に載せず技術ブログや登壇資料で代替するほうが良い結果になります。
よくある失敗と、その直し方
実際に多い失敗を、直し方とセットで挙げます。
抽象的な表現で終わっている
NG … 「コミュニケーション能力には自信があります」
OK … 「非エンジニアの事業部メンバーに対し、技術的な制約を図解して説明。仕様変更の合意形成を2営業日以内で完了させていました」
根拠のない自己評価は、読み手にとって情報がゼロです。
技術名の羅列で終わっている
NG … 「AWS（EC2, RDS, S3, Lambda）」だけで終わる
OK … スキル要約に加えて、プロジェクト経歴で「Lambda で日次バッチを実装し、EC2 の常時起動を廃止して月額コストを4割削減」と書く
その技術で何を解決したかまで書いて、はじめて実務経験として伝わります。
分量が適切でない
A4で2〜3枚が目安です。直近3〜5プロジェクトに絞ってください。
10年分すべてを詰め込んだ書類は読まれません。古い経歴は「2015〜2018年：SIerにて業務システムの開発・保守（Java, Oracle）」のように1行でまとめれば十分です。
守秘義務に触れている
社名やサービス名をそのまま書いてしまうケースがあります。契約上のリスクになるうえ、情報の扱いが甘い人だと判断されます。
「大手小売企業」「金融系のBtoBサービス」のように、業種と規模で置き換えてください。
表記がゆれている
Laravel と laravel、GitHub と Github が混在している書類は、細部への注意力を疑われます。提出前に検索して統一してください。
更新が止まっている
職務経歴書は一度作って終わりではありません。プロジェクトが終わるたびに追記してください。
記憶が新しいうちに書いたものと、半年後に思い出しながら書いたものでは、具体性がまったく違います。案件が決まった直後に更新するのを習慣にすると、次の案件探しが圧倒的に楽になります。
よくある質問
フリーランスの職歴は経歴として認められますか
認められます。「フリーランス（個人事業主）として〇〇に従事」と明記し、参画したプロジェクト単位で書いてください。
会社員時代とフリーランス期間を分けて、時系列で並べる形が読みやすくなります。
ブランク期間はどう書けばいいですか
隠さず書いてください。空白期間があること自体より、説明がないことのほうが不信感を招きます。
学習や資格取得に充てていた場合はその内容を、家庭の事情であればその旨を簡潔に。長く書く必要はありません。
実務経験が少ない場合はどうすればいいですか
個人開発の実績を職務経歴と同じ粒度で書いてください。PARモデルはそのまま適用できます。 「何を作りたくて（課題）、どう作って（行動）、何ができるようになったか（結果）」で構成します。
学習中の技術も、レベルを明示すれば書いて問題ありません。
単価交渉のために盛ってもいいですか
やめてください。参画後に必ず露見します。 期待値とのギャップは早期終了に直結し、エージェントとの信頼関係も失います。
盛るのではなく、事実の中で評価されやすい部分を前に出すのが正しい戦略です。同じ経験でも、書き方で印象は大きく変わります。
何社ぶんまで書くべきですか
直近3〜5プロジェクトが目安です。それ以前は1〜2行に要約してください。
写真は必要ですか
スキルシートには不要です。エージェントによっては求められる場合がありますが、指定がなければ載せなくて構いません。
まとめ
フリーランスエンジニアの職務経歴書で押さえるべき点を整理します。
- 提出先で使い分ける … エージェント経由ならスキルシート、企業直接なら職務経歴書
- 職務経歴に6割を割く … スキルの羅列より、プロジェクトの中身が見られている
- PARモデルで書く … 課題 → 行動 → 成果の順にすると、貢献が正確に伝わる
- 成果は数値で示す … 概算でも構わない。数値のない成果は伝わらない
- 自走力を具体例で示す … フリーランスで最も見られる部分
- プロジェクトごとに更新する … 記憶が新しいうちに書くと具体性が保てる
職務経歴書は、書けば書くほど精度が上がっていくものです。まずはテンプレートに現在の経歴を入れてみて、埋まらない項目があれば、そこがこれから言語化すべき部分だと考えてください。
書いてみたものの、これで案件が決まるか判断がつかない——そんなときは、TechSpace で現役エンジニアに相談できます。実際の案件要件と照らして、どこを補強すべきかをお伝えします。
フリーランス 
2026/10/05 
2026/08/31 
