SESで運用保守しかしてない？やめとけと言われる理由と転職先5つ

運用保守の一件を、六つの責任へ分解する

最初に、一件の問い合わせや障害を「受付・優先順位」「再現・切り分け」「原因調査」「変更・改修」「リリース・確認」「再発防止・説明」の六つへ分けます。自分がすべて担当していなくても構いません。担当した範囲、レビューを受けた範囲、上位者や顧客が決めた範囲を別々に書くと、現在の責任と次に増やす責任が見えます。

受付では、依頼内容を転記しただけか、利用者、影響機能、発生時刻、緊急度、回避策、期限を確認したかを分けます。優先度を自分で決めていなければ、判断者へ渡した情報を書きます。「問い合わせ対応力」ではなく、何を確定し、何を未確認として残したかを示してください。

再現・切り分けでは、入力データ、権限、画面、API、バッチ、時刻、環境差をどの順番で確認したかを整理します。操作ミス、仕様、データ、アプリ、外部連携、基盤のどこまで原因候補を絞ったか。別チームへ渡した場合も、再現条件と確認済みの範囲を残した事実は説明できます。

原因調査では、ログ、SQL、既存仕様、ソースコード、変更履歴、監視情報を使った範囲を出します。SQLを実行したことだけでなく、どの仮説を確かめるために、どのデータを見たかを書きます。本番データの閲覧・更新権限、承認、マスキング、証跡も職場のルールに従い、データを転職活動へ持ち出しません。

変更から再発防止では、運用回避、データ補正、設定変更、プログラム改修の選択肢を誰が比較し、自分が何を作ったかを分けます。リリース後の結果、類似箇所、手順、監視、FAQ、テスト観点へ戻したなら、単発の復旧ではなくサービスを改善した証拠です。測っていない工数削減率や障害減少率は作らず、実際に変えた成果物を示します。

• 受付・優先順位: 利用者、影響、緊急度、期限を確定する
• 再現・切り分け: データ、権限、時刻、環境、外部連携を分ける
• 原因調査: ログ、SQL、仕様、コード、変更履歴で仮説を確かめる
• 変更・改修: 回避、補正、設定、コードの選択肢を比べる
• リリース・確認: 事前条件、承認、テスト、反映後を確認する
• 再発防止・説明: 手順、監視、FAQ、設計へ結果を戻す

転職先5つを、会社名ではなく次に持つ責任で比べる

一つ目は、SIer・受託・別SESの保守開発です。現在の業務知識、ログ・SQL調査、既存コード理解を使いながら、小改修、詳細設計、結合テスト、リリースへ範囲を広げます。「保守」という名称でも問い合わせだけの求人と継続開発を持つ求人があるため、改修件数ではなく入社90日の成果物とレビュー担当を確認します。

二つ目は、自社サービス企業の開発・運用です。一つの製品について、利用状況、問い合わせ、障害、改修、公開後の結果まで継続して見られる可能性があります。ただし「自社サービス」だけで開発や裁量は保証されません。運用専任か開発チーム内か、製品コード、リリース、オンコール、改善時間を確認します。

三つ目は、社内SE・情報システム部門の業務アプリ担当です。利用部門の要求、ベンダーへの依頼、受入、問い合わせ、障害、改善を社内側で持つ求人があります。客先常駐を離れることだけを目的にせず、内製と外注、利用者対応の割合、予算・製品選定、障害当番、入社90日の担当を求人ごとに確定します。

四つ目は、SRE・DevOps・運用改善です。アプリと基盤をまたいで、監視、リリース、障害対応、自動化、性能、信頼性を継続的に改善します。運用経験だけで職名を置き換えず、コード、クラウド、CI/CD、可観測性、当番のどれを実務で持ち、何が自己学習かを分けます。求人ごとに職名の意味も違います。

五つ目は、ITコンサル・導入支援・PMOです。問い合わせや障害から見えた業務課題を、要求、選択肢、費用、リスク、移行、運用へつなげます。会議や資料作成だけを目標にせず、導入後の結果まで追うか、顧客の判断を何の成果物で支えるかを確認します。実装・変更の経験を捨てず、課題と実行の間を説明できる求人を選びます。

