かつてVisual Basicで作ったアプリケーション資産を見直す動きが高まっている。運用面の負荷が高いことに加え,マイクロソフトによるOSやVBのサポート期限切れが続々到来しているからだ。しかし.NETやJavaへの移行は容易ではない。VB資産が企業情報システムのお荷物になるかもしれない。

 「VBからVB.NETへツールによる移行を試してみた。動くことは動いたが,とてもメンテナンスに耐えるものではないことが分かった。結局,既存のVB資産を捨てて,ゼロから作り直すことになった」。

 VB 6で開発したクボタの人事情報システムのリプレースを担当したクボタシステム開発 第一ソリューション事業部 第一コンサルテーショングループ 課長代理 伏見弘樹氏は,その苦労をこう語る。

 VBアプリケーションを使い続ける限り,配布の手間やDLLの互換性問題から逃れられない。そこで,既存のVBアプリケーションを.NETやJava,リッチ・クライアントに作り替えようという動きが高まっている。

図1●マイクロソフトによるVBとOSのサポート期限と動作保証
図2●VB資産移行の選択肢と注意点
 マイクロソフトによるVBとそれを稼働させるOSのサポート切れの問題もある(図1[拡大表示])。半年後に通常サポートを受けられるのは,Windows 2000/XP上で稼働するVB 6/VB.NETだけになってしまう。

 しかし,VBからVB.NETへの移行は容易ではない。両者は実行環境が異なる。クラス・ライブラリや言語仕様も異なる。Javaやリッチ・クライアントなど他技術への移行を考えるならなおさらだ。現状の把握に基づき移行方針を検討する必要がある(図2[拡大表示])。

ウィザードに頼るのは危険

 VBアプリケーションを.NET化するツールとしては,Visual Studio.NET(Professional版以上)に付いているアップグレードウィザードという機能がある。VB 6で作成したコードをVB.NETのコードに変換できる。

 しかし,その変換効率が思いの外悪いことが分かってきた。NEC Eラーニング事業部 エキスパート 山崎明子氏は「推奨されないコーディングをしていたり,モジュール同士が密結合していたりするシステムは移行が難しい」と指摘する。

 変換効率の悪さをもたらす原因は,いくつかある。

 まず,言語仕様の違いを完全に吸収するのが難しい。例えば,メインフレームとデータをやり取りする際などによく使われる固定長文字列が,.NET FrameworkのCTS(共通型システム)ではサポートされていない。ウィザードでコンバージョンすると,特別に用意されたVB 6互換ライブラリを使う形に変換される。動くことは動くが,イレギュラーな仕組みなので,なるべくなら避けた方が賢明だ。

表1●VBのコンバージョンに役立つツールやサービス

 また,.NETではコードの記述に厳密さが求められるようになった。オブジェクト変数を実行時バインディングする記述にしていると,プロパティの変更が反映されないことがある。

 新日鉄ソリューションズ システム研究開発センター ソフトウェアシステム研究部 主務研究員 斉藤康弘氏は「コンバージョンした場合,(VBとVB.NETの違いを理解した上で)コードを目でチェックする作業が不可欠。時間とコストが許す限り,ゼロから作り直すのに越したことはない」と指摘する。まずはマイクロソフトが6月から提供しているVB 6のアドオン・ソフトCode Advisor for Visual Basic 6.0日本語版で,自社のコードをチェックしてみるのもよい(表1[拡大表示])。

 ウィザードによるコンバージョンに向いているのは,独立度の高い小規模なアプリケーションに限られると考えた方がよいだろう。大きなシステムでは,コストや期間と相談しながら部分的に使うのが現実的だ。

モジュールの独立度に注意

 アプリケーションを作り直す際には,モジュール間の独立度に注意する。独立度が高いほど,段階的移行が容易になる。画面部分とロジック部分が分離されていれば,画面部分だけを先に移行できる。販売管理と会計管理が分離されていれば,片方だけを先に移行できる。

 アプリケーションがCOMコンポーネント化されていれば,コードを書き換えなくてもラッパー経由で.NETからVBアプリケーションを使える。.NETアプリケーションからCOMを呼び出すのが,RCW(ランタイム呼び出し可能ラッパー)。VBアプリケーションから.NETコンポーネントを呼ぶのが,CCW(COM呼び出し可能ラッパー)だ。

 ただし,ラッパーを介する分だけ,パフォーマンスが落ちることが指摘されている。「COMの作り方によっては,RCWでは呼べないものもある」(斉藤氏)。また,RCWで.NETからCOMコンポーネントを呼ぶ場合,COM自体はアンマネージ・コードなので,メモリー管理など.NET Frameworkに任せられないことにも注意が必要だ。

他技術も選択肢

 移行先は,技術者のスキルを生かしやすいという意味で.NETが有力候補だが,Javaやリッチ・クライアントもあり得る。技術者にスキルがあるという前提なら「.NETでもJavaでも移行の手間はあまり変わらない」(日本IBM ソフトウェア開発研究所 WebSphereツール WebSphereツールサービス 西野真氏)からだ。

 日本IBMは,VB 5/6のアプリケーションをJavaに移行するツールを用意した。画面部分をJSPに変換し,ロジック部分はStrutsのActionクラスのひな形を生成する。実際のロジックは手作業でコーディングする。

 アクシスソフトはエム・アール・オーと共同で,VB 4/5/6からBiz/Browserへの移行サービスを始めた。こちらは,今のところツール単体での提供は行わず,見積もりから作業までベンダー任せとなる。

サポート不要なら延命も

 サポートを受けず配布の手間が苦にならないなら,VBアプリケーションを延命させるのも一つの方法だ。配布の手間の軽減だけなら,メタフレームを使いWeb化する方法もある。

 開発ツールとOSが動作保証外の組み合わせでも「ランタイムが動かないわけではない」(マイクロソフト デベロッパーマーケティング本部 .NETマーケティング部 デベロッパーエバンジェリスト 西谷亮氏)。

 堀内機械には,VB4/5で構築したアプリケーション資産が大量にある。当初はWindows 95/98上で稼働させていたが,パソコンを順次入れ替え現在では「VB4をWindows XPの上で動かしているものもある」(堀内機械 システム室長 田誠氏)。

 今後さらに,同じマシン上に.NETアプリケーションを共存させることも可能だ。ただし,VBとVB.NETとではセッション変数やアプリケーション変数は共有できない。そのため,変数を共有するにはURLのクエリー文字列で受け渡すなど作り込みが必要になる。