インフラエンジニアからアプリ開発へ移る年収｜下がる人と保てる人の4つの条件

インフラエンジニアからアプリケーション開発へ移るときの年収は、開発経験の短さでどこまで等級を下げられるかと、インフラの判断をどこまで評価してもらえるかの綱引きで決まります。そのため、同じ経歴でも、移り方によって提示額が下がる人と保てる人に分かれます。

出発点となる職種の水準はインフラエンジニアの年収相場で確認できます。この記事では、職種を移るときに年収がどう決まるかに絞って説明します。

統計上はインフラとアプリで別の区分になる

結論から言うと、公的統計を見ても「アプリへ移れば年収が上がる」とは言えません。賃金構造基本統計調査では、プログラムを書く仕事は「ソフトウェア作成者」、サーバーや通信の管理に寄る仕事は「その他の情報処理・通信技術者」に分かれて集計されています。

表の年収換算額は当サイトが月額と年間賞与から算出した概算で、調査が公表した年収ではありません。また、後者は平均年齢も勤続年数も上の区分です。インフラ側が上に出ている差の一部は、年齢と勤続の違いで説明できるため、職種の優劣としては読めません。

読み取れるのは、職種の名前を変えるだけで年収が自動的に上がるという根拠はないということです。移る理由が年収だけなら、統計はその判断を後押ししません。アプリ開発へ移って得られるものがあるとすれば、参照できる求人の幅と、事業の成果に近い場所で判断できることです。

提示額が下がる理由は等級の当てはめ方にある

提示額が下がる主な理由は、技術の難しさではなく、応募先の等級の当てはめ方です。多くの会社はアプリ開発の職種に対して「設計をリードできるか」「レビューで他者を導けるか」といった要件を等級ごとに置いています。インフラの経験が長くても、その職種の要件に照らすと実績が足りず、下の等級に置かれることがあります。

具体例として、インフラ歴8年で設計をリードしてきた人が、アプリ開発の経験者ポジションに応募した場合を考えます。面接官はアプリの設計レビューの経験を聞きますが、答えられる実績はインフラ設計についてのものです。応募先がこれを別の職種の経験と見なせば、開発歴の短い人と同じ等級で提示されます。年数が長いほど、同年代との提示額の差が目立つことになります。

当サイトの診断モデルでは、実務経験年数ごとのレンジは次のようになります。

これはエンジニア全体の推定で、職種転換を織り込んだ係数ではありません。使い方としては、アプリ開発の経験年数として見たときの行と、通算の経験年数の行の間のどこに置かれるかを確かめる目安になります。通算の行にそのまま置かれる前提で年収を見積もると、提示を受けたときに想定とずれます。

例外は、インフラの判断そのものが必要とされているポジションです。大規模なトラフィックを扱うバックエンドや、基盤の刷新を担当するチームでは、インフラ出身であることが等級を下げる理由になりません。

持ち込める経験と持ち込めない経験を分ける

インフラの経験はすべてが評価されるわけではありません。評価される経験は、アプリケーションの設計判断に影響を与えるものです。逆に、特定の製品の設定手順や運用手順の知識は、職種を移ると評価の対象から外れます。

理由は、応募先が知りたいのが「この人が入るとアプリの品質がどう変わるか」だからです。容量計画を立てた経験があれば、データ量が増えたときに壊れる実装をレビューで止められます。障害の切り分けを繰り返してきた人は、ログや監視を実装の段階で組み込めます。これらはアプリ開発だけを続けてきた人には身につきにくい視点です。

具体的な書き分けとして、「AWS上のサーバー運用」と書くと製品の経験に見えます。「想定の数倍の負荷でDB接続が枯渇した障害を受け、接続数の上限と再試行の方式をアプリ側と合意して変更した」と書くと、設計の判断として読めます。後者なら面接でアプリの話につなげられます（職務経歴書の書き分け）。

