新規開発より大変!?あまり知られていない「システム移行」プロジェクト

　新規開発というと、ゼロからシステムを構築する困難さをイメージする人もいるかと思います。一方で既存システムを新システムへ移行する「システム移行」プロジェクトは、比較的に簡単に聞こえてしまうかもしれませんが、新規開発にも勝る難しさがあります。最近では、トレンドとなっているクラウド化の流れや、ある金融機関の取り組みとして耳にする機会も増えてきているのではないでしょうか。今回はシステム移行プロジェクトについて説明します。

■システム移行プロジェクトを進めるにあたって
移行のプロジェクトは、既存のシステムから新しいシステムに乗り換えるという作業とそれに必要なモノの開発になり、新規システム開発のプロジェクトとは仕事の内容が大きく異なります。新規開発と比べるとプロジェクトごとに特有のタスクが出てくるため、進め方の標準化は難しいですが、以下のイメージを持つことで実際の移行プロジェクトで何をするのかを考えやすくなります。

1. どのような作業が発生するのか
2. どのようなことに注意しなければならないのか

1.システム移行プロジェクトで発生する主な作業
　移行プロジェクトでは、「データ移行用のスクリプト」、「移行手順書」などを主に作成することになります。まず、データ移行用のスクリプトとは、古いDBから新しいDBへデータを移行するためのプログラムです。使用しているDBによって作業は異なりますが、たとえばOracleを使っているのであれば、PL/SQLをデータ移行用のスクリプトとして準備したりします。また、新しいDBと古いDBが異なる場合はデータ移行用のバッチを作成したりすることもありますし、DBツールを使って古いDBからデータをcsvで出力してそれを新しいDBに取り込むという方法をとる場合もあります。次に、移行手順書とは、システム移行当日に行う作業を記載したものです。記載される内容は、作業内容だけでなく、作業時間、作業担当者、作業が終わった後の関係者への連絡方法、コンティンジェンシープランなど、当日の作業内容が詳細に記載されています。この「データ移行用のスクリプト」と「移行手順書」以外にも移行に必要なものがあれば用意する必要があります。

2.移行を成功させるために注意すべきこと
　システム移行に注意が必要なのは、プロジェクトにおいて主に以下の3つの基準を軸に品質を評価し、問題がある部分は改善していくことです。

・正確にデータを移行すること
移行用のプログラムでは新しいDBに移し替えたデータが想定通りであることを目指します。古いDBと新しいDBでデータの持ち方が異なる場合は移行プログラム内で古いDBのデータを修正してから新しいDBに入れます。つまり、移行のプログラムで不具合があればシステムが正しく動かない場合があるので、テストが必要です。このテスト自体は新規開発と似ていて、移行プログラムを利用してデータを移し替えた後に新システムで想定通りの動作をするか確認します。

・当日の移行手順を明確にすること
移行の手順を誰がやっても同じように成功する状態であることを目指します。たとえば、移行手順書に「7と8の移行スクリプトを実行する」と書いてあった場合、担当者によって実行の仕方が異なる可能性があります。7を実行してから8を実行する場合もありますし、その逆の順番で行う場合も出てきてしまいます。このように手順が曖昧だとテストでは発見されなかった不具合が本番当日に出てしまうということも考えられますので、誰が実施しても同じ手順になるよう詳細に記載し、移行のテスト時に問題点をすべて洗い出せるようにしておきます。

・期限の時間までに移行が終わること
すべての移行作業が目標の時間までに終わることを目指します。たとえば、BtoCのWebサービスを移行する場合、移行作業中はそのサービスを停止することになるので、それだけ機会損失が発生します（通常、移行中はサーバーを停止して行います）。そのため、通常システム移行には制限時間が設けられ、その時間内にすべての作業を完了させる必要があります。テストでは、移行プログラムを実行して時間を計り、制限時間内に終了しないプログラムはSQLチューニングなど速度改善を行います。

■移行プロジェクトで大変なこととは？
　システム移行は、それぞれ特有の難しさがありますが、多くの問題は以下の５つとなります。あらかじめ知っておくことで対策を立てやすくなります。

・前システムの詳細な仕様を調べる必要が出てきた
移行プログラムを作成するためには、前システムのデータの作り方などを理解する必要があります。ただし、設計書が用意されていないシステムだったり、前システムの開発者と連絡を取る手段が無かったりなどの理由で、前システムのコードを読む必要が出てくる場合があります。

・前システムの不具合を解消する必要が出てきた
移行タスクを進めていく中で前システムの不具合を見つけてしまうこともあります。たとえば、「前システムである処理を行うとごみデータが生成されてしまう」といった場合、新システムへの移行でこのごみデータが障害になる可能性もあり、このごみデータを削除するプログラムなどを先行して作成する必要が出てきます。

・移行プランだけでなくコンティンジェンシープランも立てなければならない
移行を行うのであれば、本番当日に障害が発生して移行ができないことも想定しておく必要があります。そのためにコンティンジェンシープランは必要です。もちろん、コンティンジェンシープランを発動した時に旧システムが今まで通り動くかどうかもテストしておかなければならないので、作業量は膨大になります。

・オンプレミスからクラウドへはそのまま移行できないことがある
近年はオンプレミスからクラウドへの移行が数多く行われています。クラウド化は外部へ環境管理の一部を依頼することができるようになるため、コスト面で大きなメリットが在りますが、カスタマイズに関しては制約が出てきます。そのため、システム運用やセキュリティ面ではそのまま移行することができず、新しい仕組みを構築する必要が出てくることもしばしばです。

・システムを止める時間を最小限で作業する必要がある
　旧システムから新システムに移行する場合、理想的には旧システムから新システムに切り替える時間は少なければ少ないほどいいとされます。特にBtoCのWebサービスを移行する際は、「システムが使用できない時間=営業ができない時間」となり、システムを稼働できない時間と比例して、会社の売上に影響する場合があります。
　移行中に旧システムも新システムも停止しなければならないプロジェクトの場合は、データ移行プログラムの速度改善を行いできるだけ移行時間を短くする、深夜など営業に影響が少ない時間を選択する、などの対策が必要になります。
　また、サービスの性質によっては、段階的に移行する方式や現行システムと新システムを並行稼働させ、比較検証しながら移行する並行移行方式をとる必要がある場合もあり、より複雑な移行の段取りが組まれることになります。

　今回はシステム移行について説明しました。システム移行はそれぞれのプロジェクトで特有の問題があることが多く、注意すべき点をすべて挙げることは難しいですが、一般的なことでも予め知っておくことだけでも十分意味があります。システム移行することになった時は、ここで説明したことも参考にしてもらえれば幸いです。