2005年03月02日

メインフレームについて話してみる

私はメインフレーマ系の SI 会社でパッケージ導入を経験し、外資コンサル系 SI に転職した身です。
そんな立場からなら一つの視点を提示できるかも、と「プログラマの思索」より「システム開発のボトルネックはメインフレームに有り」のトラックバックです。

前の会社では、自社製メインフレームからのリプレースもやりました。
メインフレームの頃からお付き合い頂いていたお客様で、ハード的な老朽化やビジネス上の要求の変化から、 Windows ベースのシステムに切り替える、なんて案件もありました。

実際にお客様のビジネスを支える、という視点に立つと、既に充分な稼動実績のある、エンジニアが使う言葉で言えば「枯れた」システムに手を入れるのは大きなリスクが伴います。

確かに「開発」という作業から見ればメインフレームやオフコンはオープン系の技術との親和性が低く、連携が絡むと足を引っ張られる、邪魔くさい存在ですが、ビジネスプロセスをどう設計するかという視点からすれば、大きな意義のある存在です。

だって今、ゲンバで実際に役立っているんですから。
システムはそれがすべてでしょう?

さらに会計や人事給与なんかは商法、証券取引法、税法などの法律や各種社会福祉制度などで業務自体がガチガチに固められているので、既にあるメインフレーム上の仕組みを置き換える理由がなかなか出てきません。
例え連携で開発コストが増えたとしても、会計の仕組み自体を作り変えるよりはずっと安上がりですし、安心です。

それに業務アプリを作るソフトウェアエンジニアは見逃しがちですが、メインフレームで使われている技術ってスゴいですよ。
トラブルがあっても基本的に一社がすべて取り仕切るので、OSのバグやミドルウェアの不具合まで含めてサポートされるというメリットもあります。「それは Sun に、これは Oracle に」なんてことは絶対ありません。
どこのメーカーもある種の威信をかけてサポートしますからね。


メインフレーム自体は技術者の減少と共に徐々に減っていくだろうとは思いますが、なかなか無くならないでしょう。

私としてはメインフレームの問題は、むしろ保守体制が生むベンダーとの関係にあると思います。
どうしてもメーカーに頼りきってしまう。
確かにサポートは厚いけれど、それに見合う金額は支払わなければならないし、徐々にベンダーをコントロールする能力を失ってしまい、お客様が自分のシステムに対して主体性を持てなくなってしまう。

レガシーマイグレーションなんて言葉も流行りですが、単純にオープン系に置き換えるだけでは「マイグレーション」は不完全で、ベンダー依存の体質からの脱却が伴わなければ、またベンダーからいいように甘い蜜を吸われてしまうんじゃないでしょうか。
posted by 市井賢児 at 2005年03月02日 02:04
| Comment(0) | TrackBack(0) | プログラミング


この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのTrackBack URL

×

この広告は1年以上新しい記事の投稿がないブログに表示されております。