LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

移行元のデータベースを開いてみると、同じ項目に書き方の違う値が混ざっている。変換を作る担当者に聞いても、どちらに合わせればよいかは業務を知る人でないと決められない——。システム刷新の現場では、データ移行をめぐるこうした詰まりが、開発の終わり近くになって見つかりがちです。システム刷新のデータ移行とは、いまのシステムが持つデータを、新しいシステムで使える形に変えて移す一連の作業です。

移行元のデータを調べ、変換のプログラムを作り、リハーサルを回す作業には、SES（技術者が客先で働く契約の形）で参画したエンジニアの力を借りやすい場面が多くあります。ただし万能ではなく、値の意味をどう解釈するか、移した結果で本番に進んでよいかといった判断までは任せられません。本記事では、システム刷新を担当する開発マネージャーに向けて、移行元データの調べ方、変換ルールの決め方、リハーサルの組み方、本番データの扱い、そして移行結果を誰が確かめるかを整理します。

システム刷新のデータ移行とは

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」は、刷新の計画で検討する観点の一つにデータ移行を挙げています。現行システムの調査では、業務データの量や仕様を把握しておく必要があるとし、データ容量とその伸び率、データ構造やテーブル数、データレイアウト（項目の並びと桁数の決まり）を調べる対象に挙げています。

移すデータの規模を測る物差しとしては、IPAの「非機能要求グレード2018」が参考になります。移行性の項目に、移行データ量、移行データ形式、移行に使う媒体、変換の対象と変換ルールの数が並んでいます。データ形式は、アプリケーションに依存した形式、テーブルの形式、文字コードなどを指すとされています。刷新でデータベースの製品や設計が変わるなら、形式が変わる前提で準備することになります。

ガイドは、データ移行はアプリケーションや試験工程に影響するため、計画の検討が遅いとプロジェクト全体の計画や費用にまで大きく響くとしています。理由は2つです。一つは、移行対象やレイアウトなど発注側が事前に確かめる点が多く、データの誤りや表記の揺れを正すクレンジングも要るので、準備に時間がかかること。もう一つは、移したデータを試験工程で使うため、移行が終わっていないとテストを始められないことです。^*1

ガイドはさらに、データ移行による問題は開発の終盤で表に出るので、解消にかかる期間も計画に入れておくよう求めています。現行どおりに動くかを試験工程で確かめるには、サンプルのデータではなく実際の業務データでテストすべきだとも書いています。^*1 SESのエンジニアに加わってもらう時期も、設計が固まってからではなく、移行元データの調査を始める段階から考えておくと進めやすくなります。

移行元データの調査

ガイドは、データ移行で問題が起こりやすい観点を表3.11にまとめています。移行対象の整理、レイアウトの確認、データクレンジングの実施、文字コードの対応づけ、移行方法の確認、移行結果の確認の6つです。^*1 調査の段階で最初に向き合うのは、このうち前の2つです。

移行対象の整理について、ガイドは、全部を移すと作業量が増え、費用も増えるので、対象は絞ったほうがよいとしています。例として、稼働期間で3年以上前のデータや取引の記録を移さないといった方針をはっきりさせることを挙げています。^*1 どこまでを移し、どこから先を移さないかは、業務と保存の決まりを知る社内の担当者が決めます。

レイアウトの確認では、移す対象のファイルやデータベースのレイアウトを、発注側と受注側の双方で確認するよう求めています。ここがSESのエンジニアに頼みやすい作業です。定義書に書かれた項目と、実際に入っているデータを突き合わせ、項目ごとに値の種類、件数、空欄の数を一覧にしてもらいます。定義書にない値が見つかれば、それが次の変換ルールの材料になります。

移行元は、データベースだけとは限りません。非機能要求グレードは、移行に使う媒体の種類として、テープ、ディスク、紙の伝票類、ネットワークによるデータ転送を例に挙げています。^*2 表計算のファイルで管理している台帳や、紙で残っている記録も移す必要があるなら、調査の対象に含めておきます。

