配置転換で開発から運用・保守へ移るエンジニアの年収｜等級と評価の5つの確認

会社の組織の見直しや人員の配置の都合で、開発の部署から運用・保守の部署へ異動するよう打診されることがあります。そのときに気になるのが、年収や将来のキャリアがどう変わるかです。結論から言うと、配置転換で開発から運用・保守の部署へ移るとき、エンジニアの年収がすぐに下がることは多くありませんが、評価の基準と手当、将来の昇格の道筋が変わることがあります。異動の直後の年収より、その後の評価と昇格がどう進むかを確かめることが大切です。

この記事は、開発から運用・保守の部署への異動を打診されたエンジニアや、すでに異動したエンジニア向けに、異動で変わるものと変わらないもの、運用・保守で評価を作る方法、元の職種に戻る道の確かめ方、異動の前後の5つの確認を整理します。自分から希望して異動する場合の考え方は社内公募・社内異動で年収は上がるかで、運用の職種の年収はネットワーク・インフラ運用エンジニアの年収でも扱っています。

結論：直後の年収より、評価と昇格の道筋を見る

配置転換の影響を考えるときは、異動の直後の年収ではなく、異動した後の評価の基準と、昇格の道筋を確かめます。

理由は、多くの会社では、異動しただけで基本給や等級を下げることはなく、異動の直後の年収は大きく変わらないことが多いからです。一方で、部署が変わると、評価の基準、評価をする上司、昇格の機会が変わります。これらが変わることで、数年後の年収に差が出ることがあります。

具体例として、開発の部署では、新しい機能を作った成果が評価されやすい一方、運用・保守の部署では、障害を防いだ成果が当たり前と見られやすく、評価されにくいことがあります。評価の基準が変わったことに気づかず、開発の部署と同じ働き方を続けると、昇給や昇格が遅れることがあります。

注意点として、異動の扱いは会社によって違います。異動に伴って職種の区分が変わり、給与の仕組みが変わる会社もあります。

異動で変わるものと変わらないもの

配置転換で、何が変わり、何が変わらないかを整理しておくと、確かめるべき点が見えてきます。

この表の読み方として大切なのは、異動の直後の受取額は、基本給より、残業代と手当の変化で動きやすいことです。運用・保守の部署では、障害の対応の当番や、夜間・休日の作業があることがあり、手当が加わって受取額が増えることもあります。一方、開発の部署で残業が多かった人は、運用の部署で残業が減り、受取額が下がることもあります。

具体的には、当番や夜間の作業の手当は、会社の制度によって大きく違います。当番の手当の考え方はオンコール・障害対応の当番手当で、深夜の作業がある働き方は深夜・シフト勤務の手当と実質時給で扱っています。

注意点として、表は典型的な傾向をまとめたもので、会社によって違います。

運用・保守で評価を作る

運用・保守の部署で評価を得るには、改善の成果を数字で示すことが大切です。

理由は、運用・保守の仕事が、システムが問題なく動いている状態を保つことであり、問題が起きないと、成果が見えにくいからです。障害がないことは当たり前と見られやすく、何もしていないように見られることさえあります。改善の成果を数字で示すと、仕事の価値が見えるようになります。

具体例として、障害の件数を減らした、障害からの復旧の時間を短くした、手作業の運用を自動化して作業の時間を減らした、監視の仕組みを見直して問題を早く見つけられるようにした、といった改善は、数字で示しやすい成果です。開発の経験がある人は、運用の作業を自動化する仕組みを作ることで、開発の力を活かしながら成果を出せます。

注意点として、改善の成果は、評価の時期にまとめて思い出そうとすると、具体的な数字が分からなくなります。日々の作業と改善の内容を記録しておいてください。

年収の水準をモデルで確かめる

異動の後の年収を考えるときは、今の等級と経験年数での年収のレンジを確かめておきます。

診断モデルの推定では、上場・大手企業、東京、スキル中位の条件で、経験年数だけを変えると次のようになります。

この表の読み方として、自分の経験年数の行のレンジと、今の年収を比べます。異動の後も、このレンジの中で昇給していけるかが、評価と昇格の道筋を確かめるときの目安になります。表はモデルによる推定で、個別の会社の年収や、異動の影響を示すものではありません。

