回答。

問題の背景：

データ移行は、大規模ITプロジェクトの重要なステージであり、特に古い情報システム（レガシー）から新しいソリューションへの移行時に重要です。要件の形式化におけるエラーは、重要な情報の損失や新しいシステムの立ち上げ時の長期的なダウンタイムにつながる可能性があります（特に大規模な導入の場合）。歴史的には、銀行がデータ移行の失敗により崩壊した悲劇的なケースがあります。

問題：

ソースとターゲットのフォーマットの不明確さ、データ構造の違い、リファレンスの相違、マッピングの誤り、ビジネスチームと技術統合者の期待の相違が、問題のある移行の主な原因です。架空の、または十分に詳細化されていない文書は、どのデータが重要であり、どのデータを集約でき、どのデータを移行できないかを追跡することを不可能にします。

解決策：

システムアナリストは、ソース側でビジネスプロセスのオーナーと共同でデータのレビューを実施し、詳細なデータマッピングを作成し、どの属性が必須の移行対象であるかを特定します。データの質に関する仮定（清浄度、完全性）を文書化し、変換ルール（例えば、日付や通貨、エンコーディングのフォーマットの変更）を定義します。重要なフィールドには、テストサンプリングの移行と照合を行うためのシナリオが実装されます。各ステージで、ロールバックの指示と移行の成功基準が並行して文書化されます。

主な特徴：

• ソースシステムとターゲットシステム間のフォーマットの不一致を注意深くレビューし処理
• 重要なフィールドを特定し、優先順位を付ける
• ロールバックシナリオとデータの整合性チェックを文書化

ひっかけ質問。

システム間のデータフォーマットを確認するだけで移行は成功するのか？

いいえ。フォーマットが一致しても、データのビジネス上の意味やリファレンスの有効性、値のセマンティクスにおいて不一致がある可能性があります。各フィールドについてビジネスと技術の監査が必要です。

「最も需要のある」データのみの移行で十分なのか？

いいえ。「稀な」データは、特定のユーザープロセスにとってビジネスクリティカルである可能性があります（例えば、古い契約や保険など）。すべては要件に記録しなければなりません。

移行のロールバックの可能性を考慮するべきか？

必須です。100%のテストを行っても、行動開始後に重大なエラーが発生する可能性があります。ロールバックは文書化の必須要素です。

一般的なエラーとアンチパターン

• データマッピングとビジネス属性の詳細が不十分
• 移行成功基準とロールバックシナリオの欠如
• テストデータでの試験移行の軽視
• 統合接点でのインシデントの無視（明白でない依存関係の見落とし）

生活の例

ネガティブケース： 遺産銀行システムの移行時に、アナリストは主要なテーブルのみの移行を確認し、古い未使用のリファレンスのビジネス上の意味を明確にしませんでした。その結果、新しいシステムの起動後に、顧客は過去数年の取引履歴に問題があることを発見しました。

プラス：

• 新しいシステムの迅速な起動

マイナス：

• データの喪失
• 銀行の評判リスク

ポジティブケース：

アナリストは、ビジネスとITとともにすべてのデータ群のレビューを実施し、「稀な」データの移行に関する要件を明確化し、検証およびロールバックのシナリオを確認しました。移行は成功し、重大な不満は発生しませんでした。

プラス：

• インシデントの最小化
• 管理された立ち上げ

マイナス：

• 準備とテスト移行に時間がかかる