いつまでたってもメインフレーム・汎用機が無くならない理由とは

業務系の開発ではオープン系（WEB系含む）と汎用機系に分かれます。汎用機とは大型コンピュータのことで、一般的にはCOBOLやRPGなどの言語で動作しています。

汎用機からオープン系へのマイグレーションは徐々に進みつつあるのですが、まだまだ汎用機系の案件は根強く残っています。なぜいつまでたってもメインフレーム・汎用機が無くならないのかについて、ご説明していきたいと思います。

コストがかかる

まず汎用機からオープン系システムにマイグレーションするにも、当たり前のことですが移行のためにSE費用が発生します。既存システムの再構築になりますので、決して安い金額では収まりません。

機能改善のためにコストをかけるなら納得もできますが、汎用機からオープン系という、環境が変わるだけのためにIT予算を投入するのは、よほどの理由が無い限り、前向きにはなれないものです。

もちろんオープン化によって、IBMなど特定のメーカーに依存しなくて済むようになったり、クラサバ形の環境で処理分散ができたりと、いくつかのメリットはあります。ただしそれらのメリットと、マイグレーションにかかるコストを天秤にかけると、どうしても現状維持という答えに至ってしまうのでしょう。

安定稼動を優先

わざわざマイグレーションして不具合でも起きたら大変ですので、現状の汎用機で問題なく運用が行われており、安定稼動しているのなら、現状維持でいっか・・とつい考えてしまうことも、いまだにメインフレームや汎用機が残っている理由の一つです。

情報システム部門などがあれば、担当者はマイグレーションによって仕事量も増えてしまいますし、近い将来どうにかしなければならないことの予測はついていたとしても、問題を先送りにしてしまうものです。

システムの保守や運用においては、”安定稼動”という言葉ほど素晴らしいものはありません。いつかはオープン化に対応しないと・・と思っていても、安定稼動を優先しがちになってしまいます。

設計書を信頼できない

オープン系にマイグレーションしたくても、躊躇している原因で一番よくあるのは、設計書を信頼できていないという問題。

通常システムというのは、実装されているプログラムと設計書はイコールになるものです。設計書に記載の仕様が実装されている状態で、過不足があってはいけません。

しかし現実には実装されているプログラムと設計書の内容が異なる事例が発生します。きっと導入当初はイコールだったはずですが、バグ対応や機能追加などでバージョンアップを繰り返していくうちに、設計書への反映漏れのために設計書に記載のない機能が実装されていたり、それとは逆に、設計書に記載の機能が実装されていなかったりするのが現状です。

それでいて安定稼動しているのであれば、一体何を信頼すればよいのかと言うと、設計書ではなく実際に動いているプログラムとなります。

そうなると設計書を確認して、オープン環境での仕様を構築していく作業が、いちいち現状のプログラミングを解析していかないといけないため、非常に手間がかかってしまいます。決してできないことはないでしょうが、その分コストも高くなってしまいますし、SEのモチベーションもあがりません。結局「現状動いているなら、今のままでいっか」という思考に陥ってしまいます。

 

おわりに

COBOLやRPGといった言語を扱える技術者も、どんどん年齢が高くなっています。汎用機系の言語を扱えるとなると、40代でも若いなと感じるぐらいです。

そうした汎用機系エンジニアの高齢化という問題を考えると、早いうちに汎用機からオープン系へ移行するのが得策だと思います。しかしそれを阻む要因として、今回挙げたようなことがあるのです。ですが問題を先送りばかりしていると、いつの日か痛い目を見ることになるかもしれませんね。