データ統合や移行でよくあるトラブルとその解決方法

1. 難易度が高い「データ統合・移行（マイグレーション）」

マイグレーションの一般的なステップ

・移行元システムと移行先システムのギャップを整理
移行元システムと移行先システムの全体像や各システムの仕様を比較し、データ移行の障害になるような差が無いかを確認します。ここでは「各機能が持つ役割」「処理内容」「取り込むデータ、受け渡すデータの扱われ方」を具体的に把握している必要があります。

・移行対象データの選定と形式の確認
移行対象データを選定し、移行元と移行先でギャップが生じないかを確認します。プログラミング言語やデータベース、インタフェース仕様の違いなどで値の形式が変わる場合は、データの変換ルールなどを定める必要があるでしょう。

・移行スケジュール立案
データ間の依存関係を整理し、移行するデータの順番とスケジュールを確定します。

・マイグレーション用ツールの開発
対象データの一時的な退避や、適切な形式への変換などに用いるツールを開発します。

・リハーサル
マイグレーションチームのメンバーだけではなく、業務担当者も交えて幾度かのリハーサルを行います。リハーサル用のテスト環境を構築する必要があるため、規模によっては1～3カ月の期間を要することもあるでしょう。

・本番移行
本番移行では、複数の業務システムから抽出されたデータを投入し、「連携は適切に行われるか」、「活用イメージに合った運用ができるか」などを確認します。

なぜマイグレーションは難しいのか

データ統合・移行が難しいとされる理由は、「業務を横断的に理解している人材が少ない」「過去の履歴を含めた全体把握が困難」という2点に集約されるでしょう。システムの設計書には「機能」の説明はあっても、業務自体の内容が記されていないことがあります。データ統合・移行の担当者が設計書からすべての業務を理解するのは困難です。また、システムの規模が大きく歴史が長いほど、「改修の履歴」は把握しづらくなります。あるデータを設計当初とは異なった目的で使用していたり、改修の背景・経緯が記載されていなかったりすると、データと設計書を見比べながら正解を導きだす作業が必要です。こうした作業は非常に時間がかかり、ただでさえ人手が不足しがちなマイグレーションフェーズでは、なおざりにされることも少なくありません。その結果、種々のトラブルを生み出す原因になってしまうのです。

2. データ統合・移行でよくあるトラブルと解決法

では、実際にデータ統合・移行で発生しがちなトラブルの事例と解決方法を見ていきましょう。

事例1: ベンダー変更に伴う仕様変更でデータ投入に失敗

旧システムと新システムを担当するベンダーが異なる場合、データ定義や連携仕様が変わってしまうことがあります。一般的にデータ統合・移行は単独のプロジェクトとしてスタートすることは稀です。通常は、何らかのシステム開発・改修プロジェクトに付随するかたちで行われます。こうしたケースでは、ベンダー間で引継ぎが十分に行われず、マイグレーションが頓挫してしまうことがあります。

特に、インタフェース定義やデータ定義が正確に引き継がれていないと、検証用のデータが作成できません。検証が十分に行われないままにデータを投入した結果、膨大なエラーが発生することがあります。こうしたエラーを解消するためには、仕様書と実データを突き合わせつつ地道な確認作業が続くため、復旧作業に膨大な時間を要することもあるでしょう。

・解決方法
解決方法としては、「ベンダー間の引継ぎ強化」や「ビッグバン的なマイグレーションの回避」などが挙げられます。ベンダー同士に引継ぎを任せず、必ず自社のシステム担当者も同席させ、新旧のギャップを把握しておきたいところです。また、インタフェースやデータ定義については、必ず「何が正か」をはっきりさせ、ベンダーと合意しておくようにしましょう。もし可能であれば、業務に影響が少ないサブシステムから移行を進め、マイグレーションのノウハウを積み重ねていく方法もおすすめです。

事例2: 対象範囲の見落としによるデータ欠損

