基幹システムは受発注・在庫・販売・請求・生産などに関わるため、十分な確認をせずに切り替えることはできません。新システムの機能が完成していても、移行データに誤りがあれば業務を開始できない可能性があります。
データ移行は、情報を単純にコピーする作業ではありません。新旧システムでは項目名、データ型、桁数、コード体系、管理方法が異なるため、何をどの項目へ移し、どう変換するかを決める必要があります。
この記事で分かること
- 移行対象データ
- マスタ整理
- 重複・欠損
- 過去データ
- 移行リハーサル
- 検証方法
- 移行後の運用
まず結論
データ移行で最初に決めるべきなのは、移行対象、データの意味、変換ルール、検証方法、移行後の運用です。移行は開発終盤の付随作業ではなく、再構築の初期段階から検討すべき工程です。
現行データがどの業務で使われ、誰が内容を説明できるか、件数はどの程度か、帳票や外部連携へどう影響するかを確認します。担当者が退職すると、項目の用途や過去の修正理由を確認できなくなるおそれがあります。
すべてのデータを移せばよいわけでもありません。利用されていない取引先、廃番商品、重複マスタ、参照されない過去データまで移すと、新システムへ問題を引き継ぎます。
移行するもの、旧システムへ残すもの、変換するもの、事前に修正するものを切り分け、複数回のリハーサルを行います。件数だけでなく、金額、残高、在庫、帳票、実際の業務操作まで検証することが重要です。
よくある背景・失敗しやすい理由
古い基幹システムでは、設計書が不足し、データ項目の意味を説明できる人がいない、保守期限が近い、開発会社と連絡が取れないといったブラックボックス化が起きています。
現場では、Excel、Access、CSV、手入力で不足情報を補っていることがあります。住所は基幹システム、担当者名はExcel、配送先はAccessという状態なら、基幹システムだけを移行しても必要な情報が揃いません。
移行対象をテーブル単位で考えることも失敗の原因です。重要なのは、現行テーブルをそのまま移すことではなく、新システムで業務を行うために必要な情報を移すことです。
また、現行データが正しいという前提も危険です。長年の運用では、重複、入力漏れ、無効コード、不要な空白、表記ゆれ、誤った日付が蓄積します。移行を本番直前まで後回しにすると、十分な修正や再テストができません。
確認すべきポイント
1. 移行対象データ
移行対象は、マスタ、取引データ、残高、未処理データなどに分けて明確にします。「すべて移行する」という方針では、必要データの漏れや不要データの持ち込みが発生します。
一般的な対象には、取引先、商品、仕入先、社員、価格情報、在庫、売掛・買掛残高、未完了の受注・発注、未請求データがあります。ただし、必要な範囲は業種や業務によって異なります。
新システムの稼働日に何が必要かを業務単位で確認します。未出荷受注は移行が必要ですが、完了済みの古い受注は旧システムで参照する方法もあります。
Excel、Access、部門システム、クラウドサービスに必要情報がある場合も対象に含めます。マクティズムでは、移行するもの、現行環境へ残すもの、移行前に修正するものを分けて整理します。
2. マスタ整理
取引先、商品、仕入先、社員などのマスタは、日々の取引を支える基礎情報です。整理が不十分なまま移行すると、重複や表記ゆれも引き継がれます。
同じ取引先が複数コードで登録されていれば、売上や売掛残高が分散します。ただし、名称や住所が似ていても、支店、請求先、納品先として分ける必要があるため、機械的な統合は避けます。
商品マスタでは、廃番商品、未使用コード、単位や分類の違いを確認します。新旧でコード体系が異なる場合は、変換表を作成してください。
移行後の登録責任者、承認方法、命名規則、廃止方法も決めなければ、再び重複が発生します。
3. 重複・欠損
移行前には、重複データや必須項目の欠損を確認します。プログラムが正常に動いても、元データに問題があれば、そのまま新システムへ登録されます。
取引先コードが異なっても法人番号や電話番号が同じ、商品コードは同じでも名称が異なるといったケースがあります。コードだけでなく、名称、住所、電話番号などを組み合わせて確認します。
新システムで税区分や支払条件が必須でも、現行データでは空欄の場合があります。一律の初期値で補うのか、担当部署が確認するのかを決め、根拠のない値を登録しないことが重要です。
全角・半角、不要な空白、機種依存文字、文字コードも確認し、検出条件、修正方針、最終判断者を明確にします。
4. 過去データ
過去データを何年分移行するかは、費用や期間だけでなく、法令、監査、問い合わせ、返品、再請求、分析を踏まえて決めます。
すべて移行すると、処理や検証に時間がかかり、容量や性能へ影響します。一方、必要な履歴を移さなければ、取引先対応や監査ができない可能性があります。
全期間を移行する、一定期間だけ移行する、旧システムを参照専用で残す、PDFやCSVで保管するといった方法を比較します。
旧環境を残す場合は、維持期間、利用者、セキュリティ、障害時の保守方法を決めてください。過去データの利用目的を確認することも重要です。
5. 移行リハーサル
本番前には、実データを使ったリハーサルを複数回行います。抽出、変換、登録、検証にかかる時間を測定し、業務停止可能時間内に完了するか確認します。
途中でエラーが発生した場合、失敗分だけ再実行できるのか、最初からやり直すのかも確認します。件数、エラー内容、修正方法、所要時間を記録し、改善へ反映してください。
本番と同じ担当者、手順、環境、データ量に近い条件で行うことが理想です。少量のサンプルだけでは、処理遅延や容量不足を把握できません。
最終リハーサルでは、帳票出力、受注、出荷、請求まで確認し、切り戻しの判断基準と手順も決めます。
6. 検証方法
検証では、件数だけでなく、金額、数量、残高、関連データのつながりを確認します。件数が一致していても、項目変換やコード対応が誤っていれば業務では使えません。
マスタ件数、売掛・買掛残高、在庫、受注・発注金額を比較し、部門別、取引先別、商品別に分けて確認します。
高額取引、マイナス金額、取消、特殊な税区分、長い名称など、変換ミスが起きやすいデータも選びます。受注と取引先・商品、請求と入金の関連性も確認してください。
確認者、実施日、結果、合格基準を記録し、業務担当者が検索、集計、帳票出力を行って日常業務で使えることを確認します。
7. 移行後の運用
本番移行後も、一定期間はデータ不備や問い合わせが発生します。問い合わせ窓口、修正手順、旧システムの参照方法を事前に決めておきます。
誤りが見つかった場合は、誰が確認し、修正を承認し、登録するかを明確にします。担当者が独自に修正すると、関連データとの整合性が崩れる可能性があります。
修正前後の値、理由、実施者、日時を記録すれば、監査や問い合わせにも対応できます。旧システムを残す場合は、新旧のどちらを正とするかも決めてください。
移行後は日次または週次で売上、残高、在庫を確認し、マスタ登録や修正のルールを整備して重複や欠損の再発を防ぎます。
自社で整理できること・外部に相談すべきこと
社内では、対象業務、画面、帳票、保守期限、利用部署、関連するExcel、Access、CSVを整理します。どのマスタや取引データがあり、何年分を保有し、どの業務で参照しているかを一覧化します。
重複した取引先、廃番商品、未使用コード、空欄の多い項目など、把握している問題も整理します。完全に修正する必要はありませんが、問題の所在が分かれば調査精度が上がります。
データベース構造が不明、複数システムから統合する、大量データの変換が必要な場合は、外部の開発会社と調査した方が安全です。ただし、重複の統合や過去データの必要性は、自社の業務担当者が判断する必要があります。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
判断表は一般的な目安です。データ量、停止可能時間、システム構成、保存要件によって適切な方法は変わります。移行プログラムだけでなく、事前調査、データ修正、リハーサル、現場確認、移行後支援まで含めて検討してください。
相談前に準備しておく情報
- 現行システムの概要と利用部署・人数
- 移行対象となる業務
- 取引先・商品などのマスタ一覧
- 受注、売上、在庫、請求などのデータ種類
- データ件数と保有年数
- 関連するExcel、Access、CSV、部門システム
- 外部システムとの連携状況
- 把握している重複や欠損
- 現行システムの保守期限
- 新システムの稼働希望時期
- 業務を停止できる日時と時間
- 想定予算
可能であれば、項目定義書、テーブル一覧、CSV、帳票のサンプルも用意します。データ内容を確認できる担当者を決め、日常業務、監査、経営分析などの利用目的を踏まえて移行対象を判断してください。
マクティズムの見解
マクティズムでは、データ移行は単純なコピーではなく、現在のデータを整理し、新システムで利用できる形へ再構成する工程だと考えています。
項目定義、コード体系、重複、欠損、過去データ、変換方法、検証基準は、開発初期から整理すべきです。後回しにすると、開発終盤で問題が判明し、全体のスケジュールが遅れます。
現行データをすべて正しいものとして扱わず、未使用マスタ、重複、入力漏れ、表記ゆれを確認します。一方、業務上必要な違いまで機械的に統合してはいけません。
マクティズムでは、移行対象一覧、項目対応表、コード変換表、修正方針、検証項目を整理し、どのデータを、どのルールで、どこへ移すかを明確にします。
本番前には複数回のリハーサルを行い、件数だけでなく、残高、在庫、売上金額、画面検索、帳票出力、実際の業務処理まで確認します。
データ移行は、現行システムに蓄積した問題を持ち込まず、今後活用できるデータへ整える機会です。対象範囲を早期に決め、業務担当者と開発会社が共同で検証を進めることが重要です。
よくある質問
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
