- 読み
- でーたいこう
- 英語
- Data Migration
- 別名・関連
- データマイグレーション、移行作業
なぜ重要か
スタートアップでは、最初はスプレッドシートやノーコードツールで運用を始め、事業が伸びてから自前のシステムに移す、という流れがよくあります。また、MVPで検証したあとに土台を作り直す場面や、古くなったコードをモダナイズする場面でも、それまでに蓄積した顧客データや取引データを新しい仕組みへ引き継ぐ必要があります。
データ移行は後回しにされがちですが、実際には想定より手間がかかることが一般に多い作業です。表記のゆれ、空欄、重複、時期によって意味の違う項目が蓄積されたデータには含まれており、作業量は件数ではなく「汚れ具合」で決まります。
事業・開発の実務での意味
開発を依頼する際に、データ移行について決めておきたいのは次の点です。
- 移行するデータの範囲と、移行しないデータの扱い
- データの実物を早い段階で開発パートナーに見せられるか
- 移行後に「正しく移った」と確認する方法と担当者
- 切り替えのタイミングと、問題があったときに元に戻す手順
見積りの段階でデータ移行が含まれているかどうかは、必ず確認してください。既存サービス改修・モダナイズでは、移行の範囲と切り替えの方法を、事業への影響を踏まえて計画します。
関連する用語
関連用語: モダナイズ、バックアップ、技術的負債、非機能要件
この用語が出てくる記事
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- PoCに必要なデータの用意きれいなデータが揃うのを待つとPoCは始まりません。手元にあるものから始める考え方と、評価用データと入力用データを分ける理由、個人情報を含む場合の扱いを発注側の視点で整理します。
- 社内でだけ通用するプロダクトの罠社内用語や既存データ形式などの暗黙の前提に依存した設計は、外部に出そうとした時点で作り直しになります。依存が生まれる箇所と、外販を視野に入れるなら最初に分けておくべき境界を整理します。
- 自社のAI活用の準備度を測るAI活用に着手できる状態かを、データの所在・業務の文書化度合い・意思決定の速さの三点で確認する方法と、準備が足りない場合に先に整えるべきものを経営者・事業責任者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開