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

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

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

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

目次

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

客先常駐でレガシー現場に当たるのは珍しくない

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

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

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

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

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

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

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

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

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

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

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

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

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

案内された共有サーバのフォルダには、同じソースファイルに日付をつけただけのコピーが並んでいました。担当していた出荷帳票のクラスだけで、フォルダの中に34個のバージョンが並んでいたのを覚えています。

単体テストも同じ調子でした。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つの現場を並べてみると、単純に「古い＝危険、新しい＝安全」とは言えないことが分かります。ここで経産省の定義が参考になります。同じレポートでは、レガシーシステムを次の5つの要因で説明しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

独学だと手が止まりやすいので、現場にない技術を体系的に押さえたいときは、教室でもオンラインでも講師に個別で教わる個人レッスン形式のスクール（Winスクールなど）を使う手もあります。エンジニアとして1年以上の実務経験があり、39歳以下で勤務地が一都三県か大阪なら、現場にない技術を軸にした転職の相談先として、経験者向けのユニゾンキャリアもあります。

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

それでも、転職市場で評価されるのは技術名の羅列より、その技術をどう使って何を判断したかという話です。古い現場での経験も、翻訳の仕方さえ間違えなければ材料になります。

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

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

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

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

つまり、古い技術に対応できる人材そのものが、供給側でも足りていないということです。同じレポートでは、2025年度のIT人材需給ギャップとして、産業分野全体で、ベンダー企業の供給が需要の66%にとどまるという試算も出ています。

この数字を見て、「じゃあ古い技術を極めれば安泰だ」と結論づけるのは早計だと思っています。私自身、COBOLを一行も書いたことがありませんし、この記事もそれを勧めるものではありません。

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

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

古い技術者が逼迫しているという事実は、あくまで「今すぐ食いっぱぐれる心配はしなくていい」という安心材料であって、「学ぶ必要がない」という話ではありません。両方を混同しないことが大事だと思っています。

まとめ

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

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

技術の古さそのものに怯えるより、体制側の欠落を見抜けるようになった方が、次の現場を選ぶときの判断材料になります。私自身、4社を渡り歩いて、ようやくその区別がつくようになったところです。