LASSIC Media らしくメディア

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

データ基盤をクラウドに移したら、毎朝見ている売上のダッシュボードが前の日までと合わない。移行を手伝うエンジニアを探したいが、何を頼めばよいのかが決まらない——。分析用のデータ基盤を持つ企業では、こうした悩みが起こりがちです。データ基盤のデータ移行とは、データを取り込む処理、たまったデータ、集計のクエリ、ダッシュボードのような利用側の仕組みまでを新しい基盤に移し替え、移す前と同じ数字が出る状態にすることを指します。

移行の期間だけ必要になる作業は多く、フリーランス活用が向いている場面の一つです。ただし万能ではなく、数字が合わないときにどちらを正とするかは、外部の人には決められません。本記事では、データ基盤を移す企業の担当者に向けて、業務システムのデータ移行との違い、取り込みの処理の移し替え、過去データとダッシュボードの扱い、並行稼働での数値の突き合わせ、そしてフリーランスに頼むときに確認したい点を整理します。

データ基盤のデータ移行とは

Google Cloudの移行ガイドは、データウェアハウス（分析用にデータをためておくデータベース）の移行を「ユースケース」という単位で考えます。1つのユースケースには、元のシステムからデータを取り込むデータパイプライン、データウェアハウスにためたデータ、データを加工・集計するスクリプトやプロシージャ、そのデータを読むレポートやダッシュボードが含まれます。^*1 「過去1年の商品別の売上を追う」といった、利用者から見た1つの用途ごとに、この4つをまとめて移すという考え方です。

このガイドは、データウェアハウスにデータを入れる側を上流、データを処理して見せる側を下流と呼び分けています。業務システムのデータを取り込むバッチ処理は上流、部門ごとの集計表やダッシュボードは下流です。データ基盤のデータ移行では、たまったデータに加えて、上流と下流の両方の移し方を決めます。

移し方は2つに分けて説明されています。1つはオフロード移行で、古いデータウェアハウスからデータをコピーして同期させながら、先に下流の仕組みを新しい基盤へ移します。もう1つは完全な移行で、上流の元のシステムから新しい基盤へ直接データを取り込むように、データパイプラインまで移します。完全に移行するには、先にオフロードしておく必要があるとされています。

業務システムのデータ移行との違い

販売管理や会計のような業務システムを作り替えるときのデータ移行は、切り替えの日に向けて移行元のデータを変換し、決まった手順で一度に移すのが基本です。変換ルールの決め方やリハーサルの組み方は「SESと進めるシステム刷新のデータ移行、変換ルールを決める手順」で扱っています。

データ基盤の場合は、移行している間も古い基盤が動き続けます。オフロード移行では、上流のデータパイプラインは変えないまま古いデータウェアハウスに書き込み続け、そこから新しい基盤へ差分をコピーして同期を保ちます。^*2 移す単位もユースケースごとで、ガイドは作業を一定期間ごとの反復（イテレーション）に分け、ユースケースを少しずつ移すよう勧めています。分析のための処理は、業務の取引を処理するシステムより運用の要件が緩いことが多く、先に移すほうが進めやすいとも書かれています。

もう一つの違いは、移したかどうかを確かめる対象です。業務システムでは、移したデータそのものが正しいかが確認の中心になります。データ基盤では、変換したクエリが正しく動くか、移したデータパイプラインが期待どおりに動くか、レポートやダッシュボードが移行後のデータを正しく読んでいるかまで確かめます。

移行の難しさは調査にも表れています。IPAの2024年度ソフトウェア動向調査で、レガシーシステムの移行を実施中で課題を抱えていると答えた33社に課題を尋ねたところ、「既存システムの複雑さにより移行が技術的に難しい（データ移行やシステムどうしの依存関係の課題など）」が20社、60.6%で最も多くなりました（複数回答）。^*7 2番目は「現行の機能を保証し引き継ぐ制約が大きい」の14社、42.4%です。データ基盤に限った数字ではなく、33社と少ない回答ですが、移行の現場で技術的な難しさが先に立つことはうかがえます。

取り込みの処理の移し替え

上流のデータパイプラインを移すとき、手間が小さいのは、今の処理の最後にある書き込み先だけを新しい基盤に付け替える方法です。取り出して変換してから書き込むETL（抽出・変換・読み込み）の処理なら、変換の部分はそのまま使えます。ただし、書き込み先のテーブルの形が変わる場合は項目の対応（データマッピング）を組み直す必要があり、スキーマもクエリも変わりうるため、過去のレポートと新しいレポートの両方で指標を確かめるよう求められています。^*2

先に読み込んでから基盤の中のSQLで変換するELT（抽出・読み込み・変換）の処理は、読み込む部分と変換する部分に分けて移します。変換する部分はSQLそのものなので、次の節で触れるクエリの変換の対象になります。