変換ルールの決め方

調査で集めた材料をもとに、移行元の値を移行先のどの値にするかを決めたものが変換ルールです。デジタル庁の「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）は、データの標準的な変換方法と例外的な変換方法を分けて定めるよう求めています。例外的なデータがあると移行が正常に終わらなかったり、サービスを始めたあとに不具合を起こしたりすることが多いため、完全性と正確性の確かめ方や、例外的なデータを見つけたときの対処方法も明確に定めるとしています。^*3

ガイドの表3.11も、想定外の値が含まれるおそれがあるのでクレンジングを行い、その役割分担を明確にするよう求めています。文字コードについては、外字（標準の文字コードにない、個別に作った文字）や同じ字形が移行先にない場合に、字形と語の意味のどちらを優先するかを調整するとしています。^*1 どちらも、値を見つけるのは技術の仕事、どう扱うかを決めるのは業務の仕事です。

そこで変換ルールは、1行に1つのルールを書く一覧にまとめ、決めた人の欄を設けておきます。SESのエンジニアには、調査の結果からルールの案と例外の件数を書き出してもらい、業務部門の担当者がその意味を確かめて決めます。

ルールの数は、移行の難しさの目安になります。非機能要求グレードは、移行ツールの複雑さを変換ルールの数で測り、10未満、50未満、100未満、100以上の段階に分けています。^*2 一覧の行数を数えておけば、変換プログラムを作る量や、確かめる手間の見当をつけやすくなります。

リハーサルの組み方

変換プログラムができたら、本番と同じ手順でデータを移すリハーサルを行います。ガイドは、テストを始める前に、クレンジングしたデータを検証環境に移す作業がリハーサルとして発生し、場合によっては移せなかった不整合データの修正や、リハーサルのやり直しも起こるとしています。一度で終わる前提ではなく、直してもう一度移す回を日程に入れておきます。

リハーサルで何を確かめるかは、非機能要求グレードの段階が参考になります。リハーサルの範囲を、主要な正常ケースのみ、すべての正常ケース、正常ケースに移行前の状態へ切り戻す異常ケースを加えたもの、正常ケースにシステム故障から回復させる異常ケースを加えたもの、と分けています。^*2 回を重ねるごとに、確かめる範囲を広げていくと組み立てやすくなります。

移行先とつながる外部のシステムにも目を配ります。グレードは、外部システムとの接続仕様が変わる場合に、新旧両方の接続仕様を確かめる外部連携リハーサルを計画するよう書いています。取引先や他部門のシステムの担当者に参加してもらう日程は、社内から早めに調整しておきます。

SESのエンジニアには、手順どおりに作業を進め、手順ごとの所要時間を記録してもらいます。グレードは、移行のためにシステムを止められる日時を、制約のない場合から夜間など利用の少ない時間帯だけの場合、止められない場合までの段階で示しています。^*2 記録した時間が止められる時間に収まるかどうかは、リハーサルで確かめられる大事な点です。当日の切り替えの段取りは「システム移行のカットオーバー計画」で扱っています。

本番データの扱い

リハーサルに本番のデータを使うかどうかは、先に社内で決めておきます。非機能要求グレードは、リハーサル環境の項目を、本番データを使用できる場合と使用できない場合に分け、本番データを使うことによる情報漏えいなどのリスクは、構築時の制約条件の項目で判断するとしています。^*2

その構築時の制約条件の説明では、開発で機密情報や個人情報を扱う場合、漏えいのリスクを減らすために、情報を使う人の制限、入退室の管理、扱う情報の暗号化などの対策を施した開発環境が要るとしています。移行作業の分担を決める項目でも、発注側のデータを扱うときのセキュリティは、発注側と受注側で取り交わしておくことが望ましいとしています。

