トピックス

「VB6で作られた製品がまだ現役で動いている」

―――ソフトウェアベンダーの方とお話ししているとこの話題が出ることがあります。動いているからこそさわれない、でも対応できるエンジニアは減る一方。Windowsが新しくなるたびにヒヤヒヤする、VB.NETに移す話も出るけれど、それで本当に解決するのか……

私たちキューボックもまさにそういうお客様の課題と向き合っています。
今回は病院向け業務パッケージを開発・販売されている医療系ソフトウェアベンダーの主力製品をVB6からC#へ、生成AIを活用しながら段階的に移行するプロジェクトについて、お話ししたいと思います。

600画面超のパッケージ

---

この製品は業務・帳票・集計・データ連携といった機能を持つ、いわゆる基幹系の業務パッケージソフトです。総画面数は600を超えます。
「全部いっぺんに刷新しましょう」という提案をしたくなりますが、正直、現実的ではありません。既存のお客様（医療機関）が今日も普通に使っているシステムです。長い時間をかけて練り上げられた業務ロジックがコードの隅々に埋め込まれています。それをビッグバンで置き換えるのはテストの負荷、業務停止のリスク、要員確保の難易度すべてが跳ね上がります。
そこで私たちは機能モジュール単位で少しずつ移していく方針を採りました。今回、その一部モジュールの移行を完了し、次にどう展開していくかを検討している、というのが現時点の状況です。

VB.NETではなく、C#にした理由

---

VB6からのマイグレーションと聞くと、真っ先に思い浮かべるのはVB.NETへの移行だと思います。ツールは提供されており、ソースコードの互換性も高く、既存のVB技術者もそのまま使えるため、移行コストも比較的安く抑えられます。一般的にはこれが正しいのですが、私たちは今回、この選択肢を採りませんでした。理由は大きく３つあります。

Microsoft自身がVB言語の進化を止めていること

2020年3月、Microsoftは公式ブログで発表しています。「VBは.NET 5以降もサポートするが、言語として発展させる予定はない」。2023年2月にも「VBは安定した言語であり、新しいワークロードへのサポートは追加しない」と明示しています。
つまり、これから.NETに新機能やパラダイムが加わっても、VB.NETには反映されません。VB.NETに移行できても数年～十数年後に「もう一度モダナイゼーション」の議論が発生する可能性は十分にあります。パッケージ製品の視点で見れば、これは二度目の刷新コストを将来の自分たちに残すことを意味します。

技術者の確保

今、新しくVB.NETを習得しようとしている若手エンジニアはほぼ見当たりません。一方でC#は、Web/モバイル/Unityなど広く使われていて、若手人材の裾野が違います。製品を10年、20年と保守・拡張していくとき、「触れる人がいる」ことの価値は本当に大きいと考えています。

製品の拡張余地

C#で作り直せば、その先の機能追加で.NETエコシステムをフルに使えます。クラウド連携、API化、AI機能の組み込み ――― こうした選択肢が現実的なコストで検討できるようになります。これはパッケージ製品の競争力にも直結します。
もちろんVB.NETを選ぶことが間違いだとは考えておりません。既存資産の量、社内スキル、予算、優先順位・・・判断の軸はお客様ごとに違います。ただ「なんとなく互換性が高いから」VB.NETを選んで数年後に後悔してほしくない、それがC#を提案した理由です。

生成AIをどう使ったのか

---

もうひとつ、このプロジェクトの特徴があります。私たちのエンジニアはほとんどコードを書いていません。
VB6コードの読み解き、業務ロジックの抽出、変換後のテスト仕様書の作成、そしてC#コードへの変換―――こうした工程で生成AIをフルに活用しました。人手による直接的なコード記述は原則として行わないアプローチです。
こう書くと「エンジニアは何をしていたのか」という話になりそうですが、実際は逆でやることは減っていません。むしろ密度が上がっています。

今回、私たちのエンジニアがやったのはこんな仕事です。
　－　元のVB6コードと実際の業務仕様を突き合わせて理解する
　－　生成AIに「何を、どういう文脈で、どう作らせるか」を設計する
　－　生成されたC#コードをレビューし、設計判断を下す
　－　テスト設計する（テスト仕様書は生成AIに作らせます）
　－　動作を検証する
　－　次にどのモジュールをどう進めるかを組み立てる
コーディングという「手を動かす作業」の時間がそのまま「設計と検証に頭を使う時間」に振り替わっている感覚です。

このアプローチによりこれまで人手コーディング前提では予算が組めなかった規模の案件にも現実的な選択肢を出せる可能性が出てきました。「600画面を全部を書き直すなんて無理」と諦められていたパッケージにも「AIを使いながら段階的に」という道筋を提示できる。まだ手応えの段階ではありますが、大きな変化だと感じています。

やってみて感じていること

---

AIが生成したコードをそのまま採用できるかというと、そんなことはありません。レビューでの引っかかりもあればテストでの手戻りもあります。
プロンプト設計が不十分だと、機能的には動作しても冗長な記述や過剰なコメントが目立つ「リファクタリングの余地が大きい」コードが生成されてしまいます。
ただ、丁寧に進めていくと、どこにAIが強くて、どこに人間の判断が必要かの勘所が少しずつ見えてきます。今回、一部モジュールを移し終えたことで「このやり方は次の案件でも活用できる」という手応え、実感を得ています。
残るモジュールにどう展開していくか、他のお客様の類似案件にどう応用していくか、これからの課題です。

同じような悩みを持っていたら

---

もしパッケージ製品の古い資産を抱えていて、こんなふうに感じているなら ―――

　－　動いているから触れない、でもこのままではまずい
　－　新しい環境に移す話は出るけど、それで本当にいいのか迷っている
　－　全面刷新は予算的にも工数的にも無理だと諦めている
　－　若手エンジニアが集まらず、保守要員の高齢化が気になっている

――― ぜひ一度、お話しさせてください。医療系に限らず、製造・物流・建設・士業向けなど、パッケージソフトを展開されているベンダーの方であれば業種を問わずご相談いただけます。
必ずしも「今すぐ全部やりましょう」という話ではありません。まずは製品を今後どう位置づけていくか、どこから手を付けるのが現実的か。そういった整理からご一緒できればと思っています。

---

お問い合わせ：こちらのフォームから