(1)レガシーシステムの移行における検討項目
レガシーシステムの移行で検討する項目としては、データの互換性がある。現行のシステムと移行後の新システムでファイルフォーマットが異なったり、文字コードが異なると、現行のシステムで作成したデータを新システムでそのまま使用することができず、変換作業が必要になる。変換が発生するとシステムの移行時に要する時間が長くなり、移行をスムーズに行うときの障害になるので、可能であれば現行のシステムで作成したデータをそのまま新システムで使用できるように検討する。
次に検討する項目としてはユーザーインタフェースの互換性がある。ユーザーインタフェースは慣れの問題であるが、システムの移行時に変わると新システムの操作性が悪いというイメージをユーザーが持ってしまい、新システムそのものの印象が悪くなってしまう。これを避けるためにもユーザーインタフェースは同じもしくは似たものにする必要がある。
三番目に検討すべきは、現行のシステムで動作しているソフトウェアのソースコードレベルでの流用性である。稼動実績のある現行システムのソースコードを利用できればプログラムの開発工数だけでなく、テストなども現行システムの開発時に行った内容が利用でき移行時のプログラム開発費用を抑えることができるので、可能な限り流用するように検討する。

(2) レガシーシステムの移行における技術的課題と解決策
最も大きな課題はソースプログラムの流用性である。プラットフォームが変わるソースコードレベルでの互換性が保証されるとは限らず、特に他のコンピュータとの通信機能や、ユーザーインタフェースに関わる箇所はプラットフォームに依存しているため、移行時に変更が必要になってしまう。
現行システムのソースコードが階層化されていて、機能ごとにまとまっていれば変更箇所は少なくてすむが、多くの場合はソースコードの全体に修正を行う必要がある。このとき問題なのは修正すべき点が漏れなく修正されたかと、修正の内容が正しいことであり、これを修正後に確認できるような仕組みが必要である。
そのため、変更を行う箇所には共通のコメントやラベルをつけ変更した箇所を特定しやすくすることと、変更内容について実際の変更を行う前に洗い出すこと、代表的な変更内容を事前に確認(レビュー)することが有効である。
変更を行った箇所を特定しやすくすると、テストの網羅性の確認や不具合発生時の修正箇所の特定が容易になる。また、変更箇所の洗い出しと変更内容の確認を事前に行うことで、変更漏れや変更内容の間違いを防ぐことが期待できる。

(3)解決策の効果とリスク
前述の対策を行うことで効果としては、変更漏れや変更内容の間違いをなくすことができ、システムの移行作業をスムーズに行うことが可能となる。多くの場合、システムの移行は期間が決まっていて手戻りの発生は、スケジュールへの影響が大きいのでこの対策によるメリットは大きい。
リスクは、システムが大きくなると事前の変更箇所の洗い出しが完全なものかを確認することが困難なため変更すべき箇所が漏れていることがある点である。事前に洗い出しをすることでソースコードの変更を行う作業者は他の箇所をチェックしなくなるので、変更時に気づくこともなくテスト工程まで進んでしまうことがある。
また、大きなシステムでは移行時の変更箇所が多く、変更パターンも多くなり、実際に変更するときにどのパターンの変更かの確認が必要になってしまい、想定よりも工数が多くなってしまったり、変更内容が正しくないといった問題がある。この問題はスケジュールに影響を与えたり、テスト工程での問題検出による手戻りといったリスクを含んでいる。
先にも述べたようにシステム移行では手戻りを考慮したスケジュールになっていないことが多いため、システム移行では手戻りを防止するため注意深いソースコードの修正が必要になってくる。

[Intermission]
レガシーシステムのプラットフォーム移行というと大きなものでは90年代半ばの大型コンピュータからUnixワークステーションへの移行や、10数年前のUnixワークステーション(サーバー)からMS-Windowsサーバーへの移行、そして、ここ数年のクラウドサービスへの移行がありますね。
おそらく、期待される解答はクラウドサービスへの移行だと思いますが、UnixワークステーションからMS-Windowsサーバーへの移行で書くのもありかな…。

戻る 一覧へ