エンジニア市場価値の診断5ステップ｜スキル・実績・単価の見立て方

エンジニアの市場価値を診断するとは｜5軸で自分の位置を見立てる

エンジニアの市場価値は、単価という一つの数字ではなく複数の軸の組み合わせで決まります。単価は結果として現れる数字であり、その手前にスキルの厚み・実績の重さ・案件需要の量・市場からの提示という4つの要素が積み重なっています。

診断とは、この4要素と単価という最終指標の5軸を一つずつ点検して、自分の位置を推定する作業です。診断は「良い／悪い」を決める試験ではなく、次の一手を決めるための地図づくりに近いものです。

なぜ単価だけでは測れないのか

単価は同じスキルセットでも、契約形態（準委任・請負）、稼働日数、業界、商流の深さで数十万円単位で変動します。ある案件で月額80万円だった人が、別の案件では60万円で提示されるケースは珍しくありません。

つまり、単価という結果だけを見ると自分の実力を過大にも過小にも見積もりやすくなります。単価の裏側にあるスキル・実績・需要を先に整理してから、単価の位置を判定するほうが誤差が小さくなります。

診断で使う5つの評価軸

以下の5軸で自分を書き出していきます。この順番で回すと、自己評価と市場評価のズレが浮かび上がります。

自己評価と市場評価がズレる理由

自己評価は現職の評価軸（社内の期待値）で作られる一方、市場評価は求人票と単価表の要件で作られます。両者は重なる部分もありますが、求められる粒度や表現が異なるため、そのまま比較するとズレます。

たとえば社内で「上流もやっている」と評価されていても、求人票で求められる「要件定義・非機能要件の折衝・体制設計」まで一人でこなしているかは別の話です。診断の目的は、この違いを言語で埋めていくことにあります。

ミニFAQ

• Q. 5軸のうち、どれから手をつけるべき？　A. 順序どおりSTEP1のスキル棚卸しから着手します。スキルの粒度が粗いままだと、STEP2〜5すべての解像度が下がります。何年目から使えるかは末尾FAQで扱います。

STEP1｜スキルの棚卸し

スキル棚卸しは市場価値診断の土台です。ここで書き出す粒度が、あとのSTEP2〜4の判定精度を左右します。

結論として、書き出す観点は「技術スタック」「担当工程」「役割」の3つです。年数を機械的に足し上げるのではなく、実際に手を動かしたか（見ていただけか）を区別して書きます。

技術スタックの整理（言語・FW・クラウド）

以下の要素で自分の技術を整理します。項目ごとに「実務何か月・実装レベル・保守レベル」まで書き分けると、後で求人票と照合しやすくなります。

• 言語：Java／Go／TypeScript／Python など。各言語で書いた実行環境（バッチ・API・SPA）も添える

• フレームワーク：Spring／Rails／Next.js／Django など。バージョンと利用範囲を添える

• クラウド／インフラ：AWS／GCP／Azure。使ったマネージドサービス名を並べる

• データ基盤：MySQL／PostgreSQL／BigQuery／Snowflake など

• 周辺ツール：Git／CI/CD／Terraform／Docker／Kubernetes

書き出しの詳しい書式は、フリーランスエンジニアのスキルシートの書き方を参照してください。棚卸しはそのままスキルシートの下書きにもなります。

担当工程の可視化（要件→設計→実装→運用）

公開案件の募集要件を見ると、エンジニアの単価は担当できる工程の広さでレンジが変わる傾向があります。要件定義や非機能設計まで担当できると、上位レンジの案件で募集されるケースが増えます。

工程は次のように分解して、「主担当」「補助」「未経験」の3段階で書き出します。

• 要件定義／要求整理

• 基本設計／外部設計

• 詳細設計／内部設計

• 実装／単体テスト

• 結合テスト／総合テスト

• リリース／運用／障害対応

「実装だけできる」状態と「要件定義から入れる」状態では、市場からの見え方がかなり違ってきます。

役割の言語化（メンバー／リード／管理）

担当した役割も市場価値に大きく響きます。以下の粒度で棚卸しします。

• メンバー：割り振られたタスクを実装する立場