データ統合・移行対象データの選定に見落としがあり、本番移行時まで誰も気が付かないと、業務に必要なデータが揃わずにマイグレーションが失敗してしまいます。また、本来であれば前もって投入されているはずのデータが存在しない場合、あとから不足分を投入しようとしても依存関係からエラーが発生し、システムを稼働させることが出来ません。こうしたトラブルは、主にウォーターフォール型プロジェクトで発生しがちです。ウォーターフォール型プロジェクトでは、上流工程の見落としをチェックする機会が少なく、データ選定の漏れに気づきにくいのです。

・解決方法
このタイプのトラブルを解決するためには、「アジャイル型プロジェクト」の要素を取り入れたプロジェクト進行がおすすめです。アジャイル型プロジェクトでは、イテレーション（ある工程を短期間で繰り返すこと）によって、仕様確定と実装を繰り返しています。このイテレーションを対象データの選定と移行リハーサルなどに取り入れることで、データの「漏れ」に気づきやすくなるでしょう。

事例3: 活用イメージとは異なるかたちで移行されてしまう

データ統合・移行には必ず何らかの目的があります。また、目的を具体化した「活用イメージ」を共有することで、プロジェクトメンバー全体にデータ統合・移行のゴールが示されます。この「活用イメージ」が明確でなく、漠然と「一カ所にデータを集めること」が優先されると、マイグレーション後にトラブルを招くおそれがあるのです。一般的に、「単にデータを一カ所に集める」だけであれば、マイグレーションプロジェクトの難易度は高くありません。しかし、実際の業務で扱えるデータ形式が考慮されていないために、いざデータを活用しようという段階になって変換作業が必要になったり、追加データの準備が必要になったりすることがあります。その結果、現場担当者の負荷があがり、コストを投じた割にはあまり使われないシステムが出来上がってしまうのです。

・解決方法
このタイプのトラブルを防ぐためには、まず部署・部門ごとに業務プロセスを洗い出し、経営幹部へのヒアリングを経て、事前に活用イメージを創り上げることが大切です。例えば、データ統合・移行の目的が「顧客データ統合によるマーケティング効率改善」である場合と、「経営状態の可視化」である場合とでは、活用イメージが異なるはずです。また、活用イメージは要件定義に必ず盛り込み、テストフェーズの終盤（システムテスト、UATなど）においても、可能な限りに現場担当者に確認してもらうようにしましょう。

事例4: パフォーマンス低下

大規模なデータ統合・移行では、マイグレーション後にシステムのパフォーマンスが著しく低下する場合があります。また、パフォーマンスに関するトラブルは、システムテストやUATでは確認できず、本番環境でのみ再現されてしまうこともあります。このタイプのトラブルが発生する原因として、「データ連携プロセス」や「インタフェース仕様」の把握が不十分なことが挙げられます。また、データベースのチューニングに問題がある場合もあるでしょう。

・解決方法
パフォーマンスに関するトラブルを解決するには、まず動的にパフォーマンスをチェックできるツールを用いて、ボトルネック部分を特定していきます。本番環境とテスト環境の違いを洗い出し、その差分の中にパフォーマンスを低下させる要因がないかをチェックしていきましょう。また、特定のデータにロックがかかることでパフォーマンスが低下している場合は、「ロックされているデータ」「ロックをかけているセッション」「ロックをかけているプログラム」などを特定します。一般的にデータのロックは、複数のユーザーが同時にデータへアクセスすることを防ぐために実装されます。そのため、「本当にそのデータをロックする必要があるのか」「複数ユーザーが同時に行うべき処理なのか」といった観点から、業務プロセスレベルで見直しを行うことも必要です。

データ統合基盤ソリューションの活用でリスク低下も

これらデータ統合・移行に関するリスクを低下させるために「データ統合基盤ソリューションの仕様に合わせてしまう」というのも一つの方法です。シンプルかつ安定したデータ統合基盤ソリューションを選定し、その仕様にそってマイグレーションプロジェクトを進行させていくのです。もちろん、仕様に合わせた業務プロセスの変更は必要になるでしょう。しかし、マイグレーション時に発生するトラブルに比べると、リスク・コスト共に小さくなる可能性が高いです。