VB6.0アプリの移行から見えてくる「DX時代の老朽化IT資産活用」の進め方

Microsoft製品のライフサイクル

Microsoftの多くの製品には、メインストリームサポートと延長サポートがあり、メインストリームサポートは製品発売から約5年間、延長サポートはその後の約5年間となります。

新機能の追加やセキュリティを含めた問題点の更新パッチが提供されるメインストリームサポートと異なり、延長サポート期間に入るとセキュリティの更新パッチしか提供されず、期間が終了すると当然セキュリティリスクも高くなります。

サポート終了まであと半年とか3カ月で「何とかならないか？」と相談を受けるケースもありますが、延長サポート期間は猶予期間と捉え、サポート終了間近に慌てなくてすむよう、早めの対策を講じたいものです。

また、Windows10は、サポートモデルが変更になっています。年に2回、機能更新プログラムがリリースされますが、バージョンごとにサポート期限が決まっており、各バージョンのサポート期間は約1年半～2年半程度に設定されています。

Windows10であればずっと同じ環境を使い続けられるというわけではなく、一部のCPUがサポート対象外となったり、ドライバー関連などは互換性が失われてしまうこともあり、今まで使用していたアプリケーションが正常に動作しなくなってしまう可能性もあります。

2021年6月にはWindows11が発表されましたが、今後もWindowsのレガシー問題がなくなることないとでしょう。

老朽化が進むシステム刷新をどう進めていくか

老朽化が進むシステム刷新の進め方については、DXレポートにも詳しく述べられています。今回は、その情報を読み解きながら解説します。レポートでは、約7割の企業がレガシー化した古いシステムがDXの足かせとなっている、と指摘されています。

長年の度重なる改修でシステムは複雑化、肥大化が進み、システム構築当時のメンバーは退職してしまい、開発当時の仕様書等のドキュメント類も保管されておらず、システムの中身がブラックボックス化したままどうにも手が施せない。このようなレガシーシステムをどう刷新していけばいいのでしょうか。

これはDXレポートで使われている絵ですが、非常に分かりやすいと思います。システムを使用する側からすれば、使用する機能などの見えている部分は氷山の一角に過ぎませんが、その裏(水面下)で、ブラックボックス化したシステムのプログラムが肥大化しています。ユーザー側は、「この画面をこんな感じにしたい」と要望してきますが、そのためには膨大なプログラムの中身を解析し、影響調査をし、改修、テストしていかねばなりません。DXレポートでは、こうしたレガシー資産を「技術的負債」と呼んでいます。

「技術的負債」を解消していくには、既存システムの全体像を整理し、システムの必要な部分と不要な部分を切り分ける、すなわち、システムで使用されていないプログラムを明確にして破棄することでスリム化を図ることが重要となります。

システム刷新の進め方を図にまとめました。第一ステップとして、現状の業務やIT資産・システムを整理して可視化を行い課題を抽出、経営者が将来ビジョンを明確にし、第二ステップとして、次期IT計画となるロードマップを作成することとなります。第三ステップでは、そのロードマップに従って、段階的に既存システムを刷新、または廃棄を行う、あるいは必要な機能は新たな構築したり、外部サービスを活用し、既存システムと連携するようにしていきます。

レガシーアプリケーションの移行手法

さて、マイグレーションによりシステム刷新を図っていく方針となった場合、具体的にどのように移行を進めていくべきでしょうか。システムズでは、さまざまなMicrosoft製品の移行のご相談を頂戴していますが、ここでは、その中でも特に多いVB6.0のアプリシステム移行にフォーカスして解説します。

なお、移行のご相談では、「設計ドキュメントがない」、「ストアドプロシージャをなど利用し、ビジネスロジックをDB側が持っている」、「ORMやDBアクセスフレームワークなどを利用していない」といった理由で「移行できないのではないか」と心配されるケースが少なくありません。しかし、実際にはこうした理由で移行が困難になることはありませんし、ドキュメントがすべて揃っている企業は極めて少ないのです。