• サブリード：チーム内の技術判断を一部担う

• テックリード：技術方針・レビュー方針を設計する

• プロジェクトリード：進捗・見積・人員配置まで見る

• マネジメント：採用・評価・育成まで担う

一人で複数の役割を兼務した経験がある場合、それぞれ分けて書きます。役割の広さは、STEP4で単価レンジのあてはめに使う情報になります。

STEP2｜実績の定量化

スキルを書き出したら、次は実績を数字にします。「頑張った」ではなく「何をどれだけ動かしたか」が実績の情報量です。

結論として、実績は「規模」「成果」「体制」の3つの数字で書き出します。数字を出せないものは、代わりに条件（対象・期間・制約）で具体化します。

案件規模の数字化

規模は以下のような数字で書きます。1つの案件について複数の側面から書けると理想的です。

• ユーザー数／MAU

• リクエスト数／ピーク秒間トラフィック

• レコード数／データ量（TB単位）

• 売上規模／取扱高

• サービス数／マイクロサービスの分割数

• 契約社数／導入拠点数

守秘義務にかかる案件は、桁を残して具体値をぼかす形（例：「MAU数百万」）にすると、実績の重さを伝えつつ機密を守れます。

成果の言語化（KPI・工数削減・障害対応）

数字で示せる成果があれば、それを主軸に書きます。目安として以下のような書き方が有効です。

• リリース回数：「デプロイ頻度を週1回→日次に短縮」

• 工数：「バッチ実行時間を6時間→30分に短縮」

• 品質：「本番障害を月10件→2件以下に削減」

• 売上：「A/Bテスト運用改善で申込率+10%」

• 開発生産性：「PRリードタイムを平均7日→2日」

数字が取れない案件では、成果の代わりに難易度の条件（規制対応・移行案件・レガシー刷新など）を添えるとよいでしょう。

体制の書き方（チーム人数・担当範囲）

同じ案件でも、体制が違えば求められた技量は変わります。以下を書き添えます。

• チーム総人数（開発／PM／QA／デザインを分けて記載）

• 自分の担当範囲（サービス全体か、特定モジュールか）

• レポートライン（誰にレビューを受けたか）

• 外部ステークホルダーの有無（クライアント直折衝の有無）

体制が薄い（1〜2人体制）ケースでは、逆に「一人で回した幅」を示せます。体制が厚い（10人以上）ケースでは、自分の担当した領域と関与の深さを明示します。

STEP3｜需要の観測

STEP1・2で自分の情報を整理したら、次は市場側を観測します。「自分に近いスキルセットの案件がどれくらい世の中にあるか」を測るステップです。

結論として、需要は首都圏中心の主要フリーランスエージェント3〜5社程度の公開案件件数と、政府統計・一次情報の需給データの2つで観測します。片方だけだと偏るため、両方を突き合わせます。

主要エージェントの公開案件で件数を数える

首都圏中心のフリーランスエージェント3〜5社の公開案件を横断的に確認し、自分のスキルセットに近い案件が何件出ているかを目視で数えます。目安の観測手順は次のとおりです。

• 対象条件：週4〜5日・準委任・首都圏（フルリモート含む）

• 検索軸：主要言語＋フレームワーク（例：Java+Spring／TypeScript+Next.js）

• 追加条件：業界・稼働形態・単価下限で絞ってヒット数を比較

件数の絶対値ではなく、自分のスキルセットと近い案件の相対的な多さを掴むのが目的です。「Java+Springの週4〜5日案件は多いが、Java+Springバッチ運用に限ると急に減る」といった感度が見えます。

業界別・技術別の需要トレンドを一次情報で確認する

エージェントの観測だけでは、業界の底にある需給がわかりにくいため、以下のような一次情報でも裏取りします。

• 経済産業省 IT人材需給に関する調査：中長期の人材需給

• 厚生労働省 職業情報提供サイト（jobtag）：職種別の求人動向と年収

• IPA DX動向調査：企業側のDX投資動向

一次情報の数字は年次で切り替わるため、公開時点で入手可能な最新版を確認して引用します。二次情報の孫引きは避け、必ず一次発表元にたどります。

