データ移行とは？
システムやクラウドの移行リスクと最善策を解説

データ移行とは

データ移行とは、データを1つの物理的または仮想的な場所から別の場所に移動する事です。単に移動元と移動先のシステムやアプリケーション間を移動するだけでなく、データ形式を変更することもあります。既存のデータセンターからクラウド上のデータストアにデータを移動することもデータ移行に含まれます。

データ移行の必要性

データ移行は、企業が保有するデータに何らかの変更を必要とする場合に必ず発生するものです。色々なケースがありますが、一般的には以下のような場合です。

• システム更改のケース。ハードウェアやシステム環境、あるいはデータベースなど既存のインフラストラクチャをアップグレードする場合
• クラウド移行のケース。オンプレミスからクラウド環境にデータを移行する場合
• データ形式の変更が発生した場合
• データウェアハウスやデータレイクを構築するケース。分析およびレポーティングのプロジェクトにデータを提供する場合
• M&Aのケース。複数種類のデータを統合する必要がある場合
• 不要データのケース。業務で使用しなくなったデータをアーカイブまたは削除する場合
• コスト削減のケース。データを保有するシステム数そのものを減らす場合

以上が、データ移行の全パターンではありませんが、典型的なユースケースです。

データ移行プロジェクトとは

データ移行プロジェクトの目標はプロジェクト毎に異なりますが、すべてのデータ移行プロジェクトに共通しているのは、詳細なプロジェクト計画が成功のカギだということです。プロジェクト計画にはデューデリジェンス、セキュリティ、コンプライアンス、データ品質その他のタスクが存在し、データの消失や流出を防ぐにはそれらタスクのオーナーが協働する必要があります。どのタスクをいつ実施し、タスク間の依存関係を反映したスケジュールも必要です。データ移行のゴールは、移行によって達成すべき業務上・技術上の目標を達成し、なおかつビジネスの中断を最小限に抑えることだからです。計画を入念に企画することは、移行のリスクとコストを最小限に抑えるために最も重要なポイントです。

1. 移行計画の作成

データ移行計画は最終的に、移行されるデータの稼働 (go live)目標およびそこに至るマイルストーンが書かれなくてはなりません。それ以外の主な要素は、以下のようなものです。

• 移行の目的：データ移行は、業務上または技術上の目的を達成するための手段です。プロジェクト計画では、移行を何のために行うかという目的を明確に表現することで、個々のタスク同士の整合を取ることができます。
• チームと責任：データ移行プロジェクトは全員が一箇所で作業するとは限りません。そのため、各チームそれぞれの役割と意思決定権者を明確に定義しておく必要があります。
• スケジュールとマイルストーン：プロジェクトに含まれる相互に複雑に絡み合った多数のタスクそれぞれの納期を適切に設定することで、移行全体の納期を遵守することができます。

2. 全ソースシステム一覧の作成

単純な移行であれば、1つのソースシステムからもう1つのシステムにデータを移動するだけですが、多くの場合はもっと複雑です。システム統合や企業M&Aなどの場合、複数のシステムが保有するデータを移行する必要があります。その際、既存データを保有するシステムがあってもデータオーナーが不明な場合は多くあります。また別のケースとして、データ統合やデータアーカイブなどの場合、むしろ移行されないデータのほうを完全に理解し、規制やビジネスルールに違反しないよう気をつける必要があります。どちらの場合でも、移行計画が対象とするすべてのソースシステムをピックアップし、一覧化するための十分な調査時間が必要です。

3. 既存データ品質の評価

データ移行は、データの品質を改善しデータの信頼性と価値を高める最良の機会です。低品質のデータは業務の混乱を招くものであり、同じデータをそのまま新しいシステムに移行しても同じ混乱が続くだけだからです。ただし、品質を向上させる前に、まず現状を評価する必要があります。移行準備においては移行元のデータを完全に監査し、データの一貫性、正確性、完全性など品質レベルを判定します。判定後、具体的にデータ品質を改善するための施策を打ち出していきます。

4. 移行先システムの調査

移行先のシステムがデータを受け入れる準備ができているかどうかを確認します。具体的にはデータモデル、アクセス権、利用可能なストレージなどを始めとする、移行先システムの徹底的な理解が重要です。

5. 移行データのマッピング

多くの場合、移行元と移行先のデータモデルは異なっており、単純なデータ移動では済みません。データ項目が似ていても異なる場合、複数項目を一つに集約する場合、一つの項目を複数に分割する場合などさまざまです。計画段階では、こうしたデータ構造の相違を踏まえ、移行元と移行先のあいだのデータ項目のマッピング定義を作成しておく必要があります。

6. データの進化

日々ビジネスは進化し、ビジネスルールも変更されていきます。移行チームの課題は、データに影響を与えるであろうビジネスルールを把握することです。しかし、そうした変更はデータに反映されているとは限りません。あちこちの部門が持っている文書に分散していたり、時には担当者の頭の中だけのものだったりします。従って、移行の計画段階で十分な時間をかけてこうしたルールを洗い出し、いつどのようにデータへの影響が出るかを調査し一覧化する必要があります。

