« ソフトウェアテスト293の鉄則 | トップページ | 在庫は商品の集合が示す状態 »

2005/02/25

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

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

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

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

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

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

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

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

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

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

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

|

« ソフトウェアテスト293の鉄則 | トップページ | 在庫は商品の集合が示す状態 »

パソコン・インターネット」カテゴリの記事

プログラミング」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

コメント

最近私もホストの事考えてたんです。とは言っても、あきぴーさんとは全く反対のホスト万歳ってスタンスですけど。(今回の内容の範囲では)

ところで、あきぴーさんはトレンド技術の軽量コンポーネントとかDIとか否定的ですか?

世の中に存在理由の無いモノは無い。全てのモノに存在理由があると考えれば、思考の幅が広がるような気がします。(かなり上から目線)

私も数年前ならホストってなんやねん、今時 FORTRAN とか COBOL かよーって思ってたように思います。

投稿: ふくもと | 2005/03/01 09:54

ふくもとさん、コメントありがとうございます。
#お待ちしてました(^^)

上記記事は一気に書いたのですが、プロジェクト管理者よりもPGの視点から書いたように読めるので、ちょっと恥ずかしい所があります(^^;)

でも、ホストの存在理由はまだ納得していません。ホストの存在意義は、その優れた技術にあるのではなく、昔のビジネスがまだ続いているから、という理由にしか僕は思えないのです。
この辺りは、歴史的経緯もあるでしょうから経験談をお聞きしたいです。

投稿: あきぴー | 2005/03/01 22:54

>ホストの存在意義
ホストでしかやれない仕事ってイメージ出来ませんか?まだまだ沢山ありますけど。

・無限の階層を持つデータ構造の行展開
・大規模の在庫引き当て

ダウンサイジングなんて事が本当に全面的可能ならソフトウェアの完全リプレースでも何でもやると思うんです。
ただ実行時のパフォーマンスは極端に落ちるので、仕事が回らなくなります。夜間バッチが朝の始業に間に合わないとか。

過去資産の運用と言った面以外にも存在意義は沢山ありますよ。ただハードウェアの利益率が高すぎるのでソフト屋が面白く無いってのなら理解できます。

投稿: ふくもと | 2005/03/02 09:54

ふくもとさん、お返事ありがとうございます。
「無限の階層を持つデータ構造の行展開」のアルゴリズムは再帰SQLと似ているでしょうか?
あげられた2つの例は、うちなら、入出荷に伴う在庫引当とそれから生じる請求計算で使われているだろうな、と想像します。
#メインフレームは触れたこともないので全く知らないのです。
確かにオープンシステムでは性能が悪そうですが、それぐらいの理由だけでしょうか?
まだ、ホストの存在意義にしっくり来ていないのです。

投稿: あきぴー | 2005/03/05 09:33

性能要件で存在意義があるが納得いきませんか。
困りました。(^^;)

現実問題、これぐらいの理由の筈です。CPUからメモリから電源やI/Oにいたる全てが冗長になってる連続運用性も基本的には性能追求の結果で、それに代替出来るオープン系のシステムがまだまだ(もしかすると永遠に)無いだけでしょう。

COBOL のソースが沢山あるとか言っても UNIX 上でなんぼでも COBOL は動くので、Java で書き直すぐらいなら移植した方が早いはずですけど、そんなの誰も現実解として選択しません。

年間1兆円の利益を出す会社なら、製造工程はほぼロボットが休み無しに働いてくれます。受発注処理がボトルネックになってしまったらビジネスチャンスを逃してしまいますよね?

再帰SQLって勉強不足で知りませんけど、ホストで物理ファイル転がして・・・なんてやるような部品展開なんかはSQLなんかじゃ全く手に負えない筈です。(最高性能のホストのRDBでも)

とか言いながら私はシステム屋が専門職じゃ無いんで、今の会社に入って4,5年で得た知識にしか過ぎないんですけどね。

投稿: ふくもと | 2005/03/07 11:17

