VB6(Visual Basic 6)をweb化!既存IT活用のひとつの選択肢。ASP.NET移行によるオンプレVBアプリの再生
「クライアントサーバ型のVB6があるのですが、これを単純にVB.NETにするのではなく、このままweb化できないですか?」というご相談が増えてきました。既存のVB6資産を有効に使いつつ、VB.NETにマイグレーションする中で、クライアントモジュールを廃止し、webアクセスとすることで、テレワークや働き方改革につなげたいというお考えが大きいようです。
VB6(Visual Basic 6) 業務アプリ移行に関するご相談の変化
windows7のサポートが1月に終了し、早くも1年近くがたちました。春先からのコロナ禍の状況において、「クライアントサーバ型のVB6(Visual Basic 6)の開発言語で構築されたシステムがあるのですが、これを単純にVB.NETにするのではなく、このままweb化できないですか?」というご相談が増えてきました。
既存のVB6(Visual Basic 6)資産を有効に使いつつ、VB.NETにマイグレーションする中で、クライアントモジュールを廃止し、webアクセスとすることで、テレワークや働き方改革につなげたいというお考えが大きいようです。
まさに今は、既存のIT資産をニューノーマルに対応させるような、大きな環境変化の真っ只中ですね。
緊急的にテレワーク環境の構築を済ませ、必要最小限の出社でビジネスが継続できるようにとの対応は、ほぼどこの企業様も取り組んでらっしゃると思います。この長引くコロナ禍において、さらにテレワーク対応できる業務はどこなのか?
今まで以上に、現状業務を見つめなおし、ネットワークやシステムの変更をされた、あるいはこれから計画されている企業様も多くいらっしゃると思います。また、社内や社外を問わず、私の参加する打合せも基本的にzoom、meet、teamsといったweb会議になり、またシステムズもそうですが、セミナー関係も大半がウェビナーになってきました。
まさにニューノーマルと呼ぶ、「当たり前のこと」が急に切り替わってきた印象です。
まだまだ大きな波が来るリスクは高い状況にあり、コロナウィルス以外にも自然災害が多くなっている昨今、BCP対策も視野にITをうまく使うという時代になってきました。
このような状況から、働き方の改革は今後も加速すると考えられますが、企業が利用する業務ITの面で考えると、様々な働き方に対応できる、柔軟なシステム基盤の構築が必要になってきている現在です。
Web化による働き方の改革
WEB化の一番のメリットは、主に企業のIT部門、情報システム部門の担当の方が「クライアントアプリのセットアップ」から解放される部分が大きいです。アプリケーションの配布やインストールなど、クラサバ型のシステムでは、このセットアップが非常に手間で、インストールマニュアルを作成し、実際の利用部門のユーザーに依頼しても、ちょっとした違いがあれば、問合せが発生し、対応に迫られるというお話をよくうかがいますので、特に利用ユーザー数の多い企業では、この部分の工数削減効果は大きくなるでしょう。
また、リリースするたびにこういった作業が必要になることから、ちょっとしたシステム改修をして、ユーザーに展開するということが難しくなり、せっかくオリジナルで開発したシステムが業務に合わず、逆にシステムの制約にあわせて業務を行うようになってしまっているというような企業さんもいらっしゃいます。WEB化することで、改修・リリースがしやすくなり、より業務の実態に合った、利用者の作業効率の向上という点にもつながると思います。
また、web化することにより、新バージョンへの更新作業はWebアプリケーションサーバーへのデプロイのみとなりますので、情報システム部門の方も在宅環境でも対応が可能となり、情シスは出社しなければならないという制約から解放され、働き方改革につなげることができるでしょう。
WEB化することで、もちろんセキュリティ面などの考慮は必要ですが、同時に利用部門の方も、場所やPCを選ばすに、使えるようになるという点では、利用者サイドの働き方改善にもつながります。
VB6(Visual Basic 6)をweb化する際のポイント
VB6(Visual Basic 6)からVB.Netへのマイグレーションであれば、マイクロソフトのアップグレードウィザードして残りは手作業でエラー修正、あるいは当社を始めマイグレーションベンダーのオリジナル変換ツールを用いてソースコードを二次変換し、実行エラーを解消したうえで、新旧バージョンの「比較検証テスト」で動作の確認と検証をするという流れですが、web化となると、もともとクライアントモジュールで実施していた処理をそのままクライアントで実施するにはブラウザの仕様もあり、制約があります。
全てをサーバー側の処理に移行し、イベントの起動やその結果の表示だけを、クライアント側に(つまりブラウザ処理に)移行すれば、移行自体は単純になりますが、全てのイベントで、都度サーバーへの問合せ(通信)が発生し、ネット環境によっては以前より遅いシステムになってしまう可能性があります。
全てのイベントをサーバ側で処理させず、一部はクライアント(ブラウザ)で処理をさせるとなると、どのようにサーバー側とクライアント側に処理を分けるのかというのが重要になってきます。ロジックの1つ1つを手作業で人が判断していては、時間がかかり、また非常に開発コストが大きくなってしまい、そうすると新規開発に比べたマイグレーションのメリットが薄れてしまいます。
システムズでは、VBマイグレーションのプログラムソースコードの解析ツールを応用し、主にDBに接続するイベントかどうかを自動的に判断して、処理を分けるようにしています。
DB接続を伴うイベントであれば、サーバー側の処理として移行します。一方でDB接続がないような処理、例えば入力チェック処理のようなイベントは、ブラウザ側の処理に移行します。テストを進める中で、処理速度や反応速度の問題など、課題が発生した場合は個別に対応を重ねます。
まとめ
コロナ禍の影響による働き方改革の一環もありVB6(Visual Basic 6)の業務アプリケーションをWeb化できないかというご相談が増えてきました。Web化することで情報システム部門、利用部門が共に働き方改革につなげることができます。
Web化においてはサーバー側、クライアント(ブラウザ)側に処理を適切に分けることが必要となり、その過程において効率良くプログラム内を解析し、移行していくことが重要なポイントとなります。
古くなったVB6(Visual Basic 6)を単にVB.Netへ移行するだけでなく、働き方改革につなげるWeb化という選択肢は、既存の資産を活かす意味でも有効です。
ご興味がございましたら、もとのVB6(Visual Basic 6)の規模感(ステップ数、画面数、モジュール数、利用しているサードパーティー製品、帳票など)の概況とともにご相談いただければ、無料で概算の費用と期間を算出いたします。
お気軽にお問合せください。