日本国内のエンジニア不足は年々深刻化している中で、Windowsのサポートが順次終了及び終了間近して行きますが、速やかに新OSへマイグレーションする必要があり、対応リソースが不足でオフショアでのリソースを利用してシステムマイグレーションを実施する。
VB 6.0から.Netへシステムマイグレーション活用事例セミナー
【このような方におすすめ】
- システムマイグレーションに興味のある方
- システムマイグレーションに検討している方
- 海外へのシステム開発外注を検討している企業の方
【セミナーの内容】
- オフショア開発することのメリット
- マイグレーション を阻む壁
- Microsoftアプリケーションマイグレーションノーハウ紹介
- Visual Basicマイグレーション理由
- Visual Basicマイグレーションとは
- Visual Basicマイグレーション概要
- Visual Basicマイグレーション特徴
- Visual Basicマイグレーション移行注意点
- Visual Basicマイグレーション実績紹介
マイグレーション を阻む壁
-
コストの問題
ひとつめの阻害要因は、コストの問題です。
長い間企業の運営を支えてきたシステムの根幹を刷新するためには、数年の移行期間と何億にものぼる費用を計上することも珍しくありません。そのため、システムマイグレーションの実現は段階的に行い、少しずつ予算の割り当てを新システムに移していくアプローチが求められます。
-
人材不足の問題
ふたつめの阻害要因は、人材不足の問題です。2030年には約79万人のIT技術者人材不足が予想されるとされています。経済産業省が平成28年に発表しました。労働人口そのものが減っています。全体的な労働力不足のなかに、IT技術者も含まれているということです。IT業界の現場では、技術者そのものが不足しているため育成も追いついていません。
オフショア開発することのメリット
-
コスト削減
ベトナムでオフショア開発をする上で日本での人月単価が100万円だとすると一人当たりのコストを７０％近くコストダウンすることが可能です。また長く続く保守運用コストを削減できるところに大きな魅力があります
-
開発リソース
ベトナムの平均年齢は２８歳です。日本と比べ非常に若者が多く、またITエンジニアの育成にも国として力を入れています。
-
理解コストが不要
一般的にオフショア開発ではシステムを理解するための、コミュニケーションが課題になります。マイグレーションは現行システムの機能をそのまま引き継ぎます。エンジニアはソースコードベースでシステムを理解することができます。つまり通常のオフショアでのシステム開発と比較するとコミュニケーションが少なくてすみます。
Microsoftアプリケーションマイグレーションノーハウ紹介
Visual Basicマイグレーション理由
- WindowsXPのOSサポートが終了したため、継続使用にはセキュリティーリスクが伴うようになります。
- VB6.0での開発支援ツールとしてサポート停止
- VB6.0の技術者が減少し、保守要員の確保が難しい
- Windows７移行での動作保証がございません
Visual Basicマイグレーションとは
旧WindowsOSでVB6.0にて構築されたシステム及びアプリケーションを現行の機能はそのままで新WindowsOSにて.Netへ移行する。
Visual Basicマイグレーション概要
弊社は下記のマイグレーションプロセスで対応いたします。
Visual Basicマイグレーション移行注意点
Windowsアプリリリースではマイグレーションは注意点がいくつ紹介いたします。
- VB6.0からVisual Studio 2017へ直接アップグレード不可
- VB6.0でのサードパーティとVisual Studio 2017のサードパーティの仕様に互換がない
- 見積工数と実際の工数が異なる（動作確認のみ２０～３０％）
二段階アップグレード
システムアプリケーションマイグレーションは直接アップグレード不可場合、下記のプロセスで二段階対応を実施します。
Visual Basicマイグレーションで主にWindowsフレームワークとサードパーティがございます。それぞれの特徴で対応方法は下記のようにシステム分析して対応します。
Visual Basicアプリケーション移行実績紹介
Visual Basicアプリケーション移行実績紹介
タイプ：VB6.0からVisualBasic2017へのマイグレーション
ステップ数：４３０ＫＬＯＣ以上
対象：
- WindowFormアプリケーション
- データベース：Oracle９i → Oracle１９ｃ
規模：５１人月（ＭＭ）
期間：７ヶ月
作業範囲
- .ＮＥＴへマイグレーション
- 結合テスト仕様書（動作テスト）は顧客から提出より動作確認実施
成果
- 変換ツールの変換率は６０％→７０％
- 生産性：開発者は一人あたり１０KLOC
- 対応期間は１０ヶ月（当初）→７ヶ月（実績）にできました
これからシステムマイグレーションでは役割分担を明確して下記のフローに沿って作業及び担当を明確して対応実施します。
システムマイグレーションで調査・分析フェーズでＭｉｃｒｏｓｏｆｔアップグレードツールを検討して対応できるかどうか検証して、自動アップグレードできる分と手動対応を分けて管理します。システムマイグレーションで手動対応する必要分を分析してパターン化へ対応する。
エラー一覧よりコンパイルエラーとランタイムエラーを分けて別々シートで管理する。
コンパイルエラー
下記の一覧で弊社側はコンパイルエラーを管理してパターン化にする。
各コンパイルエラーに対して対応方法を決めます。
ランタイムエラー
下記の一覧で弊社側はランタイムエラーを管理してパターン化にする。
ランタイムエラーに対してパターン化にして対応方法も管理します。
ソースコードでエラーを対応する際に各パターン番号を必ず記載します。
本件は下記の体制で対応しました。
オフショア開発発注の流れ
システムマイグレーションの質問応答
Ｑ．システムは古くて仕様書もございません、マイグレーション可能か
Ａ．既存ソースコードでいただいて、現行のシステムとマイグレーション後は動作処理でＩＮＰＵＴとＯＵＴＰＵＴは同じならば良いかと思われます。
本件に関して詳細情報は下記のフォームをご連絡していただければと思います。
システムマイグレーションサービスに関して下記のリンクをご参照
