情シス・ヘルプデスクから開発職へ転職する年収｜経験年数の数え方で208万円差

情シスやヘルプデスクから開発職へ移るとき、提示年収を決めるのは社会人としての在籍年数ではありません。応募先が「開発実務」として数えられる年数です。ここがずれているために、同じ在籍5年でも提示が大きく変わります。

まず、その差がどれくらいなのかを確かめます。

経験年数の数え方で提示年収はどこまで動くか

結論から言えば、年数の数え方が一段変わるだけで、推定の中央値は大きく動きます。上場・大手／東京勤務／スキル中位という条件を固定し、実務経験だけを変えるとこうなります。

未経験扱いと3〜5年扱いでは中央値に 208万円、1〜2年扱いと3〜5年扱いでも 116万円 の差があります。企業タイプも勤務地もスキル水準も同じで、変えたのは年数の扱いだけです。

なぜこれだけ動くのかというと、中途採用の等級は「何年やったか」ではなく「何を任せられるか」で決まり、その判断の入口に年数が置かれているためです。要件を自分で決めて設計し、レビューを通して本番へ出し、壊れたときに直せる人なら、年数の欄が何年であっても上の等級で見られます。逆にそこを示せないと、在籍年数が長くても入口の等級から始まります。

具体例で言うと、情報システム部門に5年いて、そのうち社内ツールの開発を2年担当していた人は、職務経歴書の書き方次第で「未経験」にも「1〜2年」にも見えます。前者で通れば表の最上段、後者なら2段目です。この差は面接で逆転させにくく、書類の段階でどちらに置かれるかがほぼ決まります。

ただしこの表は推定であり、個別の提示額を保証するものではありません。実際の提示は応募先の給与テーブルの刻み幅に沿って出るため、表の中央値ちょうどになることはまずありません。表は「どの段に置かれるかで桁が変わる」という構造を確かめるために使ってください。

在籍年数がそのまま開発経験にならない理由

情シスやヘルプデスクの年数が開発職の年数として数えられにくいのは、評価する側が見ている能力が違うからです。問い合わせ対応や端末管理で伸びるのは、原因を切り分ける力と、利用者に合わせて説明する力です。これは開発でも効きますが、提示年収を決める等級の要件になっているのは別の能力です。

開発職の等級要件は、おおむね「任せられる判断の大きさ」で段が分かれています。下の段は決められた仕様をコードにすること、次の段は仕様の抜けを自分で埋めること、その上は設計を選び、他の人の設計をレビューすることです。この並びに照らすと、運用の現場で培った切り分けの力は、下の段を飛ばす根拠にはなりにくくなります。

たとえば障害の一次対応を長く担当してきた人は、ログを読み、再現手順を作ることに慣れています。これは開発側から見ても価値のある経験で、面接でも評価されます。しかし「設計を選べるか」への答えにはならないため、等級の判定では年数の欄が効いてきます。

注意したいのは、これが能力の優劣ではなく、評価軸の違いだという点です。社内SEや情シスの仕事には、開発職の等級表では測れない価値があります（社内SEの年収は高い？）。移ることが前提の話ではなく、移るなら年数の扱いが変わると理解しておく、という話です。

数えてもらいやすい経験と、数えてもらいにくい経験

同じ情報システム部門の仕事でも、開発職の年数として説明できるものと、できないものがあります。境界は「自分が決めたか」にあります。

表の読み方は、上の行ほど「自分の判断が成果物に残っている」ということです。下の行に近いほど、決めたのは他者で、自分は実行した側になります。開発職の等級が判断の大きさで分かれているため、この並びがそのまま数えられやすさの順になります。

この表が当てはまらないケースもあります。ベンダー管理が中心でも、要件定義の主担当として仕様を決め、受け入れテストの観点を自分で設計していたなら、上の行と同じ扱いで説明できます。逆に社内ツールを作っていても、既存コードの設定値を変えるだけだったなら、下の行に近くなります。肩書きや担当名ではなく、どの判断を自分がしたかで分かれます。

企業タイプを変えると下がり幅はさらに広がる

年数の扱いと同じくらい、どこへ移るかが提示額を決めます。1〜2年扱いという同じ条件で、企業タイプだけを変えるとこうなります。

上端と下端の幅は、年数の扱いを一段上げて得られる差より大きくなっています。つまり**「開発経験として何年数えられるか」よりも、「どの企業タイプに入るか」のほうが効く場面がある**ということです。この差は事業の利益率と商流の深さから来ており、交渉では埋まりません（企業タイプ別のエンジニア年収相場）。

