運用保守はやめとけって本当？抜け出せなくなる職場の見分け方

業務システムのアプリ保守を 5 年続けている人がいるとします（架空の例です）。問い合わせに答え、SQL でデータを調べて直し、月に数件の小さな改修をして、週替わりで夜間バッチの当番に入る。新規の開発案件に手を挙げたら、いま抜けられると保守が回らない、と止められた。開発にいる同期には、保守はやめとけ、そのうち出られなくなる、と言われた。

運用保守から抜け出せなくなる原因は、年齢ではありません。そのシステムを分かっているのが自分だけになり、異動を申し出るたびに、保守が回らないという理由で止められることです。 担当が長くなるほど分かっている範囲が広がり、抜けた後の穴も大きくなるので、この止め方は年数とともに通りやすくなります。

もう 1 つは、会社が開発案件をそもそも取っていない場合です。この場合は、社内でいくら頑張っても移る先がありません。

会社に開発案件があるのに止められているなら、まず社内で引き継ぎの約束を取りにいく。案件が無いなら、外を見る。保守の仕事そのものが嫌いでなければ、保守を手放さずに、職場で変わる部分だけを変える道もあります。

保守のつらさのうち、会社を変えても残るもの

やめとけと言われる理由を、会社を変えても残るものと、会社で変わるものに分けました。

やめとけと言われる理由	会社を変えたら
システムを止めない責任（止まれば急かされ、操作ミスが大きな障害につながる怖さもある）	残る。保守という仕事そのもの
他人が作ったシステムを直すこと（影響範囲を読み、設計書が実態と合わなければソースを読み解く）	残る。設計書の状態やシステムの荒れ方は、担当するシステムで変わる
何も起きないのが成果で、ほめられにくいこと	ほめられにくさは残る。評価のされ方は会社で変わる
夜中の電話	会社で変わる。当番の人数、電話を鳴らす基準、翌日に休めるか
保守から抜けられないこと	会社で変わる。開発案件を取っているか、保守の担当者を開発に回す仕組みがあるか
年収が上がりにくいこと	会社で変わる。商流（元請けか下請けか）、給与水準、任される範囲

厚生労働省の job tag は、運用・管理（IT）の仕事を「サーバー等情報システムがトラブルや不具合で停止することなく安定して稼働するよう運用・管理する。」と定義しています（「運用・管理（IT） - 職業詳細」、2026 年 10 月 9 日確認）。止まったら原因を探して早く戻す責任は、どこへ行っても付いてきます。

他人が作ったシステムを直す難しさも同じです。項目を 1 つ足すにも、画面・データベース・帳票のどこに影響するかを読んでから手を入れます。設計書と実際のプログラムが合っていなければ、ソースを読み解くところから始まります。NTT データビジネスブレインズが情シス実務担当者 221 人に聞いた調査（2026 年 4 月）では、主要なシステムで設計書と実態が「ほぼ完全に乖離している」と答えた人が 43.9% でした。自社システムを持つ側の情シスへの調査で、調べたのもノーコード製品を売る会社なので、保守を請け負う会社の現場にそのまま当てはまる数字ではありません。

この 2 つが苦でないなら、保守の仕事を手放す必要はありません。現場から感謝されるのも、止めずに直しているからです。変えたいのは、夜中の電話、抜けられないこと、年収のように、会社で変わる側です。

保守から抜け出せない会社には 2 種類ある

1 つは、開発案件はあるのに、保守の担当者を外してもらえない会社です。保守チームでシステムを分かっている人が 1 人しかいないと、その人を外せば保守が止まるおそれがあるので、上司は外したがりません。Q&A サイトには、開発の部署に入ったのに「最初の数年（長いと5~6年？）は保守がメイン」と言われた、という新人の投稿もあります。保守に人を張り付けておく職場はあります。

もう 1 つは、開発案件をそもそも取っていない会社です。人材紹介会社の代表は自身の note で、開発や上流に移れない原因を、本人の努力不足の場合と、会社が開発案件を積極的に取っていない場合に分け、後者なら社内で頑張っても実務の場が無い、と書いています。

社内で開発案件のメンバーを募集しているのに自分は移れないなら前者、何年いても社内で開発案件の話を聞かないなら後者です。

