子会社との合併の伴うシステム統合 No38 移行当日

■　合併処理当日！

ついに当日！前日までに細かい準備を（私一人で）整えて、事前に（私一人で）計画した手順で、（私一人で）処理を実行します。

・・・文言から怨念のようなものを感じる気がしますが、気のせいですよ。うん。

まぁ、実作業は私一人なのは事実なのですが、何人かは出てきています。いざという時（致命的な問題発生など）に最終判断をする人と、マスタ系の担当者は、やっぱりいないと困りますし。

子会社の担当の方も、年次処理を実行するために深夜まで残っていたそうです。こちらと直接関係しませんが、何だかシンパシーを感じます。

■　合併共通

今回の移行システムの大きな方針は、移行用のデータ取得（抽出）、ワークテーブルへ投入、それを入力データとして合併用テーブルへデータ登録、そこから本番テーブルへ繋げる流れなのです。

移行処理っていうのは、基本的にはシステムを停止して実行するのが原則なのでしょうが、この手順だと、合併用テーブルに登録するまではシステムを止める必要がありません。

そこまでの間の処理でエラーチェックをしておけば、システム停止をせずに行程を進めることが出来ます。休日に作業するとはいえ、現実には出社して働いている方もいるので、停止時間は極小化したいのが本音。

開発当初は、合併共通を作る方針には乗り気じゃなかったのですが、結果的には良かったかもしれません。

■　結果

実のところ、結構トラブルは出ました。

債権を移行しようとしたら、それに見合う取引先マスタが無いから始まって、処理の手順（っていうか順番）を間違えて手戻りが発生したり、仕様に問題があって数値のつじつまが合わなくなったり・・・

手がかかった部分の大半は、直前になって方針を変えた部分。

現場の運用のために、本来はまとめて移行する予定の部分をかなり前倒しにしたのですが、その辺りが原因して、事前のテストや移行リハーサルでは発見できなかった隠れた障害が顕在化。

とりあえず、一通り処理を流した時点で、終わったことにしてメンバーには帰ってもらいました。後処理も色々あるし、いても何かしてもらうことも無いし。

■　後書き

本当は、移行の直前に開発環境にデータを落として、そこで移行処理を流して確認まで出来れば良かったのですが、それをする余裕が人的に存在しなかったっていうのが辛いところです。

まぁ、微に入り細に入り、そして最後は大胆にっていうのが私の方針です。事前にリスクを極小化したかったのは本音ですが、私一人では手が回らないので、多少のトラブルは当日に何とかするつもりだったので、これはこれで良かったのかもしれません。

なお、理想の終了時間は１４時くらいだったのですが、結局は日付が変わるくらいまでかかりました。

前回：子会社との合併の伴うシステム統合　No37　いよいよ本番！でも・・・
次回：子会社との合併の伴うシステム統合　No39　鬼門は手形

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

--- blog end —