クラウド時代でも廃れないメインフレーム モダナイズの現実的な選択肢を探る

メインフレームのシステムを刷新する「モダナイズ」の動きも活発になっている。しかし、一度にモダナイズすることはリスクが大きい。メインフレームのベテラン技術者に、現実的なモダナイズの選択肢を聞いた。

[指田昌夫，キーマンズネット]

　多くの企業で最新のIT技術を用いたデジタル武装が進められている。だがその一方で、長年にわたって業務を支えてきた情報システムは、汎用コンピュータ（以下、メインフレーム）の中にとどまり、粛々と改善が加えられて今日に至っている。メインフレームは専用のアプリケーションプログラムとデータベースの中で完結した業務プロセスを実行するコンピュータで、今でも1980〜1990年代にCOBOL、PL/Iなどのプログラミング言語で書かれたシステムが稼働している企業は多い。

　メインフレームはすでに技術的に「枯れた」システムといわれることもある。実際に、安定性が高く、運用コストも落ち着いているのだが、専門技術者の高齢化やクラウド、オープン化の浸透によって、メインフレームのシステムを刷新する「モダナイズ」の動きも活発になっている。

　とはいえ、現在メインフレームで動いている基幹システムを、一度にモダナイズすることはリスクが大きい。メインフレームのベテラン技術者に、現実的なモダナイズの選択肢を聞いた。

メインフレームのモダナイズは甘くない

　数々の企業のモダナイズを支援してきた日本情報通信の小山将輝氏（エンタープライズ第二事業本部ビジネス開発部　部長）は、企業がモダナイズを考える際、幾つかの過小評価があり、実際の移行作業の重さに気づいてがくぜんとするケースが多いと話す。

　「企業からメインフレームのモダナイズについて、最初にお問い合わせをいただく内容として多いのが、システムを丸ごとサポートが受けられる別のメインフレームに移したい、あるいは、メインフレーム内のCOBOLなどで書かれたプログラムを、全てJavaに書き換えたいという要望です。しかし、見積もりを取ってみると、メインフレームに蓄積されているプログラムとデータの総量は非常に大きいことが分かり、作業工数（コスト）が膨大になることから断念するケースがほとんどです」

　まるっと移行する計画を立て、軽い気持ちで見積もりを取ってみたら、「○億円です」といわれてぎょっとするような話は、メインフレームを使う企業ではよくある話なのだという。

　仮にJavaへの移行をスタートしたとしても、途中で頓挫するおそれもある。システムを丸ごとJavaベースに移行するに当たり、自動化するツールも出回っているが、完全に移行することは難しい。

　「仮に98％コンバージョンが成功して、問題なかったとしても、残り2％が引っ掛かった場合、そこを手作業でプログラミングするだけでも、数十年の蓄積は膨大なコードの量になります。そして、新たに書いたコードがシステムにどんな影響を与えるかの調査を実施し、実装の判断をするためには数多くのテストをしなければいけません。その負担は計り知れないものがあります」（小山氏）

　しかも、一般的にコンバージョンは付加価値を生まない。その作業に、巨額のコストを見込める企業は多くない。同社の中垣将樹氏（エンタープライズ第二事業本部ビジネス開発部　担当部長）は、「メインフレームメーカーは、将来的にサポートが終わるというアナウンスを十数年前からしてきていました。しかし、まだ使えているという企業側の危機感の薄さが、モダナイズの検討を遅らせてきた一因です」と話す。

多くのメインフレームメーカーが撤退

　「メインフレームは今のところ、問題なく動いているのなら、そこではなく他に投資したほうがいいのでは」と考える企業が多かったため、今日の事態を招いている。

　しかし、「塩漬け」ともいわれる先延ばしは、そろそろ限界に近づいている。日本でメインフレームを手掛けていたメーカー6社の多くが撤退し、富士通は2030年で事業から撤退すると発表した。また日立製作所はIBMからのOEMで製品を提供していたが、その事業も終了している。今後も日本市場でメインフレームのサポートを継続すると表明しているのは、事実上IBMのみとなっている。

　この状況下で、企業はメインフレームが蓄積した膨大な資産をどう運用、管理していくのかを考えなければいけない。

　メインフレームのモダナイズに際して、先ほど説明した「丸ごと移行、丸ごとコードの書き換え」ができなかった場合、次の選択肢として挙がるテーマが「ERPへの移行」だ。

　「メインフレームで動く基幹システムには、その企業が長年培った業務プロセスが凝縮されています。それをERPで実現するためには、大量のアドオンが必要になり、膨大なコストがかかります」と中垣氏は話す。

　小山氏も続ける。「『業務を変えてERPに合わせる』というトップによる明確な方針が出れば、ERP移行はうまくいくと思います。しかしそれがない場合、いわゆるフィット＆ギャップのギャップへの対応が混乱を招き、プロジェクトがうまく進まないケースが非常に多く見られます」

メインフレームの長所を残してDXを実現する「第三の道」

　塩漬けにしてきたメインフレームのモダナイズに当たり、「丸ごと移行、丸ごと変換」、そして「ERPへの移行」のどちらにも難しい企業にとっての「第3の選択肢」があると、小山氏は話す。同社が「スライスアウトモデル」と呼ぶ段階的、部分的な基幹システムの移行である。