処理どうしの順番を決めているオーケストレーション（複数の処理を順番どおりに動かす仕組み）は、段階を分けて見直すよう勧められています。最初の反復ではそのままの形で移し、次の反復で依存関係を分析して並列にできるものを並列にし、最後に共通の処理を独立させて組み直す、という順番です。

この順番は、数字の差を追いやすくもします。移行と同時に処理の中身まで作り直すと、差が出たときに移し方の誤りか処理の違いかを切り分けにくくなるためです。

過去データとダッシュボードの扱い

過去のデータは、まず古い基盤からスキーマとデータをコピーして同期させます。注意したいのは、過去の集計結果を「コピーしたもの」で持つのか、「新しい基盤で計算し直したもの」で持つのかです。移行の途中で変換の処理を直した場合、計算し直した過去分は、以前の集計表と数字が変わることがあります。どこまで過去にさかのぼって計算し直すかは、利用者と相談して先に決めておきます。

集計のクエリも移し替えの対象です。古いデータウェアハウスには標準のSQLを独自に拡張した書き方が含まれることがあり、変換の道具で解釈できないクエリは、手で書き直す必要が出ることがあるとされています。

ダッシュボードは、移行の前に洗い出しておくのが基本です。ガイドは移行の準備の段階で、関係者へのアンケートで「現在使われているBIツール、レポート、ダッシュボードは何か」を尋ねるよう挙げています。^*1 同じアンケートでは、データの鮮度（どれだけ新しいデータが必要か）の要件も聞きます。前日分が朝に見えていればよいのか、1時間ごとの更新が要るのかで、並行稼働の組み方も変わります。

並行稼働での数値の突き合わせ

古い基盤と新しい基盤を並べて動かす間に、同じ数字が出るかを突き合わせます。Google Cloudが公開しているData Validation Toolは、移行元と移行先のテーブルを比べる道具で、列ごとの集計（件数、合計、平均、値の上限と下限、グループ別の集計など）、行ごとの比較、スキーマの比較などに対応しています。^*3 行ごとの比較では、主キーで行を結び付け、指定した列をつなげてハッシュ値（内容から計算する短い値）にして比べます。

何を確かめるかの観点には、データ品質の考え方が使えます。内閣府地方創生推進事務局のガイドブックは、国際規格ISO/IEC 25012にある15のデータ品質特性のうち、正確性・完全性・一貫性の3つを、どの使い方でも欠かせない「基礎的品質特性」としています。一貫性の確認の例には「合計値や平均値等の数式に矛盾や誤りはないか」が挙がっています。^*4 スマートシティのデータ連携基盤に向けた資料ですが、移行の突き合わせにもそのまま当てはめられます。

全件を行ごとに比べると時間がかかるため、どこまでを全件で確かめ、どこからを一部で済ませるかも決めておきます。同じガイドブックは、評価の対象がすべてのデータか一部のデータかと、見つかった問題を直したかどうかで評価を分け、全件を評価して直し終えたものを最も高い評価にしています。^*4 3つの特性のうち最も低い評価を全体の評価とする決め方も、突き合わせの結果をまとめるときの参考になります。区分ごとの集計で差が出たら、その区分だけ行ごとに比べると原因に近づけます。

複数の元データを1つにまとめる処理では、項目の対応、精度や単位、コードの変換を正確に行うよう、ガイドブックは注意を促しています。移行で差が出やすいのもこうした所です。小数点以下の丸め方、日付と時刻の扱い、文字列の末尾の空白などは、基盤ごとに既定の動きが違うことがあるので、突き合わせの最初に確かめておきます。

フリーランスに任せる作業と社内で決めること

Google Cloudのガイドは、移行を始める前に成功の指標を決め、ユースケースごとに「完了」とは何かを定めるよう求めています。あわせて、事前の経験がない場合や社内に専門知識が足りない場合は、最初に移行を手伝う相手を決めておくことを勧めています。^*1 フリーランス活用を考えるなら、この2つを分けて考えると頼む範囲が決めやすくなります。

頼むときは、移行元と移行先の両方のSQLを書いた経験と、件数や合計を自動で比べる仕組みを作った経験を確かめます。依頼には、対象のユースケース、突き合わせる段階、差の一覧に書く項目（テーブル名、比べた値、差、推定される原因）を書いておきます。データ基盤そのものを作るときの役割の分け方は「フリーランス活用でデータ基盤を構築｜社内に残す役割と任せる役割」で扱っています。

つまずきやすい点

一つ目は、ダッシュボードの洗い出しが漏れることです。部門の担当者が自分で作った集計や、表計算ソフトから直接つないでいる集計は、一覧に載っていないことがあります。古い基盤への接続の記録を一定期間見て、誰がどのテーブルを読んでいるかを確かめておくと漏れを減らせます。

