富士通メインフレーム刷新の最適タイミングは？｜2035年から逆算した刷新開始時期と判断基準

クラウドやデータの利活用、AI技術の急速な進化などにより企業を取り巻くIT環境は、この数年で大きく変化しています。基幹システムも例外ではありません。長年企業の中核を支えてきた富士通メインフレームについても、大きな転換点が訪れています。「メインフレームの保守を2035年度末で終了する」というものです。

この期限だけを見れば、「まだ時間はある」と感じるかもしれません。実際、現在も安定稼働していれば、刷新を急ぐ理由は見当たらないでしょう。しかし、すでに情報収集や初期検討を始める企業も出てきています。彼らは決して「今すぐ移行する」と決断しているわけではありません。それでも動き始めているのはなぜでしょうか。

本ブログでは、2035年までの公式スケジュールをあらためて整理し、"まだ先"と考えることのリスクや、「いつ・どの観点で検討を始めるべきか」といった判断軸を紹介します。

まずは、富士通メインフレームを取り巻く公式なスケジュールを整理しておきましょう。

富士通は、メインフレーム（GS21シリーズ）および関連サーバーについて、2030年度末で販売・製造を終了すると発表しています。そして、2035年度末には保守・サポートを終了する予定です。あわせて、Fujitsu Cloud Service for Mainframeや関連データセンターサービスも同時期に終了となります※1。

業務に支障をきたさず刷新するには、上記のタイムラインを意識しなければなりません。

なお、刷新プロジェクトを進めるには一定の期間が必要です。一般的には、下記程度の期間が想定されます。

実際にかかる期間はシステム規模や選択する方式などによって大きく異なってきますが、工程を積み上げていくと、移行完了までに複数年を要するケースは珍しくありません。

2035年度末という期限は、一見すると遠い将来の話に思えますが、検討・準備・実行の各フェーズを逆算すると、決して余裕があるわけではないことがわかります。

さらに刷新判断が期限直前になると、十分な対応ができない可能性があります。今すぐ刷新判断をすることはできなくても、「いつどの観点で進めるか」といった検討は、早急に始める必要があるでしょう。

※1 出典：富士通『 富士通メインフレームに関する約束 』

「まだ10年の猶予がある」と静観している企業がある一方、すでに情報収集や初期検討を始めていう企業もあります。後者はなぜ動き出しているのでしょうか、主な理由を見てみましょう。

前述の通り、移行完了から逆算すると準備に使える時間は限られています。2030年度末の販売終了、2035年度末の保守終了という期限が近づくにつれ、「そろそろ動かなければ」と検討を始める企業が増えています。

また、長年メインフレームを担当してきた技術担当の定年退職や異動が見えてきたことをきっかけに、「いまの体制でいつまで対応できるのか」と考え始める企業も少なくありません。

将来的に移行需要が集中した場合、ITベンダーのキャパシティが逼迫し、コストが上昇する可能性があります。「需要が集中する前に状況を把握しておきたい」という観点から、早めに動き出すケースも考えられます。

これらの課題を認識している企業は、移行の最終決断にまでは至らなくても、まず現状を把握し、どのような選択肢があり得るかを整理する、いわば"判断の準備"を始めています。

2035年問題を「移行の話」として捉えるか、「準備の話」として捉えるか。その違いが、検討開始のタイミングを分けていると言えるでしょう。

前章では、企業が検討を始めるきっかけとして、有識者の退職やベンダーのキャパシティ懸念などを挙げました。しかしこれらは表面的なきっかけに過ぎません。多くの企業が2035年のサービス終了を理解しながらも、なかなか動き出せない背景には、以下の構造的な課題が存在しています。ここでは、2035年のメインフレーム問題に関する3つの構造的な課題をみていきます。

メインフレームを取り巻く環境が複雑化するほど、将来の移行は難しくなります。

近年、DXやAI活用の進展により、メインフレームは単独で完結する基幹システムではなく、外部サービスやクラウド基盤、各種APIと連携する"ハブ"としての役割を担うケースが増えています。

連携が増えること自体は価値の創出につながりますが、その一方で依存関係は複雑になります。すでに「小さな改修でも影響調査に時間を要する」状態にある場合、連携がさらに拡大すれば、移行時の調査範囲や検証範囲も広がることが予想されます。

その結果、テスト工数が膨らんだり移行コストや期間が増加したりすることや、想定外の依存関係が後から判明するなどといった事態につながります。

今は安定していても、環境が複雑化するほど、移行時の負荷は確実に増していきます。

メインフレーム刷新の難易度を押し上げる大きな要因は、技術そのものよりも"人"にあります。

長年安定運用されてきた環境では、業務ロジックや例外処理、運用上の工夫が特定の担当者の経験や暗黙知に依存しているケースが少なくありません。設計書が存在していても、実装との乖離がある場合や、実運用のノウハウが文書化されていない場合もあります。

こうした状況で有識者の退職や異動が進むと、仕様の確認だけで想定以上の時間を要したり、移行要件の整理が難航したりするリスクが高まります。

このように問題は人材不足にとどまりません。「知識がどこにあるのかわからない」という状態そのものが、移行の難易度を根本から高めてしまいます。

2035年が近づくにつれて、上記で挙げたように移行需要が集中する可能性があります。

しかしCOBOLやメインフレームに精通した技術者の高齢化はかねてから指摘されており、市場全体での供給は減少傾向にあります。若手人材が参画しにくい技術領域であることも、供給減に拍車をかけています。

需要が高まる一方で供給が限られれば、外部リソースの確保が難しくなるだけでなく、移行プロジェクトの開始が後ろ倒しになったり、想定より高いコストでの実施を余儀なくされたりするリスクもあります。

上記の課題は、企業によって深刻度が異なるため、「自社はまだ大丈夫なのか、それとも今すぐ動くべきなのか」という判断に迷ってしまうこともあるでしょう。

そこで、メインフレーム刷新への着手タイミングを見極めるための判断軸を3つご紹介します。まずは自社の現状を振り返りながら、それぞれの軸でどの程度のリスクを抱えているかを確認してみてください。

メインフレームと外部システムの連携が増えるほど、移行時の影響範囲は想像以上に広がります。特に次のような状況が見られる場合、移行難易度はすでに高まっていると考えてよいでしょう。

特に「影響調査に数週間以上かかる」状態は、現時点でもすでに相当の複雑性を抱えているサインです。連携がさらに拡大すれば、移行コストは加速度的に増大します。

人材リスクは、発生してから対処しようとしても手遅れになりやすい領域です。特にシステムを支える中心メンバーの定年退職のタイミングは、メインフレームからの移行完了を考える1つの目安と言えます。次のような状況であれば、手を打つ必要があります。

「まだ誰も辞めていない」という現状は安心材料にはなりません。退職が決まってから動き出しても、仕様の確認と整理だけで数か月を要するケースは珍しくないためです。

ITベンダー側の状況は、自社だけでは把握しにくい領域です。同業他社やベンダーとの情報交換を通じて、継続的にリソース状況を確認することを推奨します。以下のような兆候があれば、市場のひっ迫はすでに始まっています。

市場の人的リソースの状況を体系的に確認するのは困難ですが、いざリソース不足に気付いた時には、プロジェクト開始までに数か月から半年待ち、場合によっては1年以上待つ可能性があることを念頭に置く必要があります。

上記3つの中で1つでも該当する軸があれば、現状の把握を始めるサインと考えてよいでしょう。移行するかどうかはその後の話です。まず「自社がどういう状態にあるか」を知ることが、メインフレーム刷新を判断する第一歩となります。