注意点として、手順どおりの運用だけを担当してきた場合、言い換えで経歴を強く見せることはできません。面接で深掘りされれば分かります。その場合は、まず現職で判断する範囲を広げることが先になります。

SREやプラットフォームを経由すると年収を保ちやすい

年収を保ちながら移るなら、機能開発へ直接移るより、SREやプラットフォームのチームを経由するほうが現実的です。インフラの強みが評価されたまま、コードを書く比率を段階的に増やせるからです。

提示額を決めるのは職種の名前より等級と担当範囲なので、アプリ側へ移ること自体が年収の上昇を約束するわけではありません。基盤に近いチームなら、障害対応や容量計画の判断がそのまま等級の根拠として数えられます。言語を選ぶ段階では、Goは基盤やバックエンドで使われることが多く、インフラ出身者が入りやすい領域です（Goエンジニアの年収）。

実際の進め方としては、社内の運用ツールやデプロイの仕組みを、スクリプトではなくテストとレビューのあるソフトウェアとして作るところから始めます。そのうえでSREやプラットフォームの担当に入れば、次の段階でアプリ側の設計レビューに加わることもできます（プラットフォームエンジニアの年収）。

例外として、「SRE」という名前のチームでも実態が定型の運用中心であれば、コードを書く比率は増えません。求人名ではなく、業務時間の配分を面接で確かめてください。

社内異動と転職で年収の下がり方が違う

アプリ開発へ移る手段として、社内異動は年収を保ちやすい選択です。同じ会社の中なら、等級と基本給を維持したまま役割だけを変えられることが多いからです。転職では応募先が新しく等級を当てはめるため、ここで差が出ます。

社内異動の弱点は、上げ幅が小さいことと、受け入れ先の枠に左右されることです。等級が据え置かれたまま開発の実力を証明する期間が必要で、昇給の査定で不利になる年もあります。一方で、年収を落とさずに開発の実績を作れるので、その後の転職で評価される材料になります。手順は社内公募・社内異動で年収を上げられる条件を参照してください。

転職の強みは、選べる環境の幅が広いことです。ただしアプリ開発の実務が短いうちに動くと、等級を下げた提示を受けやすくなります。提示額の妥当性を見るときは、一度下げた等級をいつ戻せるかを確かめてください。戻せないと、数年にわたって差が残ります（中途入社で下がった等級を取り戻す）。

判断の目安は、現職にアプリ開発の部署があるかどうかです。あるなら社内異動を先に試し、ないか、枠がなければ転職を考えます。ただし、開発部署が存在しても、異動の前例がない会社では時間がかかります。前例の有無は早めに確認してください。

企業タイプで移りやすさが変わる

同じ職種転換でも、どの企業タイプへ移るかで年収の決まり方が変わります。同じ実務3〜5年・東京・スキル中位の条件で、企業タイプを変えた推定レンジは次のとおりです。

インフラとアプリの差より、企業タイプの差のほうが大きく出ます。つまり、職種を変える判断と、企業タイプを変える判断は分けて考える必要があります。SESのインフラからSESのアプリ開発へ移っても、商流が変わらなければ給与の原資はあまり変わりません（企業タイプ別の年収相場）。

実務では、自社サービスの会社はインフラ出身者を基盤寄りの役割で受け入れる傾向があり、受託開発の会社は機能開発の経験を重く見る傾向があります。スタートアップでは境界が曖昧で、両方を担当できる人が重宝されることがある一方、制度が整っておらず年収の説明が曖昧になることもあります。

ただしこれらは傾向で、個別の会社で確認が必要です。面接では「インフラ出身でアプリ開発に移った方はいますか、その方の役割はどう決まりましたか」と聞くと、受け入れの実績が分かります。

開発経験を積む順番

移る前に積む経験は、ツールの数より順番が大切です。おすすめは、自分が運用しているものに近い順に、コードの責任を引き受けることです。説明が一貫し、面接でも深く語れるからです。

