Home / 運輸業の基幹システムのVB6.0からVB .NETのマイグレーション事例

運輸業の基幹システムのVB6.0からVB .NETのマイグレーション事例 運輸業の基幹システムのVB6.0からVB .NETのマイグレーション事例

運輸業の基幹システムVB-ONETECH本件は2000年代から使い続けている基幹システムの刷新のためVB6.0からVB .NETへのマイグレーションです。弊社はアプリケーションのマイグレーションを担当しました。約180人月の規模となりました。VB6.0で作られたこのシステムはすでにサポート期限が切れています。VB6のシステム開発環境(IDE)は、2008年にMicrosoftの延長サポートが終了しており、新たな脆弱性が発見されたとしてもセキュリティ更新プログラムが提供されません。開発時によく使用するActiveReportsSPREADInputManなどのサードパーティー製品のサポート期限にも注意が必要です。Oracle DB10Gを利用していたため、AWS RDS for Oracleへ移行しました。


導入の経緯

運輸・運送業界は1900年代から順調に成長をし続けています。一方で企業活動の変化とともに基幹システムは必要な機能を継ぎ接ぎしながら使われてきました。業務とシステムは複雑化し、システム担当の変更やマルチベンダーへの発注によりシステム全体を俯瞰できる担当者も一握りの状態です。経済産業省が発表した「DX(デジタルトランスフォーメーション)レポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」のいわゆるレガシーシステムです。

公式の保守サポートも切れて、ブラックボックス化してしまったレガシーシステムを運用し続けることで故障やサイバー攻撃に遭うリスク、保守コストの肥大化、障害が起きた際に原因を究明できないといった問題が起こる可能性があります。

2020年未曾有のコロナ禍の影響で業界は大きなダメージを受けましたが、一方、経営陣はこの機会に現状抱えているリスクのを排除し、本格的なDXの推進をするべくレガシーシステムのマイグレーションの決断をしました。

「アプリケーションの移行」は、経営戦略にも大きく関わってくるため、情報システム部門だけでなく経営層を中心に他部門とも連携を取り、全体像を俯瞰して把握しなければ進められません。


VB6.0システムを使い続けるリスク

マイグレーションを実施すべき主な理由は、VB6.0を継続利用することで様々なリスクが伴うからです。例えば次のようなリスクがあります。
一つ目のリスクは、セキュリティリスクを伴うということです。

VB6.0の開発環境はマイクロソフトのサポートが終了しているため、その後リリースされたWindows7以降のOSでは動作保証がありません。
二つ目のリスクは、技術者の減少です。

サポートが停止されたVB6.0の技術者は年々減少することが予想されるため、企業にとっては技術者の確保が難しくなってきます。
このようにVB6.0の継続利用には多くのリスクを伴うため、早めに対策しておくことが重要になっています。


マイグレーションプロセス

ONETECHの業務範囲(ベトナムで開発、日本でサポート)

  • 資産可視化:プログラムの棚卸し、マイグレーション対象範囲を明確化
  • 概算見積もり:要件を確定させ見積もり提示
  • 調査・分析:Microsoftアップグレードツールを使い、問題点の洗い出しとパターン化
  • 変換設計:パターン化した課題に対して機能の代替、変更方法を検討、ツール変換か手動返還かを選択。変換ツールの作成とカスタマイズ。
  • サンプル変換:特性機能変換とテストを実施。変換ツールの検証。追加対応が必要な項目の洗い出し。
  • 変換修正:全ソースを変換ツールで変換、手作業対象分の修正。
  • 連携システム対応:一部システムとの連携のための開発
  • 環境構築:AWS RDS for Oracle環境構築
  • 現新比較テスト:現行処理結果との比較
  • 受け入れテスト:クライアントが実施
クラウドへの移行

今回の業務範囲はアプリケーションのマイグレーションです。データベースはオンプレミスのOracleデータベースを利用していました。今回は将来のビジネスの弾力性を重視しクラウドを選択しました。結果、AWS RDS for Oracleへのデータベース移行となりました。バージョンはOracle 10Gから19Cへの移行です。AWSの環境は別ベンダーが担当し、弊社はアプリケーションマイグレーションとテストを担当しました。

Amazon RDSアーキテクチャの全体像

参照: https://pages.awscloud.com/rs/112-TZM-766/images/01_RDS_Architecture.pdf

OCX評価

マイグレーションではサードパーティツールはVB6.0の「ActiveXコントロール」と、.NET「Windows Forms」の互換性はないため。

アップグレードウィザードでは自動変換されません。基本的に作り直しが必要です。今回の対象OCXの表計算や帳票のツールはFPSpreadやCrystal Reportを提案し変換しました。また担当者もわからないOCXについては、関係各社に弊社がヒヤリングして変換の必要性を検討しました。

VB2VB_NE-Tサードパーティツールの作り直し

変換のフェーズ分け

100万LOC以上、50モジュール以上関係部署も15部署近くあるので変換を4つの段階にフェーズ分けしました。当初の予定では変換検証期間、事前準備期間、モジュール変換フェーズ1、2、3、4、とテスト環境での結合テスト(クライアント)、本番環境移行、UATと9段階に分けてプロジェクトを進行しました。変換フェーズごとに変換済みのモジュールを関係部署が確認します。

