Railsエンジニア転職の年収｜Go・TypeScriptを足す線引き

「Railsって、もう求人ないですよね。GoかTypeScriptに乗り換えるべきですか」——Railsエンジニアの方から、初回の面談でこう聞かれることが増えました。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、この質問の多くは「求人の数」と「評価される経験の質」を一緒くたにしたところから生まれています。今回は、Rails一本で年収を保てる条件と、二本目の言語を足す人・足さなくてよい人の線引きを、書類選考や面談で見られる点から整理してお伝えします。

目次

1. Railsエンジニアの転職は本当に厳しくなったのか
2. 海外の利用率を日本の求人に当てはめない
3. Rails一本で年収を保てている人の共通点
4. 「バージョンを上げた経験」は複雑さの証拠になる
5. スタートアップ・受託・保守案件で評価される経験の違い
6. 古いRailsの保守に閉じると伸びにくい理由
7. Go・TypeScriptを足すべき人と足さなくてよい人
8. TypeScriptを足したほうがいい人
9. Goを足したほうがいい人
10. どちらも足さなくてよい人
11. 実例: 転向せずRailsのまま書類通過率を上げたUさん
12. 経歴書に隠れていたバージョンアップ経験
13. 二本目の言語を足すときの進め方
14. 志望先がRailsを軸にしているかを見分ける方法
15. よくある質問
16. まとめ

Railsエンジニアの転職は本当に厳しくなったのか

最初にお断りしておくと、「Railsの求人が何割減った」と言える一次統計を、私は見つけられていません。ここから先は、統計ではなく現場で見ている感覚の話です。

Railsエンジニアを探している企業は、今も普通にあります。変わったのは、求人票の書かれ方です。以前は「Ruby on Rails経験3年以上」だけで済んでいた必須要件に、TypeScriptやReactの経験が併記されている求人を、このところよく見ます。つまり求人が消えたというより、Railsだけで完結する求人の比率が下がり、「Rails＋α」を求める求人が増えたと見るほうが、現場の感覚には近いです。

ちなみにRails自体の開発は止まっていません。公式ブログでは、2026年9月24日にRails 8.1.4と7.2.4（7.2系の最終リリース）が出ています。フレームワークが更新され続けている以上、「オワコン」という言葉は実態から離れています。

海外の利用率を日本の求人に当てはめない

「Goのほうが伸びている」という話の根拠として、Stack Overflowの開発者調査がよく引かれます。2025年版では、全回答者の利用率はTypeScriptが43.6%、Goが16.4%、Rubyが6.4%、WebフレームワークとしてのRuby on Railsが5.9%でした(出典：Stack Overflow Developer Survey 2025 Technology)。

ただしこれは世界中の開発者へのアンケートで、日本の求人動向ではありません。数字から読み取れるのは「TypeScriptの裾野が広い」という程度で、「自分が応募する国内の求人でRailsが不利になっている」とまでは言えません。この2つを混ぜて不安になっている方は、私の経験では少なくありません。

Rails一本で年収を保てている人の共通点

では、Rails一本でも年収が崩れない人は何が違うのか。年収の相場を一つだけ確認しておきます。人材会社のMorgan McKinleyの2026年版年収ガイド（事業法人・東京のRuby on Rails開発者）では、年収レンジは低が700万円、中が900万円、高が1,000万円とされています。ここでいう「高」は、実務経験が豊富でニッチなスキルも持ち、複雑なタスクを任せられる層、「低」は経験が浅い層という定義です(出典：Morgan McKinley 2026年版 年収ガイド)。

この定義が示しているのは、言語の名前より任せられるタスクの複雑さで年収が分かれる、ということです。1つの紹介会社の区分なので全体の相場と断定はできませんが、私が見ている実感ともずれていません。

「バージョンを上げた経験」は複雑さの証拠になる

Rails一本で書類が通る人の職務経歴書には、機能追加だけでなく、次のような経験が書かれています。

どれも「Railsが書ける」ではなく「Railsの運用で起きる問題を、順序立てて解いた」経験です。面接官が見たいのは言語のシンタックスではなく、そこです。逆に、scaffoldに近い画面追加を3年続けた経歴は、Railsの経験年数が長くても「低」の層として読まれます。

