運用保守から開発へ移る｜第二新卒が現職で作れる材料と移り方の順番【2026年版】
運用保守の現場にいるエンジニアが、こう思う瞬間があります。
「このままだと、開発の経験がないまま歳を取る」
この感覚は正しい。そして、動くなら第二新卒の年齢帯が最も有利です。
運用保守から開発へ移るとき、最大の壁は「開発の実務経験がない」という一点です。書類でこれを問われると、多くの人が答えられません。
しかし、この壁は現職にいる間に低くできます。
運用保守の現場には、開発の材料が実は転がっています。作業の自動化、監視の設定、手順書のコード化、簡単なツールの作成。これらは全部、開発の実績として書けます。
問題は、それをやっていないか、やっていても記録していないことです。
この記事では、現職で作れる材料、社内異動と転職の使い分け、職務経歴書の書き方、面接での質問、応募先の選び方を整理します。
1. 結論：やることは3つ
1. 現職で、コードを書く作業を1つ作る。自動化のスクリプトで十分です。
2. その成果を、記録に残す。何を、どのくらい減らしたかを数字にします。
3. 社内異動の可能性を先に確認する。転職より早い場合があります。
1番目が全てです。
「開発経験なし」と「小さくても自動化を作った」の間には、書類上で大きな差があります。
| 状態 | 書類での見え方 |
|---|---|
| 手順書通りに作業していた | 開発の材料がない |
| 学習でコードを書いた | 実務ではない |
| 業務の一部を自動化した | 実務でコードを書いた |
3行目に到達することが、最初の目標です。
2. 運用保守で作れる開発の材料
現職の中に、材料は必ずあります。
| やること | 難易度 | 実績としての強さ |
|---|---|---|
| 定型作業をスクリプト化 | 低 | 中 |
| ログの集計を自動化 | 低 | 中 |
| 監視の設定・通知の整備 | 中 | 中 |
| 手順書の内容をコード化 | 中 | 高 |
| 小さな社内ツールの作成 | 中 | 高 |
| 構成管理の導入 | 高 | 高 |
最初は1行目から始めてください。
毎日手で実行している作業を、1つスクリプトにする。これだけで、書類に書ける材料が1つ増えます。
「日次で手動実行していた約15件の確認作業をスクリプト化し、所要時間を40分から5分に短縮しました」
この一文が書けるかどうかが、書類の分かれ目です。
勝手にやらない
重要な注意点です。
本番環境に影響する変更を、許可なく行わないでください。運用保守の現場では、無断の変更が最も重い事故につながります。
必ず、次の順で進めてください。
- 上長に「作業の効率化を試したい」と伝える
- 検証環境か、影響のない範囲で作る
- 動作を確認してから、適用の許可を得る
- 手順と結果を記録に残す
この順番を守ること自体が、面接での評価材料になります。
3. 社内異動と転職の使い分け
先に社内異動を検討してください。転職より早い場合があります。
| 方法 | 有利な点 | 不利な点 |
|---|---|---|
| 社内異動 | 実績が既に知られている | 枠がないと動けない |
| 転職 | 選択肢が多い | 未経験扱いになる |
社内異動の最大の利点は、「未経験扱いにならない」ことです。
社内であれば、あなたが何をできる人か既に知られています。転職では、書類と面接だけで判断されます。
社内異動を相談する言い方
「今の運用の業務を続けながら、開発側の作業にも関わらせていただくことは可能でしょうか。まずは、運用側で発生している定型作業の自動化から始められればと考えています」
「異動させてください」より、「関わらせてください」から入るほうが通ります。
いきなり異動を求めると、人員配置の話になって止まります。作業レベルで関わり始めて、実績を作ってから異動の話にするほうが早い。
ただし、次の場合は転職を優先してください。
- 会社に開発部門がない
- 過去に運用から開発に移った人がいない
- 相談しても半年以上動きがない
3行目が重要です。期限を切ってください。
4. 職務経歴書の書き方
運用保守の経験を、開発の言葉に翻訳します。
| 運用の言葉 | 開発側に伝わる言葉 |
|---|---|
| 障害対応 | 原因の切り分け、ログの解析 |
| 手順書に沿って作業 | 手順の理解、正確な実行 |
| 監視 | 異常の検知、閾値の設計 |
| 定期作業 | 定型処理、自動化の対象 |
| 問い合わせ対応 | 要件の聞き取り、再現手順の作成 |
2行目に注意してください。
「手順書に沿って作業していました」だけだと、指示待ちの人に見えます。
手順書を作った、更新した、不足を補ったという部分まで書いてください。
記載の型
株式会社○○ 20○○年4月〜現在 業務システムの運用保守を担当。
・約30台のサーバーの監視と、日次バッチ約40本の実行結果の確認を担当。 ・障害発生時の一次切り分けを担当し、月平均5件を対応。影響範囲の確認と関係部署への連絡までを担当。 ・日次で手動実行していた約15件の確認作業をスクリプト化（Python）。所要時間を40分から5分に短縮。 ・手順書に記載のないエラーへの対応を記録し、手順書に追記する運用を提案。同種のエラーへの対応時間を平均1時間から20分に短縮。
3行目と4行目が、開発への意思を示す部分です。
使った言語やツールは、必ず括弧で明記してください。書類選考では、この記載で要件との照合が行われます。
5. 学習の示し方
実務の材料が少ない場合、学習で補います。ただし順番があります。
| 書く順番 | 内容 |
|---|---|
| 1 | 運用保守の実務 |
| 2 | 業務内での自動化・ツール作成 |
| 3 | 業務外での学習・制作物 |
3番目から書き始めないでください。実務経験がないことの強調になります。
業務外の学習を書く場合は、次の形にしてください。
| 弱い書き方 | 強い書き方 |
|---|---|
| 「Pythonを学習中」 | 「業務の自動化に使うため、Pythonで○を作成」 |
| 「Webアプリを作った」 | 「運用の記録を管理するツールを作り、社内で試用」 |
| 「資格の勉強中」 | 「○月に受験予定」 |
業務と結びついた学習が、最も評価されます。
作ったものが実際に使われているなら、それは実務です。「個人的に作ったツールを、チームの2名が使っています」と書けるなら、書いてください。
6. 応募先の選び方
全ての開発職に応募できるわけではありません。相性があります。
| 応募先 | 運用保守からの相性 |
|---|---|
| インフラ寄りの開発 | 高い |
| 社内システムの開発 | 高い |
| 業務システムの受託開発 | 中〜高 |
| Webサービスの開発 | 中 |
| 自社サービスの新規開発 | 低〜中 |
上2つから狙うのが現実的です。
運用の経験が直接評価される領域だからです。
インフラ寄りの開発（構成の自動化、監視基盤、社内基盤）では、運用を知っていることが前提の技能として扱われます。むしろ、運用未経験の人より有利です。
社内システムの開発も同様です。利用者の困りごとを知っている人が作るほうが、使われるものになります。
求人票で見る場所
| 見る場所 | 良い兆候 |
|---|---|
| 業務内容 | 「運用も含む」「保守開発」 |
| 歓迎条件 | 「運用経験」「インフラ経験」 |
| 開発体制 | 少人数、幅広く担当 |
| 教育 | 未経験からの育成の記載 |
「運用経験歓迎」と書かれている開発求人は、必ず候補に入れてください。
7. 面接で聞かれる3問
質問1：「なぜ開発をやりたいのですか」
「運用がつまらないから」は避けてください。
「運用の中で、手作業で繰り返している処理を自動化したことがあります。作ったものが使われて時間が減っていくのを見て、直す側より作る側に関わりたいと思うようになりました」
実際にやったことを起点にすると、説得力が出ます。
質問2：「開発の実務経験がありませんが、大丈夫ですか」
正面から認めた上で、材料を出してください。
「チームでの開発経験はありません。業務の中では、日次の確認作業をPythonでスクリプト化し、実際に運用に組み込んでいます。作った後の保守も自分で行っており、他のメンバーが使えるよう手順も残しました。規模は小さいですが、書いて終わりにはしていません」
「保守まで自分でやった」が効きます。運用出身者ならではの答え方です。
質問3：「本番環境での作業経験はありますか」
これは運用出身者にとって、有利な質問です。
「あります。手順書に沿った作業を日常的に行っており、記載にないことはしない、判断に迷う場合は止めて確認する、という進め方を徹底してきました。作業前に戻す手順を確認しておくことも含めて習慣になっています」
開発だけの経験者には答えられない質問です。ここで差をつけてください。
8. 進め方と時間配分
| 時期 | やること |
|---|---|
| 今月 | 自動化できる定型作業を1つ選ぶ |
| 1〜2ヶ月目 | 上長の許可を得て作成、記録を残す |
| 2〜3ヶ月目 | 社内異動の可能性を相談する |
| 3〜6ヶ月目 | 材料をもう1つ増やす |
| 6ヶ月目 | 社内で動きがなければ転職活動を開始 |
最後の行が重要です。期限を切ってください。
「そのうち開発をやらせてもらえる」と待ち続けるのが、最も時間を失う進め方です。
そして、材料は転職活動の前に作ってください。
書類を書く段階になってから「書くことがない」と気づくと、そこから作り始めることになります。3ヶ月あれば、材料は2つ作れます。
記録の残し方
作ったものは、次の形で記録してください。
- 何を自動化・作成したか
- 使った言語・ツール
- 前後の時間や件数の変化
- 現在も使われているか
この4点を、作った直後にメモしてください。時間が経つと数字を思い出せなくなります。
なお、業務で書いたコードや社内資料を、社外に持ち出さないでください。記録するのは、何をどのくらい改善したかという事実だけです。
9. よくある質問
Q. 運用保守の経験は開発で評価されますか
領域によっては、明確に評価されます。
インフラ寄りの開発や、社内システムの開発では前提となる知識です。本番環境での作業経験や、障害対応の経験は、開発だけの経験者にはありません。
Q. 何の言語を学べばいいですか
まず、現職で使えるものから始めてください。
自動化の用途であれば、シェルスクリプトかPythonが現実的です。「業務で使える」ことが、実績を作る上で最も重要です。
Q. 資格は取るべきですか
基礎的な資格は、学習の証明として有効です。
ただし、資格より業務内での実績のほうが評価されます。資格の勉強に時間を使うより、自動化を1つ作るほうが効果が大きい。
Q. 年齢的に間に合いますか
第二新卒の年齢帯であれば、十分に間に合います。
むしろ、運用保守の経験が2〜3年ある状態は、未経験より有利です。年齢が上がるほど未経験扱いが難しくなるため、動くなら早いほうが有利です。
Q. 年収は下がりますか
下がる場合があります。
未経験の領域に移るため、一時的に下がることは想定してください。ただし、開発経験を積んだ後の伸びを含めて判断する必要があります。
Q. 社内で相談したら、引き止められました
その場合、期限を決めてください。
「前向きに検討する」と言われてから半年動きがなければ、実際には枠がないと判断して構いません。
Q. 夜勤があって学習の時間が取れません
業務内で材料を作るほうを優先してください。
業務外での学習が難しい状況であれば、業務そのものの中で自動化を作るのが最も効率的です。時間も評価も、業務内で作るほうが得られます。
Q. どのくらいの規模のものを作れば実績になりますか
規模は問いません。
「業務で使われている」ことのほうが重要です。10行のスクリプトでも、毎日実行されていれば実績です。
10. まとめ：今週やる3つのこと
1. 毎日手で実行している作業を1つ選ぶ。これが最初の材料になります。
2. 上長に「効率化を試したい」と相談する。無断で本番に触らないでください。
3. 社内異動の可能性を一度聞く。過去に移った人がいるかどうかが判断材料です。
材料は、転職活動の前に作ってください。書類を書く段階で気づくと、そこから3ヶ月かかります。
この先、読むべき記事
- 20代エンジニアの転職｜実務1〜3年で年収とスキルを上げるキャリアアップ術（キャリアの伸ばし方）
- SESから抜けるための準備｜案件を経歴に変える3ステップ（似た構造の脱出）
- エンジニアの職務経歴書｜書く順番と3つの必須欄（書類の作り方）
- インフラエンジニアの自己PR｜未経験・第二新卒の例文6パターンと止めない仕事の書き方（インフラ側の書き方）
- チーム開発の経験がないとき｜一人で作った実績の伝え方（開発経験の不足を補う）
- SREとは何をする仕事か｜第二新卒がインフラから移るための道筋（運用から向かうもう一つの先）
- テストから開発へ移る｜第二新卒が現職で作れる材料と順番（テスト側からの同じ移り方）
- 要件定義・上流工程へ移る｜第二新卒が実装から移るための材料と順番（開発の先にある工程）
- 障害対応の動き方｜未経験エンジニアが最初に覚える5つの順番（障害対応を実績にする）
この記事を書いた人
木戸 悠介（きど ゆうすけ）／なぜキャリア？運営者。1996年生まれ、神戸市出身。
23歳で上場企業子会社に新卒入社し、メディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた。2ヶ月で10社に応募し2社から内定。その後スタートアップに3人目の社員として参画し、現在は自分の会社を経営している。