二つ目は、差が出たときに判断する人が決まっていないことです。突き合わせの作業を任せたフリーランスは差を見つけて原因を調べられますが、古い基盤の数字が長年誤っていたと分かった場合に、どちらに合わせるかは業務の判断になります。ユースケースごとに、差を判断する社内の担当者を先に決めておきます。

三つ目は、並行稼働を終える条件があいまいなまま始めることです。「区分ごとの集計が一定期間続けて一致したら切り替える」のように、終える条件を移行の計画に書いておきます。

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

データ基盤のデータ移行を進めるうえで、確かめておきたい点は3つに整理できます。第一に、データだけでなく、取り込みの処理、集計のクエリ、ダッシュボードまでをユースケースごとに洗い出すこと。第二に、最初は処理の中身を変えずに移し、件数・合計・区分ごとの集計・行ごとの順で数字を突き合わせること。第三に、差が出たときにどちらを正とするかと、並行稼働を終える条件を社内で決めておくことです。この3点を踏まえておけば、「移したはずなのに、会議のたびにどちらの数字が正しいのかでもめる」という事態を避けやすくなります。移行の作業に手が足りなければ、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Google Cloud「概要: データ ウェアハウスを BigQuery に移行する」（https://cloud.google.com/bigquery/docs/migration/migration-overview?hl=ja）。出典：Google Cloud の BigQuery ドキュメント。用語（ユースケース、上流プロセス、下流プロセス、オフロード移行、完全な移行）、準備と発見のアンケート項目、計画（成功の指標、「完了」の意味の定義、概念実証、移行パートナー）、イテレーション アプローチ、分析ワークロードを先に移行する考え方、実行の手順（スキーマとデータの移行、クエリの変換、7.確認と検証）を参照（2026年9月確認）
2. *2　参考：Google Cloud「データ パイプラインの移行」（https://cloud.google.com/bigquery/docs/migration/pipelines?hl=ja）。出典：Google Cloud の BigQuery ドキュメント。データ パイプラインに移行すべきとき（オフロードと完全な移行、増分コピー、古いウェアハウスの停止）、ETLとELT、BigQuery に書き込まれるようにデータ パイプラインをリダイレクトする（データ マッピング、指標の検証）、既存の ELT パイプラインの移行、必要な移行作業（依存関係を段階的に最適化する3つの手順）を参照（2026年9月確認）
3. *3　参考：GoogleCloudPlatform「Data Validation Tool」（GitHub）（https://github.com/GoogleCloudPlatform/professional-services-data-validator）。出典：同ツールの README。対応する検証の種類（Column validation、Row validation、Schema validation、Custom Query validation）と、行ごとの検証で主キーで行を結び付けハッシュ値を比べる仕組みを参照（2026年9月確認）
4. *4　参考：内閣府地方創生推進事務局「データ連携基盤を通して提供されるデータの品質管理ガイドブック」（PDF）（https://www.chisou.go.jp/tiiki/kokusentoc/supercity/pdf/supercity_230926_guidebook_honsi.pdf）。出典：2023年9月。4.1.1(1)データの品質評価（基礎的品質特性と付加的品質特性、ISO/IEC 25012の15の品質特性）、表4-1、4.1.1(2)①の確認項目の例、表4-2「3つの品質特性」に対する評価基準、表4-3 最終評価の基準、6.4 データ統合を参照（2026年9月確認）
5. *5　参考：IPA「2024年度ソフトウェア動向調査」調査結果データの公開と分析レポートの募集（https://www.ipa.go.jp/digital/software-survey/software-engineering/result-software2024.html）。出典：IPA「2024年度ソフトウェア動向調査」の公開ページ。調査期間（2024年12月17日から2025年2月14日）と、回答を匿名化してオープンデータとして公開していることを参照（2026年9月確認）
6. *6　参考：IPA「2024年度ソフトウェア動向調査 企業向け 設問一覧」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-questions.xlsx）。出典：同調査の設問一覧。Q5-16（レガシーシステム移行の状況）とQ5-18（移行実施中の課題。Q5-16で「実施中だがクリティカルな課題が発生し対応中」または「実施中で課題あり、対応できず凍結中」を選んだ企業のみが回答、複数選択）を参照。2025年度調査にはこの設問がない（2026年9月確認）
7. *7　参考：IPA「2024年度ソフトウェア動向調査 企業向け 調査結果（選択肢項目文字列）」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-result-data-str.csv）。出典：同調査の企業向け回答データ（799件）。Q5-18に回答した33社について選択肢ごとの社数を集計し、割合を計算した。選択肢の文言は意味を変えずに短くして表記した（2026年9月確認）

Tweet