column

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

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

この記事は今何かと話題沸騰中の ChatGPT-4 にインタビューアーになってもらい、業務システム開発実績200件以上という弊社代表の島田が「業務システムをリプレースする際のデータ移行について」についてお伝えしようというものです。

「そろそろ業務システムをリプレース(リニューアル)した方がいいのはわかるけど、今のデータが今後も使えるかどうかが問題なんだよなぁ。」と、尻込みされる方も多いと思います。

今日は既存システムのデータを新システムにどうやって移行するかというお話をします。

業務システムのリプレースとは

GPT-4

GPT-4

業務システムをリプレースするというのは、ざっくり言うとどのような作業なのでしょうか?

島田

島田

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

GPT-4

GPT-4

なるほど、完全に新しいシステムに切り替えるわけですね。そうすると、以前のシステムで使用していたデータは、新しいシステムにどのように移動させるのでしょうか?

データの移行について

島田

島田

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

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

GPT-4

GPT-4

なるほど、古いシステムと新しいシステムのデータの基本的な保存場所(RDB)が同じであれば、データの利用は可能ということですね。

それでは、RDBで保存されているデータを古いシステムから新しいシステムに移行する際、具体的にどのようなステップを踏むのでしょうか?

データ移行の具体的なステップ

島田

島田

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

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

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

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

GPT-4

GPT-4

データベース定義書や設計書をもとに、旧システムのデータと新システムのデータを突き合わせる作業が行われるわけですね。

では、実際にデータが「移動」するとき、どのようにしてデータが転送されるのでしょうか?データを移す過程で、情報が漏れたり、間違ったりすることはないのでしょうか?

島田

島田

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

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

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

GPT-4

GPT-4

おっしゃるとおりです、ちょっと早足で進めてしまいましたね。

最初のポイント「①旧システムのDBに直接アクセスできるか」について、なぜこれが重要なのでしょうか?

①旧システムのDBに直接アクセスできるか

島田

島田

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

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

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

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

GPT-4

GPT-4

なるほど、データベースへのアクセス権限やデータの取り出しにコストがかかる可能性があるというのは、事前に考慮しなければならない重要なポイントですね。

次に「②データの保存方法が違う場合、どうするか」についてお伺いします。データ保存の方法が異なると、どのような課題が発生し、それにどう対処するのでしょうか?

②データの保存方法が違う場合、どうするか

島田

島田

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

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

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

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

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

GPT-4

GPT-4

確かに、データ形式や保存方法の違いからくる変換作業は、単純でないケースも多そうですね。

では次のポイント、「③移行のスケジュールをどうするか」についてお聞きします。データ移行のタイミングやスケジュールはどのように決定し、また実際の移行作業はどのように進めていくものなのでしょうか?また、ユーザーや業務に与える影響を最小限に抑えるためのポイントなどもあれば、教えていただけるとありがたいです。

③移行のスケジュールをどうするか

島田

島田

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

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

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

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

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

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

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

GPT-4

GPT-4

まさに、データ移行作業は慎重かつ丁寧な進め方が必要で、計画性が求められる業務といえますね。

もう一つの観点として、データの整合性も重要なポイントになるかと思います。データ移行中の業務の停止が難しい場合、一部のデータが新旧システムでずれてしまう可能性があると思います。例えば、リアルタイムに変化する在庫データや取引データなど、どのように移行作業時にこれをコントロールし、整合性を保つのかも大きな課題となるかと考えます。こちらについても、何か工夫やアプローチがあればお聞きしたいです。

リアルタイムデータの移行方法

島田

島田

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

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

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

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

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

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

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

GPT-4

GPT-4

了解いたしました。今回の対談、大変興味深く参加させていただきました。それでは、良い一日をお過ごしください。

さいごに

業務システムのリプレースする際に重要となるデータ移行についてお話しました。
実際にデータを移行するまでに設計などを理解しておくことや、様々なシナリオを想定してスケジュールを組んでおくのが重要ですね。

業務システムのリプレースでお困りのようでしたら、是非相談してください。


この記事の監修者

島田 徹

株式会社プラムザ 代表取締役

一橋大学 経済学部卒 / システムコンサルタント
1998年 に 28歳 で起業 / 現役のシステムエンジニア / ものづくりの第一線で活躍中
業務システムの開発実績は 200件 以上

authority

株式会社プラムザは、開発実績25年・取引企業数300社のシステム開発会社です。さまざまな業種・業界で使用されるオリジナルのシステム構築を得意としています。

システム開発の依頼をご検討されている方は、ザックリした内容でも問題ありませんので、まずはお気軽にお問い合わせください。

|まずはお気軽にご連絡ください|

無料相談・お問い合わせする

OTHERS

マンガで分かる国内ラボ型開発/OLナナちゃんのシステム開発奮闘記

2023.8.25

マンガで分かる国内ラボ型開発/OLナナちゃんのシステム開発奮闘記

MORE

SOLUTION

プラムザではお客様のご要望に合わせて、一般的な受託開発(ラボ型開発や一括請負開発)のほか専門的な各種ソリューションを提供しています。
お客様のビジネスや課題をヒアリングしたうえで、課題解決に最適な方法をトータルサポートいたします。

国内ラボ型開発

国内ラボ型開発

国内ラボ開発を自信を持って提案します!システム担当者さま必見!嬉しいプロマネ+スゴいチームと一緒にはじめてみませんか?

国内ラボ型開発

ZOOM連携開発

ZOOM連携開発

プラムザはZOOM社が認定している提携開発パートナーです。お客様がご利用の既存システムにZOOM機能を連携させる事が可能です。

ZOOM連携開発

PRIME ORDER

ZOOM連携開発

本格的なアジャイル開発の手法を取り入れた開発フロー。プロジェクトに合わせて選べる4種類のサブスクリプション形式の開発サービスです。

PRIME ORDER

一括請負

一括請負

お客様が要望するシステムをゼロから開発します。要件定義からリリースまでを順番通りに進行するオーソドックスな開発サービスです。

一括請負

ノーコード開発

ノーコード開発

OSSを活用したノーコードツールによるシステム開発サービスです。従来の開発手法より1/2~1/3程度のコストカットが可能です。

ノーコード開発

COVER365

COVER365

AWS特化型の運用保守サービスです。24時間365日の有人セキュリティ監視や、サイバー攻撃などのトラブル発生時の即時対応まで可能です。

COVER365

CONTACT

今使ってる業務システムを作り直したい

今使ってる業務システムを作り直したい

他社の見積もりが高くて困っている

他システムと連携したい

といった、ザックリな内容でもOKです。

|まずはお気軽にご連絡ください|

無料相談・お問い合わせする

無料相談・お問い合わせする
プライバシーマーク(Pマーク)

当社は、認定個人情報保護団体の対象事業者となっており
「プライバシーマーク(Pマーク)」の認証を取得しております。

© 2023 plumsa Inc. All rights reserved.