スタートアップ・受託・保守案件で評価される経験の違い

「Rails一本で十分か」の答えは、今いる環境で変わります。同じRails経験でも、環境ごとに評価の軸が違うからです。

自社サービス運営の企業が応募者に求めているのは、機能を作る手と、作った後に運用で直す判断の両方です。ここで「TypeScriptも書けますか」と聞かれやすいのは、Railsの画面側を一人で触る場面が多いからで、Railsの評価が低いからではありません。

受託は、言語よりも要件調整と見積もりの経験が効きます。保守案件については、客先常駐の運用保守で経験が止まる構造を別の記事で書いていますので、あわせてどうぞ（SES運用保守5年目から自社開発へ転職するときの書き方）。Rails保守に固有の話は、次のとおり「延命の質」に寄ります。

古いRailsの保守に閉じると伸びにくい理由

保守案件の中でも、古いバージョンのまま「動いているものを壊さない」ことだけが仕事になっている現場は、市場価値が伸びにくいと感じています。理由は単純で、職務経歴書に書ける成果が増えないからです。

同じ保守でも、延命のためにバージョンアップの計画を立てた、テストを足した、依存ライブラリの脆弱性対応を回した、と書ける現場なら話は別です。保守か新規かという区分より、判断を伴う仕事をどれだけやったかが見られます。

Go・TypeScriptを足すべき人と足さなくてよい人

ここからが本題の線引きです。私は「転向」ではなく「併走」で考えるよう勧めています。Railsを軸に残したまま、足したほうがいい人と、足さなくていい人がいます。

TypeScriptを足したほうがいい人

次のいずれかに当てはまる人は、TypeScript（とReact）を足すと、応募できる求人が実際に広がります。

こういう方は、書類で「Rails＋フロントを触れる人」として読まれるかどうかが分かれ目になります。深く極める必要はありません。業務で小さなコンポーネントを書いた、既存のTypeScriptコードにレビューを返した、といった実務の接点があるかが問われます。

学習の仕方については、独学だけでは評価が伸びにくい構造をjQueryからモダンフロントエンドへ移る年数の記事で書いています。実務に近づける手段を探す点は、Railsでも同じです。

Goを足したほうがいい人

Goは、バックエンドの性能や並行処理が事業の核になる企業で評価されます。Rails経験者がGoを足して評価されやすいのは、次のような場面です。

逆に、Goの求人はRailsより「Go経験者」を要求する傾向が強く、独学のみで応募すると経験不足で見送られやすい印象があります。まずはRailsの性能改善や、サービスの一部を別言語で書く経験を積み、それを職務経歴書に書ける形にしてから動くほうが安全です。

どちらも足さなくてよい人

相談の中で一番多いのは、実はこのタイプです。言語を足す前に、手元の経験がまだ十分に使えていないケースがとても多いからです。

ポイント： 足さなくてよいのは、「今の経験でRailsの運用上の判断を語れる人」と「志望先がRailsを軸にしている人」です。

具体的には、バージョンアップや性能改善の実績があり、志望先の求人票にRails中心の記載があるなら、二本目の言語を足す時間は、実績の書き方を磨くほうに回したほうが年収には効きます。「周りが皆Goを始めたから」という理由で足すのは、もっとも効果が薄い動機です。

実例: 転向せずRailsのまま書類通過率を上げたUさん

実際にあった例です。冒頭の質問をしてきたのは、26歳・経験3年のUさんでした。スタートアップのMVP開発を請ける小さな受託会社でRailsを書いていて、自社開発の企業に移りたいという相談です。

Uさんは「RailsよりGoかTypeScriptのほうが求人が多い」という記事を読み、Goの入門書を買っていました。ただ、職務経歴書を見せてもらうと、問題は言語ではないことがすぐに分かりました。書かれていたのは「Ruby on Railsによる新規機能開発・不具合修正」の一文だけです。

経歴書に隠れていたバージョンアップ経験

