SESの保守案件・保守運用はスキルがつかない？改修10か月で身についたことと抜け出し方

「保守案件に入ったら、新しいものを作れないからスキルがつかないよ」と、研修同期に言われたことはないでしょうか。私は今の現場に入る前、まさにその言葉で身構えていました。

SESエンジニアとして5年ほど、4社の客先常駐を経験し、今は4社目で社内向け業務システムの保守・改修に参画して約10か月になります。なお、この記事で扱う「保守」は、監視や巡回のような運用保守ではなく、コードを触るアプリケーションの保守・改修です。

今回は、保守・改修で実際に身についたことと、逆に積めなかったこと、そして転職しなくても社内で取れた動きを、実体験で書きます。

この記事で分かること

SESの「運用保守」と「保守・改修」の違い（この記事が扱う範囲）
10か月・63件のチケットで実際に身についた5つのこと
保守・改修では積みにくいもの（作業単位の表つき）
転職一択にしない、社内でできる抜け出し方と職務経歴書への書き方

SESの保守案件・保守運用とは？「運用保守」と「保守・改修」は別物
私の現場の概要
SESの保守案件でスキルがつかないと言われる理由は、半分だけ本当だった
保守・改修の10か月で身についた5つのこと
1. 他人のコードを読んで、変更箇所を特定する力
2. 障害の一次切り分け
3. 問い合わせから仕様を逆算する力
4. リグレッションを避けるテスト観点（失敗から学んだこと）
5. 依頼の裏にある要件を聞き返す力
逆に、保守・改修では積みにくいもの
運用保守（監視・巡回）の現場の場合
保守案件から抜け出すには？転職しなくても社内で取れた動き
改修の中で、設計に触れる
テストの観点を、チームの資産にする
職務経歴書には、件数と時間の変化で書く
営業に、次に入りたい現場の希望を伝える
それでも転職を考えたほうがいいタイミング
まとめ

SESの保守案件・保守運用とは？「運用保守」と「保守・改修」は別物

「保守運用」という言葉は、検索すると2種類の仕事が混ざって出てきます。サーバーの監視や定型作業を指す場合と、すでに動いているアプリケーションのコードを直す場合です。先にここを分けておかないと、スキルがつくかどうかの議論がかみ合いません。

私が経験しているのは後者です。違いを表にすると、次のようになります。

	運用保守（監視・巡回・定型作業）	保守・改修（コードを触る）
主な作業	監視画面の確認、バッチ実行の確認、手順書どおりの作業	仕様変更の実装、障害の原因調査と修正、問い合わせ対応
コードを触るか	ほとんど触らない	毎日触る
成果物	作業報告、障害の一次報告	修正したソース、テスト結果
私の経験	なし	4社目で約10か月

運用保守側の経験は私にはないので、そちらの話は後ろの章で「見分け方」として触れるだけにします。経験していないことを経験したように書くのは避けたいからです。

私の現場の概要

4社目は二次請けで、客先の社内向け業務システムを、独自の社内フレームワークを使って保守・改修しています。使う言語はJavaとTypeScriptで、今はほぼフル在宅で働いています。

仕事は「チケット」という単位で降ってきます。業務部門からの要望、障害の報告、問い合わせの3種類が、窓口を通ってチケットになります。

社内フレームワークの癖そのものは、別の記事で詳しく書きました。

この記事は、技術の古さではなく、日々の作業の中身を見ていきます。

SESの保守案件でスキルがつかないと言われる理由は、半分だけ本当だった

結論身につくものはあります。ただし、新規開発で積めるものと種類が違い、積めないものも確実にあります。

参画前に私が不安に思っていたのは、主に3点でした。同じ作業の繰り返しになる、設計に触れない、新しい技術に触れない、の3つです。

2社目では設計・実装・単体テストを一通り経験していました。そのぶん、「作る側から外れる」ことへの焦りが強かったのだと思います。

10か月やってみた感触を先に書くと、不安の3つのうち、設計に触れない点は本当でした。同じ作業の繰り返しになるかどうかは、中身次第で、思っていたより繰り返しにはなりませんでした。

