スキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳

スキルシートで単価差が生まれる仕組み

首都圏の公開案件やエージェント提案の観測範囲では、同じ「Java経験5年」でも提示単価が月10万円以上ズレるケースがあります。差の一因として、評価者に情報が届く書き方ができているかは無視できません。

単価を決めているのは誰か

スキルシートを読んで単価に「◯」をつける読み手は、多くの案件で複数の層にまたがります。エージェント担当者・発注企業のPMや開発リード・エンドクライアントで、層ごとに読む箇所と評価軸が違うため、書き手は各層に向けたシグナルを最低1つは埋め込む設計が有効です。

「エージェントは通ったが企業面談で単価が伸びなかった」ときは、案件詳細の情報密度がPM層に届いていないケースが多くみられます。

単価評価の3軸：規模・影響・独力範囲

3層に共通する評価軸は、規模（どれくらいの人／システム／トラフィックに触ったか）／影響（何を変えたか）／独力範囲（どこまで一人で回せるか）の3つです。技術名の羅列だけではこの3軸が読み取れず、初期提示単価が下限に張り付きやすくなります。

• 規模：利用者数・トラフィック・データ量・チーム人数・案件金額のいずれか1つでも書く

• 影響：Before/Afterの差分（数値でも定性でも）

• 独力範囲：どの工程を一人で完結できたか（要件・設計・実装・レビュー・運用）

ミニFAQ：単価評価の仕組み

Q. 技術名の一致度が一番大事ではないのか？

A. 一次スクリーニングでは技術名一致が使われますが、単価レンジを決める段階では規模・影響・独力範囲の情報量が重視されやすいです。技術名が揃っていても情報密度が薄いと、提示単価は同スキルセットの中の下限側になりがちです。

Q. スキルシートの書き方だけで本当に単価が変わるのか？

A. 経験そのものが同じでも、規模の数字と独力範囲が明示されているスキルシートは、エージェント側で「一段上のレンジで提案する」判断が出やすくなります。書き方だけで無限に上がるわけではなく、実力を評価に翻訳する余地の話です。

単価が上がる書き方の3原則

競合上位記事の多くは「数字で書く」で止まりますが、単価に効くのはもう一段細かい原則です。

原則1：規模は「絶対数」か「比率」で書く

規模は、絶対数（利用者数・トラフィック・チーム人数）か、比率（案件全体のうち自分が触った割合）のどちらかで書きます。

• OK：「月間PV500万のECサイトのAPI基盤を担当（バックエンド5名中1名）」

• NG：「大規模ECサイトのAPI開発を担当」

「大規模」「多数の」「豊富な」といったサイズ形容詞は、読み手ごとに想像する数字がバラバラで、単価評価には使われません。手元に数字がない場合の代替方法は後述します。

原則2：影響は「Before / After」で対比する

改善・構築・移行などの成果は、対比構造にすると評価者の頭に金額換算が起きやすくなります。

• OK：「注文処理のSQLボトルネックを特定し、平均応答時間を1.2秒→0.4秒に短縮」

• NG：「パフォーマンスを大幅に改善」

数値が厳密でない場合は、事実に基づく概算として「約」「概算」を付ける書き方が安全です。誇張はNDA面でも面談での検証面でもリスクになるため避けます。Before/Afterの構造だけは崩さないほうが評価軸に乗ります。

原則3：独力範囲は「工程名」で刻む

「担当」「参画」ではなく、要件定義／基本設計／詳細設計／実装／レビュー／単体テスト／結合テスト／リリース／運用保守のうち、独力で回せた工程だけを列挙します。ペア作業やレビューを受けた工程は「レビュー下」と注記します。

• OK：「基本設計〜結合テストを独力で担当。要件定義はビジネスサイドとの合意形成のみ関与」

• NG：「上流〜下流まで一貫して対応」

「一貫して」「幅広く」といった修飾は、独力範囲がぼやけて単価が伸びません。工程名で刻むほど、PM層の「参画後の運用イメージ」が具体化します。

ミニFAQ：3原則の書き方

Q. 実際の案件で数字を計測していなかった場合はどうすればいい？

A. 次章の「実績の翻訳フォーミュラ」で、数字がない状態から翻訳する型を紹介します。全案件で数字が揃っている必要はなく、直近1案件だけでも数字が入っていれば単価評価は上がります。

実績を定量化する4つの型

実績を数字化するときのパターンは、大きく4つに集約されます。技術寄りの案件はすべて、このいずれかに当てはまります。