• 保守開発: 既存理解を設計・改修・リリースへ広げる
• 自社サービス: 問い合わせから製品改善まで継続して持つ
• 社内SE: 利用部門・ベンダー・受入・運用を社内側で持つ
• SRE・DevOps: リリースと信頼性をコード・仕組みで改善する
• ITコンサル・導入: 業務課題を選択肢・移行・定着へつなぐ

90日で、問い合わせ対応をレビュー付きの成果物へ変える

最初の30日は、直近三案件から代表的な問い合わせ、障害、定期作業、変更を各一件選び、六つの責任へ分けます。問い合わせ票、ログ、SQL、コード、手順など社外へ持ち出せない資料はコピーせず、自分の担当範囲を一般化したメモにします。空欄は経験を作らず、次に担当したい範囲として残します。

31〜60日は、現在の仕事に接する成果物を一つ増やします。受付だけなら再現条件と確認順、切り分けまでなら原因候補と影響範囲、調査までなら運用回避と改修の比較、手順実行までなら変更前後の確認と戻し条件を作ります。担当者へレビューを依頼し、開始日、完成条件、承認者を決めます。

開発へ進みたい場合は、既存コードの影響調査、軽微なバグ修正、データ検証ツール、テスト追加など、レビュー付きで変更できる範囲を相談します。独学でアプリを作ることは知識の証拠になりますが、顧客要件、本番データ、チームレビュー、リリースを伴う実務の代わりではありません。職務経歴書で自己学習と実務を分けます。

社内SEや導入支援へ進みたい場合は、問い合わせの背景にある利用部門の業務、頻度、影響、回避策を整理し、改善候補を担当者へ戻します。単に要望を受け取るのではなく、現行手順、困りごと、対象範囲、受入条件、変更後の運用を確認します。最終決定者が別でも、判断材料を作った範囲は説明できます。

61〜90日は、現職で増やせる責任の担当者・開始日と、求人十件の入社90日を同じ表へ置きます。現職で小改修や改善をレビュー付きで始められるなら、期限を決めて残る選択があります。運用契約の範囲が固定され、案件変更条件も曖昧なら、転職で変える必要が具体化します。応募、内定承諾、退職は別々に決めます。

• 1〜30日: 三案件を受付から再発防止まで分解する
• 31〜60日: 隣の責任を成果物にし、レビューを受ける
• 開発志望: 影響調査・小改修・テストを実務で一つ持つ
• 社内SE志望: 業務・影響・受入・変更後運用を整理する
• 61〜90日: 現職の開始日と求人十件の入社90日を比べる

職務経歴書は、障害対応を判断の時系列へ変える

職務経歴書へ「運用保守を三年」「問い合わせ対応、SQL、Java」と並べても、任せられる範囲が分かりません。一案件ごとに、システム用途、利用者、チーム、自分の役割、通常時、障害時、変更時、成果物、結果を書きます。顧客名、画面名、テーブル名、本番データ、障害の内部情報は一般化します。

代表事例は時系列にします。「利用者から帳票不一致の連絡を受け、対象日・権限・入力条件を確認。ログとSQLで外部連携後の一部データに絞り、既存仕様と変更履歴から原因候補を提示。開発担当の修正後に類似データの回帰確認を行い、確認手順を運用票へ追加」のように、入口、調査、分担、結果をつなぎます。

SQLは構文名や件数より、何を判断するために使ったかを書きます。データ不整合の範囲、更新前後、バッチ処理、外部連携の状態を確認したなど、仮説との接続を示します。本番更新を行っていないなら照会までと明記し、更新権限や承認を持っていたように見せません。

小改修は、コード量より既存仕様と影響範囲を出します。依頼を受け、関連機能、API、DB、バッチ、権限、例外処理を調べ、誰のレビューを受け、どのテストとリリース確認を持ったか。チーム全体の設計や顧客の承認を自分の成果へ含めず、自分で作った成果物を明確にします。