まず、10か月間に自分が担当した63件の内訳です。

参画約10か月で担当したチケット 63件の内訳

改修 41件障害調査 14件問い合わせ 8件

改修（項目追加・条件変更など）41件
障害調査（原因特定と修正）14件
業務部門からの問い合わせ回答 8件

私個人が担当したチケットの内訳。現場全体の比率ではなく、担当範囲に偏りがあります。

改修が約3分の2で、残りが障害調査と問い合わせです。新規に画面をゼロから作る仕事は、この10か月で1件もありませんでした。

つまり、保守・改修は「作る」より「読む・調べる・説明する」の比率が高い仕事です。スキルがつかないのではなく、つくスキルの種類が違うというのが、現時点での私の見立てです。

「判断の経験が積めない」という構造的な話は、すでに別の記事で書いています。

こちらは構造の話で、この記事では日々の作業の中身を具体的に書いていきます。

保守・改修の10か月で身についた5つのこと

ここからが本題です。63件のうち、自分の中で「この件で変わった」と思えた出来事を5つ選びました。どれも劇的な成長ではなく、小さな積み重ねです。

1. 他人のコードを読んで、変更箇所を特定する力

参画3週目に任された最初のチケットは、「帳票の出力条件に1項目追加する」という、依頼文だけ見れば10行ほどで終わりそうなものでした。実際には、変更箇所を特定するだけで2日半かかりました。

誰が何のために書いたか分からないコードを、画面のどこから読み始めればいいのかが分からなかったからです。入口を見つけるまでに半日、そこから出力までの流れを追うのに丸1日かかりました。

3か月ほど経ったころ、読む順番が自分の中で固まりました。

画面の項目名から入口を探す画面に表示されている文言で検索して、その画面が呼んでいる処理の入口を見つけます。
入口から、データを取る処理までを一本の線で追う途中の分岐は、いったん全部読まずに飛ばします。
データの取得元（SQL）を確認する画面に出ている値が、どの表のどの列から来ているかを特定します。
出力側（画面・帳票）で、値がどう整形されるかを見る桁数や丸めはここで決まることが多いです。

この型ができてからは、同じ種類の項目追加チケットが約3時間で終わるようになりました。2日半が約3時間です。

ポイント： 他人のコードを読む速さは、才能ではなく「読む順番の型」で決まります。型は、読んだ本数でしか作れません。保守・改修は、これを強制的に繰り返せる仕事です。

新規開発では、自分で書いたコードを読む時間のほうが長くなります。他人が書いたコードを毎日読むという経験は、保守・改修の側に偏って積めるものです。

2. 障害の一次切り分け

参画4か月目に、業務部門から「承認済みのはずの伝票が、一覧に出てこない」という報告が来ました。担当は私でした。

最初の2時間半は、一覧の画面の処理ばかり読んでいました。コードに誤りが見つからず、焦って別の箇所まで疑い始めたころ、先輩に「データのほうは見た？」と聞かれて、ようやく順番が間違っていたことに気づきました。

先輩

その伝票、承認日時の列は入ってた？

私

見ていません。コードのほうだけ見ていました。

先輩

古いデータだと空のままのやつがあるんだよね。まずデータからだよ。

原因は、過去のデータ移行のときに承認日時が空のまま残った伝票を、一覧のSQLが「承認日時が入っているもの」として除外していたことでした。コードの誤りではなく、データとコードの組み合わせで起きる不具合です。

それ以来、障害の一次切り分けは次の順で進めています。

一次切り分けの順番

再現条件を固める（どの画面・どの操作・どのデータで起きるか）
データを疑う（同じ操作で出る伝票と出ない伝票の列を並べて比べる）
最後にコードを読む（ここまでで当たりがついていれば、読む範囲が絞れている）

この順番に変えてから、同じ種類の「画面に出ない」系の調査は、40分前後で原因の当たりがつくようになりました。最初の2時間半と比べると、4分の1以下です。