自分と近いスキルセットの求人抽出

需要観測では「マクロの需要」と「自分の座標に近い需要」を分けて見ます。マクロが高くても、自分のスキル位置に対する募集がなければ市場価値は上がりにくいためです。

• マクロ需要：「クラウド系全般」「フロントエンド全般」レベルの募集件数

• ミクロ需要：「AWS＋Lambda＋Node.jsのサーバレス設計経験」レベルまで絞った募集件数

ミクロで継続的に複数件〜数十件見つかるなら、自分の位置に対する市場需要が一定あると判断できる目安になります。数件しか出ない場合は、STEP1で並んだスキルの組み合わせ方を変えて再検索するのが有効です。

ミニFAQ

• Q. 公開案件だけを見ればいい？　A. 公開案件で観測できるのは市場の一部です。非公開案件は個別性が強く再現性が低いため、まずは公開案件ベースで需給を掴み、面談段階で非公開の提示が来たら別枠で扱います。

STEP4｜単価レンジのあてはめ

需要を観測できたら、単価レンジと自分の実績を照合します。このステップは「要件マップ」を使う作業で、要件マップ自体は既存記事に整理されているため、ここではあてはめの手順に絞ります。

結論として、週4〜5日・準委任案件を中心にした目安として、単価レンジは月60万／80万／100万超の3段階で見ます。各レンジで求められる要件は、単価レンジ別スキル要件（60・80・100万の壁）に整理されているため、そちらを参照しながら自分の実績と重ね合わせます。

レンジと自分の実績を比較する

STEP1・2で整理した自分の情報を、単価レンジ記事のチェックリスト（各レンジ5項目・計15項目）に当てはめます。あくまでセルフ診断上の目安として、あてはめの結果は次の3パターンに分かれる傾向があります。

• 上位レンジの要件を過半数満たしている：そのレンジで通用する可能性がある

• 上位レンジの要件を1〜2項目のみ満たしている：直下のレンジが実力の中心と見立てられる

• 複数レンジの要件がまだらに埋まっている：役割の広がりに対して実績の裏付けが薄い可能性がある

まだらに埋まっているケースでは、実績の言語化（STEP2）を強化するだけで一段上のレンジに届く場合があります。

「壁」に足りていないものを言語化する

診断の目的は今の位置を知ることだけではなく、次のレンジに行くために何が足りないかを言語化することです。単価が上がらない典型パターンは、フリーランスエンジニアの単価が上がらない8つの原因に整理されています。自分の状況が8パターンのどれに当てはまるかを見ておくと、改善策の絞り込みが早まります。

自分がどの単価を狙えるかの目安を早く知りたい場合は、無料のフリーランスエンジニア単価診断で当たりをつけられます。診断結果は面談での提示と併せて解釈するのが安全です。

ミニFAQ

• Q. レンジ別要件を全部満たしていないと上のレンジに行けませんか？　A. 全項目ではなく過半数が目安です。要件は「これが揃うと上のレンジで話が進みやすい」という中央値の指標で、案件・企業ごとの重み付けは異なります。

STEP5｜市場からの提示を得る

自己評価が終わったら、最後に市場側から数字を出してもらうフェーズに入ります。自己評価と市場評価は必ずズレるため、この実測で診断の精度が決まります。

結論として、実測はエージェント面談3社以上と単価診断ツールの2ルートで行います。案件領域の偏りをならすため面談は3社以上が目安で、1社の面談だけで判断すると、その会社の得意領域や紹介先の商流に引っ張られた数字になりがちです。

3社以上のエージェント面談で提示単価を集める

エージェントに登録して面談を受けると、公開案件では見えない提示単価の情報が得られます。準備の要点は次のとおりです。

• 職務経歴書とスキルシートを事前に整えておく（STEP1・2の棚卸し結果をそのまま使う）

• 希望条件（稼働日数・稼働時間帯・業界・技術）を先に伝える

• 面談時に「私の経歴で通りやすい単価レンジは？」を直接聞く

