SESのレガシー案件は市場価値が下がる？4社の実体験と対策

客先に常駐して数か月、周りが当たり前に使っているGitやSpring Bootが、自分の現場にはまだ影も形もないと気づく瞬間があります。そんな経験はないでしょうか。

経済産業省の調査でも、ユーザー企業の61%がレガシーシステムを抱えているとされています。SESエンジニアとして5年ほど、4社の客先常駐を経験してきた私も、そのうち複数の現場で世の中の標準から遅れた技術と向き合ってきました。

今回は、実際に見てきた3種類の「古さ」の中身と、古い案件で積みにくいもの、在籍したまま市場価値を落とさないためにやっていることを、実体験からお伝えします。

目次

1. SESで古い技術の現場（レガシー案件）に当たるのは珍しくない
2. 4社を渡り歩いて見えた、3種類の「古さ」
3. 2社目｜研修で習ったGitが、現場にはなかった
4. 3社目｜旧システムから新システムへ載せ替える側だった
5. 4社目｜技術は新しいのに、その現場でしか通じない
6. 経産省のレガシー定義に照らすと、本当に危ないのはどこか
7. 自分の現場を判定する5つのチェックポイント
8. 保守・移行の古い案件で積みにくいもの、積めたもの
9. 在籍しながら市場価値を落とさないためにやってきたこと
10. レガシー案件の経験を市場価値に変える職務経歴書と面談の話し方
11. レガシー技術者が逼迫しているというデータの読み方
12. まとめ

SESで古い技術の現場（レガシー案件）に当たるのは珍しくない

結論珍しくありません。ユーザー企業の過半数がレガシーシステムを抱えていて、危ないのは古さそのものではなく別のところにあります。

私がこれまで見てきた古い現場のほとんどは、技術そのものの古さが致命傷だったわけではありませんでした。そこを見誤ると、モダンな技術を追いかける努力の方向を間違えます。

まず、自分の現場が特殊なのかどうかを確認しておきます。経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」によれば、産業分野全体でユーザー企業の過半数がレガシーシステムを保有しています(出典: 経済産業省「レガシーシステムモダン化委員会総括レポート」)。

経済産業省「レガシーシステムモダン化委員会総括レポート」（2025年5月公表）より。

大企業ほどレガシーを抱えているという結果は、直感とは少しずれるかもしれません。ただ、大企業ほどシステムの歴史が長く、関わってきた人・ベンダーの数も多いと考えれば、むしろ自然な数字だと感じます。

言語構成の面でも確認しておきます。IPAの「ソフトウェア開発分析データ集2022」は、2016〜2021年度の開発案件を集めたものです。主開発言語の比率は、集計対象の1,476件のうちJavaが42.4%、COBOLが16.3%でした(出典: IPA「ソフトウェア開発分析データ集2022」)。

新しく何かを作るより、すでにあるものに手を入れる仕事の方が、業界全体として増える方向にあるということです。

つまり「新卒で入った現場からずっとモダンな技術しか触っていない」という人の方が、少数派に近いと考えられます。まずこの前提を踏まえた上で、私が実際に見てきた古さの中身を分解していきます。

4社を渡り歩いて見えた、3種類の「古さ」

一口に「技術が古い」と言っても、私が経験した現場ではその中身がまったく違いました。時系列に沿って、具体的に書きます。

2社目｜研修で習ったGitが、現場にはなかった

1社目の研修（集合2週間＋自習3週間）では、Java・SQLと並んでGitの使い方も習いました。ブランチを切って、プルリクエストを出して、レビューしてもらってマージする。当時はそれが当たり前だと思っていました。

2社目に配属されて数日後、担当画面の改修に取りかかろうとして、リーダーに聞いたときのやり取りです。

案内された共有サーバのフォルダには、同じソースファイルに日付をつけただけのコピーが並んでいました。担当する画面のソースだけでも、同じファイルのコピーがいくつも並んでいました。

単体テストも同じ調子でした。JUnitのようなテストコードという発想自体がなく、Excelのチェックシートに手動でレ点を入れていく方式です。1画面あたりの確認項目はおおむね60項目前後でした。