障害の一次切り分けは、運用の現場で最もつぶしの効くスキルだと感じています。コードが読めるだけでは足りず、データとコードの両方に目を向ける癖が、保守のチケットを処理するたびに鍛えられます。

夜間に障害の連絡が来たときの手当や扱いは、別の記事に整理しました。

3. 問い合わせから仕様を逆算する力

仕様書の更新が止まっている現場では、「いま動いているシステムが何をしているか」を、コードとデータから逆算するしかありません。それを毎回やらされるのが、問い合わせ対応です。

参画6か月目に、業務部門の担当者から「請求予定額が、先月と1円だけ違う。なぜか」という問い合わせが来ました。仕様書には、端数処理の記載がありませんでした。

コードを追うと、端数処理の方式（切り捨てか四捨五入か）が得意先ごとの区分設定で決まっていて、先月から区分が変更された得意先だったことが分かりました。回答を書くまでに丸1日かかりました。

その後、同じ種類の問い合わせが3件続きました。その3件は、最初の1件で作った「端数処理の決まり方」のメモを見ながら、それぞれ15分程度で回答できました。

初回の回答にかかった時間1日コードとデータから仕様を逆算

同種の問い合わせ3件15分/件メモを見ながら回答

端数処理に関する問い合わせへの対応時間の変化。

ここで鍛えられるのは、実装力というより「システムの振る舞いを、仕様書なしで言葉にする力」です。業務部門の担当者に、専門用語を使わず説明するところまでが回答なので、説明の技術も同時に積み上がります。

この力は、新規開発で仕様書どおりに作っていたときには、ほとんど使いませんでした。

4. リグレッションを避けるテスト観点（失敗から学んだこと）

きれいな話ばかりではありません。参画7か月目に、私は改修で差し戻しを受けました。

共通で使われている日付整形の処理に、引数を1つ足すだけの改修でした。対象の画面で単体テストをして、問題なしと判断して提出しました。ところが受入確認で、別の画面の帳票の日付表示が崩れていることが見つかり、差し戻しになりました。

そのときの反省

私が確認したのは「頼まれた画面が直ったか」だけで、「直したことで、他が壊れていないか」を確認する観点が、そもそも頭にありませんでした。差し戻しの連絡を受けたとき、呼び出し元の画面名が3つ並んでいるのを見て、背筋が冷えたのを覚えています。

この件のあと、共通部品を触る改修の前に、確認の観点を決めてから作業するようにしました。自分用に作ったExcelの観点表には、今は25項目ほどあります。

共通部品の呼び出し元ごとに、代表的な入力を1ケースずつ確認する
境界値（0件、1件、1ページを超える件数、空欄、全角・半角の混在）を通す
変更前と変更後で、変わらないはずの出力が変わっていないことを見比べる

呼び出し元そのものの洗い出し方は、冒頭近くで紹介した「スキルが身につかない理由」の記事に書いたので、ここでは触れません。ここで書きたいのは、「何を確認すれば壊していないと言えるか」という観点を持つことが、改修の腕前を分けるということです。

保守・改修では、新規開発と違って、守るべき既存の動作が常にあります。差し戻しを1回受けて痛い目に遭うのが一番早い学び方ですが、できれば受ける前に観点を持っておくほうが安く済みます。

5. 依頼の裏にある要件を聞き返す力

最後の1つは、技術というより、仕事の進め方です。

参画8か月目、業務部門から「一覧画面にボタンを1つ増やしてほしい」というチケットが来ました。依頼文はそれだけで、何のボタンなのかが書かれていませんでした。

そのまま受け取ると、ボタンの追加で数時間の仕事です。ただ、何のためのボタンなのか分からないまま作ると、また差し戻しになる予感がしたので、窓口のリーダー経由で業務担当者に確認を取りました。

私

このボタンは、押したあとにどうなる想定でしょうか。

業務担当者

いまは月末に、一覧の内容を手作業でExcelにコピーして、集計しているんです。

私

では、必要なのはボタンというより、一覧の内容を一括で出力する機能ですね。