SESのエンジニアが本番データに触れるなら、見てよい範囲、作業する端末と場所、持ち出しの禁止、作業が終わったあとの消し方を、作業を始める前に書面で決めておきます。氏名や連絡先のように、変換の確かめに中身まで要らない項目は、別の値に置き換えてから渡す方法もあります。

本番データを使えば十分というわけでもありません。ガイドの事例編には、現行システムの本番データには、プログラムの例外処理に当たるような多様なデータが含まれないことが多く、テストの網羅性が低くなりがちだという記述があります。^*1 変換ルールの一覧に書いた例外は、本番データに無ければテスト用に作って足しておきます。

移行結果を誰が確かめるか

非機能要求グレードは、移行作業の分担を、発注側がすべて行う、発注側と受注側が共同で行う、受注側がすべて行う、の3段階で示しています。そのうえで、最終的な移行結果の確認は、どの段階でも発注側が行うとしています。^*2 SESのエンジニアに作業の多くを頼む場合でも、結果を確かめる役目は社内に残るということです。

共同で作業する場合について、グレードは、旧システムの移行対象データの調査、移行データの抽出と変換、本番システムへの投入と確認などの作業分担を決めておくよう書いています。上の図のように、4つの作業ごとに、SESのエンジニアが担う部分と社内が決める部分を分けておくと、抜けが見つけやすくなります。

確かめ方も先に決めます。ガイドの表3.11は、チェックツールなどで移行結果が正しいかを確かめ、その確かめ方について発注側と受注側の双方で合意するよう求めています。^*1 移行元と移行先で件数と金額の合計を突き合わせる、変換ルールの一覧から例外の行を抜き出して1件ずつ見る、といった確かめ方を、リハーサルの前に決めておきます。照合のプログラムはSESのエンジニアに作ってもらい、結果を見て本番に進むかどうかは社内の責任者が決めます。刷新の前段にあたる要件定義の分担は「SESのエンジニアとシステム刷新の要件定義を進める手順」で扱っています。

まとめ：データ移行で確かめておきたい3つの点

SESのエンジニアとシステム刷新のデータ移行を進めるうえで、確かめておきたい点は3つに整理できます。第一に、移行元データの調査を早く始め、移す範囲と解消にかかる期間を計画に入れること。第二に、変換ルールを一覧にし、案はエンジニアが書き、値の意味は業務部門が決めること。第三に、本番データの扱いと移行結果の確かめ方を、リハーサルの前に社内で決めておくことです。この3点を踏まえておけば、「テストを始めようとしたら、移したデータが使えなかった」という事態を避けやすくなります。移行元のデータベースを読める人が社内に見つからなければ、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「システム再構築を成功に導くユーザガイド 第2版」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000057294.pdf）。出典：独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター（2018年）。2.2(5)業務データ、3.8「データ移行の計画（観点G）」の目的・表3.11「代表的な確認すべき観点」・ポイント、4.7 計画策定編「現行業務知識不足への対応（観点D）」の事例の(1)⑤検証データに関する情報を参照（2026年9月確認）
2. *2　参考：IPA「非機能要求グレード2018 改訂情報 ～初版との差異～」（PDF）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf）。出典：独立行政法人情報処理推進機構（2018年4月25日）。付録「非機能要求グレード2018 活用シート」の移行性（D.1.1.2 システム停止可能日時、D.4.1.2 移行データ形式、D.4.2.2 移行媒体種類数、D.4.3.2 移行ツールの複雑度、D.5.1.1 移行作業分担、D.5.2.1〜D.5.2.4 リハーサル範囲・環境・回数・外部連携リハーサル）と、F.1.1.1 構築時の制約条件を参照（2026年9月確認）
3. *3　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：2026年6月12日版。第3編第7章5.3)「移行ツールの実装及び移行データ・移行手順書等の作成」の解説(3)のうち、データの標準的及び例外的な変換方法の説明を参照（2026年9月確認）

Tweet