社内で開発に移れるかの手がかりは、引き継ぎの時期と補充への上司の答え

開発案件があるのに外してもらえない会社なら、辞める前に、社内で開発に移れるかを確かめられます。引き継ぎ資料を作り、後輩を育てておくのは、その準備として無駄ではありません。夜中に呼ばれるのが自分だけ、という状況も変えられます。

ただ、上司が異動を認めるかどうかは、資料の出来では決まりません。保守が回らない、と上司が言う時に足りないのは人数です。代わりの人が入る約束が無ければ、異動の話は同じ理由で止まり続けます。

だから上司には、〇月までに後輩に保守を引き継げたら次の開発案件に入れてもらえるか、代わりの人員は補充されるかを聞きます。いつまでに誰を入れるかの約束が無ければ、社内で待つより外を見る理由になります。

切り出し方は、辞めるかもしれないと匂わせるより、開発の経験も積みたいという希望として話します。人事評価の面談のように、もともと希望を話す場で出すと、引き止めの交渉ではなくキャリアの相談として聞いてもらいやすくなります。上司に聞く前に職務経歴書を書いて外の求人を見ておくと、返ってきた答えに振り回されずに判断できます。

保守でやった改修は、書き方しだいで開発経験になる

job tag は、システムエンジニア（受託開発）の仕事に、運用開始後の保守・管理や、OS の更新に合わせた改修まで含めています。保守に改修や機能追加が含まれるなら開発経験に入れてよい、という Q&A サイトの回答者の意見もあります。

書類で差が出るのは、ゼロから作ったかどうかより、経歴書が改修中心に読めるか、データ修正中心に読めるかです。小さな項目追加を件数で並べるだけだと、開発の面接官には小さな改修の集まりに見えます。伝えたいのは、既存システムのどこに影響するかを調べて、壊さずに直したことです。

たとえば画面に項目を追加した改修なら、画面・データベース・帳票にまたがる変更で、影響範囲を調べ、設計からテスト、リリースまでを 1 人で担当した、と書きます。ミドルウェアの更新に合わせた改修なら、非推奨の API を置き換え、対象箇所の洗い出しから回帰テストまで担当した、と書けます。データの調査・修正は件数を書かず、問い合わせから原因を切り分ける仕事として 1 行にまとめます。

ただ、要件定義から新しく作った経験を必須にしている求人では、この書き方でも不利は残ります。保守に入る前に開発を担当していたなら、その経験を併せて書けば補えます。

アプリ保守の経験が生きるのは、業務システム開発の求人

題名に運用保守と付く求人だけで探すと、サーバーやネットワークを見るインフラの運用の求人も混じります。アプリ保守でインフラを触ってこなかったなら、そうした求人ではインフラを一から学ぶことになります（インフラの運用についてはインフラエンジニアは楽すぎって本当？監視と構築のきつさの違いで扱っています）。

アプリ保守の経験を生かせるのは、業務システムの開発の求人のうち、仕事内容に開発と並んで運用・保守も書いてあるものです。他人のコードを直してきた経験と、顧客の業務の知識は、開発の現場でも使えます。物流のシステムを保守してきたなら、物流の業務システムを作る会社や、物流会社の社内システム部門では、業務の知識まで生かせます。開発と名の付く求人を何でも受けると、業務の知識が使えない先に行くこともあります。

移った先でまた保守から抜けられなくなるかは、求人票だけでは見分けにくい

求人の文面で確かめられるのは 3 つです。仕事内容に、機能追加・新規開発・要件定義が入社後に担当する仕事として書いてあるか。夜間・休日対応やオンコールについて書いてあるか（書いてあれば、少なくとも隠してはいない会社です）。チームの人数や体制が書いてあるか。

ただ、文面で分かる範囲は狭いです。当サイトの掲載求人のうち、題名が運用・保守・監視の求人を会社単位で数えると、夜勤やシフト勤務、夜間・休日の対応のどれかについて書く会社は約 3 割で、残る約 7 割の会社は、どの求人にもこれらを書いていませんでした。インフラ寄りの求人を多く含む数字で、アプリ保守だけの数字ではありません。また保守から抜けられなくなるかは体制で決まるので、確かめる先は面接になります。

