誤った判断は高くつく——日立メインフレーム撤退のいま考えたい、正しい選択とは

富士通に続き日立もメインフレーム事業からの撤退を発表し、長年ホストで基幹システムを動かしてきた企業では、「そろそろ自社も決断しなければ」という圧力が一気に高まっています。

ただしここで注意したいのは、「メインフレームがなくなるなら、とりあえずSAPなどの大規模パッケージに乗り換えよう」と、サポート終了だけを理由に急いで方向性を決めてしまうことです。

実際、富士通メインフレーム撤退のタイミングでも、私たちは複数の現場で、こうした“拙速な判断”による混乱を目にしてきました。
この記事では、正しい判断とはなにかを、実際の案件で見えてきたポイントとともに解説します。

富士通メインフレーム撤退で見えた「支援格差」と高くついた刷新

富士通のメインフレーム撤退時には、大手企業にはベンダーから出口戦略の提案や移行支援が入りましたが、地方の中堅・中小企業では状況が大きく異なりました。

• ベンダーから十分なサポートが受けられない
• 社内にもメインフレームやレガシーに詳しい人材がいない
• 「とにかく急いでメインフレームから脱出しなければ」という焦りだけが先行する

こうした中で、現行システムの中身や業務への影響を十分に確認しないまま、移行先や刷新方針を決めてしまうケースが少なくありませんでした。
その結果として、

• 想定外のカスタマイズが膨らみ、数十億円規模の追加投資が発生した
• パッケージ導入を進めたものの、必要な業務をカバーできず途中で断念した
• 途中から既存資産を活かす方向へと方針転換せざるを得なくなった

といった、問題が起きています。
今回の日立メインフレーム撤退でも、同じことが繰り返されるリスクがあるという点に注意が必要です。

「メインフレーム撤退＝パッケージ一択」という思い込みの危うさ

日立のメインフレーム撤退を受けて、多くの企業が真っ先に思い浮かべるのは、

• 「メインフレームがなくなるなら、もうSAPなどの大規模パッケージに移るしかない」
• 「大変だから、Fit to Standardで標準パッケージに業務を合わせよう」

といった選択肢ではないでしょうか。

もちろん、Fit to Standardという考え方自体は間違っていません。在庫の入出庫を記録するだけ、といった「どの会社もほぼ同じ」業務領域であれば、標準機能に合わせていくのは合理的です。問題は、そこに「自社固有の強みとなっている業務」まで一律に含めてしまうことです。

たとえば製造業であれば、

• 需要予測のロジック
• 生産計画の立て方
• 在庫調整や安全在庫の考え方

といった部分は、扱う製品や顧客、サプライチェーンの構造によって大きく異なります。ゴム製品を扱うメーカー、食品容器を作るメーカー、鉄鋼関連のメーカー——いずれも「需要予測」「生産計画」という言葉は同じでも、実際の考え方やアルゴリズムはまったく違うはずです。

ここを一律に「パッケージの標準機能に合わせる」ことは、自社が長年培ってきたノウハウや強みを、わざわざ捨てにいくようなものになりかねません。

さらに、パッケージ刷新プロジェクトで怖いのは、「あとから気づく“この機能がない”」という事態です。導入がかなり進んだタイミングで、「あれ、この業務を支える機能がパッケージにない」と気づき、そこで初めて、

• 大規模なカスタマイズが必要になる
• 追加で数億〜数十億の投資が必要になる
• そもそもパッケージでは表現できない業務だった

といった問題が表面化します。これが、プロジェクト開始から1〜2年経った後にわかるケースも珍しくありません。すでに数十億投資してしまっている中で、「やっぱりやめよう」とはなかなか言えないのが現実です。

富士通メインフレーム撤退に伴ういくつかの刷新案件でも、この「あとから気づく機能不足」「想定外のカスタマイズ問題」によって、計画の見直しや方向転換を余儀なくされた事例が多く存在します。

メインフレーム撤退をきっかけにシステム刷新を考える際には、「パッケージ一択」「Fit to Standard一択」と短絡的に決めてしまうのではなく、自社の強みとなっている業務をどう扱うか、パッケージで本当に表現しきれるのかを、慎重に見極めることが不可欠です。

現行システムを“見える化”してから正しい刷新方針を決める

システム刷新の検討で、特に意識すべきポイントは次の2点です。

「何のために刷新するのか」をはっきりさせる

サポート切れは、刷新を考える“きっかけ”にはなりますが、目的ではありません。

• 現場は、今のシステムにどんな不満・課題を感じているのか
• 経営として、これからどんな業務変革・DXを実現したいのか
• そのために、ITシステムにどんな役割を期待するのか

ここを言語化せずに、
「古いから新しくしなきゃいけない」
「みんなSAPにしているから」
といった理由だけで刷新を始めると、非常に危険です。

ある半導体メーカーでは、SAP刷新プロジェクトが立ち上がった際に、
CIO経験のある方が現場ヒアリングを行いました。
「今のシステムで何が問題ですか？」
と聞いて回ったところ、どの部門からも返ってきた答えは、
「機能面では特に不満はない。古いだけです」
というものだったそうです。

結果としてその企業は、フルリプレースではなく、必要な部分だけのリメイク・部分再構築に切り替え、
数億円規模で実現できる道を選びました。
もしそのままSAP刷新を進めていれば、数十億〜百億単位の投資になっていた可能性もあります。

現行システムの「仕様」をきちんと把握する

もうひとつ重要なのが、
どの刷新方法を選ぶにせよ、現行システムの機能・仕様をきちんと洗い出しておくことです。

• パッケージ刷新
• 新規スクラッチ開発
• クラウド移行
• レガシー資産のマイグレーション・リホスト

どの道を選ぶにしても、

• 今どんな業務が、どの画面・どのバッチ・どの帳票で実現されているのか
• どの機能が「標準で代替可能」で、どの機能が「自社固有の強み」に関わるのか

を把握しておかなければ、正しい見積もりも、正しい方式選定もできません。
これは、私たちがこれまで多くのレガシー刷新・マイグレーションで痛感してきたポイントです。

日立メインフレーム撤退は、「正しい刷新」を考え直すチャンス

日立メインフレーム撤退は、「正しい刷新」を考え直すチャンスです。

サポート終了や老朽化はたしかに危機ですが、同時に、

• 自社の業務やシステムを棚卸しする
• 「どこが自社の強みで、どこは標準化してよいか」を見直す

ための絶好のタイミングでもあります。

特に、現行システムの中身がブラックボックス化している会社ほど、
仕様を「見える化」（仕様解析する）価値は大きくなります。

そのうえで大事なのは、次の2ステップです。

• 「なぜ刷新するのか」という目的をはっきりさせる
• 「今のシステムで何ができているのか」という仕様をきちんと整理する

この二つを土台にして、どのような刷新方法が最適かを一緒に考えていく──
そのプロセスこそが、今回のメインフレーム撤退を「ピンチ」ではなく「チャンス」に変える鍵になります。