概算見積もり

LOC数に自動変換想定率(70%)を乗じて、残りを手作業変換をオフショアの生産性(2800STEP/人月)と人月単価で手作業の工数を算出します。

上記に変換対象のOCXの作業工数を算出して足します。

その他想定される作業なども別途見積もりとして算出します。

システムマイグレーションのポイント~オフショア開発での成功事例

キックオフ会議

  • プロジェクト概要:プロジェクトの目的や概要などを確認
  • スケジュール:マスタースケジュールを確認、詳細スケジュールはWBSで提示、フェーズごと進捗ごとに詳細スケジュールを更新して提示
  • 成果物受け入れ条件:成果物の定義、受け入れ条件の確認
  • 開発体制:開発体制の提示
  • コミュニケーション方法:定例報告などの会議体、コミュニケーションツールの確認、進捗報告方法の確認
  • リスク共有:本案件に想定されるリスクと回避の提案

日本語でコミュニケーション定例会議実施

本件に関しては、毎週1時間ほどの定例会を実施して進捗を報告しました。定例会議では、日本人ベトナム人が参加しますが、100%日本語で実施します。文書類も全て日本語です。定例会は事前にアジェンダを用意して進行します。進捗の確認、QAの確認、成果物の中間確認などを行います。コミュニケーションツールは定例会議ではWEB会議ツールを使用します。日常のコミュニケーションは、メーリングリストを作成しメールでやりとりします。QAシートなどは弊社の方で用意がありますので、クライアントは回答するのみで伝えます。

変換手順

2段階アップグレード

VB6.0からVisual Studio 2017へ直接アップグレードできないため、1段階目としてVB .NET2008に更新し2段階目として最新版のVB .NET2017に移行します。現在、VB.NETは、IDE製品であるVisual Studio 2017が最新版となっています。

サードパーティツールの作り直し

VB6.0でのサードパーティとVisual Studio 2017のサードパーティの仕様に互換がない、作り直しをしました。

WINDOWSアップグレードウィザードでの自動変換でのエラー対応

自動変換時にコンパイルエラーとランタイムエラーが発生します。エラーを分類し独自変換ツールを作成して変換をします。独自変換ツールで変換できないモジュールは手作業で変換します。

動作保証 現新一致テスト

新システムでの入力と出力、操作と操作結果が現システムと比較し同じかどうかを検証し動作保証をします。いわゆるブラックボックステストが基本です。テスト結果は現システムと新システムの画面キャプチャや動画で提出します。今回はさらに連携する他のシステムとの結合試験も担当します。


導入後の効果ーマイグレーションの効果

DXだけでなく資産の有効活用も

リスクを最小化

マイグレーションによってアプリケーションの公式サポートの対象になります。公式サポートは常にセキュリティーも最新の状態に保たれリスクを最小化することができます。

保守コストの削減

レガシーシステムを運用していた時の肥大化してしまった保守コストの削減が可能です。クラウドや共通プラットフォームを活用し、オープン化することで、メンテナンスが容易になり、機能追加などの変更も行いやすくなります。

資産の有効活用

蓄積してきたデータや培ってきたノウハウ、アプリケーションなどの会社の資産を、新システムなどへ乗せ換えることで、引き続き、活かすことができます。

ベトナムオフショア開発の効果

業務理解のためのコストが少ない

ベトナムでオフショア開発でマグレーション開発することは非常に相性の良い開発と言えます。一般的にオフショア開発は業務理解が非常に重要と言われています。業務理解ができないとシステム開発もうまくいきません。また業務理解のために時間をかけてコミュニケーションしていくことになります。コミュニケーションの際にはブリッジSEと言われる橋渡役がキーマンとなります。一方でマイグレーションの場合、現行システムの機能をそのまま新システムに移行するのでこのコミュニケーションコストが非常に少なくて済みます。前と同じ挙動にすれば良いのでテストも非常にしやすいです。従いまして単純に日本企業の単価に比べての差異がそのまま費用に反映されますので日本企業の60%くらいお安く提供できるのが特徴です。
オフショア開発の活用の流れ

プロジェクトの反省点

クラアインとの担当者は、肥大化するシステムの全貌がわからず非常に苦労していました。事前準備の際に弊社としてもできるだけわかりやすくヒヤリングをしようと心がけたのですが、情報の引き出しのためのコミュニケーションに問題がありました。いただきたい情報を整理するために手順をドキュメント化したり、オンラインで画面の共有をしながら説明をするという工夫で乗り切りました。今回は直接エンドユーザーとの案件でしたのでSI様が間に入るケースですとこのような調整はSI様に依頼するケースが多いのでコミュニケーションを軽く考えていたところが反省事項です。しかしプロジェクト初期でこの問題を改善することができました。今後はしっかりとお客様の立場で依頼ができるように改善してまいります。


VBマイグレーション対象システム

業務システム全般、勤怠管理システム、人事システム、基幹システム、生産管理システム、物流システム、予約システム、生産・販売管理パッケージ、配車管理システム、車両管理システム、診療予約システムWindowsシステム、会計システム、給付システム、、経費管理システムなど

無料相談
お問い合わせ