はじめに
こんにちは、あじさいです。
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2025の3日目の記事をお届けします。
レガシーシステムの保守・刷新は、多くのITエンジニアが避けて通れない課題です。
今回は、私が、約半年間かけて、レガシーシステムをレガシーから脱却するために取り組んだ内容について紹介していこうと思います。
直面した課題と、その解決の過程で得られた知見、苦労話をお伝えします。
レガシーシステム刷新プロジェクトの軌跡 〜10年以上放置された“宝の地図システム”を救い出すまで〜
参考にした記事：
https://qiita.com/phibi-soon/items/0c7cd1bfd4292e236588
システム概要（Before）
今回刷新したシステムの構成は、以下の通りです。
| 要素 | バージョン | 備考 |
|---|---|---|
| アプリ | VB9.0 | 2008時代の資産 |
| サーバー | Windows Server 2008（オンプレ） | サポート終了済み |
| DB | SQL Server 2008 | サポート終了済み |
| Office | VBA 6.5 | パスワード保護あり |
問題点まとめ
- すべてが古く、OSもDBも“動いているのが奇跡”
- ソースコードはGit管理されておらず、納品後はローカルにしか存在しない
- 設計書がほぼ無い（要求仕様レベルの“宝の地図”のみ）
- Spread for Windows Forms のバージョンは 7（200X年代）
リプレイス方針
Phase 1：インフラ刷新（オンプレ → Azure）
まずは何よりも「止まるリスク」を取り除く必要がありました。
- サーバー：
Windows Server 2008 → Windows Server 2025 - DB：
SQL Server 2008 → SQL Server 2022
セキュリティ・可用性の観点からAzure移行を提案。
Phase 2：アプリケーション刷新
- VB9.0 → VB.NET（2019）
- Spread for Windows Forms
v7 → v17（10バージョンアップ）
Phase 3: 設計書のリバース
-
DB設計書
- A5:SQL Mk-2を用いて、markdown形式で自動生成
- Cursorを利用し、マークダウンから更に分析して整理
-
画面設計
- Cursorを利用し、同じくリバースさせ生成
苦労したポイント（地獄編）
1. クラウド移行の承認が通らない
地方の小売店で、IT・クラウドへの理解が薄い。
「お金をかけたくない」「今のままで動いている」という理由で、移行提案に1か月近くかかりました。
2. VBAが古すぎて、開発メンバーのPCで起動しない
開発メンバーのOfficeのバージョンが新しすぎて、
起動した瞬間にVBAがエラーで吹っ飛ぶ。
検証用に“わざわざ古いOfficeをクリーンインストールして実行”という手間が発生。
3. VBAのパスワードが誰も知らない
数年前に作った外注業者も不明。社内に知っている人もいない。
解析からスタート。
こういうパターン、本当に多い……。
4. Spread for Windows Forms が10バージョン進化していてビルド不能
Spread v7 → v17
APIもプロパティも仕様が別物。
ビルドが通らない箇所は100カ所以上。
v7で動いていた謎コードがv17では弾かれ、
“ここは通さねぇとな”の気合いで全箇所を修正。
5. VB.NET側も同様にエラー祭り
VB9 → VB.NET 2019では、
- 廃止された構文
- 互換用の警告
- COM参照の不一致
など、ひたすら地道な修正作業。
6. 参照設定の地獄：循環参照で全部ビルド不能
最も深刻だったのがこれ。
複数プロジェクト間で参照が循環しており、
- A → B を参照
- しかし B も A を参照している
- 一部DLLはローカルにしかなく、バージョン不明
- リビルドすると片方が壊れ、他も全部連鎖的に壊れる
というカオス状態。
一度触るとすべてが壊れるジェンガ状態で、
参照整理だけで数週間かかりました。
成果（After）
苦労の末、以下の状態まで改善できました。
✔ インフラ刷新
- Windows Server 2025 + SQL Server 2022
- Azureに載せたことで可用性・保守性が向上
- 老朽化ハードウェアのリスクがゼロに
✔ アプリケーション刷新
- VB.NET 2019へ移行で保守性UP
- Spread v17で表まわり強化
- ソースコードはGitHubで管理
- CI/CDも導入し、二度と“ローカルにしかソースがない”状態を作らない
✔ 設計書も再整備
要求レベルの“宝の地図”から、実装レベルまで整理。
まとめ
レガシー刷新は「技術的負債の総返済」そのものです。
- 古い言語
- 古いDB
- 古いOS
- 古いVBA
- 参照が循環したプロジェクト構成
- Git管理なし
- 設計書ほぼ無し
これらが組み合わさると、1つ触るだけで全体が崩れる“ジェンガシステム”になります。
しかし、クラウド移行と最新環境へのアップデートによって、
ようやく“未来に続く基盤”に生まれ変わりました。
本記事が、同じようにレガシーと戦うエンジニアの希望になれば幸いです。