子会社とのシステム統合 No19 再び

■　合併

前に実行した合併（子会社との合併に伴うシステム移行　No1　始まり）は見事に成功しました。これで暫くは別の案件に取り掛かれると思ったのですが、今度は別の子会社と合併するそうです。

・・・やめようよ（泣）

合併ってなると、システム以外にも資産の扱いとか色々と面倒なので、事務方からすると、合併するんじゃなくて精算会社として残して、取引だけ引き受けるって方が都合が良いと思うのです。

詳しくは知らないのですが、前回の合併についても未だに扱いがハッキリしない資産とか色々と残っているらしいですし、この状態でもう一社くっつけて大丈夫だとなのだろうか？

後、相手が完全な他社なら合併に持ち込むこともわからないでもないのですが、子会社となると、合併しようが、清算会社として残そうが、連結決算になるので結果は変わらないと思うんですけど・・・

営業面の何かとか、社外発表の影響とか、株式とか、上場とか、監査とか、何か合併の方が都合が良いことがあるんですかね？

ずっとシステムの世界で生きてきた私にはよく分からないです。と言っても、私もサラリーマン。会社がやれと言うならやるだけの話です。

■　システム

とりあえず、上司が相手の会社に話を聞きに行った（というか、挨拶がてらに様子を聞いてきた）のですが、話を聞けば聞くほど心配になっています。

まず、システムが何十年も前にスクラッチ開発で作ったシステムらしいです。Windowsサーバーに載せている集中システムでデータベースはOracle。ただし、開発言語はCOBOLで、ユーザーはリモートデスクトップで接続しているそうです。

開発時期がそんなにも昔というなら、まず間違いなくホストコンピューターかオフコンのはず。それなのにWindows？、Oracle？

あと、上司はリモートデスクトップって聞いてきましたが、言葉通りのリモートデスクトップではなく、おそらくCitrixあたりの仮想化技術を使用しているのでしょうね。

COBOLと言っても、当時の状況を考えると仕様どおりの純粋なCOBOLと考えるのは危険。どこかのベンダーが機能拡張したCOBOLをWindowsでも動くようにしたものと考えた方が自然。

そうであれば、データベースも開発時点からOracleだったと考えた方が良いでしょうか。今でもデータベースを載せ替えるには開発当初から複数のデータベースで動かすことを前提に開発しなければ難しいのに、当時の状況ではなおさら難しいでしょう。

うーん、考えれば考えるほど嫌な感じがする。

そもそも、集中システムというけど、当時のネットワークって今みたいに信頼性の高いものじゃなかったはず。それなのに集中システムって運用可能だったのか？
これ、元々は分散システムで、何かのタイミングで集中システムに切り替えただけなのではないか？

分散システムであることを前提に作られたシステムを集中システムにするのって相当なコスト（費用＆時間）だったはず。しかも、対応したとして得られるメリットが無い。

・・・これ、ハードレベルだけ集中させただけの、なんちゃって集中システムなんじゃないか？

さらに、それまでにも色々と追加開発はしていたらしく、当然の如く仕様書なんてものは無い。開発にしてもベンダーを頼らずに、自分達で設計からプログラミングまで行っていたらしく、ベンダー自身も仕様を把握していないそうです。

・・・これを移行しろと？そもそも、移行できるデータってあるのか？基幹システムのデータは適当なもので、会計システム側で調整仕訳とか入力して辻褄合わせてたりするんじゃね？

救いなのは、データベースがOracleってこと。これなら私にも多少の知識があるので、データの抜き出しとかは問題なく出来そう。

あと、システムを維持管理してきた人がいるらしく、かなり詳しいらしいです。どの程度のものなのか分かりませんが、その人の実力次第では何とかなるかもしれません。

とりあえず、その人に会って色々と聞いてみますか。

■　後書き

営業のことはわからないことが多いんだけど、合併の方が良いことっと何なのだろうか？

外から入ってきた人（つまり、銀行さん）が色々と動いているらしいけど、根回しとか全然しないで本社の都合を押し付けるようなやり方をするから、現場レベルの長はかなり困惑（要は、怒ってる）してるとも聞くし、大丈夫なのかね？

次回：子会社とのシステム統合　No20　データ分析

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

--- blog end —