メインフレームで実施していた業務の独自性が強く、移行プロジェクトが中止に――。約30年にわたってメインフレームのシステムをオープン系ハードウエアに移行する作業に携わってきた筆者は、こうした事例をよく見聞きしてきた。独自性の強い業務はメインフレームシステムが塩漬けになる理由の1つだ。

 例えば、ある製造業で現場が悲鳴を上げているエピソードがあった。その企業では、プログラムロジックをそのままに言語だけを置き換える「リライト」の手法を用いてメインフレームのアプリケーションを移行しようとした。COBOLからJavaへソースコードを変換したところ、浮動小数点演算の部分で、旧システムと新システムとで計算結果に誤差が生じた。

 この誤差が業務上許容できるものかできないものか、移行作業を担当した者には判断がつかなかった。長年、先輩社員がプログラムロジックに反映させてきた業務ノウハウを継承できていなかったからだ。このことが理由で、移行プロジェクトは中止に追い込まれた。

 移行プロジェクトの中止まではいかなくても、独自業務がネックでプロジェクトが難航することもある。最近、筆者が聞いた話はこうだ。ある金融機関では、メインフレームの撤廃を経営トップが高らかに宣言した。5年以内に現在稼働中のメインフレームは稼働を停止する予定である。経営トップの宣言では、ハードだけではなくアプリケーションも書き換える「リビルド」の予定だ。しかし、移行プロジェクトの現場では「リビルドは無理だ」とあきらめムードが漂っている。

 現場の担当者がリビルドについて無理だと感じている理由は、独自の業務が複雑すぎるため。同じ業務のアプリケーションを作り直そうとすれば、予算もスケジュールも超過してしまうと考えたからだ。リビルドはあきらめ、プログラムをそのままオープン系ハードに移植する「リホスト」や、リライトに切り替えるべきだと、現場では考え始めた。

 しかし、この現場の判断はまだ経営トップの承認を得ていない。業務改革につなげるというシステム再構築の趣旨からすると、プログラムのロジックをそのままにするリライトやリホストは、経営トップから却下される可能性が高いからだ。そのため、刷新期日の間際になってから「どうしても再構築(リビルド)では間に合いません」と経営トップに訴え、無理やりリライトかリホストの了承を取り付けよう――。現場ではこんなシナリオを描いているようだ。

職人技をアプリに実装し過ぎた

 業務の独自性が問題でメインフレームが塩漬けになってしまうのには、日本特有の歴史的な経緯が関係している。

 日本のコンピュータ導入の黎明期では、当時の通商産業省が国内のコンピュータメーカーを育成するため、国産メインフレームの利用を奨励してきた。国から後押しされた結果、ユーザー企業とITベンダーの双方が貪欲にあらゆる業務処理をコンピュータに取り込んだ。例えば製造業では、部品の需要予測、生産工程で温度、湿度など多くのパラメータを基にした判断処理など、その業務の専門家の職人技と言えるほどのノウハウをアプリケーションロジックに実装した。

この先は会員の登録が必要です。今なら有料会員(月額プラン)登録で6月末まで無料!