型1：改善率型（Before/After）

処理速度・エラー率・工数・顧客数などの改善案件はこの型に落とします。

• 例：「バッチ処理を並列化し、実行時間を4時間→30分に短縮」

• 例：「デプロイ手順を自動化し、月次リリース工数を8人日→1人日に削減」

改善率型が最も金額換算されやすいのは、発注側が「同じ改善を自社で再現できるか」を想像しやすいためです。

型2：絶対数型（利用者数・トラフィック）

新規開発案件や運用案件はこちら。改善差分がない代わりに、扱った規模の絶対数で単価評価が入ります。

• 例：「1日1,000万リクエストを処理するAPIゲートウェイを新規構築」

• 例：「月間30万人が利用する会員基盤の運用・機能追加を担当」

数字が公開情報でない場合は「概算」「約」を添え、ケタが誤らないようにします。ケタ間違いは信頼を大きく落とすため、不明ならレンジで書くのが安全です。

型3：範囲型（工程・領域の広さ）

要件定義から運用まで独力で担当したケースや、フロント・バックエンド・インフラを横断したケースは、範囲そのものが単価評価対象になります。

• 例：「要件定義〜運用まで一貫担当（PM兼任、開発チーム4名の技術リード）」

• 例：「フロント（Next.js）・API（Go）・IaC（Terraform）を横断」

範囲型で単価を上げるコツは、「一貫して」でぼかさず、担当工程を列挙することです。

型4：継続性型（期間・回数）

長期保守や、繰り返し発生する業務の実績はこの型で書きます。

• 例：「同一顧客のECサイトを3年連続で保守（毎年の年次リプレイス含む）」

• 例：「四半期ごとの機能追加を12回連続で担当」

期間の長さ自体が「継続的に信頼された」というシグナルになるため、案件終了時期がまたがる場合は明示します。

ミニFAQ：定量化の型

Q. どの型を優先すればいい？

A. 直近1〜2案件は改善率型・絶対数型で書き、それ以前は範囲型・継続性型で圧縮する構成が読みやすいです。直近が最も評価に影響するため、数字が拾いやすい案件は必ず改善率型で書き直します。

実績の翻訳フォーミュラ：数字が手元にないとき

「数字を書けと言われても、実案件で計測していない」というケースは多くあります。数字がなくても翻訳できるフォーミュラが5つあります。

フォーミュラ1：システムの規模から逆算する

計測していなくても、システムの規模（DB件数・テーブル数・エンドポイント数など）は推定できます。

• 「約50テーブルのデータベースを持つ販売管理システム」

• 「約120のREST APIエンドポイントを持つマイクロサービス群」

フォーミュラ2：チーム人数と自分の担当割合

改善率が測れなくても、チーム人数と自分の担当領域は事実として書けます。

• 「開発チーム8名中、フロント3名の技術リードを担当」

• 「バックエンド4名の中で決済基盤を主担当（他3名はカタログ・ユーザー担当）」

フォーミュラ3：関与した工程と成果物

工程ごとに何を作ったかを名詞で示すと、規模感が伝わります。

• 「基本設計書（約80ページ）、API仕様書（エンドポイント約40件分）を作成」

• 「テスト仕様書（約200ケース）を作成し、単体テストを独力で実施」

フォーミュラ4：意思決定・提案の内容

技術選定や設計判断に関わったならば、それ自体が単価評価軸になります。

• 「認証基盤の技術選定でOAuth 2.0 / OpenID Connectを比較検討し、採用理由を含めてPMに提案」

• 「非同期処理をRabbitMQ・Amazon SQSで比較し、運用コスト観点でSQSを推奨」

フォーミュラ5：レビュー・教育の関与

自分がレビューを受けた側ではなく、レビュー・教育をした側の情報は、単価上振れに直結します。

• 「同チームのジュニアメンバー3名のコードレビューを担当」

• 「新メンバー2名のオンボーディング資料を作成」

定量化と翻訳フォーミュラの選び方

単価レンジ別・書き分けの型

同じ人でも、狙う単価レンジによって強調すべきポイントが変わる傾向があります。以下は2026年時点で、首都圏中心の主要フリーランスエージェント数社の公開案件（週4〜5日・準委任案件）で見られる募集要件を参考にした目安です。地方在住・完全リモート案件・特殊技術領域では上下します。

60〜75万円レンジ：独力範囲を可視化する

