【流通工房】既存データのデータ移行の考え方・重要ポイント

-------------------------



＜要件定義１（データ構造）＞

【データ移行】

【ポイント】
データ移行計画、実務は実際にデータ移行を実施したことがないと組み立てが難しいと
思いますが以下に重要ポイントを記載します。
ここではこの要件定義フェーズのみではなく、その後のフェーズも含めデータ移行に
関連する重要事項を全て記載します

マスタ移行のポイント
トランデータの移行ポイント
マスタ、トラン共通の留意点
移行プログラム開発の役割分担
移行データを使った機能テスト
移行リハーサル
体制について

●マスタデータ移行のポイント
　既存マスタと新システムマスタの項目マッピング
　既存システムと新システムでフラグや区分などのデータ値が異なる場合の変換テーブル
　新システムマスタで追加した項目についてはデフォルト値を何にするかの検討が必要

⇒TOPへもどる

●トランザクションデータの移行ポイント
　大きくは２つ
　１つは対前年比などの出力、発注の際の参考情報表示などのため、最低でも昨年１年
　分のデータは移行が必要だが、それ以外に何年分移行するかの検討が必要
　当然、できる限り移行してほしいという要望が顧客から出ることが多いが

　・移行データ量が多ければ多いほどデータ移行時間がかかる
　・過去のデータほど下記に記載するような不備データが多く整備に時間がかかる
　・ディスク容量の圧迫

　などの作業負荷の増大、スケジュールへの影響、システムリソースの圧迫が伴うため、
　十分に顧客と協議をして決める必要があります。
　私の今までの経験では過去３年をひとつの目安として調整をしました。
　
　もうひとつのポイントは、昨日時点の売上データ、発注残、入荷情報、売掛残、
　買掛算、入金情報など新システムへの切り替えタイミングで「生きている」データ
　の移行。

　これは、切り替え前日のデータが確定し、翌日のシステムリリースまでにデータを
　移行する必要があるが、当然既存システムと新システムではデータ構造、ロジックが
　異なるため、マッピングと新システムで移行データを使って問題なく機能が稼動するか
　の検証を十分にしておく必要がある。また、移行時間の実検証も重要

⇒TOPへもどる

●マスタ、トランのデータ移行における共通の留意点
　長年のシステム運用の過程で作成された
　・親子関係の関係が崩れているデータ
　・打合せ時点で提示されていた以外の区分値のセット
　・データ自体が不要なゴミデータ
　などが様々な想定外のデータが移行元データには必ず含まれています。

　これらのデータは該当データを抽出し、移行するかしないか、する場合のデータの整備が
　必要であり、この整備作業は基本的に判断が伴うため顧客側での作業となります。
　かなり工数としては大きくなることが多いため
　・項目のマッピング
　・既存システム側、新システム側の移行プログラムの開発
　が終了した時点でできる限り早く一部のデータでも良いのでテスト的にデータ移行を
　行うようにすること。

　私の経験では一度できれいになることはなく、整備してその結果を検証するために
　データ移行テストを行い、そこで更なる不備などが発見されることが多いため、データ
　量と規模にもよりますが3回～5回程度はデータ移行テストを行うことになるでしょう。
　
　また、同一のパターンの不備データへ一律でデータパッチをあてたり、デフォルト値を
　セットするなどについては簡易プログラムやスクリプトを作成し、開発会社側でサポート
　することも重要。

⇒TOPへもどる

●データ移行プログラム開発の役割分担
　データ移行のためのプログラムは新システム側だけで構築するのではありません。
　データ元である既存システム側である程度、データのチェック、整備をし、また
　新システムの移行プログラムへインターフェースをしやすいレイアウトへ加工する
　など既存システム側でも移行プログラムの作成作業が発生します。

　既存システムと新システム側でどの部分をどちらで実施するのかといった役割分担、I/F
　するデータレイアウトを明確にした上で進めることが重要です

⇒TOPへもどる

●移行データを使った機能テスト
　開発から結合テスト時点では移行データが間に合わないことが多く、新システムで
　データをエントリーしそれでテストを実施することが多いが、新システムで作成した
　データで機能がきちんと動くことは当然です。

　しかし、移行データについては、既存システムで作成されたデータであり、また、
　移行プログラムを介してのデータ連携になるため項目のマッピングのミス、デフォルト
　値の設定ミス、必須項目の漏れなどにより新システムでエントリーしたデータでは
　問題なく稼動している場合でも、移行データを使ったら稼動しないというケースは
　多々あります。

　また、開発チームがテストする上でもマスタおよびとランデータについてある程度
　まとまったデータが必要にもなるため、移行チームはまずはマスタを先に順次、
　トランデータを開発チームに渡して移行データの精度の検証もしてもらう必要があります。

⇒TOPへもどる

●データ移行リハーサル
　個々の移行プログラムは問題なく動き、処理時間の見積りができている場合でも
　実際の全件のデータを予定しているデータ移行スケジュールに沿って実施をすると
　システムリソースの競合によるレスポンス悪化やつぶしこんだはずがさらに想定外
　のデータが含まれていることにより移行プログラムが異常終了するなどが発生します。

　最終データ移行で失敗することは翌日の新システム稼動開始時間へ影響し、最悪は
　システムのリリース延期などにも及びます。
　また、システムの稼動開始時間が遅延することは顧客の業務に多大な影響を出します。
　
　よって、最低１回は移行リハーサル（１ヶ月前などのデータで想定される全データを
　想定している移行スケジュールどおりに実施し、処理時間の計測、作成されたデータ
　の確認を行うこと）を実施し、さらにその移行データでの全機能の動作確認を行う
　ことは重要です

⇒TOPへもどる

●体制について
　データ移行は既存システムと新システムの双方のデータ構造を抑えている必要があり
　リーダクラス、そしてサブリーダクラスまではシステムインテグレーションプロセスを
　理解し、システム全体のデータ構造を抑えることができ、また流通業のシステムの知識
　構築経験がを持ったレベルの要員である必要があります。

　また、既存システムがHOSTの場合は、できればHOSTでの開発経験があり、HOSTのファイル
　構造やデータ型などを理解している方がなお良いです。
　さらに、実際にデータ移行の経験があり、発生するタスクとリスクなどの想定がつく
　人のアサインをしたいところです。もし、データ移行自体の経験が全員が未経験の場合
　はプロジェクトリーダなど経験があるものが計画のレビューやリスク管理などを代行
　する必要があります

⇒TOPへもどる