この記事について問い合わせる

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

経済産業省が公開したDXレポートの中でも、古くなったシステムの見直しの重要性が繰り返し記されていますが、マイグレーション プロバイダである当社にも、レガシーシステムの見直しに関する問い合わせやご相談を多く頂戴しています。今回のコラムでは、その中でも特にご相談が多いVB6.0のアプリシステムをどのように刷新し移行していくか、システム見直しの全体的な進め方と合わせて解説します。

Microsoft製品のライフサイクル

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

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

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

Microsoft製品のライフサイクル

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

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

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

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

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

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

システム刷新の進め方 DXレポート

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

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

システム刷新の進め方

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

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

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

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

VB6からのアップグレード

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つめは、「変換パターンのチェック」です。当社独自ツールによる変換では、同じエラーに対して同じ変換を行いますので、各パターン毎に最低1個所は変換個所のロジックを通す単体テストを実施し、正しさを確認します。

品質確保の方法(テスト手法) 画面・帳票項目チェック/出力データコンペア

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

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

お問い合わせ

タイトル 必須
お名前 必須
お名前(フリガナ) 必須
メールアドレス 必須
会社名 必須
部署
役職
電話番号 必須
お問い合わせ内容

個人情報保護方針

株式会社システムズは、コンピュータ関連システムの構築、コンサルテーション、ソフトウェアの 開発・設計・販売・保守等を提供するに当たり、個人情報はお客様、お取引先様、株主様および 従業者等からお預かりした重要な資産であるという認識のもと、情報社会の一端を担う企業とし ての社会的責務を全うするため、個人情報に関する法令、国が定める指針、規範に基づき以下 に個人情報保護方針を定め、個人情報の厳正な取り扱いに努めます。

1.目的

個人情報の重要性を全社員・役員に認識させ、個人情報に関する法令、国が定める指針、規範を遵守するとともに、管理規程を制定し着実に実施いたします。またこれらの取り組みを継続的に維持および改善いたします。

2.個人情報の取得

個人情報はお客様ご本人に利用目的を明示し同意を得た上で、サービス提供上必要な範囲内で取得します。

3.個人情報の利用

取得した個人情報は利用目的にのみ使用します。お客様の同意がある場合または法令・指針・規範等に基づく場合を除き、目的外利用および第三者への提供・開示はいたしません。またそのための措置を講じます。

4.Googleアナリティクスの利用

  1. 当サイトは、利用状況を把握し、サイトの改善を図るため、Googleアナリティクスを利用しています。Google社が訪問履歴を収集・記録・分析しますが、個人を識別する情報は含まれておりません。
  2. 当サイトではGoogleアナリティクスデータとお問い合わせフォームから送信された個人情報を紐付けることが可能ですが、これを第三者に無断で提供・販売することはありません。
  3. Googleアナリティクスの利用規約とプライバシーポリシーにつきましては、Google社のサイトでご確認ください。
    Google Analyticsの利用規約
    Googleのプライバシーポリシー

また、Googleアナリティクスによる情報収集を停止することも可能です。「Google アナリティクス オプトアウトアドオン」をインストールし、ブラウザのアドオン設定を変更してください。

5.クッキーについて

当サイトでは、ウェブサイトの利便性向上を目的にクッキーを利用しています。クッキーはサーバーから利用者に送信されブラウザに保存される情報です。クッキーは無効にすることもできますが、その結果サイト機能の一部またはすべてが利用できなくなる可能性があります。

6.個人情報の管理

取得した個人情報について、充分な安全対策を実施し管理することで、不正アクセス・漏えい・滅失・毀損等の防止・是正をいたします。

7.苦情・お問い合わせへの対応

個人情報への扱いに対するお客様からの苦情およびお問い合わせには、誠意ある対応をいたします。

8.個人情報の開示等

取得した個人情報に関して、お客様ご本人からの訂正・削除および開示等のご要望には迅速かつ適切な対応をいたします。

制定日 2005年4月1日
改定日 2011年10月1日
株式会社 システムズ
代表取締役社長 小河原 隆史

当社の個人情報の取扱いにつきまして、ご意見・ご質問等ございましたら、下記までご連絡くださいますようお願い申し上げます。

株式会社 システムズ 個人情報保護に関するお問い合わせ先
個人情報お問い合わせ窓口
株式会社 システムズ 個人情報窓口

TEL:03-3493-0033
FAX:03-3493-2033
メールアドレス:kojin_jyouhou@systems-inc.co.jp

この記事を書いた人

通称ぶいびー板倉
当社の看板セミナー講師