バックエンドからフルスタックへ、広げる転職は本当に得なのか

バックエンド専任からフルスタックへ守備範囲を広げようか迷っている人が、まず計算するのはたいてい「応募できる求人の数」だ。フロントエンドもできれば、バックエンドだけの求人にもフルスタックの求人にも応募できる。足し算で考えれば、選択肢は確実に増える。だから広げるのは得だ、という結論にすぐ着地してしまう。

だがその「増えた母集団」の正体を見ないまま広げると、単価はむしろ下がる方向に動くことがある。

増えた求人の多くは「安く一人で回したい」層

フルスタックを募集する求人が多いのは、エンタープライズでバックエンドとフロントエンドを分業できる体制が整っている会社ではない。むしろ分業する余裕がない小規模な会社やチームだ。フロントエンドの専門家とバックエンドの専門家を別々に雇う予算がないから、一人に両方を頼みたい。この手の求人が持つ予算感は、バックエンドの深い設計力に対する評価ではなく、「とりあえず一人で全部動かせる人」への相場で組まれていることが多い。求人票を読むと見分けがつく。「少人数チームで幅広く」「一気通貫で」「裁量大きく何でも」といった言葉が主役になっている募集は、専門性の深さより、担当範囲の広さと手の速さを買おうとしている合図であることが多い。

つまりフルスタックを名乗った瞬間に応募できる求人の数は増えるが、その増分の中心は、専門性への対価ではなく、人員不足を一人で埋める便利さへの対価を払おうとしている求人になる。母集団が増えることと、その母集団の単価が高いことは、まったく別の話だ。広い網を投げれば魚は増えるが、増えた魚の多くは小粒だということに注意がいる。

さらに採用側の視点に立つと、守備範囲を広げることは「この人は何の専門家か」という問いへの答えを曖昧にする。バックエンドのアーキテクチャ設計で評価されたいポジションに、フロントエンドもできますと添えて出しても、採用担当者が見るのは「設計が強い人」ではなく「色々できる人」という印象になりやすい。専門性の濃さで評価される枠では、広さはむしろノイズになる。

広さは深さに掛け算されて初めて効く

ここで分岐が生まれる。今の自分がバックエンドの深さで既に戦えているかどうかだ。

データベース設計の選択理由を説明できる、負荷が増えたときにどこがボトルネックになるか見立てられる、チームの設計判断に意見を言える。こうした深さを既に持っている人がフロントエンドの知識を足すと、見え方は「フルスタックという名の便利屋」ではなく、「画面側の制約まで理解して設計できるバックエンドエンジニア」になる。API の形をフロントエンドの都合に合わせて最初から正しく設計できる、UIの要件が変わったときにバックエンドへの影響を即座に見積もれる。これは深さの上に広さを乗せた人にしか出せない価値で、単価は上がる方向に働きやすい。

一方、CRUD の API を書く段階で止まっている人が広さを足すと、評価の軸が「深さ」から「広さ」に移動してしまう。移動した先の「広さ」の市場は、前段で見た「一人で安く回したい」求人がひしめく場所だ。深さで戦えていない状態で広げるのは、評価されやすい土俵から評価されにくい土俵に自分から移動することに近い。器用貧乏という言葉がしっくり来てしまうのは、だいたいこのパターンだ。

つまり広げる前に確認すべきことは、応募できる求人の数ではなく、今のバックエンドの深さが単体で評価される水準にあるかどうかだ。設計の理由を言葉で説明できないなら、広げるより先に深さを詰める方が単価の天井を上げる。すでに説明できるなら、フロントエンドの知識を足すことは防御ではなく武器になる。

広げる前に、今の深さを求人側の言葉で確かめる

自分の深さが足りているかどうかの一番手早い確認方法は、実際の求人票を読むことだ。バックエンド専任の求人がどこまでの設計経験を前提にしているか、フロントエンドの求人がどこまでの実装範囲を求めているかを見比べると、自分が今どちらの土俵で戦える段階にいるかが見えてくる。広げる判断は、応募できる数の足し算ではなく、今いる土俵で既に評価されているかどうかの確認から始めた方がいい。

https://s-tasklog.com/jobs/for/backend

https://s-tasklog.com/jobs/for/frontend

たすくろぐは、求人票や学習データを横断して比べられるサイトで、バックエンドとフロントエンドそれぞれの求人がどこまでの深さや範囲を求めているかを見比べる材料にも使える。