実務上の意味は、応募先の選び方で下がり幅を調整できることです。現職が中小の情報システム部門で、移る先が上場企業の開発部門なら、年数が一段下がっても総額は維持できることがあります。逆に現職が大手で、SESの開発案件へ移るなら、年数の扱いが据え置きでも下がります。

ただし企業タイプの上側は選考も厳しくなります。年数の扱いが入口の等級になる段階では、上端の企業タイプで通る確率は高くありません。表は「選べるなら上を狙う」という指示ではなく、落差の原因が二つあることを分けて見るために使ってください。

同じ年数帯の中でもスキル評価で動く

等級の段が決まった後も、レンジの中のどこに置かれるかは残ります。1〜2年扱いという同じ枠の中で、スキル評価だけを変えるとこうなります。

• スキル下位（スコア30）：393〜461万円
• スキル上位（スコア85）：482〜565万円

同じ段の中でも幅があるため、年数で下の段に置かれたとしても、そこで終わりではありません。情報システム部門での経験は、この「段の中の位置」を上げる材料として効きます。社内の業務フローを知っていること、利用者の使い方を具体的に説明できること、既存システムの制約を把握していることは、新しく入った開発者が持っていない情報です。

具体的には、社内向けプロダクトを作っている部署、業務システムを扱う受託開発、社内の情報システムを自社開発に切り替えている会社では、この材料がそのまま評価になります。一般消費者向けのサービス開発では効きにくいため、応募先を選ぶ段階で振り分けたほうが無駄が少なくなります。

注意点として、スキル評価は自己申告では動きません。コーディングテストや技術課題、過去の成果物の説明で判断されます。社内ツールのコードを見せられる状態にしておくか、同じ題材を手元で作り直しておくかは、応募の前に決めておく必要があります。

社内異動で開発職に移る場合

同じ会社の中で移れるなら、年収の落差はほぼ出ません。等級が職種をまたいで共通の会社では、異動しても等級が据え置きになり、基本給が変わらないためです。移る方法としてはこれが最も安全です。

理由は制度の作りにあります。多くの会社は等級ごとに給与の範囲を決めており、職種は役割の名前として扱われます。この構造なら、開発職としての実力が等級に追いつくまでの期間を、会社側が負担する形になります。社内公募の仕組みがあるなら、まずそこを確認するのが順序です（社内公募・社内異動で年収は上がるか）。

一方で、職種別に給与テーブルが分かれている会社では、異動と同時にテーブルが切り替わります。手当の扱いも変わることがあり、たとえばシフト勤務や当番の手当が付いていた場合、開発職に移ると前提ごと消えます。額面の基本給が据え置きでも、年間の受取額が下がることはあります。

打診を受けた段階で確認するのは、等級の持ち越しの有無、給与テーブルの切り替わり、手当の扱い、そして次の評価までの期間です。口頭の説明ではなく、人事制度の文書で確かめてください。 異動の希望を出す側が不利な条件を飲みやすい場面なので、条件を揃えて比べる工程を省かないほうがよいです。

転職で移る場合に提示年収を決める4つの材料

社外へ移る場合、提示額を作っているのは次の4つです。順に強く、上の2つでほぼ枠が決まります。

この並びの意味は、交渉で動かせるのが下の2つだけだということです。上の2つは応募の前に決まっており、提示が出た後では変えられません。だからこそ、職務経歴書をどう書くかと、どこに応募するかに時間を使う価値があります（エンジニアの職務経歴書で提示年収が変わる理由）。

4つ目の現年収については、内訳を把握しておかないと比較を誤ります。情報システム部門では当番手当や休日対応の手当が付いていることがあり、額面の年収にそれが含まれています。開発職の提示額がその総額を上回っていても、所定内の給与では下がることがあります。基本給、固定手当、変動部分を分けて並べてから比べてください。

市場の状況も枠の外側を決めます。情報処理・通信技術者の有効求人倍率は 1.39倍 で、全職業の 1.1倍 より高い水準です。ただし新規求人数は前年同月比で -16.3%、新規求職件数は 14.6% と動いており、入口の等級で競合する人数は増える方向です。未経験寄りの枠を狙う場合は、この変化が効きやすくなります。

求人票と面接で確認する項目

提示が出る前に、自分がどの段で見られているかはある程度わかります。求人票の必須要件に「開発実務3年以上」と書かれていれば、それ未満の扱いになる応募は上の段に乗りません。要件の文言から等級を逆算する手順は別の記事で扱っています（求人票の必須要件・歓迎要件から等級を逆算する）。

