システム開発 移行とは

移行プロジェクトは、既存のシステムから新しいシステムに乗り換えるという作業とそれに必要なモノの開発になり、新規システム開発のプロジェクトとは仕事の内容が大きく異なります。新規開発と比べると業務の特性やデータの複雑性、旧システムから新システムへの切替タイミングなどプロジェクトごとに特有のタスクが出てくるため、進め方の標準化は難しいですが、以下のイメージを持つことで実際の移行プロジェクトで何をするのかを考えやすくなります。もちろん業務内容や利用者への影響度によって様々なケースがありますので、開発ベンダーと顧客の間で入念な打ち合わせが必要となります。

• 切り替えるタイミング

• 新旧並行本番期間

• 移行テストチェック方法

• マスタデータ移行方法

• オンライン系データ移行方法

• バッチ更新系データ移行方法

• 旧システム過去データ参照期間

• 旧システム停止タイミング

• オペレーション社員の負荷を軽減する対策

• 新システムオペレーション教育期間

• 新旧締め処理時点でのデータチェック方法

• 新システム移行に伴い業務改善の有無

システム移行プロジェクトで発生する主な作業

移行プロジェクトでは、「データ移行用のシナリオ及びスクリプト」、「移行手順書」などを主に作成することになります。第一に、データ移行用のスクリプトを作成しますが、これは古いDBから新しいDBへデータを移行するためのプログラムです。使用しているDBによって作業手順は異なりますが、例としてOracleを使っているのであれば、PL/SQLをデータ移行用のスクリプトとして準備します。また、新しいDBと古いDBが異なる場合はデータ移行用のバッチを作成したりすることもありますし、DBツールを使って古いDBからデータをcsvで出力してそれを新しいDBに取り込むという手作業による方法を選択する場合もありますが、何回も移行したデータをチェックする場合には移行スクリプトを作成した方が良いでしょう。
第二に、移行手順書とは、システム移行当日及び移行期間中に行う作業を時系列的に記載したものです。記載される内容は、作業内容だけでなく、予想される作業時間、作業担当者、役割、作業が終わった後の関係者への連絡方法、コンティンジェンシープランなど、当日の作業内容が詳細に記載されていなければなりません。順次移行以外に、販売系システムやPOS連動、在庫連動するような業務で365日ノンストップのシステムあれば、１日で短期間で移行することになり、この場合は過酷な徹夜作業となりますので、詳細なタイムスケジュールが必要となります。
この「データ移行用のスクリプト」と「移行手順書」以外にも移行に必要なものがあれば用意する必要があります。




移行を成功させるために注意すべきこと

前述の通りシステム移行に注意が必要な事はお判りいただけたと思いますが、プロジェクトにおいて主に以下の3つの基準を軸に品質を評価し、問題がある部分は改善していくことをお勧めいたします。




• 正確にデータを移行すること

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

• 当日の移行手順を明確にすること

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

• 期限の時間までに移行が終わること

すべての移行作業が目標の時間までに終わることを目指します。たとえば、BtoCのWebサービスを移行する場合、移行作業中はそのサービスを停止することになるので、それだけ機会損失が発生します（通常、移行中はサーバーを停止して行います）。そのため、通常システム移行には制限時間が設けられ、その時間内にすべての作業を完了させる必要があります。テストでは、移行プログラムを実行して時間を計り、制限時間内に終了しないプログラムはSQLチューニングなど速度改善を行います。
ただし、どうしても本番サービスを停止できないことも多く、最近のWebサービスの移行方法はテスト環境とステージング環境を同期をとりながら、テスト環境でテストしたものを夜間に差し替えるという方法を選択することも多くなっています。その方が顧客への影響が少ないからです。




移行プロジェクトで大変なこととは？

システム移行は、それぞれ特有の難しさがありますが、多くの問題は以下の６つとなります。あらかじめ知っておくことで対策を立てやすくなります。

• 仕様が曖昧で、旧システムの詳細な仕様を調べる必要が出てきた時

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

• 旧システムの不具合を解消する必要が出てきた時

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

• 移行計画だけでなくコンティンジェンシー計画も立てなければならない時

移行を行うのであれば、本番当日に障害が発生して移行ができないことも想定しておく必要があります。そのためにコンティンジェンシー計画は必要です。もちろん、コンティンジェンシー計画を発動した時に旧システムが今まで通り動くかどうかもテストしておかなければならないので、作業量は複雑で膨大になります。
コンティンジェンシー（Contingency）とは、不確実性や偶然性、不慮の事故や偶発事件などを意味する言葉のこと。

• オンプレミスからクラウドへはそのまま移行できないことがある

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

• システムを止める時間を最小限で作業する必要がある

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

• システム本番移行リハーサルで失敗するのは想定内

旧システムから新システムに移行する場合、移行リハーサルを必ず行います。模擬データを利用する場合、本番データを利用する場合、企業の考え方に合わせて移行するデータを作成し、リハーサルを行います。マイグレーションなどには必須作業です。仮にリハーサルに失敗したとしても、そのこと自体は失敗ではなく想定内と考えて、失敗した原因を分析します。移行ツールのバグなのか、新旧のDBのテーブルの違いから発生したのか、原因を探れば、その横展開も可能になります。エンジニアとしては、リハーサルに失敗した時の予備スケジュールも用意しておくべきなので、課題は放置することなくシステム移行計画書に記述し、顧客と共有します。内部でのリハーサル、本番を想定したリハーサルのダブルチェックとなります。

いかがでしたでしょうか。今回の記事は、システム開発後の移行作業に関して解説いたしましたが、小生の経験では、ノンストップサービスの入れ替え作業はとてもプレッシャーがかかり、失敗すると大きな損失になる為、数カ月かけて移行準備をしたことを思い出します。
過去に様々なトラブルを経験してまいりました。最近ではその経験をもとに必ず成功に導けるノウハウがありますが、自動化できる便利なツールなどもこれからはどんどん出てくるでしょう。誰でも深夜作業などは避けたいものです。人材不足の時代ですから機械的に移行作業をトラブルなく完了できる時代が到来するでしょう。
重要なポイントは、一度でもトラブルが発生すると顧客との信頼関係は低下します。人の気持ちまでは自動化されても制御できませんね。重要な事は、そのトラブルを迅速かつ冷静に判断して、人が対応する姿勢を常に維持することもノウハウの一つだと考えます。
新システムのプログラム品質は高くても移行に失敗しては本末転倒。そしてその逆も。プロジェクトの成功とは最後のプロセスまで気を抜かないこと。当社J&Cカンパニーでは、様々な経験をもとにご相談に応じております。そしてこの解説をしながらも現行プロジェクトをリアルタイムで動かしております。次回にご期待ください。

• Go back