結果として、チケットの中身は「ボタンの追加」から「一覧のCSV一括出力」に変わり、工数の見積もりも出し直しになりました。依頼どおりに作っていたら、月末の手作業は何も変わらないままでした。

依頼文は、業務部門の人が自分の言葉で書いた「手段」であることが多いです。その裏にある「困りごと」を聞き出して、本当に必要なものに置き換える作業は、要件定義の入口にあたる経験です。

保守・改修の現場は、業務部門との距離が近いぶん、この経験を小さな単位で何度も積めます。新規開発の下流工程だけを担当していたときには、まず経験できなかったことでした。

逆に、保守・改修では積みにくいもの

結論設計・技術選定・ゼロから作る経験は、保守・改修の中では積みにくいです。ここは「ない」と認めたほうが次の手が打てます。

5つ書いたあとで言うのも何ですが、保守・改修で身につかないものは、はっきりあります。作業の単位ごとに、積めるものと積みにくいものを整理しました。

作業の単位	身につくもの	積みにくいもの
改修（項目追加・条件変更）	他人のコードの読解、変更箇所の特定、既存動作を壊さないテスト観点	画面・DB・処理構造の設計（構造はすでに決まっている）
障害調査	データとコードの両面からの切り分け、ログの読み方	障害が起きにくい作りにするための設計判断
問い合わせ対応	仕様の逆算、専門用語を使わない説明	仕様そのものを決める経験
依頼の整理	困りごとを聞き出して要件に直す力	複数の要望をまとめた要件定義全体
リリース作業	手順書に沿った本番反映、切り戻しの考え方	リリース手順そのものの設計・改善

この表の右の列に共通しているのは、「構造や方針を決める側に回る経験」が積みにくいということです。

私の現場では、技術選定は元請けより上で決まっています。独自の社内フレームワークの中で改修する以上、「どのライブラリを使うか」「どう分割するか」を決める場面が、そもそも存在しません。

新規に画面をゼロから作ることもないので、画面遷移の設計や、テーブル設計を、一から考える機会もありませんでした。

正直に書くと、ここが一番もどかしいところです。2社目では設計も担当していましたが、4社目に来てから10か月のあいだ、設計書を一から書いた回数はゼロです。ここは保守・改修にいる限り、放っておくと錆びていきます。

運用保守（監視・巡回）の現場の場合

先に書いたとおり、私は監視や巡回が中心の運用保守の現場にいたことがありません。ここからは経験談ではなく、自分の現場との比較から考えた見分け方です。

コードを触らない運用保守の場合、上の表の「身につくもの」は、障害対応の手順や、一報を入れる流れの理解に絞られるはずです。作業の中心が「手順書どおりに実行して報告する」なら、自分で考える余地が小さくなります。

面談・参画前に確かめたいこと

作業の中心は、手順書どおりの定型作業か、原因調査やコード修正か
手順書にない事象が起きたとき、誰がどう調べるのか（自分が調べる余地があるか）
障害対応の結果を、手順書や仕組みの改善につなげる運用があるか
改修チケットを担当する機会が、メンバーに回ってくるか

どれも、聞いてみれば答えてくれる質問です。「保守案件」と一括りにせず、作業の中身を面談で確認しておくだけで、入ったあとのギャップはかなり減らせると考えています。

保守案件から抜け出すには？転職しなくても社内で取れた動き

結論抜け出す前に、今の現場の中で設計や自動化に近い仕事を自分から取りにいく余地があります。それでも足りなければ、そこで初めて転職を考えれば十分です。

保守案件の記事を読むと、結論はだいたい「自社開発へ転職しましょう」に寄っています。それが正しい場面もありますが、在籍したまま取れる動きもあるので、私が実際に試したものと、その結果を書きます。うまくいかなかった部分も含めてです。

改修の中で、設計に触れる

参画8か月目に、課題管理票を読み返していて気づいたことがあります。帳票に項目を1つ追加するチケットが、参画前の分も含めて、過去1年のあいだに6件あったのです。

そのたびに、ほぼ同じ手順でコードを書き足していました。6件とも担当者は違い、書き方も微妙に違っていました。