リリースは月1〜2回、23時開始の深夜作業です。手順書どおりにFTPで本番サーバへファイルを転送し、対象サービスを手動で再起動します。ロールバック手順は用意されていましたが、自動化されたパイプラインという発想はありませんでした。

このとき初めて、「教わった標準」と「現場の実態」は別物だという感覚を持ちました。研修で習ったことが、そのまま通用するとは限らないという当たり前の事実に、配属されて初めて気づいたわけです。

この現場にいた時期に基本情報技術者を独学で取ろうと思ったのも、この不安が一因でした。古い技術ばかり触れていると、自分の知識が世の中の標準からどれくらいずれているのか、自信が持てなくなっていたからです。

関連記事基本情報技術者はSESで意味ない？取得後に現場で効いた場面SESエンジニアが独学で基本情報技術者を取得した後、実際にSESの現場でどう扱われたのかを実体験から書きます。スキルシートでの反…

3社目｜旧システムから新システムへ載せ替える側だった

3社目は二次請けとして、金融系のWebサイト案件に約2年半入りました。前半の約1年は、旧システムのデータを新システムへ移す移行作業で、後半の約1年半は新システムの保守改善です。

移行作業での私の役割は、手順書に沿ってリハーサルと本番切り替えを実行することでした。対象は数百テーブル、数百万件以上のデータで、リハーサルは3〜4回、本番の切り替えは連休をまたいで24時間以上かかりました。夜間や休日に作業する日もあり、振替休日で処理していました。

3社目の移行期。対象は数百テーブル、数百万件以上のデータでした。

後半の保守改善では、改修依頼や障害調査をフロントとサーバーの両方で担当しました。依頼ごとに担当が割り振られ、改修は毎回レビューを受けていました。影響範囲の調査に1件あたり半日〜1日かかり、リリース手順は重く、証跡やドキュメントも多い現場でした。

ポイント： 「技術が古い」と一口に言っても、2社目は現場そのものが古いままだった一方、3社目は旧システムから新システムへ載せ替える過程に立ち会っていました。同じ「古さ」でも、立場によって得られるものはまったく違います。

載せ替える側にいた経験で身についたのは、古いか新しいかの知識よりも、影響範囲の調べ方や、リリース手順と証跡の作り方でした。これらは業務ドメインが変わっても、その後の現場でそのまま使えています。

4社目｜技術は新しいのに、その現場でしか通じない

4社目は社内向け業務システムの保守・改修で、Java・TypeScriptを使っています。言語だけ見れば、2社目や3社目よりずっとモダンです。

ただし、この現場では独自の社内フレームワークが使われていて、書き方に強い癖があります。

研修や独学で覚えたSpring Bootの知識は、この現場ではほとんどそのまま使えません。言語は新しくても、フレームワークの作法だけを新しく覚え直す必要がありました。

ここで気づいたのは、「新しいか古いか」という軸とは別に、「世の中で通じるか、その現場でしか通じないか」というもう一つの軸があるということです。

2社目は古くて世の中でも通じない、3社目は古い技術を新しい世の中の標準に翻訳する過程、4社目は新しいのに世の中の標準からは外れている。同じ「不安の種」でも、中身は全部違います。

3つの現場を、技術と体制の観点で並べると次のようになります。

こうして並べると、不安の中身がそれぞれ別物だと分かります。次の章では、この違いを経産省の定義に照らして整理し直します。

経産省のレガシー定義に照らすと、本当に危ないのはどこか

結論技術の古さではなく、体制が整っているか、仕様が明確か、改良を続けられるかです。

3つの現場を並べてみると、単純に「古い＝危険、新しい＝安全」とは言えないことが分かります。ここで経産省の定義が参考になります。同じレポートは、レガシーシステムの要因を技術の面と経営の面に分けて説明しています。このうち、私の現場の整理に使ったのは次の4つです。

この中でもとくに核心的なのが、次の一文です。

現行システムが、メインフレーム等の古い技術や開発手法で構築されたシステムであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではないと言える