このレンジでは「技術的な自走ができるか」が判定軸として見られやすい傾向があります。工程名で独力範囲を刻み、レビュー下・独力の区別を明示します。

• 押し出す情報：担当工程の粒度、独力範囲、実装スピード

• 弱めていい情報：上流・要件定義への関与、マネジメント経験

• キーとなる書き方：「基本設計〜結合テストを独力担当」「実装フェーズは1人で完結」

75〜90万円レンジ：数字と横断範囲を出す

このレンジでは、規模・改善数値・横断的な担当範囲が単価の起点として見られやすい傾向があります。改善率型と絶対数型のいずれかで、直近1案件は必ず数字を入れます。

• 押し出す情報：改善数値、担当システムの規模、フロント〜バックエンド横断

• 弱めていい情報：技術名の羅列（多くの案件で共通のためレンジ判定に効きにくい）

• キーとなる書き方：「月間PV500万のECサイトのAPIを担当、応答時間を40%改善」

90〜110万円レンジ：責任範囲・意思決定を書く

このレンジでは「実装できる人」よりも「設計・意思決定できる人」が評価される傾向が強くなります。技術選定・アーキ設計・レビュー体制構築などをフォーミュラ4〜5と組み合わせます。

• 押し出す情報：技術選定・アーキ設計・レビュー主導・オンボーディング設計

• 弱めていい情報：単体機能の実装工数（このレンジでは前提扱い）

• キーとなる書き方：「認証基盤の技術選定と設計を主導、実装は3名のチームでレビュー担当」

110万円超レンジ：事業KPIへの接続を書く

このレンジでは、事業側のKPIや採用・組織に踏み込んだ実績が単価判定に入る傾向があります。事業指標との接続、または開発生産性・組織改善の実績を書きます。

• 押し出す情報：CVR・売上・生産性など事業KPIとの接続、開発組織の改善

• 弱めていい情報：使用言語・フレームワークの詳細（技術的な自走は前提）

• キーとなる書き方：「新規機能のリリースサイクルを月1回→週1回に短縮、開発チーム10名のCI/CDを再設計」

レンジと書き分けの対応表

上記のレンジ帯は目安であり、案件個別の条件で上下します。

現在の市場単価の目安は、フリーランスエンジニア単価診断で条件を入力して確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方でも整理しています。

フリーランス案件単価の直接データではないものの、職種要件や市場需給の参考指標としては、厚生労働省の職業情報提供サイト job tagで職種別の要件や賃金統計が確認できます。スキルシートに書く「スキル名」の粒度を、公的な職業定義に照らして揃えたいときの外部指標として利用できます。

発注側が金額換算の参考にしやすいセクション

スキルシートは全体を均等に読まれるわけではありません。発注側は「金額の当たりをつけるための決め打ち箇所」を持っていることが多く、ここに情報を集中させると単価判定が上振れしやすくなります。

決め打ち箇所1：職務要約（冒頭3行）

職務要約は、初期スクリーニングでほぼ必ず読まれます。ここに規模・独力範囲・直近スキルの3点を圧縮します。

• OK：「Web系バックエンドを中心に約8年。直近は月間PV500万規模のECサイトでGo・AWSでの新規API開発を独力担当。上流工程では要件整理からPMと直接会話。」

• NG：「Java、PHP、Pythonでの開発経験があり、幅広くWebシステムに携わってきました。」

職務要約の書き方の詳細はスキルシートの職務要約の書き方で解説しています。

決め打ち箇所2：直近1案件の見出し

直近案件のプロジェクト名・役割・使用技術を1行で読ませる見出しは、単価の初期見立てに直結します。以下の要素を圧縮します。

• プロジェクトの規模（利用者数・トラフィック・案件金額のいずれか）

• 自分の役割（フルスタック／技術リード／基盤設計 等）

• 使用技術のうち市場価値の高いもの3つ以内

決め打ち箇所3：スキル一覧の粒度

「Java」だけではなく、「Java（Spring Boot 3.x / Java 21）」のようにバージョンと主要フレームワークを添えると、直近性が伝わります。10年前のJava案件と直近のJava案件は評価が大きく異なります。

• 経験年数の書き方は「実務◯年（うち直近◯年は◯◯◯環境）」の形式が読みやすい

• 実務外で触った技術は「学習：」等の別ラベルで分離

決め打ち箇所4：資格・受賞・登壇