面接では、年収の金額を聞くより先に役割の範囲を確かめたほうが情報が取れます。具体的には、入社直後に任される範囲、設計をどこまで自分で決めるか、レビューをする側かされる側か、の3点です。これが決まれば、応募先の等級表のどこかはほぼ特定できます。

職種を変える応募では、未経験可の求人と経験者向けの求人を同時に受けると比較しやすくなります。前者は入口の等級、後者は年数が数えられたときの等級で返ってくるため、自分の経験がどちらに寄って評価されるかが実測できます。書類で落ちた理由は通常わかりませんが、どちらが通るかという事実だけは残ります。

確認の際に避けたいのは、将来の昇給を口頭の説明で織り込むことです。「半年で見直します」という説明があっても、判定の時期と基準が書面にないなら、提示された現時点の金額で判断します。期待を含めて計算すると、下げ幅の回収年数を実際より短く見積もることになります。

下がる提示を受けてよいかの判断

下がる提示を受けるかどうかは、下げ幅を何年で回収できるかと、回収の前提が自分で確かめられるかで決まります。感覚ではなく、回収年数を出してから判断してください。

計算は単純です。下げ幅を、応募先で見込める年あたりの昇給額で割ります。昇給額の目安は、応募先の改定率と等級の刻み幅から出します。情報通信業の1人平均賃金の改定率は 3.9%、改定額は 14,096円/月 です。定期昇給だけで回収しようとすると、下げ幅が大きい場合は年数がかなり伸びます。

現実的には、回収は昇格で起きます。表の段が一つ上がるときの差が、定期昇給の数年分に当たるためです。したがって確認すべきは昇給率そのものより、次の等級の要件が明文化されていて、判定の時期が決まっているかです。ここが曖昧な会社では、回収の計算に根拠がありません。判断の型は別の記事で整理しています（年収が下がる転職を受けてよい4つの条件）。

例外として、回収年数が長くても受ける判断はあり得ます。移った先で得られる経験が、次の転職での年数として数えられるものであれば、2回目の移動で戻せる余地があります。ただしこれは見込みであって確定ではないため、下げ幅が生活に直接響く水準なら、先に下げ幅を小さくする応募先を探すほうが順序としては安全です。

入社後に等級を戻す

入口の等級で入った場合、そこからどう上げるかは入社後の工程です。ここで効くのは成果の量ではなく、次の等級の要件に当たる仕事を取れているかです。

理由は、昇格の判定が要件との照合で行われるためです。要件に「設計を主導した」と書かれているなら、与えられた実装を速くこなしても段は上がりません。入社直後の面談で、次の等級の要件と、それに当たる仕事をいつ任せてもらえるかを確認しておくと、1年の過ごし方が変わります。中途入社で等級が低く決まったときの進め方は別の記事で扱っています（中途入社で等級が低く決まったエンジニアが取り戻す手順）。

情報システム部門から移った人の強みは、入社直後に出しやすい成果があることです。社内で使われているシステムの制約、利用部門の実際の運用、過去に失敗した移行の経緯などは、開発側が把握しきれていないことが多く、設計の判断に直接効きます。この情報を設計のレビューで出せると、要件に当たる仕事が回ってくる速度が上がります。

一方で、運用側の視点をそのまま持ち込むと噛み合わないこともあります。運用の安定を最優先にする判断は、プロダクトの変更速度を重視する組織では採られないことがあります。どちらが正しいという話ではなく、判断の優先順位が組織によって違うという前提で、根拠を揃えて出す必要があります。

情報システム部門に残って年収を上げる選択

移らずに上げる道も検討してから決めたほうが、比較の材料が揃います。情報システム部門にいながら年収を上げる経路は、担当範囲を上流へ広げることと、評価の軸がある会社へ移ることの2つです。

理由は、情報システム部門の年収も担当範囲で分かれているからです。問い合わせ対応と端末管理が中心の役割と、システムの選定と全社の設計を決める役割では、同じ部門名でも等級が違います。後者は開発職の等級表で言えば設計を選ぶ段に当たるため、職種を変えずに段を上げられます。

具体的には、基幹システムの刷新、全社の認証基盤の設計、クラウド移行の計画といった仕事が担当範囲に入るかどうかが分岐点です。これらは社内の利害を調整しながら技術を選ぶ仕事で、開発職へ移るより現職の延長で取りやすいことがあります。隣接する職種では、インフラ運用から設計へ進む経路も同じ構造です（ネットワーク・インフラ運用エンジニアの年収相場）。

