データ移行
データ移行は簡単に見られがちですが、実は8割以上が移行トラブルを経験しています。なぜ移行トラブルが起こるのか、どうすれば防げるのかを解説します。
データ移行の現実
経済産業省が発表した『DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開』において、既存システムの改革を進めなければ2025年以降年間最大12兆円の経済損失が生じる恐れがあると警告を発したことで、それまで日本企業の多くがその存在を認識しながらも後回しにしてきたモダナイゼーションに取り組む必要を認めています。
多くの企業が長年運用してきたレガシーシステムのモダナイゼーションを検討しています。このモダナイゼーションには、長年の運用で蓄積したデータという資産を新たなプラットフォーム上に移行するデータ移行も含まれます。
モダナイゼーションは、その企業の今後を占う上でも、システム更改後の業務改革やそれに見合うシステムの機能に目が行くのは当然のことです。ところが、実際にモダナイゼーションを行うとデータ移行が全体工数の35～40％を占めており、8割以上が移行トラブルを経験しているのが現実です。
データ移行のトラブルが原因でシステム本稼働が遅延する、最悪の場合はモダナイゼーションそのものが仕切り直しということも起こります。
データ移行トラブルの事例と原因
移行トラブルには次のような例があります。
ケース１
ドキュメントに記載された現行システムの仕様に基づいて移行に臨んだが、現行システムはドキュメントとまったく異なる仕様であることが分かり、そのままでは移行困難であるとの結論に達した。スケジュールを仕切り直すしかなかった。
ケース２
抽出データによる移行リハーサルを重ねて本番に臨んだが、本番（全件）データには特殊なデータが含まれており障害を引き起こした。
ケース３
現行システムの開発ベンダーに移行データの抽出作業を頼んだが法外な見積もりを提示された。やむなく自分でデータを抽出することにしたが、現行システムの仕様把握に時間がかかり、移行延期を余儀なくされた。
このように原因はいくつかありますが、どんなに素晴らしいシステムを構築してもデータ移行を失敗すると、システムの稼働時期が遅れてしまいます。データ移行はモダナイゼーションにとって、とても重要な位置付けであるにもかかわらず意外と安易に考えられている場面があります。
データ移行のポイント
データ移行を行うためには、移行要件（移行対象範囲の明確化など）、移行方法（一括で移行するのか段階的に移行するのかなど）、移行体制、役割分担、移行スケジュールなど決めておかなければならないポイントがあります。
データ移行を安易に考えることなく、しっかりとしたプロジェクトを組むことを忘れてはいけません。
かと言って、プロジェクト体制をしっかり組めば移行トラブルを防げるという訳ではありません。どんなにしっかりしたプロジェクトを組んだところで、移行仕様を誤ってしまえば移行トラブルにつながってしまいます。
データ移行時に発覚する想定外データ
ドキュメントにないデータ（長年のシステム運用でドキュメントが更新されていない）
ドキュメントには、「項目名：受付日、型式：文字列、項目長：７、備考：GYYMMDDで入力（G＝１：昭和、２：平成）」とありました。ところが、データには「20190601」など西暦で登録されているデータもありました。確認すると、元号が平成から令和に改元されるタイミングで受付日は西暦で登録するようにシステム改修があったのですが、ドキュメントが修正されず、過去のデータコンバートもされなかったため、西暦と和暦の混在する項目になっていました。
運用テスト時のテストデータ（通常運用には影響を与えない）
現行システムの本稼働日以前のタイムスタンプが入ったデータがありました。調査した結果、本稼働前の運用テストを行っていた時のデータがクリアされずに残っていることが判明しました。
見えないデータ（アプリケーションからは存在しないデータ）
移行結果を検証するために、データ件数を比較したところ、現行システムの集計表に出力された件数と移行件数が一致しませんでした。調査した結果、現行システムでは、テーブル間の整合性が取れていないデータは、全て対象外としていることがわかりました。
また、データ移行の落とし穴として存在するのは前回のデータ移行です。データ移行時にシステム仕様を無視して無理矢理移行を行ったことにより、「ドキュメントにないデータ」や「見えないデータ」が発生していることも多くあります。
安全なデータ移行を行うために
移行仕様を誤らないためには、「ドキュメントとデータは一致していない」「データには必ずイレギュラーデータやゴミデータがある」ということを念頭に置いて、今あるデータを知る（確認する）ことから始める必要があります。
今あるデータを知るとは、移行対象となるテーブル全件を対象とし、各項目にどのような値が入っているかを調べ、ドキュメントとの整合性を図ることになります。
この工程を省くと、先ほどのケース１の事例となってしまいます。
また、データ量が多いと時間がかかるので、データを抽出して時間短縮を計ったところ、ケース２の事例となります。
そして、想定以上に時間がかかった事例がケース３になります。
移行トラブルには様々な原因はありますが、弊社では「データを知る（確認する）」という工程をきっちり行うことが移行トラブルを防ぐ最も重要なことだと考えています。
弊社が展開している「データ整備サービス」のデータ確認は、まさしくこの工程を短期間で実現できるサービスになります。お預かりしたデータの項目ごとに値（最小値、最大値）、件数（最小件数、最大件数）、桁数（最小桁数、最大桁数）を調査し、「データ確認レポート」を作成します。
これを見れば、ドキュメント通りのデータか否か、想定外のデータが存在していないかを確認いただけます。詳しくはホームページをご覧ください。
関連動画：データ移行はデータ整備サービスで