高単価帯では、このセクションが加点材料として見られることがあります。AWS認定・GCP認定・情報処理安全確保支援士などの資格、社内表彰・カンファレンス登壇・OSSコミット等は、事実として書ける範囲で列挙します。

ミニFAQ：決め打ち箇所

Q. 全案件で同じ情報密度で書く必要があるか？

A. 直近1〜2案件に情報を集中させ、それ以前は範囲型・継続性型で圧縮する構成が読みやすいです。全案件を均等に厚く書くと、直近の重要情報が薄まってしまいます。

単価が下がるアンチパターン

同じ経験でも、以下の書き方をしていると単価が下限側に張り付きやすくなります。1つでも該当しているなら、優先して修正します。

アンチパターン1：技術名の羅列だけ

「Java、PHP、Python、Ruby、Go、TypeScript、React、Vue.js、Angular、AWS、GCP、Docker、Kubernetes...」のように、技術名だけを大量に並べるパターンです。

• 何をどのレベルで使ったかが読めない

• 直近性が読めない（10年前のPHPと直近のGoが並列に見える）

• 独力範囲が読めない

修正するには、各技術に「実務◯年」「直近◯年で◯◯環境」「レビュー下◯年」などのラベルを添えます。

アンチパターン2：工程の羅列だけ

「要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・リリース・運用保守を担当」のような、フルサイクル書きです。

• 独力範囲がぼやける

• 「一貫して」の実態が読めない

• レビュー下と独力の区別がない

修正するには、独力担当した工程だけを列挙し、レビュー下の工程は別に注記します。

アンチパターン3：主語のない改善

「〜を改善」「〜を推進」「〜を実現」だけで終わり、何がどう変わったかがないパターンです。

• Before/Afterの差分がない

• 数字も定性も入らない

• 発注側の頭に金額換算が起きない

修正するには、型1（改善率型）か型2（絶対数型）で書き直します。

アンチパターン4：直近ほど薄い

古い案件だけ厚く、直近案件が1〜2行で終わっているパターンです。直近案件は単価判定の起点になるため、ここが薄いと単価は上がりません。

• 直近1案件は最低でもプロジェクト概要・担当工程・使用技術・成果の4点を書く

• 古い案件は範囲型で圧縮する（詳細は必要になったら面談で話す）

アンチパターン5：数字が全部「大幅に」

「大幅に改善」「大量のデータ」「多数のユーザー」で全部済ませているパターンです。

• サイズ形容詞は評価者の想像に依存するため、単価判定には使われない

• 数字が計測できていないなら、フォーミュラ1〜3で翻訳する

アンチパターンのチェックリスト

• ☐

  技術名の羅列だけになっていないか

• ☐

  工程の羅列だけになっていないか

• ☐

  「改善」「推進」の主語がないか

• ☐

  直近1案件が古い案件より薄くないか

• ☐

  「大幅」「大量」「多数」で数字が代替されていないか

• ☐

  独力範囲が「一貫」「幅広く」でぼやけていないか

セクション別・単価に効くBefore/After

抽象論より、実際の書き方の変化を見ると差が伝わります。以下は同じ案件を「単価が下がる書き方」と「単価が上がる書き方」で並べた例です。

案件概要のBefore/After

Before：

「大規模ECサイトのバックエンド開発を担当。Java、Spring Bootを使用し、新機能の実装とバグ修正を行った。」

After：

「月間PV500万・注文数月30万件規模のECサイトのAPI基盤を担当（バックエンド5名中1名）。決済・在庫のAPI新規実装と、注文処理のパフォーマンス改善を主担当。技術スタックはJava 21 / Spring Boot 3.x / PostgreSQL / AWS ECS。」

成果のBefore/After

Before：

「注文処理のパフォーマンスを改善した。」

After：

「注文処理のSQLボトルネックを特定し、クエリ最適化とRedisキャッシュ導入で平均応答時間を1.2秒→0.4秒に短縮。ピーク時のタイムアウト件数を月8件→0件に減らした。」

独力範囲のBefore/After

Before：

「上流〜下流まで一貫して担当。」

After：

「基本設計〜結合テストは独力で担当。要件定義はビジネスサイドとの合意形成にPMと同席する形で関与、リリース後の運用は運用チームに引き継ぎ。」

意思決定のBefore/After

Before：

「認証基盤の設計に関わった。」

After：