ただし会社によっては、情報システム部門がコスト部門として扱われ、等級の上限が低く設定されていることがあります。上流の仕事を取っても段が上がらないなら、残る選択の価値は下がります。自社の等級表に情報システム部門の上の段があるかどうかを、先に確かめてください。

年齢が上がってから移る場合

30代後半以降で職種を変える場合、年数の扱いの影響が大きくなります。入口の等級の金額は年齢と連動していないため、現年収との差が開きやすくなるためです。

ここで効くのは、前職の経験を「開発の年数」ではなく「別の価値」として等級に反映させられるかです。業務知識、社内調整、ベンダー管理、要件定義の経験は、職種が変わっても使える能力として評価の対象になります。これらを成果として説明できれば、入口の等級より上から入る余地があります。年齢帯ごとの判断は別の記事で扱っています（40代以降で職種を変えるエンジニアの転職）。

具体的な進め方としては、純粋な開発職ではなく、業務知識が評価される領域を選ぶ方法があります。社内システムの開発、業務システムの受託、導入支援を含む職種では、前職の経験がそのまま要件に近くなります。隣接する職種として、テクニカルサポートから開発へ寄せる経路もあります（テクニカルサポートエンジニアの年収相場）。

注意点は、下げ幅が大きい提示を「経験を積むため」と受け入れた後、戻すのに時間がかかることです。転職で年収が増加した人の割合は 60.4%、増加した人の平均増加額は 73.1万円 ですが、これは全体の数字で、職種を変えた移動に限った値ではありません。移動のたびに上がる前提では計算しないほうが安全です。

よくある失敗

職種を変える移動では、落ち方の型がいくつか決まっています。先に知っておくと避けられるものが多いです。

1つ目は、職務経歴書を部門名と担当業務の羅列で書いてしまうことです。「情報システム部門で5年、ヘルプデスクと端末管理を担当」という書き方では、開発の年数として数える材料がありません。自動化や社内ツールの開発を担当していたなら、そこを独立した項目にし、要件の決め方と設計の判断を書く必要があります。

2つ目は、未経験可の求人だけに応募して、入口の等級の提示しか集まらないことです。数えられる経験がある人でも、応募先の枠が入口しかなければ上の段は出ません。経験者向けの求人も並行して受けると、自分の経験がどこまで通るかが実測できます。

3つ目は、現年収の内訳を把握せずに提示を比べることです。当番手当や休日対応の手当が外れる移動では、額面が同程度でも受取額が下がります。4つ目は、口頭の昇給の見込みを計算に入れることです。いずれも、判断の前に紙に並べれば避けられます。

移る前に整理する手順

応募を始める前に、次の順で手元の情報を揃えます。

1. 情報システム部門での担当内容を、自分が決めた範囲とそうでない範囲に分ける
2. 自分が決めた範囲のうち、成果物が残っているものを開発経験の項目として独立させる
3. 現年収を基本給・固定手当・変動部分に分け、移動で外れる手当を特定する
4. 社内異動の制度があるか、等級が職種をまたいで共通かを人事制度の文書で確認する
5. 応募先の候補を企業タイプで分け、どの段から入りそうかを求人票の要件で見積もる
6. 下げ幅の許容範囲と、それを超えたときの選択を先に決めておく

この6つのうち、1と2が最も結果を左右します。同じ経歴でも、ここの整理で入口の等級が変わるためです。4は社内異動の可能性を捨てないための工程で、制度があるなら最も落差が小さい選択になります。

手順を踏んでも、提示がどの段で出るかは応募先の判断です。自分でできるのは、数えられる材料を漏らさないことと、落差の原因を二つに分けて見ることまでです。

まとめ

• 提示年収を決めるのは在籍年数ではなく、開発実務として数えられる年数。未経験扱いと3〜5年扱いで推定の中央値は208万円変わる
• 数えられるかどうかは「自分が決めたか」で分かれる。自動化や社内ツールの開発は説明できれば年数になる
• 落差の原因は年数の扱いと企業タイプの2つ。応募先の選び方で下がり幅を調整できる
• 社内異動で等級を持ち越せるなら最も落差が小さい。打診の前に給与テーブルと手当の扱いを文書で確認する
• 下がる提示は回収年数を出してから判断する。次の等級の要件が明文化されていない会社では計算の根拠がない