忍び寄る「塩漬け」の恐怖。君のキャリアは大丈夫か？
やあ、みんな。海外でITエンジニアやってます。
メインはC#とWPFを使ったデスクトップアプリケーションの開発と設計。まあ、イマドキのキラキラしたWeb系（ReactとかNext.jsとか？）とはちょっと違う、地味だけど社会のインフラを支える系のシステムを作ってる感じかな。
さて、このブログを読んでる君は、きっと「海外でエンジニアとして働きたい」とか「海外のモダンな開発環境でスキルアップしたい」って思ってるんじゃないかな。
うんうん、その気持ち、めちゃくちゃ分かる。僕もそうだった。
日本を出る前は、「海外のIT企業＝GoogleやMicrosoftみたいな最先端の技術」「クラウド、マイクロサービス、AIが当たり前」って、どこかで信じてた。日本の古いSIer体質から抜け出して、自由な環境でバリバリコードを書きたい、ってね。
でもね、先に言っておく。その幻想は、こっちに来て早々にぶっ壊される可能性が高い。
もちろん、そういうキラキラした現場もあるよ。でも、それと同じくらい、いや、体感的にはそれ以上に、僕たちが直面するのは**「レガ<b>シー</b>システム」**っていう、とんでもない化け物なんだ。
「レガシーシステム？古い技術のことでしょ？まあ、どこにでもあるよね」
そう思った？甘い。
僕たちが今から話すのは、単なる「古い」って話じゃない。それは、会社を、社会を、そして**君たちエンジニアのキャリアを静かに殺していく「時限爆弾」**の話だ。
止まる航空会社、凍りつく銀行口座
つい最近のニュース、君は見た？
2025年10月、アラスカ航空で大規模なIT障害が発生した。データセンターの「障害」が原因で、49,000人以上の足に影響が出た。しかも、この会社、2025年に入ってからこれが2回目の大規模障害だっていうじゃないか。（※参考：GeekWire, 2025/10/24）
航空業界だけじゃない。金融なんて、もっと悲惨だ。
イギリスでは、2023年からの約2年間で、主要な銀行（BarclaysとかHSBCとか）がシステム障害で止まった時間を合計したら、なんと803時間。丸々33日間以上、銀行システムがどこかしらトラブってた計算になる。（※参考：UK Parliament Treasury Committee, 2025/03/06）
特にヤバかったのが、2025年2月のBarclaysの障害。彼らの「メインフレーム」（出たよ、レガシーの王様…）の処理能力がガクンと落ちて、オンライン決済の56%が失敗した。給料日に振り込みができない、家賃が払えないってパニックになった人が続出したんだ。結局、銀行は多額の補償金を払うハメになった。
「いやいや、それは海外のデカい会社の話でしょ？」
本当にそう思う？
僕もね、海外の今の会社（そこそこの規模の事業会社だ）に入って、びっくりしたことがあるんだ。
僕の仕事は、C#とWPFで、現場の人が使う業務アプリを作ること。UI/UXをモダンにして、業務効率を上げようぜ！っていうプロジェクトだ。僕の作るWPFアプリ自体は、MVVMパターンでキレイに作ってるし、CI/CDも回してる。「お、なかなかモダンじゃん」って思ってた。フロントエンドはね。
でもある日、そのWPFアプリが叩いてるバックエンドのAPIの仕様が知りたくて、バックエンドチームのドキュメントを漁ったんだ。そしたら、そのAPIの先に繋がってる「基幹システム」の資料が出てきて、僕は二度見した。
「システム概要：VB6で構築された在庫管理モジュール」
……VB6？
冗談だろ？Windows XP時代、いや、2000年代初頭の技術だ。僕がまだ学生だった頃の。
慌ててチームの古株（イギリス人のおじさん）に聞いたら、「ああ、それね。ウチの心臓部だよ。20年前に作られてから、ずっと『秘伝のタレ』みたいに継ぎ足し継ぎ足しで動いてるんだ。触れる人間は、もう世界に数人しかいない」って笑ってた。
笑えねえよ。
「塩漬け」が吸い尽くすカネと未来
これが何を意味するか、分かるよね。フックで言うところの「 escalating costs（増大し続けるコスト）」ってやつだ。
まず、金銭的なコスト。
古いシステムってのは、動いてるだけで金がかかる。古いハードウェアを維持する費用、ライセンスがとっくに切れたOSやミドルウェアを、セキュリティ上のリスクを抱えながら使い続ける「延命措置」の費用。
僕の会社も、そのVB6モジュールを動かすためだけに、いまだに物理サーバーをデータセンターに置いてる。クラウドに移行？できるわけない。移行しようとしたら、誰も仕様を理解できないから、テストだけで何年かかるか分からない。
Barclays銀行だって、2023年にIT予算として100億ドル（1兆円以上！）も使ってたのに、あのザマだ。金をつぎ込んでも、レガシーシステムは金食い虫として、ただただ予算を食い潰していく。
でも、もっと怖いのは**「機会損失」**というコストだ。
僕がWPFアプリで「ここにAIを組み込んで、需要予測をリアルタイムで表示したい」って提案したとする。イケてるだろ？
でも、バックエンドチームからはこう言われる。「ごめん、そのデータはVB6のモジュールが夜間バッチでCOBOLのDBから持ってきてるから、リアルタイムは無理だ。CSV出力なら、週明けに手動で送れるけど？」
……は？
競合他社がAWSやAzureの上で、PythonやGoで書いたマイクロサービスをガンガンデプロイして、A/Bテストして、ユーザーの反応を見ながらサービスを改善してる。まさにそういう時代に、僕たちは「VB6の仕様書（紛失）」と「COBOLのDB（解読不能）」と戦ってるんだ。
これが、レガシーシステムが奪う**「未来への投資（＝機会損失）」**だ。新しいことにチャレンジしようにも、古いシステムが足かせになって、一歩も前に進めない。会社はじわじわと競争力を失っていく。
専門家（シニア）は、もういない
そして、最大の問題点がこれだ。「スキルギャップ」。
その「秘伝のタレ」であるVB6やCOBOL。それを唯一触れる、あのイギリス人のおじさん。仮に彼を「ジョン」としよう。
ジョンは、来年65歳で退職する。
さあ、どうなる？
会社はパニックだ。「ジョン、辞めないでくれ！給料を2倍にするから！」「退職後もコンサルタントとして週3で来てくれ！」と必死に引き留めてる。
Deloitteの調査によると、メインフレーム（COBOLとか）を扱ってるチームの71%が人手不足に陥ってるそうだ。そりゃそうだ。今、新卒や若手のエンジニアが「よーし、俺はCOBOLをマスターするぞ！」って思うか？ミレニアル世代やZ世代は、クラウドやAI、モバイル開発には興味があっても、メインフレームの研修なんて受けたこともない。
結果、どうなるか。
COBOLやVB6、あるいは古いJava（EJBとか）の知識を持ってるシニアエンジニアの市場価値が、一時的に高騰する。彼ら「レガシー専門家」は、引退を先延ばしにされ、高い給料で「延命措置」だけを続けることになる。
ここで、これから海外で働こうとしている君に、リアルな警告をしたい。
もし君がエージェントから「未経験でもOK！C#エンジニア募集！」って求人を見たとしよう。よく見たら、仕事内容が「既存システム（WinForms, .NET Framework 2.0）の保守・運用」だったりする。
あるいは、「給料めちゃくちゃ良いですよ！金融系のシステムメンテです！」って言われて、研修でCOBOLをやらされたりする。
めちゃくちゃ危険なサインだ。
一度その「レガシーの沼」に足を踏み入れたら、どうなるか。
君は、その会社でしか通用しない「秘伝のタレ」の継ぎ足し方法を覚える。給料は、他に行き場がないから、そこそこ良いかもしれない。
でも、5年後。君の市場価値はどうなってる？
周りのエンジニアがクラウドネイティブな技術やAIを当たり前に扱ってる中で、君の履歴書に書けるのは「COBOLによるバッチ処理の改修」だけ。
Reddit（海外の掲示板）で、「COBOLエンジニアになったら、もう二度とWeb開発者には戻れない」って書き込みを見たことがあるけど、あれは半分冗談で、半分本気だ。
僕がメインで使ってるC#とWPFだって、他人事じゃない。
Web全盛のこの時代に、WPFっていうデスクトップ技術をやってること自体、すでに「レガシー予備軍」だと僕は自覚してる。だからこそ、僕はWPFをやりつつも、Azureの知識を必死に勉強してるし、バックエンドの動向にもアンテナを張ってる。
レガシーシステムは、どこにでもある。
君が憧れる海外の、あのカッコいいロゴの会社にだって、必ずある。
それは単なる「古い技術」じゃない。
会社の成長を止め、エンジニアのキャリアを食い物にし、そしてある日突然、航空会社や銀行のように社会インフラを麻痺させる**「時限爆弾」**なんだ。
これが、僕が海外の現場で目の当たりにした「現実」だ。
じゃあ、なんでそんなヤバい爆弾が、GoogleやMicrosoftみたいに優秀なエンジニアを抱える大企業でさえ、簡単に撤去できないのか？
「さっさと全部作り直せばいいじゃん」って思うだろ？
それができない、もっと根深い、組織的・技術的な「闇」があるんだ。
なぜ撤去できない？ レガシーシステムが「ゾンビ化」する構造的な闇
「起」で話した「時限爆弾」、覚えてるかな？
VB6、COBOL、20年モノのメインフレーム…。航空会社を止め、銀行をフリーズさせ、そして僕たちエンジニアのキャリアを静かに蝕む、あの忌まわしい「レガシーシステム」だ。
僕もね、自分の作ってるピカピカのWPFアプリの裏側が、そんな「秘伝のタレ（VB6）」だったって知った時は、正直ドン引きしたよ。
で、普通こう思うだろ。
「いや、ヤバいって分かってるなら、さっさと全部作り直せばいいじゃん」
うん、僕もそう思ってた。C#（.NET 8）とモダンなWeb API、データベースはクラウド（Azure SQLとか）に移行して、アーキテクチャもクリーンにすれば、全部ハッピーになるじゃん、って。
でもね、現実はそんなに甘くない。
この「レガシーシステム」っていう化け物は、僕たちが思ってる以上に根が深くて、複雑で、おまけに「触ろうとする者」に呪いをかける、まさに**「ゾンビ」**みたいな存在なんだ。
「作り直せばいい」――その一言がいかに無邪気で、現実を見ていないか。
僕がこの海外の現場で学んだ、「レガシーシステムをリプレースできない、本当の理由」を、技術的な闇と、組織的な闇に分けて、ガッツリ語っていこうと思う。
闇１：技術的な絶望。それは「クモの巣」であり「ブラックボックス」である
まず、技術的な側面から。
「古いシステム」ってのは、ただ古いだけじゃない。それは、20年間かけて無数のエンジニア（その多くはすでに退職済み）が触りまくった結果、とんでもない「怪物」に変貌してるんだ。
① 解読不能な「スパゲッティ・地獄」
君は「スパゲッティ・コード」って言葉は知ってるよね。処理があちこちに飛びまくって、追いかけるのが大変なコードのことだ。
レガシーシステムで起きているのは、その**「アーキテクチャ版」**だ。
僕のWPFアプリがVB6のAPIを叩いてるって話をしたけど、その後の調査で、さらに恐ろしい事実が判明したんだ。
- 僕のWPFアプリ（C#）が、あるAPI（VB6製）を叩く。
- そのAPIは、データベースA（SQL Server 2008）の値を参照する。
- 同時に、別サーバーで動いてる謎のWindowsサービス（C++製）にTCP/IPでソケット通信を送る。
- さらに、夜間バッチ（COBOL製）がメインフレームから持ってきたデータを、別のデータベースB（AS/400）に書き込んでいて、VB6のAPIは「たまに」そっちも参照する。
- 極め付けに、そのVB6のAPIの処理の一部が、なぜか**Excelマクロ（VBA）**をキックして、特定の共有フォルダにレポートファイル（.xls形式）を吐き出すトリガーになっていた。
……もう、意味が分からないだろ？
これが「依存関係のクモの巣」だ。
僕が「よし、このVB6のAPIをC#で書き直そう！」と思って、単純にデータベースAだけを見てAPIを作り直したらどうなる？
C++のサービスは動かなくなり、AS/400のデータ不整合が起き、VBAのレポートは出力されなくなる。そして、そのレポートが出力されないことで、まったく別の部署（経理部とか）の業務が止まるんだ。
リプレースしようにも、どこからどこまでが「一つの機能」なのか、その全体像を誰も把握していない。これが一つ目の闇だ。
② 「仕様書」は、退職したジョンの「頭の中」
じゃあ、そのクモの巣を解き明かす「設計書」や「仕様書」があるのか？
ない。
あるわけがない。20年前に作られたシステムのドキュメントなんて、とっくに実態と乖離してるか、そもそも存在しない。
じゃあ、仕様はどこにあるのか？
そう。あの古株エンジニア、「ジョン」の頭の中だ。
僕が「このAPI、なんでこんな複雑なことしてるんですか？」ってジョンに聞きに行くと、彼は「ああ、それね。15年前に、経理部のスーザン（5年前に退職）から『月末だけこうしてくれ』って言われて、急遽パッチを当てたんだよ。ここのIF文がその名残さ」とか言うわけだ。
もはや、それは「仕様」じゃない。「歴史」であり「伝承」だ。
ジョンは来年退職する。ジョンがいなくなったら、その「伝承」は永久に失われる。
会社は必死にジョンを引き留めてるけど、ジョンは「もう孫とゆっくり釣りでもして暮らしたいよ」って笑ってる。
この「人間への属人性」こそが、レガシーシステムを最強のブラックボックスにしてる原因なんだ。
③ 「動いているものが正義」というテスト不能の壁
じゃあ、最悪、仕様がわからなくても、インプットとアウトプットさえ分かれば、リプレースできるんじゃない？「ブラックボックステスト」ってやつだ。
甘い。
レガシーシステムは、正常に動いているとは限らないからだ。
「このAPIに”A”って入れたら”B”が返ってくる」
「じゃあ、新しいシステムも”A”で”B”が返るように作ろう」
↓
「できました！」
↓
「あれ？現場のユーザーが『前のシステムと動きが違う』って怒ってるぞ！」
↓
「なんで！？同じインプットで同じアウトプットなのに！」
↓
「よく調べたら、前のシステムは”A”を入れると”B”を返しつつ、謎のDBテーブルXに”C”というゴミデータを書き込むバグがあった。そして、現場のユーザーはその『ゴミデータ』が書き込まれることを前提に、別のExcelマクロ（またか！）を組んで業務を回していた」
これが現実だ。
「バグ」なのか「仕様」なのか、もはや誰にも分からない。
ユーザー（現場）は、その「バグ」を含めたシステムの「振る舞い」そのものを「仕様」として業務を最適化しちゃってるんだ。
これを100%再現しろって？無理だろ。
リプレースプロジェクトは、こういう「想定外の振る舞い」の地雷原を歩くようなもの。一つ踏み外せば、業務が止まり、大炎上する。だから、誰も手を出せない。
闇２：組織的・金銭的な絶望。「誰が、そのカネを出すんだ？」
技術的な絶望、分かってもらえたかな？
でも、本当に厄介なのは、こっちかもしれない。組織とカネの問題だ。
① 経営陣には「止まってない＝問題ない」としか見えない
君がCFO（最高財務責任者）だと思って聞いてほしい。
僕：「CFO、あのVB6のシステム、ヤバいです。技術的負債の塊です。来年ジョンが辞めたら、誰も触れなくなります。だから、5億円と2年をかけて、C#で全面的に作り直させてください！」
CFO：「ふむ。で、その『ヤバい』システム、今、動いてるのかね？」
僕：「えっ？あ、はい。一応、動いてはいますけど…」
CFO：「動いてるものを、なぜ5億円もかけて作り直す必要があるんだ？その5億円で、新しいAIマーケティングツールを導入すれば、来期の売上が10%アップするかもしれないんだぞ？」
僕：「いや、でも、これは『投資』というか『保険』で…」
CFO：「『保険』か。じゃあ、リプレースしなかった場合、いつ、どれくらいの確率で、いくらの損害が出るんだね？」
僕：「……それは、分かりません。でも、いつか必ず…」
CFO：「『分からない』ものに5億円は出せない。却下だ。ジョンには給料を3倍払ってでも残ってもらうよう人事が交渉中だ。以上」
……これが「経営」だ。
エンジニアから見れば「時限爆弾」でも、経営陣から見れば「（一応）動いている資産」なんだ。
「動いているもの」を作り直すという行為は、彼らのロジック（ROI：投資対効果）では、よほどのことがない限り正当化できない。
② 「守護神」という名の抵抗勢力
じゃあ、現場の人間（ジョン）はリプレースに協力的か？
これも、そうとは限らない。
皮肉なことに、レガシーシステムが複雑でブラックボックスであればあるほど、それを唯一触れる「ジョン」の社内的な価値は上がる。
ジョンは「レガシーの守護神」として、高い給料をもらい、周りからリスペクト（というか恐怖）されている。
もし、システムがピカピカのC#にリプレースされたらどうなる？
ドキュメントは整備され、若手エンジニアでも改修できるようになる。
それは、ジョンの「唯一無二の価値」が失われることを意味するかもしれない。
もちろん、ジョンがそんな悪意を持っているとは限らない。でも、無意識のうちに「このシステムは複雑すぎて、俺以外には触れないよ」「君のC#のプランじゃ、あのトリッキーな月末処理は考慮漏れだ」と、リプレースの芽を摘んでしまう（＝抵抗勢力になってしまう）可能性は、十分にあるんだ。
③ 終わらない「延命措置」という麻薬
結局、経営陣は「全面リプレース（5億円）」という外科手術を選ばず、「ジョンに給料アップ（年間+1000万円）」という**「延命措置（痛み止め）」**を選ぶ。
僕たちフロントエンドのエンジニアもそうだ。
「バックエンド（VB6）はそのままにして、フロントエンドだけイマドキのWPF（あるいはWeb）にして、ガワだけ綺麗にしてください」
というプロジェクトが、世の中には溢れてる。
僕が今やってる仕事も、まさにそれだ。
根本的な「癌（レガシー）」は放置したまま、皮膚（UI）だけを綺麗にしているようなもの。
一時的にはユーザーは満足するかもしれない。でも、癌は確実に蝕んでいく。
そして、その「痛み止め」を打ってる間に、技術的な闇はさらに深くなり、リプレースはもっともっと困難になっていく。
これが、「承」の答えだ。
レガシーシステムは、技術的なクモの巣と、組織的な利害関係によってガチガチに固められた「ゾンビ」なんだ。
「作り直せばいいじゃん」という単純な正論は、この複雑な現実の前では無力だ。
海外の現場でも、これはまったく同じ。いや、むしろM&A（合併・買収）が盛んな海外では、会社が合併するたびに「VB6のシステム」と「COBOLのシステム」と「Javaのシステム」が無理やり連結させられて、さらにカオスな「キメラ・レガシー」が爆誕してたりする。
もう絶望しかないだろ？
「じゃあ、海外エンジニアになっても、そんな『塩漬け』キャリアしかないのかよ…」
「WPFみたいなデスクトップ技術やってる俺、オワコンなのか…」
って、落ち込むのはまだ早い。
この絶望的な「レガシーの沼」の中でこそ、僕たち**「中途半端な」技術（WPFやC#）**を持つエンジニアが輝ける、特殊な「活路」があるんだ。
次回、「転」。
この「詰み」の状況をひっくり返す、僕なりのサバイバル術と、レガシーとの「現実的な戦い方」について、熱く語らせてくれ。
「沼」を「金脈」に変えろ。WPFエンジニアが握る「現実的な解」
「承」で話した通り、僕たちの前には絶望的な「ゾンビ（レガシーシステム）」が横たわってる。
技術はスパゲッティ、仕様書はジョンの頭の中、経営陣はカネを出さない。
まさに「詰み」だ。
僕も最初、この事実に気づいた時、本気で転職を考えた。
「俺はこんなVB6の尻拭いをするために、わざわざ海外まで来たんじゃない」ってね。
でも、ある日、ふと思ったんだ。
「待てよ。会社はなんで、今さら俺みたいなC#とWPFのエンジニアを雇ったんだ？」
考えてみてほしい。
会社が本当に「延命」だけしたいなら、引退したジョン（VB6の達人）を、それこそ日給20万円とかで雇い続けるほうが安上がりだ。
逆に、会社が本気で「AIでイノベーション！」とか考えてるなら、PythonとTensorFlowの博士号を持ってるようなスターエンジニアを雇うはずだ。
どっちでもない、僕。C#とWPF。
この技術スタックって、まさに**「古き（VB6やCOBOL）」と「新しき（クラウド、Web API）」の「中間」**に位置してるんだ。
そう気づいた瞬間、僕の本当の「ジョブ・ディスクリプション（職務記述書）」が見えた。
僕の仕事は、WPFでキレイな画面を作ることじゃない。
僕の本当のミッションは、**「VB6ゾンビを、誰にも気づかれずに安楽死させ、その死体の上にモダンなシステムを再構築する」**ことだったんだ。
5億円は要らない。「絞め殺し」という現実解
「全面リプレースには5億円と2年かかります！」
こんな提案は、CFO（最高財務責任者）に一発で蹴られるって話はしたよね。
じゃあ、僕がどうしたか。
僕は、CFOや上司に、リプレースの「リ」の字も言わなかった。
その代わり、こう提案したんだ。
「僕の新しいWPFアプリ、イケてるでしょ？でも、バックエンド（VB6）が不安定で、よくフリーズするんですよね。ユーザーのクレームも多い。
そこで、僕のWPFアプリとVB6の間に、**一つだけ『安定化させる層』**を挟ませてもらえませんか？ C#（.NET 8）で、ちょっとしたAPIサーバーを立てるだけです。VB6が死んでても、最低限のレスポンスを返せるようにする『クッション』みたいなものです」
上司：「ふむ。VB6は触らないんだな？」
僕：「もちろんです！あんな恐ろしいもの、触りたくもありません。僕はただ、**VB6を『包み込む』**だけです」
上司：「よかろう。予算もサーバー1台分くらいなら、すぐ出す」
これが、僕の仕掛けた「トロイの木馬」だ。
C#は「最強の翻訳機」である
ここからが、C#エンジニアの真骨頂だ。
C#（.NETプラットフォーム）ってのは、恐ろしいほど「後方互換性」のオバケで、「あらゆる古い技術」と「あらゆる新しい技術」を「繋げる」ことに関しては、世界最強のノリなんだ。
僕が立てた、この新しいC# API（.NET 8製）は、こんな動きをする。
- 僕のWPFアプリは、この新しいC# APIに、モダンな「JSON形式」でリクエストを送る。
- C# APIは、そのリクエストを受け取ると、**内部で「翻訳」**する。
- VB6が理解できる、古臭い「COMコンポーネント」の呼び出し形式や、C++のソケット通信、AS/400へのDB接続（！）など、すべての「汚い仕事」を、このAPIサーバーが全部引き受ける。
- そして、VB6やAS/400から返ってきた、解読不能なバイト列やゴミデータを、C# APIが再び「浄化」して、キレイなJSONとしてWPFアプリに返す。
外から見れば、このAPIは超モダンなイケてるAPIだ。
でも、その内側では、僕だけが知っている「ゾンビとの死闘」が繰り広げられている。
この「翻訳層」「防護層」（専門用語で「Anti-Corruption Layer (ACL)＝腐敗防止層」って言う）を一枚挟んだ。
たったこれだけ？
そう、たったこれだけ。
でも、これが「転」の第一歩だ。
僕はこの瞬間、**「レガシーシステムに支配される側」から「レガシーシステムを支配する側」**に回ったんだ。
「絞め殺しイチジク」という必殺技
この「防護層」を作ってから、半年が経った。
ある日、現場のユーザーから、新しい機能改修の要望が来た。
「在庫データ（VB6が管理）に、新しく『予約フラグ』を追加して、WPFの画面で見られるようにしてほしい」
さあ、どうする？
【絶望ルート（以前の僕）】
- ジョン（VB6の守護神）に「VB6のDBとAPIに『予約フラグ』を追加してください」と土下座してお願いする。
- ジョン：「無理だ。そのテーブル（COBOL）は、経理バッチ（C++）と密結合してるから、カラムを一つ増やしただけで、月末の決算が吹っ飛ぶぞ」
- 僕：「（詰んだ…）」
【金脈ルート（今の僕）】
- 僕：「（ニヤリ）なるほど。VB6は触りたくないな…。よし」
- 僕は、VB6のデータベース（SQL Server 2008）とは別に、新しいピカピカのデータベース（Azure SQL）を一つ用意する。
- 僕が作ったC# API（防護層）を、こっそり改修する。
- ユーザーが「予約フラグを立てる」ボタンを押すと、C# APIは…
- オリジナルの在庫データは、従来通りVB6に（読み込みだけ）取りに行く。
- 「予約フラグ」の情報だけ、僕が新設したAzure SQLに書き込む。
- そして、C# APIは、WPFアプリに返す直前に、**VB6のデータとAzure SQLのデータを「マージ（合体）」**させて、あたかも「最初から一つのデータでした」という顔をしてJSONで返す。
ユーザー：「おお！VB6のシステムなのに、爆速で新機能が追加された！アイツ（僕）は魔法使いか！？」
これが、IT業界で有名な「Strangler Fig Pattern（絞め殺しイチジクのパターン）」という戦術だ。
イチジクの木は、他の巨大な木にツルを巻きつけ、その木の養分を吸い取りながら成長し、最終的には元の木を「絞め殺して」自分がその場所の主になる。
僕がやったのも同じだ。
僕は「VB6をリプレースします」とは一言も言わない。
ただ、「新機能」という名の「イチジクのツル」を、僕のC# APIに次々と追加していく。
「この機能は、C# API側で処理しよう」
「ああ、このデータもVB6じゃなくて、こっちの新しいDBに入れちゃおう」
これを2年間、繰り返したら、どうなる？
気づいた頃には、あの恐ろしかったVB6モジュールは、何も仕事をすることがなくなっている。ただの「抜け殻」だ。
すべての機能は、僕のC# API（モダンな.NET 8製）に置き換わっている。
ログを見ても、VB6へのアクセスはゼロ。
その時、僕はCFOにこう言うんだ。
「CFO、あの古いVB6サーバー、誰も使ってないみたいだから、電源切ってもいいですか？電気代、月50万円浮きますよ」
これが、僕の考える「勝利」だ。
キャリアの「金脈」
この戦い方、君はどう思った？
「ずる賢い」？「卑怯だ」？
僕は、これを**「最高のエンジニアリング」であり、「最強のキャリア戦略」**だと思ってる。
なぜなら、この「レガシー・リファクタリング」の経験は、そこらへんのWeb系エンジニアが「Reactの新しいバージョン使ってみた」って言うのとは、ワケが違う価値があるからだ。
僕が5年後に転職市場に出た時、僕の履歴書にはこう書かれる。
「ミッションクリティカルなVB6/COBOLベースの基幹システムを、ビジネスを止めることなく（ゼロダウンタイムで）、モダンな.NET 8マイクロサービス・アーキテクチャへ段階的に移行（Strangler Fig Pattern）させた実績を持つ。結果、レガシー保守コストの80%削減と、新機能開発速度の5倍向上を達成した」
……どうだ？
そこらのスタートアップでイケてる技術を触ってるエンジニアより、よっぽど「高値」で売れると思わないか？
「C# WPF」という中途半端な技術スタック。
「海外企業」という、モダンとレガシーがカオスに混在する現場。
この二つが揃った時、それは「塩漬け」の絶望ではなく、**「レガシー・モダナイゼーション・スペシャリスト」**という、超ニッチで超高給な「金脈」への入り口になるんだ。
この「沼」は、君のキャリアを殺す場所じゃない。
君が「本物の価値」を証明するための、最高の「狩り場」なんだよ。
「爆弾処理班」こそ、最強のエンジニアである
ここまで長い話に付き合ってくれて、ありがとう。
「起」では、航空会社や銀行を止める「レガシーシステム」という時限爆弾の恐怖について話した。
「承」では、それが技術的・組織的な闇によって「ゾンビ化」し、誰も手出しできない絶望的な現実を語った。
そして「転」では、C#とWPFという「中間の技術」を持つ僕たちが、いかにして「絞め殺し（Strangler Fig）パターン」という必殺技で、そのゾンビを「安楽死」させ、キャリアの金脈に変えるか、その具体的な戦術を明かした。
この4部作を通して、僕が君に伝えたかった「得する情報」「人生術」は、突き詰めればたった一つだ。
それは、**「エンジニアの『本当の価値』は、どこに宿るのか？」**という問いへの、僕なりの答えだ。
「グリーンフィールド」の幻想、「ブラウンフィールド」という現実
これから海外で働こうとする君は、きっと希望に満ちている。
「最先端のAIに触れたい」
「モダンなマイクロサービスをReactとGoで作りたい」
「完全リモート、フルフレックスな環境で働きたい」
素晴らしい。その夢は、絶対に持ち続けるべきだ。
でも、僕たちはその「キラキラした世界」を**「グリーンフィールド（Greenfield）」**と呼ぶ。
「まっさらな更地」だ。何の制約もない場所で、ゼロから美しい設計で、最新の技術を使って、自由に家（システム）を建てる。
それは楽しい。めちゃくちゃ楽しい。僕だって大好きだ。
新卒や若手のエンジニアが技術を学ぶ場として、これ以上の環境はない。
でも、忘れないでほしい。
世の中のITシステムの99%は、「グリーンフィールド」じゃない。
僕たちが海外で働く「現場」は、そのほとんどが**「ブラウンフィールド（Brownfield）」**だ。
「汚れた土地」という意味だ。
そこには、20年前にVB6で建てられた「傾いた家」が、COBOLの「謎の配管」に繋がれ、C++の「違法建築」と癒着し、なぜかJavaの「プレハブ小屋」が隣接している。
そして、そのカオスな家々が、今この瞬間も、会社の売上の80%を生み出している。
さあ、君の仕事だ。
「この売上（ビジネス）は、絶対に止めるな。でも、この傾いた家を、なんとか耐震補強しながら、裏でこっそりモダンなタワーマンションに建て替えてくれ。住民（ユーザー）にバレないようにな」
これが、僕たち「中堅エンジニア」が直面する、リアルなミッションだ。
なぜ「爆弾処理班」は、給料が高いのか？
「グリーンフィールド」のエンジニアは、「建築家」だ。
彼らは、最新の建材（技術）を知っている。美しい設計図（アーキテクチャ）が描ける。
では、「ブラウンフィールド」のエンジニア、つまり僕たちC#使いやレガシーと戦う者は何か？
僕たちは**「爆弾処理班」**だ。
僕たちの仕事は、美しい設計図を描くことじゃない。
赤と青、どっちのコードを切れば爆発しないか（ビジネスが止まらないか）を、冷や汗をかきながら見極めることだ。
「このVB6のAPIを止めると、経理部のExcel（VBA）が止まる」
「このCOBOLのテーブルを触ると、月末のバッチ（C++）が吹っ飛ぶ」
この複雑怪奇な「依存関係」という名の爆弾の回路図を、退職したジョンの「記憶（伝承）」や、誰も読めない古いコードから解読する。
そして、「転」で話した「絞め殺し（Strangler Fig）」という技術を使って、一本ずつ、慎重に、爆弾の信管を抜いていく。
どちらが「難しい」と思う？
どちらが「替えがきかない」と思う？
Reactの最新バージョンなんて、半年勉強すれば誰でもキャッチアップできる。
でも、**「ビジネスを止めずに、VB6とCOBOLの時限爆弾を、モダンなC# APIに置き換える」**という経験は？
その経験を積んだエンジニアは、市場でどう評価される？
答えは、言うまでもないよね。
「爆弾処理班」の給料は、高いんだ。
なぜなら、彼らがいなければ、会社そのものが「爆死」するからだ。
彼らは、技術（Tech）と、ビジネス（Biz）と、過去の歴史（Legacy）の**「交差点」**に立っている。
C# WPFは、君の「最強の武器」になる
「どうせ海外でやるなら、Web系じゃなきゃ…」
「WPFなんて、もう古いですよね…」
僕も、そう思っていた時期がある。
でも、この「ブラウンフィールド」という戦場において、C#と.NETプラットフォームは「最強の武器セット」だ。
なぜなら、
VB6やC++（COM）といった「超レガシー」とも対話でき、
AzureやAWSといった「最先端のクラウド」ともシームレスに連携できる、
**「最強の翻訳機（Anti-Corruption Layer）」**だからだ。
そしてWPFは？
Web技術（HTML/CSS）では絶対に実現できないような、複雑な業務オペレーション（例えば、金融トレーダーの画面や、工場の製造ラインの制御盤）を、リッチかつ高速に提供できる。
レガシーな現場（ブラウンフィールド）の「最後の砦」として、今もなお、現役バリバリで求められている技術なんだ。
君がもし、僕と同じC# WPFエンジニアなら、胸を張ってほしい。
君の技術は、古くない。
君の技術は、「グリーンフィールド」ではなく、「ブラウンフィールド」という最もカネになる戦場で、爆弾を解体するために最適化された「特殊装備」なんだ。
結び：エンジニアよ、「問題」から逃げるな
これから君が飛び込む海外の現場は、理不尽なことだらけだろう。
キラキラした幻想は、すぐに打ち砕かれるかもしれない。
「なんで俺が、こんなVB6のコードを読まないと…」と絶望する日も来るだろう。
その時、このブログを思い出してほしい。
その「絶望」こそが、「金脈」だ。
誰もが嫌がる「問題」。
誰もが触りたがらない「レガシー」。
誰もが解読を諦めた「ブラックボックス」。
そこに、エンジニアとしての君の「本当の価値」が眠ってる。
「新しい技術を学ぶ」のは、当たり前だ。それは「消費」だ。
「古い問題を解決する」のは、地獄だ。だが、それは「投資」だ。
逃げるな。
「爆弾処理班」になることを恐れるな。
君が持つC#という武器を信じて、ゾンビ（レガシー）の首を獲りに行け。
それが、海外の厳しい現場で「こいつは替えがきかない」と認めさせ、圧倒的な市場価値と、クソ高い給料と、何より「俺がこの会社の心臓部を動かしてるんだ」という強烈な「誇り」を手に入れる、唯一の道だと、僕は信じている。
君の戦いを、遠い空の下から応援してるぜ。
コメント