ビジネスルールを含む、こうしたデータ調査結果は価値あるナレッジです。今回のデータ移行プロジェクトを超えて、今後のデータ統合、データ品質、メタデータ管理、マスターデータ管理などの他のプロジェクトでも活用できます。残念なことに、現実的にはこうした知識は移行プロジェクトが終了すると捨てられ、忘れられてしまいます。そのため、意識して規定やシステムのナレッジを保存しておき、今後のビジネスや他プロジェクトで活用できるよう気をつけます。実際、データ移行は企業全体のどこかで必ず発生しているため、ナレッジをカタログ化することは他の移行における効率化に寄与します。

7. データ構築

現行データに不要な項目が見つかる場合がある一方、移行先のデータモデルに現行にない新しいデータ項目が見つかることがあります。しかしそのデータがないままでは業務に支障をきたす可能性があります。移行計画においては、現行にないデータを新たに構築する活動も含める必要があります。

8. データの移動

データ移行では、DVDなど物理メディアなりネットワークなりを介して、物理的なデータの移動を行います。その際に重要なのは、データの漏洩を防ぐことです。また、小規模なデータ移行では一度に全データを移動できても、大規模な移行では段階的なデータの移動が必要になります。移行計画では、どちらのアプローチをとるのかを決定しておく必要があります。

