子会社との合併に伴うシステム移行 No14 移行処理の設計と移行準備

■　考慮事項

移行処理という特性上、気にかけなければならない事が色々とあります。実行速度、異常時の再処理方法、複雑性の除外、イレギュラーパターンへの対応、結果確認方法、・・・パッと思い付くのはこんな所でしょうか？

原則として移行の実行時にはシステムを停止する必要があるため、システムを停止していられる時間内に移行処理が終了しなければお話になりません。

無駄なログを吐かない、DBアクセス時には適切な実行計画になるように注意する、場合によっては、移行用にインデックスを追加するとか、システム自体への変更もありえると思います。

エラー発生時の考慮も重要ですね。想定外のデータの発生、仕様上の考慮漏れ、プログラムのバグ、様々な理由で移行プログラムが異常終了することはありえます。その時に、原因の特定が出来る仕組みにしなければなりません。

また、原因特定後の再処理の方法にも注意が必要で、データが少なければ単純に頭から走り直せるようにすれば良いでしょうが、大量データを扱う長い処理の場合は、異常発生時点から再開できるように作らないとダメですよね。

設計レベルでは、イレギュラーなパターンにはあえて対応しないという方針も有効でしょうか？

イレギュラーなパターンに対応する為に仕様（プログラム）を複雑にすると、異常時の原因特定が難しいですし、処理時間にも影響がでるかも知れません。

移行後のデータパッチやマスタメンテナンス機能で対応が可能であれば、移行プログラムでは対応しないようにしても良いでしょう。

後は、移行処理の成功判断が出来るようにしないといけないですね。

■　移行結果判定

移行した結果が正しいかどうかがはっきりと分かるのは、移行から数ヶ月経過してからになると思います。と言っても、まさか「移行プログラムが正常終了したから移行成功だ」って訳にも行かないでしょうし、最低限の確認方法は考えないといけないと思います。

まさか、移行したデータの全てを確認する訳にもいかないので、ある程度集約して確認するのが現実的ですね。考え方としては、移行前の結果 + 移行データ = 移行後の結果になればOKって所でしょうか？

とすると、在庫系の移行結果確認方法は

① 子会社の在庫表を取得
② 移行前の親会社の在庫表を取得
③ 移行後の親会社の在庫表を取得
④ ③ = ① + ② を確認

って感じですね。これを部署別とか倉庫別とかの単位でバラして確認出来るようにしておけば良しと。似たような方法で、手形、工事契約、売掛残高、買掛残高、etc・・・と移行データの全ての結果を確認出来る手法を用意しますか。

■　手順書

移行処理の基本的な流れは、システム停止→バックアップ→移行プログラム実行→結果検証→システム稼働、となります。場合によっては、移行プログラムの実行後に再度バックアップを取得する事もあるかもしれないですね。

やることは単純なのでチェックリスト程度で良いと思ったのですが、少し真剣に作る事にしました。

何故かと言うと、移行プログラムという性質上、あまりにもイレギュラーなパターンに対する実装は見送ったため、移行処理の実行後に既存の機能（マスタメンテナンスとか）を使ってデータを修正するような処理があったりします。

他にも、子会社の人達がシステムを使えるようにするための準備とか、色々とやるべき準備作業があります。

まぁ、私がいなくても作業出来るようにする必要もあるので、どちらにしても手順書は必要ですしね。

前回：子会社との合併に伴うシステム移行　No13　セキュリティ
次回：子会社との合併に伴うシステム移行　No15　移行リハーサル

投稿記事の一覧：http://harikofu.web.fc2.com/

--- blog end ---