子会社との合併に伴うシステム移行 No11 既存機能の流用

■　移行プログラム

基本的には、子会社のシステムから抜いたデータを、こちらのシステムに合わせて加工するプログラムを新規作成するようにしたのですが、一部の機能については既存の機能をそのまま使用する事にしました。

とある情報を作成する機能があるのですが、１０を越えるテーブルを作成する複雑な処理で、仕様の一部がブラックボックスになっているという極悪ぶりです。真っ当に移行プログラムを作るとすると、プログラムから仕様を解析して作り直すという大変な作業になってしまいます。

そこで考えたのが、機能（ロジック）は存在するのだから、それを起動するためのパラメータを移行プログラムで作ってやれば良いだろってことなのです。これであれば、解析が必要なのは起動パラメータに渡している値だけだし、移行プログラムもデータを起動パラメータに加工するだけで済みます。

当初は、少ない時間で確実にデータ移行が可能になる良案だと思ったんですよ。今でも、発想は良いと思うんですよね。

■　問題

実際、仕様の作成からプログラミング、単体テストまでは順調に進んだのですが、本番に近い形でデータを流してみると様々な問題が顕在化しました。

問題①　エラーチェック

使用したプログラム内部のエラーチェックが強力なため、少しでも問題があるとエラーとして止まってしまいます。例えば、担当者の所属や権限の確認、与信の状態、取引先の状態、などとことあるごとに止まってしまいます。
エラーチェックのロジック自体は問題ないし、本来の運用であればエラーを返して良いのですが、移行の場合は多少のエラーは無視してくれないと困ります。

問題②　コミットのタイミング

使用したプログラムの内部でコミットが実行されてしまうため、移行プログラム自体が１つのトランザクションとして動かせません。大量のデータを流している途中で問題①のエラーで停止した場合、そこからの復旧が非常に手間です。

途中で止まっても再処理ができるように設計、プログラミングの両方を考えなければならないなりません。これが意外と引っかかりました。

問題③　速度

ほかの問題ともからむ話しですが、処理の内部で色々とやるため速度が遅いです。移行時間が膨らむため、何らかの問題があった場合の対処時間が少なくなってしまいます。

問題④　移行処理の手順

問題①を解決するため、移行プログラムの実行前に強力なエラーチェックをしたり、マスタの情報を書き換えたりと無駄な作業が追加されてしまいました。作業手順が複雑になり、移行時の負担になってしまいました。

■　後悔

当初は良いアイデアと思ったのですが、今では後悔しています。

結局、単体テスト以降の行程で多大な手間が掛かる事になってしまい、当初期待していた「少ない時間で」という部分がボロボロです。これなら、プログラムを解析した方が良かったってものです。

まぁ、奇麗なデータを作ることが出来たので意味が無かったとは思いませんが、プラスマイナスで言うと、ややマイナスですね。もう時間もないのでこのまま進むしか無いのですが、次があったら別の手段を検討したい所です。


前回：子会社との合併に伴うシステム移行　No10　マスタ
次回：子会社との合併に伴うシステム移行　No12　開発環境

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

--- blog end ---