つまり、技術の古さ自体は、レガシーかどうかの決定打ではないということです。決め手は、体制・仕様の明確さ・改良を続けられるかどうかにあります。

この定義に照らして自分の現場を振り返ると、次のようになります。

レポートには、もう一つ気になる一文もあります。「既にメインフレーム等から脱却済であっても、運用維持保守に問題があれば再レガシー化する可能性がある」というものです。新しい技術に移行しても、体制がついてこなければまた古くなる、ということです。

4社目のような「新しいのに属人化している」現場は、この再レガシー化の入り口に近いのかもしれません。

自分の現場を判定する5つのチェックポイント

ここまでの整理を踏まえて、自分の現場を判定するときに私が実際に見ている観点をまとめます。技術の古さそのものより、体制側の観点を優先しています。

このうち1つ目と4つ目は、参画してすぐに確認できます。共有フォルダの中を見せてもらえれば、だいたいの実態が分かります。

2つ目と5つ目は、少し時間をかけて雑談の中で探る必要があります。「この仕組み、最初に作ったのはどなたですか」と聞いてみて、返ってくる答えが具体的か、それとも「もう分からない」で終わるかを見ています。

3つ目は、担当領域の改修依頼がどれくらいの頻度で来ているかで判断できます。ここ1年で機能追加の依頼が一件もないなら、その領域は塩漬けになっている可能性が高いです。

私の場合、2社目は1つ目と4つ目が明確にアウト、3社目は体制面ではアウトになる項目が少ない一方、原因特定に時間がかかる障害があり2つ目にやや不安が残る、4社目は2つ目にやや不安が残る、という判定になります。技術の新旧だけで見た印象とは、少し違う結果になりました。

保守・移行の古い案件で積みにくいもの、積めたもの

上位のレガシー案件の話でよく出てくるのが、保守だけでは設計や開発の経験が積めないという悩みです。私の場合、3社目の前半と後半でこれがはっきり分かれました。

移行期は手順書を正しく実行する役だったので、コードを書く経験はほとんど積めませんでした。「古い案件にいたから伸びなかった」というより、「手順を実行する役だったから伸びなかった」というのが実感です。

一方で保守改善期は、依頼内容の確認、改修の設計、実装、単体・結合テストと証跡作成まで関われました。同じ古い現場でも、割り当てられる役割で得られる経験が別物になります。

ここで大事なのは、移行の経験を「作業をした」で終わらせないことだと思っています。経産省のレポートは、古いシステムを新しい作りに移すモダン化そのものを主題にしています。その過程を現場で通ってきた人は、旧システムの癖と移行の落とし穴を知っている人として語れます。

この点は私の見立てですが、移行と保守の両方を経験した点は、のちの4社目でも効いています。3社目から持ち込めたのは次の3つです。

私は4社目で、自社の役職上は管理職として、手を動かしながら3〜5名を見る立場になりました。メンバーを見る側になって実感するのは、「どの技術を触ったか」より「どこまで任されて、何を判断したか」の方が、人を評価するときの手がかりになるということです。

在籍しながら市場価値を落とさないためにやってきたこと

現場を選べる立場にはないので、私が実際にやってきたのは、判定した上で個人としてできる範囲を埋めることでした。

正直に言うと、これらをやったからといって、劇的に何かが変わったという実感はありません。2社目でローカルにgit initしていたことも、当時の単価や評価にはまったく反映されませんでした。

独学だと手が止まりやすいので、現場にない技術を体系的に押さえたいときは、教室でもオンラインでも講師に個別で教わる個人レッスン形式のスクール（Winスクールなど）を使う手もあります。

関連記事SESで勉強時間がない｜残業月40〜60時間でも2か月で基本情報を取った学習法SESの客先常駐で残業が月40〜60時間ある現場にいると、勉強時間はどこから作ればいいのか。私物PC持ち込み禁止という制約の中で…

エンジニアとして1年以上の実務経験があり、39歳以下で勤務地が一都三県か大阪なら、現場にない技術を軸にした転職の相談先として、経験者向けのユニゾンキャリアもあります。