　企業の業務には、常に最新の技術を導入して競争力の源泉にすべきプロセスと、過去もこれからも、長期にわたって新たな機能の追加を考えなくてもよいプロセスがある。メインフレームが受け持つのは、後者のプロセスであり、そこで安定性が高く保守が楽なメインフレームのメリットが生かされる。つまり新しい、古いではなく、業務の特性に合わせたシステムを採用するのが最も合理的ということだ。

　スライスアウトモデルは、その名の通りメインフレームから少しずつ機能を外に削り出していく移行モデルだ。そのため、1回で完了ではなく、3回、4回と繰り返す必要がある。そうすることで、前段で説明した丸ごと変換や、ERP移行の問題を回避し、段階的に移行を進め、最終的にモダナイズを完了させられる。

　スライスアウトモデルの具体的なアプローチを、中垣氏は次のように説明する。

　「基幹システムの中で、例えば今後10年にわたって新たな機能追加が発生しないと思われるものは、そのままメインフレームで動かすことを前提にします。逆に、消費者とのインタフェース、EC（オンライン通販）のシステム、データ分析、AIなど技術の進化が速く、頻繁に開発が必要な領域は、メインフレームの外に取り出して、データだけを接続できる仕組みを作る方針を立てます。それが決まれば、あとはスライスアウトを実行するだけです」

「メインフレームは古い」という固定概念を捨てるべき

　このように、企業にとって最も重要なのは、自社にとって何をメインフレームに残し、どこを切り出すかという判断だ。小山氏は、企業のIT部門は、メインフレームに対する誤解や偏見をなくし、フラットな視点でシステムを捉えるべきだと話す。

　「メインフレームは、基本的にどんな業務システムでも作ることができます。しかし、AIやデータ分析などは最新のSaaSなどに任せるほうが使いやすく、コストもかかりません。そのため、メインフレームには古くから業務の根幹を担ってきたデータの処理を担うことが多く、相対的に『メインフレームは古い技術』というイメージが固定化されています」

　こうしたイメージから、IT部門の部員の間に、メインフレームとそれ以外のスキルセットの溝が生じていると、小山氏は指摘する。

　「特にある程度歴史がある大企業のIT部門の場合、内部はネットワークおよびインフラのチーム、COBOLなどを使うメインフレームチーム、そしてJavaを中心に扱う新しいアプリケーションのチームに3分割される傾向があります。このうち、メインフレームチームとJavaチームの間の情報共有はほとんどなく、別物として扱われていることが問題です」（小山氏）

　スライスアウトモデルを成功させるため、IT部門は、古い技術も新しい技術も理解した上で、全体最適の方策を検討し、その結果を経営層に進言しなければいけない。そのために、Javaチームもメインフレームチームも、それぞれの技術を学び合う場を持つことが必要ではないかと、小山氏は提起する。

「自分たちのRFP」を作ることがモダナイズの必須要素

　ビジネス戦略と、それに基づいたIT戦略、システムの未来図を描く際、自社のリソースだけで足りない場合もある。外部のコンサルティング企業を利用するケースも多いはずだ。ただ、その際には気を付けることがあると小山氏は指摘する。

　「コンサル会社などの外部の力を借りることもいいと思いますが、それが実効性を伴わない“絵に描いた餅”にならないよう、注意が必要です。コンサル会社が作るIT戦略はRFP（提案依頼書）の形になりますが、RFPを丸投げで作らせてはいけません。その中身はあくまで、お客さま企業が実行できるものとして納得したものでなければ、モダナイズは絶対に成功しません」

　基幹システムのモダナイズという重要テーマだけに、外部コンサル会社との関係にもいっそうの慎重さが求められる。

　いったん、実行可能なシステムの未来図ができ上がれば、モダナイズを得意とする専門のITベンダーと協議しながら、スライスアウトの領域を決めていけばいい。

　前段でERPへの移行には課題が多いと書いたが、スライスアウトモデルの考え方を使えば、ERPが担える部分はERPに移行し、難しいプロセスだけをメインフレーム側に残して、両者の接続を取ることもできる。このような一見複雑なモダナイズの方法も、最初にシステム全体を把握しておくことで、柔軟に対応できるのがスライスアウトモデルの特徴だ。

　さらに、単にシステムを部分的に移行するだけでなく、従来よりもIT部門の競争力を高める「攻め」の要素を盛り込むことも可能だ。

　「基幹システムから外に出す領域では、ノーコードツールを導入して開発を内製化し、開発のスピードアップとコスト削減を図りたいと考えるお客さまも多くなっています」（中垣氏）

　長年の業務プロセスが詰め込まれたメインフレームのモダナイズは、一気に進めようとしても無理がある。だからこそ残せるものは当面残し、段階的に進めるアプローチは有力な選択肢になる。ただし、メインフレームの市場はこれからも縮小すると考えられるため、手を付けるのは早いほうがいい。まずは自社のシステムを棚卸しし、その未来図を描くことから始めるべきだ。