そこで、A4で1枚の設計メモを作りました。項目の定義を設定ファイルに外出しして、コードの変更なしで追加できる形にする案です。

リーダーに提出したところ、元請けまで話が上がりました。ただ、結論は「保守予算の範囲外のため、全体の共通化は見送り」でした。

過去1年の同種チケット6件帳票への項目追加

設計メモの結果一部採用全体は保留、私の担当分のみ

全体の共通化は通りませんでしたが、私が担当する範囲では新規の項目を設定ファイルで定義する形が採用されました。

全面採用ではなかったので、成果としては小さいです。それでも、自分の担当範囲で「どこまで構造を変えるか」を考えて、案を文書にして通すところまでを、保守・改修の中で経験できました。

設計書を一から書く経験は得られませんが、「既存の構造をどう整理し直すか」を考える経験は、改修の中に潜んでいます。同じ種類のチケットが3件以上並んだら、それが設計メモを書くタイミングだと考えています。

テストの観点を、チームの資産にする

先ほどの自作のテスト観点表は、最初は自分用でした。ただ、共有フォルダに置いておいたところ、同じ現場にいる協力会社のメンバー1人が使い始めました。

テストの自動化まで提案できればよかったのですが、私の現場では外部の自動化ツールを入れられず、契約の範囲でもありません。その事情は別の記事に書きました。

できる範囲でやるなら、観点を文書にして共有するところまででした。自動化の提案は現時点では出していませんし、出す見込みも今のところありません。

職務経歴書には、件数と時間の変化で書く

保守・改修の経験は、そのまま書くと「既存システムの保守・改修を担当しました」の一行で終わってしまいます。これでは、何ができるのかが伝わりません。

私が使っている書き方は、作業の種類・件数・変化を並べる形です。

弱い書き方　社内向け業務システムの保守・改修を担当
強い書き方　社内向け業務システムの保守・改修（約10か月、63件）。障害調査14件では、データとコードの両面から切り分ける手順を確立し、原因特定までの時間を2時間半から約40分に短縮。依頼内容の裏にある業務の困りごとを確認し、ボタン追加の依頼を一括出力機能に置き換えた

数字は、自分のチケット管理画面を見返せば拾えます。「63件」「2時間半から40分」のような具体的な数字があるだけで、読む側が仕事の中身を想像しやすくなります。

書き方の全般は、別の記事で詳しくまとめました。

保守・改修の経験が転職でどう評価されるかについては、私は今、転職活動をしていないので、自分の経験として断言はできません。ただ、評価する側にとって分かりやすいのは、技術名の羅列ではなく、「何をどう判断して、どう変わったか」が書いてあることだと考えています。

営業に、次に入りたい現場の希望を伝える

在籍している間でも、次の現場に何を求めるかは、営業に先に伝えておけます。「設計工程を含む案件」「新規開発がある案件」のように、具体的に言葉にしておくのがコツです。

私自身は、4社目に入ってから、営業に現場を変えたいという申し出をしたことはありません。ただ、手順だけは確認してあります。

それでも転職を考えたほうがいいタイミング

ここまで書いた動きを試しても、なお足りない場合があります。私が転職を検討する判断軸として持っているのは、次の2つです。

転職を考え始める目安

半年たっても作業が同じ型の繰り返しになっている読む順番も切り分けの型もできて、新しい判断が必要な場面が減ってきたら、その現場で積めるものは出尽くしています。
設計メモを出す余地が現場にない自分の担当範囲の構造を変える提案が、誰にも届かない・聞かれもしないなら、社内で設計に近づく道は塞がっています。

私の現場は、まだ1つ目に当てはまっていません。10か月たっても、毎月のように初めて見るデータの組み合わせに出会うからです。

転職を考え始めたときの選択肢としては、自社開発だけでなく、社内SE・ITエンジニアの求人を扱い、常駐のない求人が中心の転職サービス（社内SE転職ナビなど）もあります。

自社開発企業への転職については、実際に求人を見て面談まで行った記録を、別の記事にしています。