「移行すれば未来が開ける」という幻想が崩れた2年5ヶ月
古いシステムをモダン化する。経営層からすれば当然の判断に見えます。技術的負債を解消し、保守性を高め、将来の拡張に備える。理屈としては完璧です。
しかし現場では、その「当然の判断」が2年以上もの時間を費やし、結局元の技術スタックに戻るという結末を迎えることもあります。私が2001年8月から2003年12月まで担当した物流管理パッケージシステムのVB6からVB.NET移行プロジェクトは、まさにそんな事例でした。
当時の私はSEとして、20名から最大50名規模の体制でこのプロジェクトに関わっていました。顧客の倉庫業務を支える基幹システムです。入出庫管理、在庫管理、配送計画、請求処理まで、すべてがこのシステムで動いていました。
マイクロソフトがVB6のサポート終了をアナウンスし、VB.NETという「次世代プラットフォーム」を打ち出した時期です。技術的には正しい選択のように思えました。オブジェクト指向の本格的なサポート、.NET Frameworkの豊富なライブラリ、Webアプリケーションへの展開可能性。すべてが魅力的に見えたんです。
2001年8月から2003年12月、私はSEとして物流管理パッケージシステムに2年5ヶ月従事しました。体制は20〜50名規模で、最大のテーマがVB6で構築された業務システムをVB.NETに移行することでした。結論から言うと、この案件で『2年5ヶ月かけて得た結論は、VB.NET移行は見送る』というものでした。互換性の問題、移行コストの大きさ、現状の安定運用との比較、利用者への影響評価などを徹底的に検証した結果、『移行する価値は今はない』と判断したのです。当時はVB6が使えなくなる懸念が業界で話題になっていましたが、結果的にVB6は20年以上動き続けました。レガシー脱却は『技術トレンドだから』ではなく『ビジネス価値』で判断すべきだと、身を持って学んだ案件でした。
あの頃は「技術の進化に乗り遅れてはいけない」という焦りが業界全体にありました。でも、現場で実際に何が起きたかを振り返ると、移行判断の難しさが浮き彫りになります。
VB6で動いていた資産の実態
私たちが扱っていた物流管理システムは、約5年かけて育ててきたVB6のコードベースでした。総コード行数は正確には覚えていませんが、フォーム数だけで200以上、モジュール数は100を超えていました。
それぞれのフォームには顧客の業務ノウハウが詰まっていました。入庫時の検品ルール、出庫時の優先順位ロジック、在庫引当の複雑な条件分岐。単なるコードではなく、現場の試行錯誤の結晶だったんです。
さらに厄介だったのが、外部連携です。バーコードリーダー、ハンディターミナル、自動倉庫システムとのインターフェース。これらはすべてVB6のActiveXコントロールやCOMコンポーネントで実装されていました。
「アップグレードウィザード」が示した残酷な現実
VB.NETには「アップグレードウィザード」という自動変換ツールがありました。VB6のプロジェクトを読み込ませれば、VB.NETのコードに変換してくれるという触れ込みです。
試しに小規模なフォームで試してみました。結果は散々でした。変換はできるんです。でも、変換後のコードには大量の警告とコメントが付いていました。「この機能はサポートされていません」「手動で修正が必要です」といったメッセージの嵐です。
特に痛かったのが、コントロール配列の扱いでした。VB6では同じ種類のボタンやテキストボックスを配列として管理できたのですが、VB.NETではこの概念がなくなっていました。物流システムでは、入庫明細を一覧表示するために大量のテキストボックスをコントロール配列で動的生成していたので、この部分だけで全面的な設計変更が必要になりました。
なぜVB6からVB.NETへの移行はこれほど困難だったのか
あれから20年以上経った今、当時の移行がなぜあれほど難航したのか、構造的な理由が見えてきます。単なる技術的な互換性の問題ではなかったんです。
「互換性」という言葉の残酷なトリック
マイクロソフトは「VB6からVB.NETへの移行パス」を用意したと謳っていました。でも、これは厳密には嘘ではないけれど、真実でもありませんでした。
VB6とVB.NETは、名前こそ似ていますが、根本的に異なる言語です。VB6はCOMベースのRAD(Rapid Application Development)ツールでした。フォームに部品を貼り付けて、イベントハンドラにコードを書く。直感的で、生産性が高く、初心者でも形になるものが作れました。
一方、VB.NETは.NET Frameworkという巨大なプラットフォーム上で動く、本格的なオブジェクト指向言語です。継承、ポリモーフィズム、名前空間、アセンブリ管理。VB6にはなかった概念が大量に導入されていました。
つまり、「移行」という言葉が示唆する「ちょっとした手直しで動く」という期待は、最初から成り立たなかったんです。これは「引っ越し」ではなく「建て替え」でした。
現場の業務ロジックとコードが一体化していた問題
もう一つの構造的問題は、VB6時代の開発スタイルにありました。私たちは顧客の要望を聞いて、すぐにフォームを作り、すぐにコードを書いていました。設計書は後から作る。仕様変更があれば、その場でコードを修正する。
その結果、業務ロジックがフォームのイベントハンドラの中に埋め込まれていました。「このボタンを押したら、在庫を引き当てて、出庫指示を出して、配送計画を更新する」といった処理が、すべてボタンのClickイベントの中に書かれているんです。
VB.NETで同じことをやろうとすると、まずビジネスロジックをUIから分離する必要がありました。でも、5年分の業務ノウハウが詰まったコードから、純粋なロジックだけを抽出するのは至難の業でした。「このIf文は画面制御なのか、業務ルールなのか」を一つひとつ判断していく作業に、膨大な時間がかかりました。
見えないコストが積み上がる恐怖
プロジェクトが進むにつれて、私たちが恐れたのは「見えないコスト」でした。表面的には変換できたように見えても、実際に動かしてみると予期しない動作をする。VB6では暗黙的に処理されていたことが、VB.NETでは明示的に書かないといけない。
例えば、データ型の自動変換です。VB6は型に関して非常に寛容でした。数値型と文字列型を混在させても、多くの場合は勝手に変換してくれました。でもVB.NETでは、厳密な型チェックが入ります。既存コードをそのまま移行すると、実行時エラーが頻発しました。
こうした「小さな違い」が、システム全体では数百箇所、数千箇所に及びました。一つひとつは些細な修正でも、それを全部洗い出してテストする工数を積み上げると、恐ろしい数字になりました。
さらに怖かったのが、「今は動いているけど、将来のバージョンアップで動かなくなるかもしれない」という不安です。.NET Frameworkは進化が速く、互換性が破壊されることもありました。移行したとしても、また数年後に同じ問題に直面するのではないか。その懸念が、経営判断を鈍らせました。
2024年の今なら使える、レガシーシステムのモダン化手段
あの頃の私たちには限られた選択肢しかありませんでした。でも、2024年の今は状況が大きく変わっています。レガシーシステムのモダン化を支援するツールやサービスが充実してきました。
段階的移行を可能にする「マイクロサービス化」のアプローチ
現代のモダン化で主流になっているのが、一気に全部を作り替えるのではなく、機能ごとに段階的に移行していく方法です。これは「ストラングラーパターン」と呼ばれる手法で、古いシステムを徐々に新しいサービスで置き換えていきます。
例えば、AWS Migration HubやAzure Migrateといったクラウドベンダーの移行支援サービスは、既存システムの分析から移行計画の立案、実際の移行作業までをサポートしてくれます。特に印象的なのは、依存関係の自動分析機能です。「このモジュールを移行するには、先にどのモジュールを移行すべきか」を可視化してくれるので、段階的な移行計画が立てやすくなっています。
私が30年見てきた経験から言うと、この「全部を一度に変えない」というアプローチは、リスク管理の面で非常に優れています。2001年の物流システムでも、もしこの手法が使えたら、まず請求処理だけを新プラットフォームに移行し、動作を確認してから次の機能に進む、という現実的な計画が立てられたはずです。
コード変換の精度が劇的に向上した自動化ツール
あの頃の「アップグレードウィザード」とは比較にならないほど、現代の変換ツールは賢くなっています。例えば、Visual Basic Upgrade Companion(VBUC)やMobilize.Netといった専門ツールは、VB6からC#やVB.NETへの変換で、実用レベルの精度を実現しています。
これらのツールが優れているのは、単純な構文変換だけでなく、設計パターンの変換まで行ってくれる点です。VB6のコントロール配列を、.NETのコレクションとイベントハンドラの組み合わせに自動変換してくれたり、COMコンポーネントの呼び出しを.NETの標準ライブラリに置き換えてくれたりします。
完全に自動化できるわけではありませんが、私が現場で使うなら、まずこうしたツールで8割方を変換し、残り2割を人手で調整するという戦略を取ります。2001年当時は9割が手作業でしたから、工数削減効果は計り知れません。
「移行」ではなく「置き換え」という選択肢
現代のもう一つの有力な選択肢が、既存システムをSaaSで置き換えてしまうことです。特に物流管理の分野では、クラウド型のWMS(倉庫管理システム)が充実してきました。
例えば、Logicブロス、クラウドトーマス、LOGILESSといった国産のクラウドWMSは、中堅企業の物流業務に必要な機能をほぼカバーしています。バーコード連携、ハンディターミナル対応、配送業者とのデータ連携など、かつて自社開発していた機能が標準搭載されています。
もちろん、カスタマイズした独自機能をすべてSaaSで再現するのは難しいかもしれません。でも私が30年の経験から学んだのは、「本当に必要な独自機能は思ったより少ない」ということです。多くの場合、業務プロセスを標準に合わせることで、システムの複雑さを大幅に減らせます。
2001年の物流システムでも、振り返ってみれば、顧客固有の要件と思っていた機能の7割くらいは、実は業界標準の範囲内でした。残り3割のために独自システムを維持し続けるコストと、SaaSの月額費用を天秤にかければ、答えは明白だったかもしれません。
20年以上経って、あの判断をどう評価するか
結局、私たちのプロジェクトは2年5ヶ月の検証期間を経て、VB.NETへの全面移行を断念しました。VB6での保守継続を選択したんです。当時は「失敗」のように感じました。でも今振り返ると、あれは正しい判断だったと思います。
「動いているシステム」の価値を見誤るな
金融系の厳格なシステム開発現場で私が学んだことの一つに、「本番稼働しているシステムの安定性は何物にも代えがたい」という原則があります。どんなに古い技術でも、毎日確実に業務を支えているシステムには、計り知れない価値があります。
物流システムは顧客の商売の生命線です。入出庫が止まれば、配送が遅れ、取引先との信頼関係が崩れます。そのリスクと、「新しい技術に移行する」というメリットを天秤にかけたとき、経営判断としてリスクを取らないという選択は合理的でした。
技術者としては「古い技術を使い続けるのは恥ずかしい」という気持ちもありました。でも、システムの価値は使われている技術のモダンさではなく、ビジネスに貢献しているかどうかで測るべきです。VB6だろうがCOBOLだろうが、確実に動いて利益を生んでいるなら、それは優れたシステムなんです。
中小企業が今すぐできる小さな一歩
もしあなたが今、古いシステムのモダン化を検討しているなら、私からのアドバイスは「まず現状を可視化すること」です。いきなり「全面刷新」を目指すのではなく、以下のような小さなステップから始めてみてください。
- システムの依存関係図を作る(どの機能がどの機能を呼んでいるか)
- 保守に最も時間がかかっている部分を特定する
- ビジネスへの影響度と技術的負債の大きさでマトリクスを作る
- 「高影響・高負債」の部分だけを優先的にモダン化する計画を立てる
2001年の私たちに欠けていたのは、この「段階的なアプローチ」でした。全部を一度に変えようとしたから、リスクが膨らみすぎて身動きが取れなくなったんです。
小さく始めて、成功体験を積み重ねる。一つの機能のモダン化が成功したら、次の機能に進む。その繰り返しです。5年かかっても10年かかってもいいんです。重要なのは、ビジネスを止めずに、着実に前に進むことです。
あの2年5ヶ月で私が学んだのは、「技術の選択は、常にビジネスの文脈の中で行うべきだ」ということでした。最新技術を追いかけることが目的ではありません。顧客の業務を支え続けることが、私たちの仕事なんです。
もしあなたの会社に、古いけれど確実に動いているシステムがあるなら、それを恥じる必要はありません。それは過去の開発者たちの努力の結晶であり、今もビジネスを支えている資産です。その価値を認めたうえで、未来への道を一歩ずつ進んでいけばいい。それが、30年現場にいた私が、心からお伝えしたいことです。
コメント