面談の進め方の具体は、フリーランスエージェントとの面談の内容と必要な準備や面談で聞かれる質問と回答例を参考にできます。逆質問の型を持っておくと、単価だけでなく案件の裏側までヒアリングできます。

単価診断ツールで数値の当たりをつける

エージェント面談の前に、フリーランスエンジニア単価診断などのツールで数値のあたりをつけておくと、面談時の期待値調整がしやすくなります。診断ツールの数字は入力データに依存するため、STEP1・2で整理した情報を正確に反映することが大事です。

診断ツールの結果は、面談で得られる提示単価とセットで解釈します。両者が近ければ市場評価と自己評価が揃っている状態、大きく離れていればスキル・実績の見せ方（言語化）に伸びしろがあるサインです。

提示単価と自己評価のギャップ分析

3社以上から提示単価を集めたら、以下の観点でギャップを整理します。

• 中央値：3社の提示のどこが中心か

• 最大値と最小値の差：極端に離れている場合、案件領域が違っている

• 案件条件との連動：稼働日数・業界で単価が変わるか、変わらないか

• 自分の希望との差：希望単価に届いているか、届いていないか

ギャップが大きいときは、要因を「スキル軸」「実績軸」「見せ方軸」の3つに分けて切り分けます。単価そのものを追いかける前に、単価交渉のコツなどで交渉の型を確認しておくと、実測結果を次の契約に反映しやすくなります。

ケース別｜3タイプの診断シナリオ

診断は「型」だけでは動きにくいため、ここでは代表的な3ケースで診断の流れをたどります。数字は首都圏中心の主要フリーランスエージェント3〜5社の公開案件と、面談時に提示される非公開案件の傾向をもとにした目安（週4〜5日準委任案件を中心に見た数字）で、実務経験3年以上を想定しています。個別の条件（業界・稼働形態・商流）で変動するため、あくまで参考値として扱ってください。

ケースA｜経験3年目・Web系Webエンジニア

プロフィール：Ruby on Rails中心、フロントはVue.js、AWSは触れる程度。自社サービスで機能開発を担当。

診断結果の傾向：

• スキル：言語＋FWは実装レベル、クラウドは補助レベル

• 実績：MAU10万以下のサービスで機能開発の複数実績

• 需要：公開案件ベースでは、Rails単体よりReact／Vue＋Node.jsまで含む募集のほうが見つかりやすい傾向

• 単価：月60〜75万円のレンジで提示されるケースが中心

• 提示：面談3社中2社が60万台、1社が70万台

STEP4のあてはめでは、上位レンジ（80万）の要件は1〜2項目のみ該当。次の一手として、上流工程の担当か、クラウド側（AWS Lambdaや設計）の実務経験を1案件重ねるのが効きやすいパターンです。

ケースB｜独立2年目・単価停滞中のフルスタック

プロフィール：独立2年目、月額70万円で1年半継続中。TypeScript＋React、Node.jsバックエンド、AWSの実装経験あり。

診断結果の傾向：

• スキル：フロント／バック／クラウドをまたぐ幅がある

• 実績：継続案件が長く、単一クライアントに偏る

• 需要：需要は十分。マクロもミクロも公開案件が数十件出る

• 単価：レンジ的には80万〜90万に届く要件を満たしている

• 提示：他社面談で80万円台の提示が複数

このケースは「単価が上がらない8原因」のうち「交渉タイミング逸失」や「市場相場認識の齟齬」に該当しやすいパターンです。診断結果は市場提示のほうが自己評価より高い状態のため、更新交渉か案件移動が次の一手になります。

ケースC｜40代・技術リード

プロフィール：40代前半、金融系Java＋Springの経験15年、直近5年はテックリードでコードレビュー・アーキ設計・チームビルディングを兼務。

診断結果の傾向：

• スキル：言語・工程・役割の3つとも上位レンジ

• 実績：MAU数百万規模／体制20名以上の案件を複数経験

• 需要：金融×Java×リードは公開案件が細いが、非公開で高単価案件が回る領域

• 単価：金融系の長期経験に加え、要件定義・技術リード・対人折衝まで担える人材を想定した目安として、月100万〜130万円のレンジで提示されるケースがある

