子会社との合併に伴うシステム統合 No22 システム構成

■　基幹システム以外

私が基幹システムの担当なせいか、どうしても基幹システムがどうなっているか気になるのですが、実際にはグループウェア（メール）、ディレクトリサーバ、共有ファイルサーバなどの色々なサーバ（システム）が存在します。

これらについても考えないと行けないのですが、幸いなことに大したものはないようです。会計システムや給与システムはあるようですが、これらは単純な片寄で良いので考える必要もありません。

ネットワークの統合がちょっと厄介かもしれませんが、新しい事業所が出来たと考えれば難しいこともありません。現在使っている線を流用したいとか、合併後もしばらくの間は旧システムに接続する必要があるとか、色々とあるにはありますが、出来ないことは出来ないと割り切れば、どうとでもなります。

うん、こっちは良いですね。

■　基幹システム

肝心の基幹システムについては、システム構成をしっかりと確認してきました。随分前に上司が聞いてきた時（子会社とのシステム統合　No19　再び）には色々と疑っていたのですが、かなり確信をついた内容だったようです。

例えば、リモートデスクトップは本当にリモートデスクトップを使っていました。リモートデスクトップでサーバに接続して、そこから基幹システムに接続する感じです。当初は直接接続できるようにする計画だったようですが、難しかったみたいです。

あと、COBOLについては私がちょっと侮っていました。

想像通り、某社のWindows対応のCOBOLを使っていたのですが、DB（Oracle）へのアクセスはSQL文を使用せずに、COBOLのREAD文、WRITE文で直接DBへアクセスできるソフトがあるらしいのです。

要するに、READ文、WRITE文をSQL文に変換するようなものなんでしょうが、こんなものがあるからこそ、言語はCOBOLのままで大きな改修もせずに、近代化改装が出来るんですね。

データ分析をした時（子会社とのシステム統合　No20　データ分析）に、テーブル間の結合キーに違和感を覚えていたのですが、SQLでテーブル結合を行うことを前提としていないのであれば、納得できないこともありません。

データを見る時には、この辺りを意識しておかないと痛い目に合うかも知れませんね。

■　後書き

COBOL言語のREAD文、WRITE文でDBにアクセスするソフト、そんなものがあるのかと思ってビックリしたのですが、後で調べてみると結構あるんですね。

基幹システムの再構築って難しいので、こういう仕組みを使って延命を図るのも一つの手ですね。追加開発が少ないような枯れたシステムであれば、これで良い気もします。

最新の言語が云々、環境が云々と騒ぐやからがいますが、どんな言語（Javaとか）でも、10年前のバージョンが最新のハードやOSに乗るのかって言うと、なかなかそうは行きません。結局、変わらないんですよね。

前回：子会社との合併に伴うシステム統合　No21　現状の聞き取り
次回：子会社との合併に伴うシステム統合　No23　議事録の書き方

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

--- blog end —