開発会社から「移行対象データのご準備をお願いします」とメールが届いて、手が止まった。何をどこまで自社でやるのか書かれていないし、見積書を見直しても「データ移行一式」としか書いていない。そんな状態の方に向けた記事です。
先に結論を書きます。データ移行は、システム開発の工程の中で数少ない「発注側が自分で手を動かす作業」です。開発会社は移行の仕組みを作れますが、どのデータを残すかは決められません。あなたの会社の業務を知らないからです。この記事では、システム開発のデータ移行で発注側が実際に担う作業と、費用が後から膨らむ原因を説明します。
この記事のポイント
- データ移行は抽出・変換・投入の3工程で、発注側が主役になるのは前半
- どのデータを捨てるかを決められるのは発注側だけ
- 移行元の仕様が出るまで、開発会社は正確な金額を出せない
- 見積書に「データ移行一式」とあったら中身を分解して聞く
目次
システム開発のデータ移行で発注側が担う作業
まず、作業の全体像から整理します。ここを分けて考えないと、どこまでが開発会社の仕事なのかが最後まで曖昧なままになります。
データ移行は抽出・変換・投入の3工程
データ移行は、大きく3つに分かれます。旧システムからデータを取り出す抽出、新システムの形式に合わせる変換、新システムに入れる投入です。移行ツールを使うかプログラムを書くかは開発会社が決めますが、工程の分かれ方は変わりません。
このうち、発注側の関与が最も重いのは抽出の手前にある「対象を決める」部分です。次の表が、実務でのおおまかな分担です。
| 作業 | 主に担う側 | 発注側がやること |
|---|---|---|
| 移行対象の決定 | 発注側 | どの範囲を何年分移すか、捨てるデータはどれかを決める |
| 移行元の仕様提供 | 発注側 | 項目の意味、コード体系、例外的な使われ方を伝える |
| データの抽出 | 開発会社 | 旧システムの保守会社との連絡窓口になる |
| 変換ルールの設計 | 開発会社 | 提示された変換ルールが業務的に正しいか確認する |
| データの整備 | 発注側 | 重複や誤記を業務側で直す。開発会社には判断できない |
| 移行結果の検証 | 発注側 | 件数と金額の突合、実際の画面での目視確認 |
表を見ると分かるとおり、6つのうち4つに発注側が主体で関わります。移行を丸ごと外注するイメージで見積もりを見ていると、この4つ分の社内工数が計算から抜け落ちます。
どのデータを捨てるかは発注側しか決められない
移行の話で最初に決めるべきなのは、移すものではなく捨てるものです。10年分の受注データがあるとして、全部移すのか、直近3年分だけにするのか。この判断で移行の費用と期間が大きく変わります。
そして、この判断は開発会社にはできません。「過去5年分は税務調査で見られる可能性がある」「20年前の顧客でも年に1回だけ発注が来る」といった事情は、業務をやっている人しか知らないからです。開発会社に聞かれて「とりあえず全部お願いします」と答えてしまうと、使わないデータの変換ルールを作る費用を払うことになります。
私の感覚では、ここで一度立ち止まって業務側にヒアリングするだけで、移行対象が半分近くまで減ることがあります。減らせなかったとしても、残す理由を説明できる状態になっていれば、あとで「なぜこのデータを移したのか」と問われたときに困りません。
捨てると決めたデータの扱いも、同時に決めておいてください。完全に削除するのか、参照用に旧システムを一定期間残すのか、CSVで書き出して保管するのか。旧システムを残す場合は、そのぶんの保守費用が稼働後も発生します。
移行元の仕様が出ないと誰も見積もれない
データ移行の見積もりが後から動く最大の原因は、移行元の情報が出てこないことです。開発会社は新システムのことは分かりますが、旧システムのデータがどうなっているかは、中を見るまで分かりません。
必要なのは、テーブル定義や項目一覧といった書類だけではありません。実務で本当に効くのは、次のような「書類に載っていない運用」の情報です。
- 備考欄に、本来は別項目に入れるべき情報を書く運用になっていないか
- 取引先コードの付番ルールが、途中で変わっていないか
- 使われなくなったまま残っている項目はどれか
- 担当者が手作業で修正しているデータはないか
こうした情報は、旧システムを入れた会社との保守契約が切れていると、社内の誰も答えられない状態になっていることがあります。その場合は、移行の見積もりを取る前に調査だけを先に発注するほうが結果的に安く済みます。調査を挟まずに進めると、開発中に「聞いていない仕様が出てきた」として追加費用の話になります。
リハーサルは最低2回、所要時間まで測る
本番の切り替えの前に、同じ手順で移行を試すのがリハーサルです。ここを「時間がないので1回で」と削ると、切り替え当日に判断できなくなります。
最低2回は確保してください。1回目は失敗する前提です。文字化けや件数の不一致が必ず出るので、それを直すための回です。2回目は、直した状態で本番と同じ手順を通し、問題なく終わることを確かめます。
そして、リハーサルでは必ず所要時間を測ってください。データ量によっては投入だけで数時間かかることがあります。土日の2日間で切り替える計画なのに、移行だけで20時間かかると分かったら、計画そのものを見直す必要があります。この数字が手元にないまま当日を迎えると、深夜に「続けるか戻すか」を勘で決めることになります。
検証の方法も、リハーサルの時点で決めておきます。件数が合っているかは自動で確認できますが、金額の合計や、実際の画面で見たときの表示崩れは人が見るしかありません。誰が何を見るのかを一覧にしておくと、当日の作業が滞りません。
システム開発のデータ移行で費用が増える落とし穴
ここからは、契約したあとに金額が動きやすい箇所を挙げます。どれも事前に確認しておけば防げるものです。
見積書の「データ移行一式」は中身を聞く
見積書に「データ移行一式 200万円」とだけ書かれていたら、そのままでは妥当かどうか判断できません。次の4点を聞いて、金額の前提を書面にしてもらってください。
- 移行対象は何テーブル・何件を想定しているか
- リハーサルは何回分が含まれているか
- データの不整合が見つかったとき、直すのはどちらの費用か
- 旧システムからの抽出作業は、この金額に含まれているか
特に3つ目でもめます。移行してみたら同じ取引先が3件登録されていた、という状況はよく起きます。これを開発会社が直すのか、発注側が業務で直すのかを決めていないと、作業が止まります。実務では、判断が必要なものは発注側、機械的に処理できるものは開発会社という線引きが現実的です。
データ移行は、要件定義の段階で抜けやすい項目の代表格でもあります。要件定義書レビューシートには非機能要件やデータ移行など見落としやすい論点が並んでいるので、見積もりを受け取る前に自社の要件と突き合わせておくと、あとからの追加費用を減らせます。見積書全体の読み方はシステム開発の見積もりの見方の記事でも扱っています。
実データを見るまで分からない不整合がある
移行費用が事前に確定しにくいのには、構造的な理由があります。データの中身は、実際に取り出して見るまで誰にも分からないからです。
現場でよく出てくるのは、次のようなものです。
| 起きること | 原因 | 対処 |
|---|---|---|
| 文字が化ける | 旧システムと新システムの文字コードが違う | 変換ルールを追加する。丸数字やローマ数字は特に注意 |
| データが切れる | 新システムの項目のほうが桁数が短い | 項目を広げるか、業務側で内容を短くする |
| 同じ相手が複数件になる | 表記ゆれのまま登録され続けていた | 業務側で名寄せする。機械的には統合できない |
| 並び順が変わる | コードの付け方が新旧で違う | 変換表を作るか、業務の運用を変える |
これらは開発会社の見落としではなく、実データを見て初めて分かるものです。だからこそ、見積もりの段階で「不整合が出た場合の扱い」を決めておく必要があります。件数に応じた単価を先に決めておく方法もあります。
本番データを渡すのは委託にあたる
移行の検証をするには、開発会社に本番のデータを渡すことになります。ここで見落とされがちなのが、その中に顧客の氏名や連絡先が入っている場合の扱いです。
個人データの取扱いを外部に任せる場合、委託した側には委託先を監督する責任があります。個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）にも「委託先の監督」の項が置かれており、必要かつ適切な監督が求められるとされています。開発会社に渡したから自社の責任がなくなる、という整理にはなりません。
実務としては、契約書に個人データの取扱いに関する条項があるか、作業が終わったあとにデータを消してもらう手順が決まっているか、渡す経路が安全かの3点を確認しておけば大きく外しません。個別の判断が必要な場合は、自社の法務や専門家に相談してください。
検証だけであれば、氏名を仮の値に置き換えたデータで足りることもあります。ただし住所や電話番号の桁あふれを確かめたい場合は、実データでないと意味がありません。何のためにどこまでのデータが要るのかを、開発会社と先に詰めておくと無用なリスクを負わずに済みます。
切り戻しの判断期限を先に決める
切り替え当日にうまくいかなかったときのために、旧システムに戻す手順と、その判断をする時刻を決めておきます。
決めておくのは3つです。何時までに移行が終わらなければ中止するのか、その判断を誰がするのか、戻したあと月曜の業務をどう回すのか。この3つ目が抜けていると、戻す判断そのものができなくなります。
移行したデータが正しいかどうかは、受入テストの中で業務担当者が確認するのが確実です。テストのシナリオに移行データを使った確認を組み込んでおくと、切り替え前に問題に気づけます。進め方はシステム開発のUATの記事で詳しく扱っています。なお、移行の方式そのものをどう選ぶかは基幹システムの移行方式の記事が担当しています。
システム開発のデータ移行についてよくある質問
- Q. データ移行とシステム移行は何が違いますか。
- システム移行は、旧システムから新システムへ切り替えること全体を指します。データ移行はその中の一部で、データを移す作業だけを指します。ほかに業務のやり方を移す業務移行や、機器を移す環境移行が含まれます。
- Q. 移行費用は全体の何割くらいが目安ですか。
- データ量や旧システムの状態によって幅が大きく、一律の目安を示すのは適切ではありません。旧システムの仕様が分からない状態では見積もりが出しにくいため、まず調査だけを先に依頼して前提を固めるほうが結果を読みやすくなります。実際の金額は個別の見積もりで確認してください。
- Q. 移行ツールを使えば安くなりますか。
- 抽出や投入の作業は効率化できますが、費用の多くは変換ルールの設計とデータの整備にかかります。ここはツールでは減らないため、ツールの有無だけで金額が大きく変わるとは考えないほうが安全です。
- Q. 旧システムの保守が切れていても移行できますか。
- できますが、データの取り出し方を調べるところから始めるため、費用と期間が上振れしやすくなります。保守契約が残っているうちに、データの抽出だけでも先に済ませておくと選択肢が広がります。