応募先に合わせて順序を変えます。保守開発ならコード調査・改修・テスト、自社サービスなら問い合わせ・障害・改善、社内SEなら利用部門・受入・ベンダー協働、SREなら監視・変更・自動化、導入支援なら課題・選択肢・合意を前へ出します。経験の事実は変えず、未経験と次に持つ責任を添えます。

• 背景: 業界・用途・利用者・体制を一般化する
• 入口: 問い合わせ・障害・変更依頼と影響を整理する
• 調査: 再現、ログ、SQL、仕様、コード、変更履歴をつなぐ
• 分担: 自分・開発・基盤・顧客・責任者の境界を分ける
• 結果: 修正確認・回避・手順・監視・再発防止を残す

求人票と面接で、運用保守が続く条件を7項目確認する

一問目は、入社後30・60・90日の製品、案件、工程、成果物です。「開発あり」「上流へ挑戦」と書かれていても、最初の配属が問い合わせと手順実行だけで固定される場合があります。運用、調査、改修、設計、改善の時間割合と、配属決定者、希望外配属の見直し条件を聞きます。

二問目は、問い合わせ・障害の責任分界です。一次受付、再現、ログ・SQL調査、コード調査、修正、リリース、利用者説明を誰が持つか。別会社や別チームへ渡す境界はどこか。障害の重要度、復旧、再開、再発防止の最終判断者も確認します。

三問目は、変更とレビューです。製品コード、設定、データ、手順のうち何を変更でき、誰がレビューするか。検証環境、テスト、承認、リリース、切り戻し、証跡をどう管理するか。保守開発求人でも、既存コードを読むだけか実際に変更するかで経験の広がりが違います。

四問目は、夜間・休日・オンコールです。担当頻度、一次と二次、待機場所、呼出し実績、手当、代休、入社直後の参加、重大障害時の指揮を聞きます。「原則なし」「状況により」だけで判断せず、現在の人数と直近の運用を確認します。

五問目は、案件の継続と終了後。六問目は、評価と次の役割。七問目は、給与と労働条件です。契約終了時の配属、待機給与、案件変更、教育、評価日、基本給、固定残業、賞与、試用期間、業務・就業場所の変更範囲を書面で照合します。「開発職」という名称だけで、入社後の担当を決めないでください。

• 入社30・60・90日の製品・工程・成果物・配属決定者
• 受付・再現・調査・修正・説明の責任分界
• コード・設定・データ変更とレビュー・リリース権限
• 夜間・休日・オンコール・手当・代休・人数
• 案件終了後・待機給与・次の配属・変更条件
• 評価する障害対応・改善・開発成果と見直し時期
• 給与内訳・試用期間・業務と就業場所の変更範囲

相談先は、対象条件と探す職場の違いで二社まで選ぶ

TechGoは、確認した主な利用条件では主に実務経験二年以上のITエンジニアが対象の目安です。運用保守の在籍年数を開発経験へ置き換えず、ログ・SQL調査、コード理解、小改修、変更、改善の証拠で紹介可能な求人を確認します。経験者向けの保守開発、開発、ITコンサルなど、次の責任を上げる求人の選定理由を比べる候補です。

STRATEGY CAREERは、確認した主な利用条件ではエンジニア経験者、主に20〜30代、東京・大阪エリアでの就職希望が対象の目安です。保守開発、事業会社、社内SE、導入・DevOpsなど進路を一つに決める前に、現在の経験がどの職種で評価されるか比較する候補です。掲載事例や年収表示を自分の結果へ置き換えません。

社内SE転職ナビは、利用者の問い合わせ、業務理解、受入、障害、ベンダー協働を社内側で持つ求人を探す候補です。社内SEでも問い合わせ中心、一人情シス、ベンダー管理中心、内製開発など仕事は異なります。対象年齢・地域・面談期限に合う場合だけ、入社90日、内製と外注、当番、評価を確認します。

