フリーランスエンジニアの単価は、スキルそのものだけでなく、スキルシートの「見せ方」でも変わります。同じ経験でも、担当できる工程の幅や成果が伝わるかどうかで、提案できる案件の単価帯は変わるのです。
「本来もっと高い単価の案件に通れたのに、書き方で損していた」というのはよくあること。スキルを上げるには時間がかかりますが、見せ方を整えるのは今日からできます。しかも、いちばん費用対効果が高い単価対策でもあります。この記事では、単価につながる見せ方を3つの切り口で整理し、逆に損をしやすい書き方も具体的に挙げていきます。
なぜ「見せ方」で単価が変わるのか
単価は、案件先が「この人にいくらまで払えるか」を判断して決まります。その判断材料は、面談の前段階ではほぼスキルシートだけです。つまり、スキルシートに書かれていないことは、評価にのりません。
実際にはできることでも、書いていなければ「できない人」として扱われます。逆に、やった工程を漏れなく・正確に書けば、それだけで提案できる案件の単価帯が一段上がることがあります。スキルを上げる話ではなく、今ある経験を取りこぼさず伝える、という話です。だからこそ、時間をかけずにすぐ着手できる、割のいい単価対策になります。
| 損をしている状態 | 単価につながる状態 |
|---|---|
| できるのに書いていない | できることを漏れなく書けている |
| 「開発した」で工程が見えない | 設計〜運用のどこを担えるか分かる |
| 成果が定性的で規模が不明 | 数字で貢献の大きさが伝わる |
単価の相場は、まず押さえておく
見せ方の前に、自分の経験帯の相場感を知っておきましょう。準委任の単価相場は 準委任の単価相場と手取りの考え方 にまとめています。そのうえで、レンジの上側に近づけるのが本記事のテーマです。相場を知らないと、そもそも通せるはずの単価で提案していない、ということが起こります。
単価を上げる3つの見せ方
単価につながる見せ方は、大きく3つです。①担当できる工程の幅、②成果の数字、③希少なスキル。どれも新しく経験を積む話ではなく、すでにある経験の書き方を変えるだけで効きます。順に見ていきます。
1. 担当できる工程の幅を見せる
「開発した」で止めると、実装だけの人に見えます。要件定義 / 設計 / 実装 / テスト / 運用のうち、どこを担当できるかを分解して書きましょう。関われる工程が広いほど、任せられる案件＝単価の高い案件につながります。
| 単価が上がりにくい書き方 | 単価につながる書き方 |
|---|---|
| Webシステムを開発した | 要件定義・基本設計から実装・テスト・運用保守まで一貫して担当 |
| 実装を担当した | 詳細設計と実装に加え、コードレビューと後輩の技術指導も担当 |
案件先は「どこから任せられるか」で単価を決めます。上流（要件定義・設計）まで担えると分かると、任せられる範囲が広がり、単価も上がりやすくなります。実装だけの人と、設計から任せられる人では、案件先が想定する単価帯がそもそも違う、ということです。
ポイントは、実際に担った工程を漏れなく書くこと。「言われて実装しただけ」と思っていても、仕様の相談に乗った、テスト設計をした、運用の引き継ぎをした——といった工程は、立派な担当実績です。省かずに書き出してみてください。
2. 成果を数字で添える
「パフォーマンスを改善」より「レスポンスを◯%短縮」「月間◯◯万リクエストを処理」。可能な範囲で数字を添えると、貢献の大きさが伝わり、評価が変わります。
| 伝わりにくい成果 | 伝わる成果 |
|---|---|
| パフォーマンスを改善した | クエリ見直しで一覧表示のレスポンスを約40%短縮 |
| 大規模なシステムを担当した | 月間◯◯万リクエスト規模のサービスのバックエンドを担当 |
| チームをまとめた | 開発5名のチームで進行管理を担当し、納期遅延ゼロで運用 |
数字が思い出せない場合は「約◯%」「約◯名規模」で構いません。正確さより、規模感が伝わることが大事です。無理に盛った数字は面談で崩れるので避けます。
数字が単価に効くのは、案件先が貢献の大きさを比較できるからです。「改善した」は主観ですが、「40%短縮」「月間◯◯万リクエスト」は誰が見ても同じ大きさに読めます。比較できる情報が多いほど、案件先は安心して高い単価を提示できます。逆に定性的な表現ばかりだと、判断のしようがなく、無難なレンジに落ち着いてしまいます。
3. 希少なスキルを前面に出す
クラウド設計、SRE、データ基盤、PM・PdMなど、需要が高く担い手が少ないスキルは、単価のレンジを押し上げます。持っているなら、スキルシートの目立つ位置に置きましょう。
| 単価を押し上げやすいスキル例 | なぜ効くか |
|---|---|
| クラウド設計（AWS／GCPのアーキ設計） | 設計まで任せられる人は少なく、需要が高い |
| SRE・信頼性設計 | 運用の安定に直結し、担い手が限られる |
| データ基盤・データエンジニアリング | 専門性が高く、対応できる人が少ない |
| PM・PdM・テックリード | 技術に加えて推進・調整ができる希少枠 |
これらは持っていれば強力ですが、無い場合に無理やり書くものではありません。今できることの中で希少性の高いものを、埋もれさせず前に出すのが狙いです。よくあるのは、希少スキルを持っているのに、他の項目に埋もれて目立っていないケース。スキルシートの上のほうや、業務経歴の見出しに置くだけでも、案件先の目に留まりやすくなります。
単価で損をしやすい、よくある書き方
3つの見せ方の裏返しとして、単価を下げてしまいがちな書き方も挙げておきます。当てはまっていないか、自分のスキルシートで確認してみてください。
| 損をしやすい書き方 | どうするか |
|---|---|
| 案件を「参加した」「携わった」で書く | 自分が担当した工程を主語にして書き直す |
| 使った技術を羅列するだけ | その技術で「何を担ったか」まで書く |
| 直近の案件も昔の案件も同じ密度 | 直近と関連の強い案件を厚く、古いものは簡潔に |
| 謙遜して控えめに書く | 事実の範囲で、担った範囲を正確に書く（過小評価も損） |
とくに謙遜しすぎは見落とされがちです。「これくらい誰でもできる」と思って省いた工程が、案件先には十分な評価ポイントだった、ということはよくあります。盛るのはNGですが、過小評価も同じくらい損だと考えてください。自分では当たり前になっている経験ほど、第三者から見ると価値がある、というのはよくあることです。判断に迷ったら、省かずに書き出しておき、あとで取捨選択するほうが安全です。
見せ方を整えたら、希望単価も添える
スキルシートで「できること」を正しく見せられたら、次は希望単価を伝えることです。書き方を整えても、希望を出さなければ、案件先はレンジの下側で提案してくることがあります。見せ方で土台を作り、希望提示でレンジの上側を狙う、という順番です。
Relayでは登録時に希望単価を伺い、それを踏まえて案件をご紹介します。相場を押さえたうえで希望を出せば、「見せ方」と「希望提示」の両輪で単価が決まりやすくなります。単価交渉そのものが苦手でも、間に担当者が入るので、直接値段の話をせずに済みます。希望と案件先の条件のあいだで、担当者が調整役になります。
「盛る」のではなく「伝わる形」にする
単価を上げる見せ方は、事実を盛ることではありません。やった工程を、案件先に伝わる言葉で正確に書くこと。盛った内容は面談や参画後の実務で必ず露見し、かえって信用と次の案件を失います。単価を上げる近道は、事実の解像度を上げることです。
具体的な言い換えは 経験を“伝わる言葉”に翻訳するスキルシートの書き方 を、項目全体の作り方は スキルシート完全ガイド を参考にしてください。職種別の書き方の例は 職種別の記入例 にまとめています。
まとめ：見せ方は、いちばん手軽な単価対策
単価を上げる見せ方を、あらためて整理します。
| やること | 効果 |
|---|---|
| 担当した工程を分解して書く | 「どこから任せられるか」が伝わり、上位の案件に届く |
| 成果に数字を添える | 貢献の大きさが具体的に伝わる |
| 希少スキルを前面に置く | 単価レンジそのものを押し上げる |
| 過小評価・謙遜をやめる | 取りこぼしていた評価ポイントを拾える |
どれも、新しくスキルを身につける必要はありません。すでにある経験を、正確に・伝わる形に直すだけです。スキルアップより早く、今日から効果が出せる単価対策だと考えてください。まずは直近の案件1つを、この観点で書き直すところから始めてみてください。
整えたスキルシートで案件を探すなら、Relayに登録を。希望単価を含めて、経験に合う案件を担当者がメールでご紹介します。登録面談なし・営業電話なしなので、まずシートを整えて登録するだけで始められます。