フロントエンドもバックエンドも担当している。それでも「今の単価は妥当なのか」「次はどこを伸ばせば条件の良い案件を狙いやすくなるのか」が見えにくいことはありませんか。
フルスタック案件は、使える技術の数だけで単価が決まるわけではありません。実装だけを担当するのか、DB設計やクラウド、CI/CD、技術選定まで持つのかによって、求められる責任範囲は変わります。
この記事では、特定の金額を相場として断定するのではなく、フルスタック案件の単価を判断するときに何を見るべきかを整理します。掲載媒体や時期によって案件条件は変わるため、金額だけでなく「何を任される案件なのか」まで一緒に確認していきましょう。
フルスタックの単価は「職種名」だけでは決まらない
同じ「フルスタックエンジニア」という募集でも、担当工程や稼働条件は案件ごとに異なります。単価を見るときは、平均値だけを基準にするより、自分が担当する範囲と契約条件をそろえて比較することが大切です。
| 見るポイント | 確認したい内容 |
|---|---|
| 担当工程 | 実装中心か、設計・技術選定・運用まで担当するか |
| 責任範囲 | フロント、バックエンド、DB、クラウドのどこまで判断を持つか |
| 稼働条件 | 稼働日数、勤務時間、常駐・リモートなどの条件 |
| 商流・体制 | 顧客との距離、チーム人数、レビュー体制、意思決定の範囲 |
| 契約条件 | 契約期間、更新条件、緊急対応の有無など |
相場感を確認したい場合も、条件の異なる案件を一括りにせず、自分と近い担当範囲・稼働条件の募集を複数比較すると判断しやすくなります。
単価差を分けやすいのは技術数より責任範囲
フルスタックという名前でも、仕事の深さはかなり違います。画面とAPIを実装する役割もあれば、DB設計、クラウド、CI/CD、監視、技術選定まで一つの機能やサービスを横断して持つ役割もあります。
| 担当イメージ | 仕事として問われやすいこと | 確認したい責任範囲 |
|---|---|---|
| フロント＋API | 画面実装、API実装、既存設計に沿った開発 | 仕様どおりに実装する範囲か、設計判断まで含むか |
| ＋DB設計 | テーブル設計、データモデル、API境界の判断 | データ構造や性能をどこまで自分で決めるか |
| ＋DevOps / IaC | クラウド、CI/CD、Terraform、監視、リリース | 本番反映や運用改善まで継続して担当するか |
たとえばReactとNode.jsを扱えても、決められた仕様を実装する役割と、API・DB・クラウド構成まで設計する役割では、同じ「フルスタック」でも任される仕事が異なります。
単価を比較するときは、技術名の数だけではなく「どの判断まで自分が持つのか」を確認すると、案件同士を比べやすくなります。
案件では複数領域をどう横断するかを見る
フルスタック案件では、フロントエンド、バックエンド、データベース、クラウド、開発基盤など複数領域をまたぐことがあります。募集要項では、React / Next.js、Node.js、Python、RDB、AWS / GCP、Docker、CI/CDなどが組み合わされるケースもあります。
ここで大切なのは、すべてを同じ深さで扱えることではありません。「横断できる領域」と「深く責任を持てる領域」を分けて考えると、自分の強みを説明しやすくなります。
- フロント： React / Next.jsなどでUIから状態管理まで追える
- バックエンド： API設計、認証、業務ロジックを担当できる
- データ： RDB設計やクエリ、データモデルの判断ができる
- クラウド： AWS / GCPでデプロイや運用まで追える
- 開発基盤： Docker、CI/CD、IaCで変更を再現可能にできる
「全部触れます」より、「バックエンドを軸に、フロントとAWSまで一つの変更として完結できます」のほうが、任せられる仕事を具体的に伝えられます。
担当範囲を広げる3つの方向
APIとDBの「設計判断」を持つ
実装経験が中心なら、次に伸ばしやすいのは設計です。APIの責任範囲、データモデル、トランザクション、エラー設計まで説明できると、単にコードを書く役割から「機能を任せられる役割」へ担当範囲を広げやすくなります。
AWSとCI/CDをリリース後まで追う
アプリを作れても、本番へ安全に出して運用するところで担当が切れるケースがあります。AWS、Docker、CI/CD、Terraformなどを使い、デプロイ・監視・障害切り分けまで追えると、フルスタックとして説明できる範囲が広がります。
技術選定を理由とセットで話す
より広い責任範囲を求める案件では、複数領域の経験だけでなく、アーキテクチャ設計、パフォーマンス改善、技術選定、チーム内の意思決定などが求められることがあります。
「Next.jsを使いました」だけで終わらず、要件、候補、採用理由、運用上の注意まで話せると、技術選定にどこまで関与したのかが見えます。
スキルシートは技術名より担当範囲を書く
フルスタックをアピールするとき、技術スタックだけを並べると「全部少し触った人」に見えることがあります。
伝わりにくい例
React、TypeScript、Node.js、PostgreSQL、AWS、Dockerを使用。フロントからバックエンドまで担当。
責任範囲が見える例
React / TypeScriptの画面開発からNode.js API、PostgreSQLのテーブル設計まで担当。既存AWS環境へのデプロイ経路を整理し、CI/CDの修正とリリース後のログ確認まで対応。
これは書き方の例です。実際に担当していない設計や運用を足してはいけません。「何を実装したか」に加えて、「何を判断したか」「どこまで引き渡したか」を書くと経験の深さが伝わりやすくなります。
面談では6項目を確認して単価を読む
同じ提示単価でも、役割が違えば負荷も得られる経験も変わります。面談では募集要項だけで判断せず、次の6項目を確認してみてください。
- フロントとバックエンドの担当比率はどの程度か
- API・DB設計を自分で判断する範囲はどこまでか
- AWS / GCP、CI/CD、監視・障害対応まで担当するか
- 技術選定やアーキテクチャ変更に関与するか
- チーム人数、レビュー相手、テックリードの有無はどうか
- 稼働日数、リモート条件、緊急対応など契約条件はどうか
この質問で担当範囲が具体化できれば、提示単価が自分の経験や責任範囲と釣り合っているかを判断しやすくなります。
単価が高くても「一人で全部」は確認が必要
「フルスタックだから全部お願いします」という案件は、一見すると経験を広げやすそうです。ただし、担当範囲が曖昧なままでは、開発・インフラ・運用・問い合わせ対応まで際限なく広がる可能性があります。
提示単価だけを見るのではなく、優先順位を誰が決めるのか、レビュー相手がいるのか、障害対応の時間帯はどうか、テストやリファクタリングの時間を確保できるかまで確認したいところです。
フルスタックの価値は、一人で抱えることではありません。複数領域をつなぎ、必要な判断を前へ進められることにあります。
単価アップを目指すなら「一つ深く持てる領域」を作る
フルスタックエンジニアの単価を見るときは、金額だけでなく、設計・DB・クラウド・DevOps・技術選定のどこまで責任を持つ案件かを確認します。
すべての領域を同時に深める必要はありません。バックエンド設計、AWS運用、IaCなど、自分の軸を一つ深くし、その前後をつなげられる状態を作るほうが経験を説明しやすくなります。
具体的な相場を確認するときは、掲載時点、稼働条件、商流、担当工程などが近い案件を複数見比べ、自分の条件に近い募集を基準にしてください。
まずは直近のスキルシートを1案件だけ開き、技術名の羅列を「担当工程・判断したこと・運用までの範囲」に書き換えてみてください。次に狙う案件で足りない経験が、見えやすくなるはずです。