面接では、最近あった出来事を聞く

方針を聞けば、誰でも前向きに答えられます。最近あった出来事なら、答えをごまかしにくくなります。聞きたいことを大事な順に 3 つ挙げます。

1. 保守の担当から開発の案件に移った人は、この 1〜2 年で何人いて、何年目で移りましたか。その時、保守はどう引き継ぎましたか
2. 保守のチームは何人で、それぞれのシステムの中身を分かっている人は何人いますか
3. 直近 3 か月で、夜間に呼ばれたのは何回ですか。当番は何人で回し、対応した翌日は休めましたか

1 つ目で、移った人がいない、あるいは何年目で移ったかが答えられなければ、移った先も今の職場と同じく保守から抜けにくい可能性が高いと思います。

年収は、今の額の中身を分けてから比べる

保守から開発寄りに移ると年収が下がるのか、どれくらい下がるのかを示す数字は手元に無く、この記事では示せません。保守の年収は、会社の給与水準、元請けか下請けか、保守の中でどこまで任されるかで変わります。

今の年収が残業代と夜間当番の手当込みなら、内定先の提示額とそのまま比べると、移った後に手取りが減ることがあります。今の年収を基本給・残業代・当番手当に分けておき、提示額には残業代が何時間分含まれているか、夜間対応の手当はあるかを聞いて、同じ内訳どうしで比べてください。

よくある質問

運用保守は底辺の仕事ですか？

いいえ。job tag の受託開発の SE の仕事にも、運用開始後の保守や改修が入っています。作ったシステムを止めずに動かし続ける仕事で、開発と別の格下の仕事ではありません。ただ、何も起きないのが成果なので、ほめられにくいのは確かです。

運用保守に向いている人は？

止めない責任を負うことと、他人が作ったシステムの影響範囲を読みながら直すことが苦にならない人です。この 2 つはどの会社でも付いてきます。夜中の電話がつらい、抜けられないのがつらい、というのは向き不向きより会社の体制の問題です。

運用保守はスキルが身につきませんか？

担当の範囲で変わります。手順どおりの作業とデータ修正だけなら身につくものは増えにくく、改修や機能追加まで任されるなら、既存システムを直す力と業務の知識が身につきます。

運用保守は楽ですか？

障害が無い日は落ち着いていますが、止まった時の責任があり、夜間の当番がある職場もあります。楽かどうかは、当番の人数と担当するシステムの数で大きく変わります。

この記事の数字と見立てについて

• 当サイトの数字は、2026 年 9 月 27 日時点で当サイト PREVIO に掲載していた求人が対象です。職種に運用・保守・監視・テクニカルサポートのいずれかが含まれる求人から、題名が運用・保守・監視の仕事のものに絞り、会社単位で数えて 5% 単位に丸めました。書いてある会社は、その記載がある求人を 1 件以上出す会社、書いていない会社は、どの求人にも書いていない会社です。インフラ・サーバーの運用保守の求人を多く含み、アプリ保守だけの数字でも、日本の求人全体の数字でもありません。書いていないことは、無いことを意味しません
• job tag は「運用・管理（IT）」と「システムエンジニア（受託開発）」を 2026 年 10 月 9 日に確認しました。NTT データビジネスブレインズの調査は 2026 年 5 月 19 日公表、調査期間 2026 年 4 月 17〜18 日、情シス実務担当者 221 人が対象です
• 保守に配属された新人の声、開発に移れない原因についての人材紹介会社の代表の見方、保守を開発経験に数える意見は、個人の声・意見として紹介しています
• 次は当サイトの見立てと助言です
  • 抜けられない状態が年数とともに強まること
  • 上司が異動を認めるかを決めるのは資料より補充の約束であること。その約束が無ければ外を見る理由になること
  • 上司への切り出し方と、聞く順番
  • 経歴書の書き方と面接官への見え方。要件定義から作った経験を必須にする求人では不利が残ること
  • 業務の知識を生かせる転職先
  • 求人の文面で見る 3 点と、面接の質問
  • 年収の比べ方
  • 運用保守が楽かどうかが、当番の人数と担当するシステムの数で変わること