VB6.0から.Net 2019へのアップグレードの例を図示しました。VB6.0のアプリケーションは、VB6.0共通プログラム群と記載していますが、Microsoftから提供される多くの関数を使用しながらプログラムを作成したり、サードパーティ製品を使用したり、データベースへの接続にも接続プログラム群が使用されます。

VB6.0のアプリケーションのバージョンアップ自体は非常に簡単で、自動的にMicrosoftアップグレードウィザードが起動して更新、バージョンアップしてくれます。ただし、.Netに移行する場合は、Microsoftが提供する関数の仕様が変わっていたり、関数自体がなくなってしまうケースもあります。

アップグレードウィザードはこれらを判断できずエラーとなってしまうため、プログラム側を修正していかなければなりません。また、サードパーティ製品やDB接続プログラム群などは、Microsoftのアップグレードウィザードではうまく変換できないため、すべて.Net環境に合わせてプログラムを修正する必要があります。

ちなみに、VB6.0からのアップグレードは.Net 2008までしかできないため、最新の2017や2019にバージョンアップする際は、いったん2008にバージョンアップし、その後、2019へ再度バージョンアップする必要があります。

もう1点、触れておきたいのは、アップグレードレポートに出力されないようなエラーも多く存在する、ということです。上の図は、ラベルの文字が大きくなってしまい、文字切れしてしまう差異や、マイナス記号の位置が「」の前後で違ってしまうエラーで、エラーレポートには記載されません。これは、実はプログラムの問題ではなく、OSの設定の問題であったりもします。マイナス記号の位置については、コントロールパネルの設定で変更でき、ラベルの文字に関しては、Windowsの設定から変更ができます。

このほか、タブ移動の順番がばらばらになってしまい、それにより画面表示時の初期カーソル位置が変わってしまう、IME制御がリセットされる、最大桁を超えて入力できる、Gridに正しく表示されない、Gridの動作が異なる、帳票プレビュー時にViewerの表示ができない、帳票のレイアウトがずれるといった、エラーレポートには記載されず、動作させてみないと分からない類のエラーがあります。

アップグレード ウィザードや隠れたエラーのパターン化と変換設計

このような隠れた不具合は、経験豊富な企業でなければなかなか知り得ない情報です。当社のようなマイグレーションベンダーは、こういった点も事前にプログラム改修した上で、テストを実施しています。

この図は、当社のマイグレーションの流れを示したものです。資産の可視化（棚卸）、必要に応じて資産のスリム化を行い、移行対象の資産が確定したら、移行元と移行先の環境をそれぞれ構築し、MSのアップグレードウィザードでアップグレードを実施。

アップグレード後に出力されるアップグレードウィザードからエラー内容を抽出し、数千～数万にも及ぶことの多いエラーをパターン化します。ある事例では、約2万7千件も発生したエラーが40程度のパターンになりました。これらのエラーパターン毎に変換設計を行います。

ツールで変換する場合は、当社独自の変換ツールのカスタマイズを行います。特定の機能を対象に変換し、新旧の比較検証テストを実施、変換仕様や変換ツールの正しさを検証していきます。

最後に、品質確保のためのテスト手法について簡単に触れておきます。1つめは、「変換パターンのチェック」です。当社独自ツールによる変換では、同じエラーに対して同じ変換を行いますので、各パターン毎に最低１個所は変換個所のロジックを通す単体テストを実施し、正しさを確認します。

次に画面・帳票項目のチェックですが、隠れた不具合が発生するのは、画面の動作周りや帳票のレイアウト周りです。従って、すべてのコントロールを一覧化し、コントロール種別ごとに確認項目を設け、全コントロールの動作確認（新旧比較）を実施します。

今回のコラムでは、VB6のアプリレガシーの移行を題材に、移行のポイントと隠れた不具合などの注意すべきポイント、エラー対策と品質確保への当社の取り組みについて解説しました。レガシーシステムからの脱却には、現状分析と可視化が重要であることを念頭に置いて、「技術的負債」の解消に取り組んでいきたいものです。