システム間のデータ移動には、何らかのツールを使用します。簡単にスプレッドシートで済ませる場合もありますが、ビジネススイートやデータベース管理システムに付随するデータ移行ツールが使える場合もあります。また、サードパーティのツールとしては統合プラットフォームサービス（iPaaS）があります。iPaaSはアプリケーション統合やデータ統合のためのクラウドソリューションであり、オンプレミスとクラウドを含むさまざまな環境間でデータを移行および統合するサービスです。伝統的な方法としては、ETL(抽出、変換、ロード）があり、ソースシステムからデータを抽出(Extract)し、それをマッピング・変換(Transform)し、ターゲットシステムにロード(Load)します。ELTツールはソースからターゲットシステムにデータを移動してから変換します。ツールの選択はプロジェクトの特性に依存します。

9. データの検証

企業全体のプロセスや意思決定のためには、データが利用可能で信頼できることが重要です。したがって、移行においては変換されたデータの検証が必要であり、とくにターゲットシステムにロードされる前に十分な時間と労力を費やすことが重要です。

稼働直前に駆け込みでデータを検証すると、移行遅延のリスクが高まります。データエラーが頻発し、その都度デバッグや改修が想定外の時間を要するからです。データのマッピング、変換、構築、移動の活動はウォーターフォール的ではなく複数回を反復的に実行してデータを継続的に検証することで、稼働遅延リスクを低減することができます。

10. 本番移行

上記のステップを成功裏に完了すると、データの本番移行は完了です。データは新しい環境にあり、業務で使用できる状態になります。理想的な移行計画が理想的に実施された場合、本番移行はシームレスに行われ業務への影響は生じません。業務の中断が発生しないことが本番移行では重要です。

データ移行時で考慮すべき要素

データ移行のプロセスは複雑です。したがって、データ移行プロジェクトに着手する前に、あらかじめ必要な要素を考慮しておくことが不可欠です。以下は、理想的な移行に役立つ主要な要素ですが、実際には個別のプロジェクト条件も考慮する必要があります。

プロジェクトマネジメント

データ移行は、単なるシステムイベントではありません。多くの部門の多くの人々が関わります。そのためにはプロジェクトマネジメントにおける経験と実力が必要で、とくにタイムリーなコミュニケーション、プロジェクトのモニタリングと報告、そして意思決定力が必要です。

意思決定のトレーサビリティ

移行プロジェクトにおける意思決定は、いくつもの後続タスクに影響します。意思決定を正しく実行するには、どのデータ変更についてもその理由となったビジネスルール変更や意思決定まで遡れるトレーサビリティが必要です。

エラー対策のトラッキング

「プロジェクトでは、いかなるプロセスもエラーの可能性がある」ことを銘記しておかなくてはいけません。したがって、移行で発見されたすべてのエラーは、対処すべき担当者の割り当てからエラー解決までのすべてを追跡できる必要があります。そうして初めて移行データ全体の整合性を保ち続けることが可能となります。

スケジュール

スケジュールでもっとも重要なのは、データの物理的な移動時間を見積もることです。それには移行データのボリュームと、ソースシステムとターゲットシステムの時間差を考慮する必要があります。時間差をつねに最小限に抑えることが、突発事態による混乱を最小化するポイントです。

データ移行におけるリスク

データ移行では、さまざまなプロセスが相互に連携しつつ、かつ膨大なデータを扱います。以下に、プロジェクトを妨げるさまざまな要素と移行プロセスへの影響するかを示します。

業務の混乱につながるリスク

移行において、外部からの突発事態が大きなリスクです。企業にとっては移行中であってもシステムが稼働を続け、顧客、従業員、パートナーの業務を継続することが望ましいです。そのため、もし移行中にデータの変更が生じても、それをただちに移行先に反映することは困難です。結果、システム内でデータの不一致が生じ、不正確なデータが発生します。

データの損失または破損のリスク

当然のことながら、移行におけるデータの損失・破損のリスクは最小限に抑える必要があります。データ損失や破損は、不完全なデータ転送やシステムの非互換性、人為的ミスなど、いくつもの理由で発生する可能性があります。データの損失は、深刻な経営損失や風評被害をもたらし、顧客および潜在顧客への影響が懸念されます。もし移行計画そのものが無い場合、最悪データが消失しても復活できず、多大な経営損失につながる可能性もあります。

データ漏洩のリスク

移行中の重大なリスクがデータ漏洩です。データの移動中はシステム本体もデータも、どちらも最も脆弱な状態だからです。データが移動するルートが最も弱く、攻撃者はそこを狙ってデータを盗み・改竄できてしまいます。これはデータ移行の失敗に直結します。

データ移行のリスクを最小限に抑えるために

データ移行は多くの危険に満ちているため、プロジェクトチームは成功を確実にするための連絡方法や手順を決めておく必要があります。以下はその方法の例です。

計画立案

計画の重要性は強調してもしすぎる事はありません。データ種類やデータ構造、保管方法などを調査することに始まって、活動のトレーサビリティやエラーの追跡などすべてに渡って計画を立て、追跡できるようになっているほど、移行プロジェクト成功の確率は高くなります。

移行プロセスを開始するに当たって、事前準備として必要なのが、全社の関係者全員が移行の最終目的を共有し理解することです。これにより、これ以降に行われるすべての意思決定やタスクが目的に沿ったものになることが保証されます。

データ環境の理解

目的の次に大事なのが、移行元と移行先の両方の環境を完全に理解すること、そのための調査に十分な時間を取ることです。よく理解できているほど、移行の後半になって発見されるエラーが少なくなります。特に、移行先の環境というのは現段階では未知の外部環境であるため、移行の影響を予測するための詳細なレポートを作成する必要があります。

検証とテスト

テストは、本番稼働前にできるだけ多くの欠陥を洗い出すために行います。プロジェクトで早期に欠陥を発見できるほど、解決のコストは低くなります。大量のデータを変換し移行する場合は特に、移行のできるだけ初期から始めてプロジェクト全体にわたり、継続的にテストを行うことが必要です。

データ移行のベストプラクティス

データ移行は複雑なプロセスであるため、成功させるためにはベストプラクティスやガイドラインに従うのが有効です。すでに定評のあるベストプラクティスは、移行リスクの低減と同時に、移行プロセス全体の効率の向上に役立ちます。以下に、いくつかのベストプラクティスを紹介します。

データを知る(KY : Know Your data)

データを移行する前に、現在データがどんな用途で使用されているか、何のために移行を行うのかの目的を理解しておくことが重要です。そして各ステークホルダーにはより一層の深い理解が求められます。現在システムを使用しているのは誰か、そして移行されたデータはどのように使用されるのかを理解することも重要です。

さらに、移行元と移行先におけるデータの互換性を詳細に分析することも必要です。これは、単なるシステム効率の問題ではなく、今後のデータ活用においても有用です。

データ環境の理解

データ移行先の環境を知ることは最も重要です。データ移行先の環境こそがデータの挙動や連携にかかわる根本的な要素だからであり、データ移行の目的にも直結します。さらに移行先の環境は、移行プロジェクト時点では未知の世界です。移行の影響を予想するためには詳細なレポートを作成する必要があります。

また、移行先と移行元の環境のデータ互換性はプロジェクト開始前によく理解しておくことも重要です。

貢献分析

移行による経営貢献を調査するのが貢献分析です。移行の戦略立案に当たっては、移行後の新しい環境が業務や経営にいかなる貢献をもたらすかを理解する必要があります。移行には多くの費用を要するため、コストメリット分析も重要です。つまり企業は、今回のデータ移行によって新たな価値を創出したり、業務要求を満たしたりすることができると確信できている必要があります。貢献分析は、移行にかかわる全員が、なぜ今回の移行を行うのか、どんな貢献が期待されるかを理解するために実施します。

データ移行は組織にとって重要である

データ移行はデータを移動するだけでなく、データ品質改善、既存システムのパフォーマンス改善、データへのアクセス性向上などの機会を提供するものでもあります。既存システムが現状のインフラストラクチャで十分であったとしても、いつかはアップグレードの日を迎えます。企業におけるデータ移行とは、本質的にはより良い環境にアップグレードし、システムがより高速になり、業務効率が向上するということです。

また同時にデータ移行は、自社のデータを詳しく調べる棚卸しの機会でもあります。調査を通じてシステム内のさまざまな不整合や重複を発見できることで、システムからさまざまなエラーを排除したり、重複データを削除してデータ量を削減したりするために使用できます。また自社のどのデータがどこに保存されているかを明確に理解する役にも立ちます。

データ移行は業務、システム上のさまざまな理由で全社のどこかで絶えず行われています。移行の実力を上げ、移行から得た組織知を確保することで、将来にわたるプロジェクト成功確率を高めることができるようになります。