詳しく聞くと、Uさんは担当案件の一つで、Railsのバージョンを2つ上げた経験をしていました。テストがほとんどなかったため、重要な画面の動作確認を先に自動化してから上げたそうです。また、一覧画面が遅いという相談を受け、N+1を潰して表示を数倍速くした経験もありました。

これをそのまま書けば「複雑なタスクを任せられる人」として読まれる内容です。本人は「当たり前のことをしただけ」と思っていたため、経歴書に出ていませんでした。

そこで、Goの学習は一度止めました。バージョンアップの手順とテスト補強の判断、N+1の調査から改善までの経緯を、職務経歴書に書き直してもらいました。あわせて、求人票でTypeScriptが歓迎要件に載っていた会社については、Uさんが過去の案件でReactの小さな修正を数回やっていたことも、正直に「範囲を限定して」書き添えています。

書き直したあと、10社に応募して書類通過は4社、2社から内定が出ました。年収は現職より約40万円上がっています。Goを足さずにこの結果になったのは、Uさんがすでに「判断を伴う経験」を持っていて、それが経歴書に出ていなかっただけだからです。

ただし、これはUさんの経歴がたまたま噛み合った例で、誰でも同じ結果になるとは言えません。バージョンアップや性能改善の経験がない方は、先にその機会を探すほうが先です。

二本目の言語を足すときの進め方

足すと決めた場合も、進め方で結果が変わります。

2つ同時に始めて、どちらも中途半端なまま応募するという失敗を、私は何度も見てきました。学習に使う時間は有限ですので、先に求人票の側から、足すべき言語を決めるのが確実です。

「実務で触れた範囲」と「独学の範囲」を分けて書くことには、もう一つ意味があります。独学を実務のように見せると、面接で深掘りされたときに答えに詰まるからです。転向にかかる年数の考え方はCOBOLからの転向でも同じ構造で、COBOL・VB6のモダン言語転向にかかる年数の記事でも触れています。

志望先がRailsを軸にしているかを見分ける方法

求人票だけでは、その会社が今後もRailsを軸にするのかは分かりません。面談では次の2点を聞いてみてください。

Railsの外へ新規機能を出していく方針の会社では、Goなどの経験が後から必要になります。反対に、バージョンアップを定期的に回している会社は、Railsの運用を重視していると見てよいです。技術発信やコミュニティへの関与も手がかりになり、カンファレンスのスポンサー状況から技術文化を見る方法も参考になります。

よくある質問

Railsエンジニアは今から未経験で目指しても遅いですか。 未経験からの入口は、言語の選択より「実務に近い経験を得られる環境」に入れるかどうかで決まります。Railsだけに絞るより、TypeScriptも触れる自社開発・受託のジュニア枠を並べて探すほうが、現実的な選択肢は広がります。

Rails一本のままで年収900万円以上は狙えますか。 年収ガイドの区分でいえば、中の900万円や高の1,000万円は、複雑なタスクを任せられる層です。言語を増やすより、バージョンアップや設計の見直しといった判断を伴う経験を、職務経歴書に書ける形で積むことが条件になります。

RailsからGoに完全に転向したほうがいいですか。 私は併走を勧めています。Goの求人はGo経験者を求める傾向があり、転向してゼロから積み直すと年収が下がる場合があります。Railsの実績を残したまま、性能が要る領域で足すほうが安全です。

保守案件にいてバージョンアップの機会がありません。どうすればいいですか。 自分から計画を提案するのが先です。依存ライブラリの更新や、テストの後付けなど、小さな単位でも構いません。それが通らない環境なら、機会のある現場へ移ることも選択肢に入ります。

まとめ

「Railsは求人が減った」という声は、数の問題というより、Railsだけで完結する求人が減り、「Rails＋α」で評価される比率が上がったという変化として受け止めるのが、現場の感覚に近いと私は考えています。

Rails一本で年収を保てるかどうかは、言語の数ではなく、バージョンアップや性能改善のような「判断を伴う経験」を持っていて、それを職務経歴書に書けているかで決まります。そのうえで、志望先の求人票がTypeScriptやGoを求めているなら、1つだけ、実務に近い形で足せばいい。この順番を間違えないことが、この記事で一番伝えたかったことです。