• 提示：面談3社中2社が100万円超、1社が90万円台

このケースでは、公開案件だけを見ると需要が薄く見えるため、STEP5の面談ルートに時間を割くのが効きます。40代の独立事情は40代フリーランスエンジニアになるにはにも整理があります。

よくある失敗と対策

診断は手順を踏んだつもりでも、いくつかの典型的な落とし穴があります。

平均相場だけを見て自分の位置を誤解する

平均や中央値の相場だけを見ると、自分の位置がぼやけます。相場を体系的に確認したい場合は、フリーランスエンジニアの単価相場と単価の上げ方で単価の考え方を整理しつつ、レンジ別要件の当てはめ（STEP4）と組み合わせるのが有効です。

一社の面談結果だけで市場提示と決めつける

面談は最低3社が目安です。1社の提示だけで自分の市場価値と決めるのは、母集団が小さすぎます。エージェントごとに扱う案件領域や商流が違うため、複数社の結果の中央値で判断するほうが安全です。

自己申告のスキル項目が募集要件と噛み合わない

「Reactが書ける」と自己申告しても、募集要件が「Next.js＋TypeScript＋SSR運用」のように具体的な場合、要件との一致度が採用側から見えにくくなります。スキルは要件と同じ粒度で書き出すのが対策です。

過去実績の言語化が薄く体験談で終わる

「Webサービスの機能改善を担当しました」で止まると、市場価値は伝わりません。数字（規模・成果）を必ず1つ以上添える形にします。STEP2の3項目（規模・成果・体制）はどれか1つでも書ければ体験談ラインを越えられます。

単価レンジの壁を経験年数だけで語ってしまう

「◯年やれば◯万円」といった経験年数だけの言い方は、あてはめ精度が低い方法です。年数ではなく担当工程と役割の広さで判定するほうが実態に近い結果になります。

数値目標を立てず「もっと」で止まる

診断で終わらせずに、次のアクションを数字で決めます。「3か月以内に上流工程の案件を1本経験する」「6か月以内に単価+10万を目指す」のように、期間と数字を具体化するのが有効です。

まとめ

エンジニアの市場価値診断は、単価だけを見るのをやめて5軸で自分の位置を見立てる作業です。STEP1〜STEP4で自己評価を積み、STEP5で市場からの実測を得ることで、自己評価と市場評価のズレを埋められます。

診断で得た位置は固定ではなく、動かせるものです。特に単価に近い軸ほど、伸ばす軸を1つに絞って3〜6か月単位で回すと、次の診断で位置が変わります。診断を受けたら、必ず「次のアクションを1つ数字で決める」ところまでを1セットにしてください。

セルフ診断10問チェックリスト

• スキル棚卸しを技術・工程・役割の3軸で書き出したか

• 実績を「規模・成果・体制」の数字で書けているか

• 公開案件で自分のスキルセットに近い案件を数えたか

• マクロ需要とミクロ需要を分けて確認したか

• レンジ別要件（60／80／100万）と自分の実績を照合したか

• 一次情報（経産省・厚労省）で需給トレンドを裏取りしたか

• エージェント3社以上に登録して面談を受けたか

• 単価診断ツールで数値の当たりをつけたか

• 面談での提示単価と自己評価のギャップを言語化したか

• 次の3〜6か月で伸ばす軸を1つに絞ったか

まずはSTEP1〜5で自己診断の型を作った上で、単価診断ツールを補助的に使うと精度が上がります。自分がどの単価レンジで通用するかの当たりをつけたい場合は、無料のフリーランスエンジニア単価診断を使うと早いです。診断結果はエージェント面談の準備資料としても使えます。

参照元・関連リンク

• フリーランスエンジニアの単価相場と単価の上げ方

• 単価レンジ別スキル要件（60・80・100万の壁）

• 単価が上がらない8つの原因と改善策

• フリーランス独立の判断チェックリスト

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

• フリーランスエージェントとの面談の内容と必要な準備

• 経済産業省 IT人材需給に関する調査

• 厚生労働省 職業情報提供サイト（jobtag）

• IPA DX動向調査