TechClipsエージェントは、ITエンジニア経験を使い、自社サービス企業を含む開発・運用改善の求人を比較したい人の候補です。自社開発という会社分類を、製品コードの変更や公開後の改善へ関われる保証にしません。現在紹介可能な求人、開発チームとの分担、リリース、当番、改善時間を面談で確かめます。

比較中の全社へ申し込む必要はありません。年齢、実務経験、勤務地、転職時期が対象に合い、求人紹介を実際に利用したい候補を二社まで選びます。同じ版の職務経歴書と七問を渡し、紹介数ではなく、求人を選んだ理由、評価された事例、不足条件、未確認事項、応募前の同意手順を比較します。

• 今の運用保守経験で紹介可能な職種と選定理由は何か
• どの障害・変更・改修経験が評価されたか
• 入社90日の工程・成果物・レビュー担当は誰か
• 運用から開発・改善へ広げる条件と時期は何か
• 配属・案件終了・待機・希望外配属の条件は何か
• 企業ごとの応募前に本人確認を取るか
• 給与内訳・評価・業務と勤務地の変更範囲は何か

応募・内定・退職を分け、次に残る責任で決める

面談後24時間以内に、紹介求人、選定理由、評価された経験、不足条件、未回答項目、次の連絡日を記録します。「運用保守だから未経験」と一括りにせず、再現、調査、変更、改善のどこを理解したかを見ます。紹介求人がない場合も、対象外の理由が具体的なら次の経験計画へ使えます。

応募前には、企業名、職種、勤務地、給与レンジ、担当工程、送付する職務経歴書の版、推薦文を確認します。相談と応募は別です。企業ごとの説明と本人同意を受ける手順を確かめ、重複応募を避けます。希望外の運用求人へ応募数を増やす必要はありません。

内定時は、開発や社内SEという職名より、最初に作る成果物を確認します。影響調査、設計、小改修、テスト、受入、障害分析、改善のどれを持つか。誰がレビューし、何か月後に担当範囲を見直すか。口頭の「いずれ開発へ」を書面の確約として扱わず、不確実な条件として比較します。

給与は想定年収の最大値だけでなく、基本給、固定残業、賞与、当番手当、試用期間、評価日を現職と同じ表へ入れます。工程が広がっても、夜間当番、頻繁な勤務地変更、待機条件が生活に合わない場合があります。求人票、面接回答、最終条件の差分を確認してから承諾します。

転職しない結論も失敗ではありません。現職で原因分析、小改修、改善を始める担当者と期限が決まり、求人より早く証拠を作れるなら残る選択があります。一方、心身へ影響がある、ハラスメントや安全上の問題がある場合は、90日計画より休息、医療、社内外の相談窓口を優先してください。

• 面談: 選定理由・評価事実・不足・未回答を記録する
• 応募: 企業・求人・送付書類・推薦文へ個別に同意する
• 内定: 成果物・レビュー・見直し時期を書面で確かめる
• 条件: 当番・給与内訳・働き方・変更範囲を比べる
• 退職: 入社条件が揃ってから別の判断として決める

職務経歴書の変換例

「運用保守しかしていない」を、受付、再現、調査、変更、検証、再発防止、未経験、次に持つ責任へ変えます。

行動前チェックリスト

• アプリ運用保守とインフラ運用を分けた
• 直近三案件を受付・再現・調査・変更・確認・再発防止へ分けた
• 自分・開発・基盤・顧客・責任者の担当を分けた
• 保守開発・自社サービス・社内SE・SRE・導入支援を比較した
• 自己学習と本番の開発・変更実務を混ぜていない
• 顧客名・画面・テーブル・本番データを持ち出していない
• 90日で作る成果物・レビュー担当・期限を決めた
• 求人で入社90日の工程・成果物・配属決定者を聞く
• 夜間・休日・オンコール・手当・代休を確認する
• 案件終了・待機・評価・変更範囲を書面で確認する
• 対象条件に合う二社までへ同じ経歴と7問を渡す
• 相談・応募・内定承諾・退職を別々に判断する