注意点として、厚生労働省の調査では、情報通信業で昇給の内容が業績評価などによる企業の割合は 88.6% でした。多くの会社で昇給は評価に基づくため、異動の後の評価の基準を確かめることが、年収の見通しを立てるうえで欠かせません。

運用・保守の経験の価値

運用・保守の経験は、開発の経験と組み合わせると、市場での価値が高まることがあります。

理由は、システムを安定して動かす力、障害の原因を調べる力、運用の自動化の経験が、SREやクラウドのインフラの職種で求められているからです。開発と運用の両方が分かる人は、作るときから運用のしやすさを考えた設計ができるため、評価されやすくなります。

具体例として、開発の経験を持つ人が運用・保守の部署で、監視の仕組みの改善や、障害の対応の自動化を担うと、その経験はSREの職種への転職で強みになります。SREの年収はSRE・インフラエンジニアの年収で扱っています。

注意点として、運用の作業の繰り返しだけを長く続けると、こうした経験は積みにくくなります。改善や自動化に関わる機会を意識して作ることが大切です。

開発の力を保つ

運用・保守の部署にいる間も、開発の力を保つことを意識しておきます。

理由は、運用・保守の部署にいる期間が長くなると、開発の経験が古くなり、元の部署に戻るときや、開発の職種に転職するときに評価されにくくなることがあるからです。

具体的には、運用の作業を自動化する仕組みを自分で作る、運用の中で見つけた不具合の修正に関わる、開発の部署との連携の仕事を担う、といった形で、開発の力を使う機会を作ります。業務の外で新しい技術に触れておくことも役に立ちます。

注意点として、運用・保守の部署の仕事の量によっては、開発の力を使う時間を取りにくいこともあります。上司と相談して、改善の取り組みに時間を割けるようにしてもらうと、評価と力の維持の両方につながります。

元の職種に戻る道を確かめる

異動の前後で、元の開発の部署に戻る道があるかを確かめておきます。

理由は、戻る道があるかどうかで、異動した後の働き方の考え方が変わるからです。異動の期間が決まっている場合や、社内公募の制度がある場合は、運用・保守の経験を積んだ後に、開発の部署に戻ることができます。戻る道がない場合は、運用・保守の部署で評価を作るか、社外の選択肢を考えることになります。

具体的には、異動の打診を受けたときに、異動の理由、異動の期間の見込み、戻る道があるかを上司や人事に聞きます。答えがあいまいな場合でも、自分が開発の仕事を続けたいという希望を伝えておくと、将来の配置の検討で考慮されることがあります。

注意点として、配置転換は、就業規則で会社が命じることができると定めていることが多く、正当な理由なく断ることは難しいことがあります。家庭や健康の事情がある場合は相談し、判断が難しい場合は、人事や専門家に相談してください。

異動の前後の5つの確認

配置転換の打診を受けたら、異動の前後で次の5つを確認します。

1. 基本給、等級、職種の区分が変わるか
2. 異動先の残業の量と、当番や夜間の作業の手当
3. 異動先の評価の基準と、評価をする上司
4. 異動先からの昇格の実績と道筋
5. 異動の期間の見込みと、元の部署に戻る道

この5つを確認すると、異動の直後の年収と、その後の年収の伸び方の両方が見えてきます。特に3と4は、数年後の年収を左右するため、異動の前に確認してください。

注意点として、すべての点に、異動の前に明確な答えがもらえるとは限りません。答えがもらえなかった点は、異動の後に上司との面談で改めて確認してください。

よくある誤解

「開発から運用に異動すると年収が下がる」という見方は正確ではありません。多くの会社では、異動しただけで基本給や等級は下がらず、手当で受取額が増えることもあります。

「運用・保守の仕事は評価されない」という理解も一面的です。改善の成果を数字で示せれば、評価されやすくなります。

「運用・保守の経験は転職で役に立たない」という見方も誤りです。開発の経験と組み合わせると、SREやクラウドのインフラの職種で評価されます。

まとめ

• 配置転換の影響は、直後の年収より、評価の基準と昇格の道筋で考える
• 異動の直後の受取額は、基本給より、残業代と手当の変化で動きやすい
• 運用・保守では、障害の削減や自動化などの改善の成果を数字で示す
• 開発の力を保ちながら、開発と運用の両方が分かる人材を目指す
• 基本給と等級、残業と手当、評価の基準、昇格の道筋、戻る道の5つを確認する