業務システムをリプレースする際のデータ移行について

前に「業務システムをリニューアルするメリット」というテーマでお話をしましたが、「システムのリプレース」とは、色々と問題が出てきた古いシステムを新しいシステムに置換える作業ですね。リニューアルとほぼ同義ですが、リニューアルよりも完全に作り替えるイメージが強いです。

基本的には今の業務システムはデータの保存場所としてRDB（リレーショナルデータベース）というのを使っていることが多いです。1990年以前に作られたシステムは別にして、それ以降のシステムであれば、OracleであったりSQL Serverであったり、MySQLであったりといったRDBが裏で動いています。

これから作られる業務システムも、開発ベンダーが特別な技術を使うと言っていなければ通常はRDBを使います。それゆえ、古いシステムのデータは基本的に新システムでも利用ができます。

RDBの中のデータを移行する際に大事なのは、その設計がどうなっているか？が明確になっていることです。

通常、システムを構築した際に開発ベンダーは「データベース定義書」とか「データベース設計書」と言われる仕様書を作成していると思います。それを見ると、旧システムのデータがどのように格納されているかが一目瞭然にわかります。

たとえば、顧客に請求書を出した記録であれば、「顧客マスタ」というテーブル（Excelで言うと表みたいなもの）と「請求書（請求履歴）」などのテーブルに分かれて保存されていると思います。

それを新システムの開発ベンダーのエンジニアが読み取って、「このテーブルは新システムで言うこのテーブルに当たる」というように突き合わせをしていくのです。

ちょっと話が先に進みすぎですね。
突き合わせが明確になった後、実際の移行までにはいくつか検討しなければならないことがあります。

①旧システムのDBに直接アクセスできるか
②データの保存方法が違う場合、どうするか
③移行のスケジュールをどうするか

等々です。このあたりの説明をしましょう。

旧システムの開発ベンダーと、新システムの開発ベンダーが同じなら何の問題もないのですが、もし違う場合、旧システムのデータベースは旧開発ベンダーの管理下にあって、「勝手にアクセス出来ない」状態にあるかも知れません。

その理由は単なる「嫌がらせ」ということもありますし、あるいは他のお客さんのデータも混在しているので見せられない、ということもあり得ます。

いずれにしても、旧システムのデータベースを直接見れない場合、なんらかの方法でデータを出力してもらわないといけません。通常はCSVなどの形式で出してもらう必要がありますが、その作業にはおそらくコストがかかります。

まず仕様調査時に一回、リハーサルで一回、本番で一回の最低三回は作業をお願いしないといけないので、もしかすると数十万円単位のお金を請求してくるかもしれませんね。旧開発ベンダーは、こういった作業を面白く感じていない可能性もありますので、高めの作業賃になってくるかも知れません。

これがいつも結構問題になります。
たとえば簡単な例を挙げますと、旧システムでは顧客の住所が「東京都港区赤坂4-2-11」などという一文で管理されていたとします。一方新システムでは住所は「都道府県」と「市区町村」「それ以外」の3項目に別れていたとします。

このようなケースでは、旧システムから新システムに移行する際に、データを分割しなければなりません。手で分割するのは大変すぎますのでプログラムを組んで分割しますが、その開発コストをどうするのか？が一つの問題です。

また都道府県とそれ以外は分割できそうですが、市区町村とそれ以下の情報はなかなか難しいです。最終的に「プログラムではできない」となった際に「契約違反じゃないか」ということにもなりかねず、揉める部分ですね。

実際は、住所の持ち方のような簡単な話ではなく、旧システムでは、「区分の番号が何を現すのかがプログラムに書かれてしまっている」、とか「リレーションのキーがIDではなく文字になっている」、などなど開発者でないと分からないような厄介な障害が多数出てくるものです。

こういうのは一つ一つ新システムの開発ベンダーと発注者の方と相談しながら解決策を考えていきますが、なかなか難しい問題ですね。

通常、システムのリニューアル（リプレース）の場合、旧システムと新システムの切り替え時にはデータ移行のための期間を設けます。土日の2日間で終わることもあれば、大規模なシステムの場合もう少しかかることがあります。

いずれにしても日常の業務を長い時間止めるわけにはいかないので、綿密な計画を立ててコンバート（変換）のプログラムを組み、一気に作業を行います。たいていの場合

(1)旧システムの停止
(2)旧システムからのデータの出力
(3)前整形(手作業での微修正)
(4)コンバートプログラム実行
(5)動作確認

といった流れになります。そして(5)の動作確認で、うまくいっていればいいのですが、まったく考慮不足があったりしてうまくいかなければ「いったん作業を停止して元のシステムに戻す」というような選択を迫られることがあります。

もちろん、元に戻すような事態になれば、発注会社、開発ベンダー共に大きな損失は免れませんので、そうならないように何度もシミュレーションを行うのですが、現実には不測の事態というのは起るものです。

一番最悪なのは、たとえば土日に作業をしていて、日曜日の昼間などに不測の大障害が発生して、月曜日の始業時間までに絶対に解決しないと分かっているのに、元に戻さない選択を続けることです。

そうならないためには、リハーサル以外に「こういうシチュエーションに陥ったらどうする」などの緊急対応のフローを発注会社と開発ベンダーとでよく話し合っておくべきですね。

おっしゃる通りですね。金融系のシステムであったり、外部のシステムと連動したシステムだったりすると、旧システムをひと時も止められないということがあります。

そういったシステムのリプレースで、かつデータの移行に数十時間かかるような場合、移行作業中に旧システムではどんどんデータが変化していってしまいます。

そのため、まずは一回目のデータコンバートを行い、それが完了したらもう一度差分の移行を行います。

二回目の移行は一回目よりは短時間で終わることが予想されますが、それでも数十分、数時間などかかるようだと、さらに差分が発生してしまうので、三度目の移行を行います。

そのような規模のデータ移行となりますと、計画も作業もコンバートプログラムも大規模なものになり、データ移行だけで数人月以上の作業となることがあります。

システムのリプレースでは、このデータ移行のコストというのが馬鹿になりませんので、発注に際してはよく確認を行う必要がありますね。

今回はこれにて対談終了としたいと思います。