システム改修の際に考えなくてはいけないデータ移行。「データを移動するだけだから簡単にできそう」と思われがちですが、実はとても難易度が高い作業です。失敗してしまうことも少なくありません。
また、データ移行を行う際はお客様の協力が不可欠ですが、そのことはあまり知られていません。受注者・発注者ともに作業工程やポイントを理解しておかないと、スムーズに移行が進まなくなってしまいます。
そこでこの記事では、データ移行にフォーカスをあてて紹介します。この記事で得られる情報は次の通りです。
- データ移行とはどのようなものなのか
- データ移行の作業内容
- データ移行を行う際に受注者側で気をつけるポイント
- データ移行を行う際に発注者側で気をつけるポイント
- アクシアでのデータ移行エピソード
アクシアでのデータ移行エピソードでは、実際に取り組んで苦労したエピソードをいくつか紹介します。受注者側、発注者側ともに参考になりましたら幸いです。
データ移行とは
データ移行とは、新しいシステムを構築して運用を開始する際に、これまで別で蓄積してきたデータを新しいシステムに入れる作業のことです。
「これまで別で蓄積してきたデータ」のパターンとして、
- 古いシステムのデータベース
- ExcelやGoogleスプレッドシートなどのファイル内のデータ
- 紙
などがあります。もちろん、これまで別で蓄積してきたデータが新システムで不要な場合はデータ移行は行われません。
新しいシステムは新しい仕組みとなるため、形の異なる「入れ物」にデータを入れることになります。データ移行の注意点や前提事項、データの取捨選択など検討観点がいくつかあるので、次の項で詳しく紹介します。
保守移管との違い
「保守移管」は、システムの状態はそのままで保守を依頼するシステム開発会社を切り替える作業です。そのため、データ移行は発生しません。対象のシステムの仕様を解析し、そのシステムが稼働するための保守作業を引き継ぐ作業となります。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
データ移行で行う作業
新システムの設計と同時に、データ移行作業の計画を立てていきます。新システム設計（システム開発）の流れについては、こちらの記事で詳しく紹介しています。
データ移行で行う作業についてはいくつか観点があるので、以下の観点ごとに説明します。
- 要件定義時（データ移行が必要かどうか）
- 新システムの機能設計時（基本設計時、詳細設計時）
- データ移行方法進行（データ移行用プログラムを作成、移行リハーサルの実施、リハーサルを行ったデータでテスト運用の実施）
新システムの要件定義時 – データ移行が必要かどうか
新システムを開発する一番初めの段階で、新システムにこれまで蓄積してきたデータの移行が必要かどうかを見極めます。データ移行を行う場合は、新システムの構築費用に加えて別途データ移行にかかる費用が必要になります。
データ移行が必要な場合でも、検討が面倒だからと「まるっと全部移行しといてください！」とするのではなく、データの種類ごとに本当に必要なのかを見極める必要があります。
データの件数が少ない場合は、マンパワーで新システムに直接データ入力したほうが安上がりになることがあります。
新システムの機能設計時 – 基本設計（外部設計）時
システム開発会社側の対応力が問われるポイントです。データ移行を前提とする場合、データ移行に影響がないかを考慮しながら新しいシステムを設計する必要があります。
例1
旧システムでは住所を一つのテキストボックスに「東京都千代田区九段南1-5-6りそな九段ビル5F」と入力しているが、新しいシステムでは住所の入力を「都道府県」「市区町村」「番地」「建物名」に分けて入力したい
このような場合、旧システムのデータを「都道府県」「市区町村」「番地」「建物名」に分割する必要があります。このときに、旧システムのデータがこの処理をできる状態で入力されているかの確認が必要です。以下のように統一されていないフォーマットで入力されている場合、事前にデータを整形するなどの対応を見据える必要があります。
「千代田区九段南1-5-6りそな九段ビル5F」※都道府県がない
「東京都九段南1-5-6りそな九段ビル5F」※市区が抜けている
「東京都千代田区九段南1-5-6りそな九段ビル5F」※建物名と番地の間に区切りがない
例2
旧システムでは請求のステータスを「請求済」と表現しているが、新システムでは「請求書作成済」と「請求書送付済」とステータスを細分化して表示したい
この場合は、旧システムで「請求済」となっているデータを移行した際、新システムでは「請求書作成済」または「請求書送付済」のどちらのステータスにするかのルールを決定しておく必要があります。
新システムの機能設計時 – 詳細設計（内部設計）時
旧システムのデータを移行することを考慮して、データベースのリレーションやカラムごとのデータ⻑を設計する必要があります。
また、旧システムからの移行データなのか、新システムで入力されたデータなのかを判断できるよう、旧システムからの移行データには旧システムのデータを一意に特定できるIDなどの情報をレコードに持たせる設計とすることで、トラブルシューティング時に役に立つことがあります。
補足：データ長とは
データの長さ（データの大きさ）のことです。例として、ここでは以下の画像のような想定をしています。
「タスク名」という項目に対して文字列最大50文字が入るように設定しています。50文字を超える入力をしてしまうとデータベースが受け入れられないため、エラーがでてしまいます。
入力できるデータの長さを決めること、つまり、何文字分入力できるようにするかルールを決めることをデータ長の設計といいます。データ長は何を入れるかによってタイプを変えます。文字列ならば○文字以内、データや画像のアップロードならば○GB以下、といった具合です。
データ長は長すぎても短すぎてもいけません。適切な長さに設定する必要があります。
データ移行方法進行 – データ移行用のプログラムを作成
データ移行プログラムの実装パターンは大別して「DBtoDB」「ファイルtoDB」の2つに分かれます。
共通して重要なポイントとして、新旧のシステムの項目の紐づけ(マッピング)を行い、データを移す際にどのような変換処理が必要なのかをプログラム設計として明確にしてゆきます。
DBtoDB
新旧システムのDBに同時に接続し、データを変換しながら（後述）新システムにデータを入れます。
ファイルtoDB
旧システムのデータからエクスポートしたファイル(CSVやExcel)を読込み、データを変換しながら新システムにデータを入れます。
データを変換する工程はこのようになります。
①旧データ、ファイルを1行読み込む
②対応するデータを取得する
③新データに合うように変換する
④新システムのデータベースに保管できるようになる
具体的な例を挙げると、旧システムのデータには「山田太郎」「東京都千代田区九段南」と入力しているが、新しいシステムのデータは「山田」「太郎」「東京都千代田区」「九段南」に分けたい場合はこのようになります。
①旧データ、ファイルを1行読み込む
②name、addressに分解する
③nameをfamily_nameとfirst_nameに分解する。addressをaddress_1とaddress_2に分解する。
④新システムのデータベースに保存する
データ移行の処理の順番を含めて設計する
データ移行のプログラムを複数開発する場合は、データ移行プログラムの実行順序を明確にしておきます。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
データ移行方法進行 – 移行リハーサルの実施
移行対象データ全件でリハーサルを実施します。リハーサル時に、
- 移行プログラムが想定通り動作するか(異常終了しないか)
- 処理にどれくらいの時間がかかるのか
を検証しておきます。これは本番リリース当日のリリーススケジュールを組む際に必要となります。
データ移行方法進行 – リハーサルを行ったデータでテスト運用の実施
リハーサル時には、さまざまな問題が表出するリスクがあります。リハーサル自体は半日〜1日、かかっても数日で終わりますが、事前準備にはかなり時間を要し、数週間かかることもあります。本番環境と同等のテスト環境を用意したうえで、本番環境に適用するデータと同程度のデータ量を用意し、移行テストをする必要があります。
この期間を無理に圧縮すると、十分な検証が行われないまま移行が不完全な状態で本番稼働を迎えることになるため、データ移行が必要な場合は十分なリハーサル期間を設けたスケジューリングが必須です。
データ移行を行う際のポイント
データ移行を行う際のポイントを、受注者側と発注者側それぞれの観点から紹介します。
受注者側
受注者側では、以下の3つがポイントです。
①データ移行が必要なプロジェクトでは、新機能の設計時に常に「データ移行可能か」の観点をもつこと
前述の「基本設計(外部設計)時」のとおり、データ移行時に問題が起こらないように旧システムのデータがスムーズに処理できる状態になっているかチェックしたり、新システム移行時のルールを決めたりする必要があります。
②データ移行プログラムはサンプルデータだけではなく、早い段階で全件データでリハーサルを行うこと
前述の「移行リハーサルの実施」のとおり、本番リリースのスケジュールを組む際に検証が必要です。リハーサル時にはなにかしらの問題が表出します。
サンプルデータと全件データでは、勝手が違うことがあります。（アクシアではここで苦労した経験があります。詳しくは後述の「アクシアでのデータ移行エピソード」参照）
問題を早期発見するためにも、早い段階で全件データでリハーサルを行うことが重要です。
③データ移行にあたり発注者側でしか判断できないデータの仕分け作業がある場合、早期に依頼すること
前述の「基本設計(外部設計)時」のとおり、対象のデータが統一されていないフォーマットで入力されている場合があります。早い段階でのリハーサルを行うために、仕分け作業は早期に依頼しましょう。
発注者側
発注者側では、以下の2つがポイントです。
①本当にデータ移行が必要な情報なのか慎重に判断すること
前述の「要件定義時 – データ移行が必要かどうか」のとおり、データ移行には別途費用がかかります。これまで蓄積したデータの中に、新システムでは使用されないデータもあるかもしれません。本当に必要なデータのみを事前に取捨選択しておきましょう。
②Excelなどの手入力データが移行対象に含まれる場合、可能な範囲でデータの整形を行っておくこと
前述の「基本設計(外部設計)時」のとおり、対象のデータが統一されていないフォーマットで入力されている場合、新システムでうまく処理ができるように事前にデータを整形する必要があります。
新システムにどのようにデータを保存したいかはお客様次第ですので、データの整形はお客様にお願いしております。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
アクシアでのデータ移行エピソード
ここまで、データ移行の作業内容とポイントを紹介してきました。「データを移すだけだから簡単だろう」「すぐに終わるだろう」と思われがちですが、実は設計時に考えるべきことや作業量がとても多く、新規システムの開発と同じくらいの難易度とボリュームがあります。
そのため、油断すると大変な思いをしたり、失敗してしまうことも多くあります。この項では実際にアクシア内であった、データ移行の際に苦労したエピソードをいくつか紹介します。公開することで、データ移行の際に苦い経験をする方を少しでも減らせたら……と思います。
エピソード①
移行対象の旧システムのデータがどのように保管されているかを確認できない状態で新システムの設計を進めて、後付けでデータ移行を行ったことが過去にあります。旧システムの外部仕様から「こんな感じでデータが入っているだろう」という根拠のない前提の上、新システムを設計しました。
プロジェクトの後半で旧システムのデータベースが手に入ると、想定と異なる箇所が多く、データ移行に膨大な時間を要することとなりました。さらに、データ移行が間違っている箇所もあり、本番運用後にそのデータ修正作業に追われる事態が起きました。
エピソード②
提供されているサンプルデータで移行プログラムを作成しましたが、全件データを入手し移行プログラムを実行すると、想定外のデータが山のようにあったことがあります。
サンプルデータに含まれないイレギュラーパターンが多く発見され、移行プログラムの修正作業が発生し、本番リリース日程が変更になりました。
エピソード③
リハーサル期間を十分に設けず、リハーサルも本番移行もスムーズに進む前提でスケジュールを組んでしまいました。リハーサルを実施して何も起こらないことはまずないので、バッファ期間を十分に設けるべきだと考えます。
新システム開発の際のデータ移行について・まとめ
データ移行は新システム開発よりも手間がかからないと思われがちですが、実際は難易度が高く、かなりの入念な準備が必要です。どれだけ精度の高いデータを手に入れられるかが、データ移行成功の鍵を握ります。そのためには、お客様側の協力が不可欠です。
できるだけ密に打ち合わせを行い、もしもルールから外れるものがある場合、どうするかを明確に先に決めておくことが重要です。また、移行スケジュールを立てる際は、想定外の不具合対応を考慮した見積もりが必要と考えます。
この記事がデータ移行を行う際の参考になりましたら幸いです。最後までお読みいただき、ありがとうございました。