レガシー案件の経験を市場価値に変える職務経歴書と面談の話し方

結論古い現場の経験は、技術名の羅列ではなく「何を判断し、どう安全に変更したか」に翻訳すると材料になります。

市場価値への影響を単価で見ると、私の数字からは「古い技術だから下がる」とは判断できませんでした。1社目から2社目に移るとき、単価は月55万円から年490万円（月約41万円）へ下がっています。ただ、2社目の中では年490万円から530万円へ上がりました。3社目は年580万円から、離任時には650万円です。

古い現場だったから下がったのか、商流や更新のタイミングの問題なのかは、手元の数字だけでは切り分けられません。確かなのは、技術の新旧と単価を直結させて落ち込む必要はないということです。世間の単価相場については、確認できていない数字は書かないでおきます。

評価されやすい書き方は、職務経歴書でも面談でも同じです。3社目の移行・保守の経験を例に、技術名だけの書き方と、判断まで書いた書き方を並べます。

職務経歴書の全体の書き方は別の記事にまとめています。

関連記事SESの職務経歴書の書き方｜常駐先の会社名が書けないときの例SESの職務経歴書で会社名が書けないとき、何を書けばいいのか。金融系Webサイトのデータ移行・保守改善案件を例に、スキルシートと…

COBOLのように単一の古い技術に絞るのは、私は勧めにくいと考えています。その技術を使うシステムが移行されたとき、拠り所が技術名しかないと、判断の材料がなくなるからです。技術名の裏にある「影響範囲を調べる」「仕様を読み解く」「安全に変えて証跡を残す」という力は、フレームワークが替わっても持ち運べます。

古い現場から抜け出したいときも、まずはこの翻訳をしてから動く方が、次の現場の選択肢が広がります。

関連記事SESでスキルが身につかない理由｜移行と保守で見えた、積める現場の見分け方SESでスキルが身につくかどうかは、担当が「手順を実行する役」か「自分で判断して完結させる役」かで変わります。データ移行と保守改…

レガシー技術者が逼迫しているというデータの読み方

ここまで不安を煽るような話が多かったので、逆側の話もしておきます。古い技術の現場にいることは、悪いことばかりではありません。

経産省のレポートでは、ベンダー企業側の課題感として次の3つが挙げられています。

レガシー技術者については、案件が重なることで逼迫している、という整理です。一方、同じレポートが示す2025年度のIT人材需給ギャップ（ベンダー企業の供給が需要の66%にとどまるという試算）は、IT人材全体の数字です。レガシー技術者に限った数字ではないので、「古い技術者が足りない」ことの裏づけには使えません。

この2つを混ぜて、「じゃあ古い技術を極めれば安泰だ」と結論づけるのは早計だと思っています。

私が受け取っているのは、もう少し控えめな読み方です。古い技術に触れた経験そのものは、需要が枯れていく一方の経験ではない、というくらいの受け止め方です。

「新しい技術しか価値がない」という不安に、無条件に飲み込まれる必要はありません。ただし、その古い技術に対応できる人材として評価されるには、技術を知っているだけでなく、体制の不備を見抜いて動けることまでセットで求められると考えています。

ベンダー側でレガシー技術者が逼迫しているという指摘は、あくまで「今すぐ食いっぱぐれる心配はしなくていい」という材料であって、「学ぶ必要がない」という話ではありません。両方を混同しないことが大事だと思っています。

まとめ

SESの現場で技術が古いと感じたとき、本当に確認すべきは技術の年式そのものではありません。私が見てきただけでも、次の3つはまったく別物でした。

経産省の定義に照らせば、古い技術で構築されていても、体制が整っていて仕様が明確ならレガシーとは言えません。逆に、新しい技術でも属人化が進めば、再びレガシー化する可能性が残ります。

古い現場の経験は、技術名ではなく「どこまで任されて何を判断したか」に翻訳すれば、職務経歴書や面談で使える材料になります。技術の古さそのものに怯えるより、体制側の欠落を見抜けるようになった方が、次の現場を選ぶときの判断材料になります。私自身、4社を渡り歩いて、ようやくその区別がつくようになったところです。