「認証基盤の技術選定でOAuth 2.0 / OpenID Connectを比較検討し、既存の認証サーバ資産を活かせるOIDC＋Keycloakを採用理由と合わせてPMに提案。設計書レビューを経て採用され、3ヶ月かけて実装まで担当。」

単価交渉との連動

スキルシートを書き直しても、単価交渉の場で使わなければ効果は限定的です。書き方と交渉の連動には型があります。

職務要約と希望単価を紐付ける

希望単価を提示するときは、「職務要約に書いた◯◯の経験があるので◯万円希望」と紐付けます。スキルシート内の記述にない要素で単価を主張しても説得力が薄いためです。

直近1案件の数字を交渉根拠にする

「直近案件で応答時間40%改善」「月間PV500万規模のシステムを独力担当」のように、スキルシート上の数字をそのまま交渉根拠に使います。事前に書いた情報だけで交渉する型のほうが、その場で口頭補足するより通りやすい傾向があります。

単価交渉の詳しい進め方

単価交渉のタイミングや伝え方は、単価交渉のコツ｜タイミング・伝え方・根拠の作り方にまとめています。スキルシート更新後の交渉フローもここで確認できます。

ミニFAQ：単価交渉との連動

Q. スキルシートを更新するタイミングは？

A. 案件終了時と、次の案件の面談前が最低ラインです。案件中でも大きな改善成果が出たタイミングで追記しておくと、次の交渉で数字がフレッシュな状態で使えます。

スキルシート改善の実践ステップ

書き直しは、以下の順序で進めると効率的です。

ステップ1：直近1案件を型1・型2で書き直す

まず直近1案件だけを対象に、改善率型か絶対数型で数字を入れます。全案件を一度に直そうとすると挫折しやすいため、直近から着手します。

ステップ2：職務要約に規模・独力範囲・直近スキルを圧縮

直近案件の書き直しが終わったら、その内容を圧縮して職務要約に反映します。冒頭3行の情報密度が最も単価判定に効きます。

ステップ3：アンチパターンチェック

前章のチェックリストで、技術名の羅列・工程の羅列・主語のない改善が残っていないか確認します。

ステップ4：単価診断で市場目安を確認

書き直しが終わったら、フリーランスエンジニア単価診断で現在のスキルセットの市場単価目安を確認します。書き直し前後で提示単価に差が出るかを見比べる材料になります。

ステップ5：次の案件面談で数字ベースで交渉

面談では、書き直したスキルシート上の数字と独力範囲を交渉根拠にします。

スキルシート改善のロードマップ

関連する既存記事との違い

本記事は「単価評価軸に絞ったスキルシートの書き方」に限定しています。以下の関連記事とあわせて読むと、書類選考通過から単価交渉までの流れが1本の線でつながります。

• 書類選考の通過を優先したい場合：実績が少ないフリーランスエンジニアでも通るスキルシートの書き方

• スキルシート全体の基本書式：フリーランスエンジニアのスキルシートの書き方を徹底解説

• 職務要約の冒頭3行の書き方：スキルシートの職務要約の書き方

• 単価交渉のタイミング・伝え方：単価交渉のコツ｜タイミング・伝え方・根拠の作り方

まとめ

スキルシートで単価を上げる書き方は、規模・影響・独力範囲の3軸を発注側が金額換算できる粒度で書くことに集約されます。技術名の羅列や工程の羅列では、同じ経験でも単価は下限に張り付きます。

• 直近1案件は改善率型・絶対数型で数字を入れる

• 職務要約に規模・独力範囲・直近スキルを3行で圧縮する

• 独力とレビュー下は工程名で分ける

• 単価レンジ別に押し出す軸を切り替える（独力範囲→数字→意思決定→事業KPI）

• 数字がないときはフォーミュラ1〜5で翻訳する

• アンチパターン5つのチェックリストを最後に必ず通す

書き直しが終わったら、フリーランスエンジニア単価診断で現在のスキルセットの市場単価目安を確認できます。単価交渉の進め方は単価交渉のコツ｜タイミング・伝え方・根拠の作り方、単価そのものの上げ方の総論は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方を併読すると、書類・交渉・市場相場の3方向から単価を体系的に整理できます。

市場全体の需給トレンドを確認したい場合は、本文主張の直接根拠ではなく補足資料として、経済産業省のデジタル人材の育成関連ページや独立行政法人IPAのデジタル人材の動向調査が参考になります。スキルシートに載せるスキル名の粒度・領域を、業界全体のスキル要件マップと照らして整えたい場合の外部指標として使えます。