システム開発のボトルネックはメインフレームに有り

　システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？
　JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。

　どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。
　そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。
　しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？

　普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つまり、企業にとって死活的に重要なデータは、必ずメインフレーム内で管理している。
　いくらOOAをフルに使ったWebシステムを作ったとしても、Webシステムは、集めた受注データをホストへ送り、入出荷や請求のデータをホストからもらうだけ。業務的には、入り口のシステムに過ぎない。
　Webシステムがダウンするのは当然困るが、企業活動そのものが止まってしまうわけではない。

　僕がメインフレームを毛嫌いする理由は、OO技術者にとって、メインフレームがブラックボックスだから。メインフレームでデータをどのように加工し出力しているのか、全く意味不明だから。

　更に、ホストとのやり取りのために、無駄なインターフェイスが必要になる。
　例えば、受注データをリアルタイムにホストへ送信したり、月次請求や四半期決算のデータをホストから特定の日に受信する処理がある。
　仕組みとしては、ホストはバイト長データしか扱えないため、バッチプログラムがバイト長データを変換してRDBのワークテーブルに一旦保管し、Javaが扱うテーブルへ移し変える。そのプログラムは、典型的なCのプログラムで、オブジェクト指向以前の古い設計に基づく。しかもテストしにくい。

　オブジェクト指向をフルに使った設計やオープンソースのフレームワークを適用したオープン系システムを開発しようとしても、結局、メインフレームとの整合性を取るためのシステムテストがボトルネックになる。
　何しろ、受け入れテストに必要なシナリオやテストデータを洗い出し、実際の業務をシミュレーションするために、1週間とか1ヶ月も時間を費やす。オープン系システム内部で閉じたシステムなら、システムテストは楽なのに、ホストと連携するテストを行うために、無駄なコストがかかる。

　「メインフレームはオープンシステムに取って代われる」という記事を随分昔から見てきたけれど、未だに実現されているとは思えない。それらの記事は、単なるデマだったのだろうか？

【参考記事】「5年後，メインフレームはなくなる」　日経コンピュータ2003年3月24日号

　IT業界に入って、結局いつもぶち当たる壁は、ORマッピングとメインフレーム。
　それらを再考し直すと、結局、メインフレーム・RDB・オブジェクト指向プログラムの3つはどれも思想的に全く異なるシステムであって、それらのインターフェイスを合わせる為に、ORマッピングやバッチプログラムという無駄な中間レイヤーが必要になる。
　企業システムとは、結局、これら３つの相容れない混合システムであるべきものなのか？
　多分そうでないはず、と思うし、皆そう感じているのではなかろうか？

　メインフレームが今もなお存在する理由は、IBM・NEC・富士通・日立等のような大手ベンダーが過去あるいは今までメインフレームを製造し続けてきたからだろう。
　メインフレームというハードを中心にしたビジネスが長らく続き、そのビジネススタイルからなかなか脱皮できない所に原因がある気がする。