例えば「メインフレームは「滅び行く恐竜」にあらず」
http://www.ciojp.com/contents/?id=00001003;t=25
とか。
あと私のトラックバックにも落としましたが「メインフレームのすごさについて技術的に解説しよう」
http://www.itmedia.co.jp/enterprise/0208/26/op_01.html
とその続編とか。

説明としてはこれまでに上がったファクトとロジックで必要十分だと思うんですけどねぇ。
(私は上記Gartnerコラムでへぇボタン連打でした)

「しっくりこない」で説明を求められても、どういうロジックを出せばいいかわからないので;納得がいかない点をロジカルに説明してもらえれば、論理構造なり前提なりを指摘したり、新たなファクトを提供できると思うのですが。

ってか、「しっくりこない」レベルなら、メインフレームを知っている先輩に聞いてみては?(連携やるならいますよね)
あと実際に購入しているお客様に話してみるとか。お話の限りではインフラの仕事はされていないようなので、若手がそれとなく話題に出す分には恥ずかしいことではないと思いますし。

身近にいなければ、社内で ROI/ROA の視点から EAI を提案してるような部署に聞いてみるとかもありますね。

投稿: 市井賢児 | 2005/03/07 14:14

ふくもとさん、市井さん、詳細なコメントありがとうございます。私はメインフレームは全く知らないので、市井さんのリンクは非常に参考になります。
メインフレームの存在意義にしっくり来ないのは、バッチプログラム開発で随分苦労させられたことによる感情的な理由だけです。故に、深い意図はありません。

話はずれますが、大企業ではメインフレームやWebシステム、クラサバなどアーキテクチャが全く異なるシステムが並存して、大企業内で誰もシステムの全体像を理解していないように見えることに違和感があります。
毎年のように次から次へとサブシステムを作っていくと、収拾がつくのかな、と他人事のように感じています。そんなことを突き詰めて考えると、どうしてもメインフレームの存在意義にぶち当たる気がするのです。
整理しきれていませんが、別の機会に考えをまとめてみたいと思います。

投稿: あきぴー | 2005/03/07 21:34

ちょっとクローズしかけてるようなので、簡単に。
#個人的には Strike while the iron is hot が良いと思っています。

>アーキテクチャが全く異なるシステムが並存して
ここで、TCO が高まるってデメリットには誰もが必ず行き着きますよね?
だからこそ、ホストでしか出来ない仕事が世の中には事実として存在するって事を思考のパラメータに加える事が必要なんです。
(あきぴーさん側の見方で言えば必要悪だと思えば良い)

なので、DI の考え方と同様に異質なモノを繋ぐ為の Adaptor が必要で、それ(ホスト連携処理)を作るのは、当然の事となります。
勿論結合テストコストは高くつきますけど、DI でも同様ですよね。なんなら MockObject とかで代理させれば良いだけだし。

(感情的に)イランのちゃうの?って結論からスタートするんじゃ無くて、(実際に必要だから)存在してるって結論からスタートしたら、より心情的にも理解しやすいかも知れません。

システム屋が費用対効果の点以外ではホストを否定すべき理由は存在しないと思うんで、感情的な部分を排除すればあきぴーさんのお立場ならすぐに納得いかれると思いますよ。

#たぶん、ホスト側の事情を全然知らないんで、なんとなくお尻がこちょばい気がするだけでしょう。

投稿: ふくもと | 2005/03/08 10:05

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/3077416

この記事へのトラックバック一覧です: システム開発のボトルネックはメインフレームに有り:

» メインフレームについて話してみる [SE 市井賢児のメモ]
私はメインフレーマ系の SI 会社でパッケージ導入を経験し、外資コンサル系 SI に転職した身です。 そんな立場からなら一つの視点を提示できるかも、と「プログラ... [続きを読む]

受信: 2005/03/02 02:04

» 私は、「メインフレーマー」。 [ヒビコレカイゼン]
私はメインフレームで生産管理のシステムを10年作ってきました。 メインフレーマーです。 PC系も時々やりますが、主にメインフレームでやってます。 DBやファイル... [続きを読む]

受信: 2005/03/31 00:33

« ソフトウェアテスト293の鉄則 | トップページ | 在庫は商品の集合が示す状態 »