TOP
＞
業務システム
＞ イントロダクション
IT基盤を刷新する レガシーマイグレーション入門
第４回：レガシーマイグレーションの落とし穴
著者：
新日鉄ソリューションズ 荒木 義史
2006/7/5
1
2
3
次のページ
イントロダクション
パッケージ導入やスクラッチ型（注1）の開発を問わず、大型のシステム開発プロジェクトではコスト超過や工期遅延、場合によっては目標とした品質確保の未達成というような例をしばしば耳にする。
※注1：
SIerがユーザの要望に応えて行う、オーダーメード型のシステム開発
レガシーマイグレーションの案件についてはそういった問題はあるのだろうか。特に「Rehost型マイグレーション（注2）」は、「通常のスクラッチ型の開発に比べて、短工期・低コストでの開発が可能」といわれているが、実際にそうなのだろうか。果たして落とし穴はないのだろうか。
※注2：
ビジネスロジックには変更を加えず、機械的なコード変換技術やエミュレーション技術でアプリケーションをレガシー基盤から新基盤に移行させるマイグレーション方式
今回は主にRehost型マイグレーション案件において、一般によく見受けられる問題点をいくつか紹介する。
ツール変換という落とし穴
Rehost型マイグレーションはビジネスロジックには変更を加えないまま、機械的なコード変換技術やエミュレーション技術でアプリケーションをレガシー基盤から新基盤に移行させるものである。
基盤を移す場合に変更する部分としない部分を分けると、具体的には次のものになる。
変更する部分
原則として、環境の相違に伴う修正のみ
変更しない部分
本番プログラムおよび関連資源との間のインターフェース／プログラムロジック・機能・画面／帳票のレイアウトおよび論理マップ（アプリケーションとのインターフェース）
表1：Rehost型マイグレーションする際に変更する部分としない部分
この「環境の相違に伴う修正」はその修正をコードレベルで行う、もしくは実行時ルーチンやコンパイラ側で吸収させるかなどの条件に分かれていくつかの方式があるが、いずれの方式も、環境固有部分の修正仕様についてパターン化が可能である。
そのことより、ほとんどのマイグレーションベンダーはその修正作業をプログラムで実施するソリューションを可能としている。つまり、必要な修正作業を変換ツール（実行時ルーチン、コンパイラなどを含む）で実施することによって、手作業より正確・短工期・低コストを実現しているのである。
しかし、「企画 → 設計 → 製作 → テスト → 移行 → 保守」という一連のシステムライフサイクルの中で、変換ツールが行う範囲はコーディング部分のみである。企画・設計工程や、テスト・移行工程については、それぞれ現行分析やテスト結果の検証などの支援ツールが一部に存在しているものの、原則は人間が行う仕事となる。
例えばレガシー上のネットワーク型や階層型のDBをRDBに移行する場合、配列（オカレンス）項目をフラットに並べるか、スプリットして別テーブルとして持つかというような判断は、データベースの設計作業を行った上で決定する必要がある。変換ツールはその設計結果に基づき、自動コーディングしているに過ぎない。
1
2
3
次のページ
著者プロフィール
新日鉄ソリューションズ株式会社 荒木 義史
入社以来、製鉄所生産管理システムに対して、企画〜設計〜開発〜保守のソフトウェアライフサイクル全般に渡る業務に従事。現在は鉄鋼システムでの知見をもとにレガシーシステムを中心としたコンサルティング業務を担当。
INDEX
第4回：レガシーマイグレーションの落とし穴
イントロダクション
変換ツールの種類
運用管理という落とし穴
