かつてVisual Basicで作ったアプリケーション資産を見直す動きが高まっている。運用面の負荷が高いことに加え,マイクロソフトによるOSやVBのサポート期限切れが続々到来しているからだ。しかし.NETやJavaへの移行は容易ではない。VB資産が企業情報システムのお荷物になるかもしれない。
「VBからVB.NETへツールによる移行を試してみた。動くことは動いたが,とてもメンテナンスに耐えるものではないことが分かった。結局,既存のVB資産を捨てて,ゼロから作り直すことになった」。
VB 6で開発したクボタの人事情報システムのリプレースを担当したクボタシステム開発 第一ソリューション事業部 第一コンサルテーショングループ 課長代理 伏見弘樹氏は,その苦労をこう語る。
VBアプリケーションを使い続ける限り,配布の手間やDLLの互換性問題から逃れられない。そこで,既存のVBアプリケーションを.NETやJava,リッチ・クライアントに作り替えようという動きが高まっている。
図1●マイクロソフトによるVBとOSのサポート期限と動作保証 |
図2●VB資産移行の選択肢と注意点 |
しかし,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のクエリー文字列で受け渡すなど作り込みが必要になる。