1. 運用の自動化を、テストとレビューのあるコードとして書き直す
2. 社内向けの管理画面やAPIを、要件定義から本番運用まで担当する
3. プロダクトのコードのうち、監視、ログ、性能に関わる部分を修正する
4. アプリチームの設計レビューに、性能と障害の観点で参加する
5. 小さな機能を、設計からリリースまで担当する

この順番にするのは、途中のどの段階でも「インフラの判断を活かしてコードを書いた」と説明できるからです。逆に、運用と無関係な題材で個人開発をしても、職務経歴との接続が弱くなります。

言語の選び方も、現職のプロダクトで使われているものが第一候補です。市場の単価や求人の数だけで選ぶと、実務で使う機会がなく、業務経験として積めません。スキルが年収に効く条件は年収に効くスキルで扱っています。

注意点として、個人開発や学習の成果は、それ単体では実務年数として扱われにくいものです。補助の材料と割り切り、実務の中で書く機会を作ることを優先してください。

面接とオファーで確認すること

提示を受ける前後で、次の項目を確認します。特に職種転換では、入社時の等級と次の昇格条件が重要になります。

• 自分の経歴を、どの職種のどの等級で評価しているか
• 開発の実務年数とインフラの実務年数をどう扱っているか
• 入社後の業務でコードを書く時間と運用の時間の比率
• 当番やオンコールに入る前提かどうか、その手当
• 次の等級へ上がるために求められる実績と、判定の時期

最初の質問は聞きにくく感じるかもしれませんが、提示の根拠を確かめる普通の質問です。提示額が想定より低いときは、等級の根拠を聞いたうえで、インフラの判断が等級要件のどの項目に対応するかを示して交渉します。金額だけを主張するより通りやすくなります（年収交渉の進め方）。

オンコールの条件も重要です。インフラ出身というだけで当番を多く割り当てられ、開発の時間が取れないことがあります。入社の目的がコードを書くことなら、比率を確認しないと、移った意味が薄くなります。

移らないほうがよいケース

アプリ開発へ移ることが常に正解ではありません。理由が「インフラの将来が不安」だけなら、まず確かめたほうがよいことがあります。クラウド化で手順の仕事が減っても、設計と運用の判断の需要が消えたわけではないからです。

統計で見ると、情報処理・通信技術者の有効求人倍率は1.33倍で、全職業の1.06倍を上回っています。ただしこれはハローワークの集計で、職種ごとの需給を示すものではありません。転職市場の実感とは一致しないこともあります。

また、インフラのまま年収を上げる経路もあります。クラウド設計、SRE、セキュリティ、データベースのように専門性で上がる道です（クラウドエンジニアの年収相場、セキュリティエンジニアの年収）。コードを書くこと自体が好きで移りたいのか、年収を上げたいのかで、選ぶ道は変わります。後者なら、職種を変えるより専門を深めるほうが速い場合があります。

この記事の数字の読み方

統計の年収換算額は産業計・企業規模計の職種平均を基に当サイトが計算した概算で、調査の公表値ではありません。

診断モデルのレンジは全エンジニアの条件から計算したもので、職種転換の影響を個別に織り込んではいません。求人倍率はハローワーク経由の求人を集計した数字です。いずれも自分の位置を確かめる出発点で、個別の提示額を判定する根拠にはなりません。

最終チェック

応募の前に、次を確認してください。

• 移る理由が、年収か、仕事の内容かを言葉にした
• インフラの経験のうち、アプリの設計に影響する判断を書き出した
• 現職で実務としてコードを書く機会を試した
• 社内異動の前例と枠を確認した
• 応募先がどの職種のどの等級で評価するかを確認した
• 入社後の開発と運用の時間の比率を確認した

職種の移動で年収を動かすのは、職種の名前ではありません。インフラで下してきた判断をアプリの設計の言葉に翻訳できるかどうかが、提示額の分かれ目になります。