メインフレーム脱却、なぜ「2027年が締め切り」に？ ベンダー撤退より先に来る“人の期限”：2035年へのレガシーモダナイゼーション実務論（2）（1/2 ページ）

国産メインフレームの撤退表明が相次ぐ中だが、「まだ時間がある」と考えている企業もあるかもしれない。しかしシステム移行に必要な期間を逆算すると、判断を先送りできる時間は限られている。

[中野恭秀（アクセンチュア）, 編集：遠藤文康，＠IT]

　「メインフレームの保守が終わる2035年まで、まだ8年ある」。そう考えている担当者は多い。だが工程を逆算すると、システムの移行に着手するかどうかを判断できる時間はずっと短い。しかも、その保守が終わるという技術的な期限より先に迫る、別の期限がある。第2回は残り時間の測り方を解説する。

この連載「AIに任せる、人が決める──2035年へのレガシーモダナイゼーション実務論」について

　レガシーシステムの刷新は先送りできない課題になっている。一方、AIによってシステムの解析やコード変換は大幅に速くなりつつあるが、移行方針の選択や仕様の判断など、人が決めなければならない仕事は残る。

　本連載では、2035年までのレガシーモダナイゼーションを見据え、「AIに何を任せ、人は何を決めるのか」という視点から、アセスメント、仕様復元、移行、テスト、保守までの実務と判断軸を全20回で解説する。

期限は、1つではなく3つある

　国産メインフレームの終わりは、もう具体的に日程が決まる段階になっている。

　日立製作所は2026年5月、メインフレーム向けOS「VOS3」の販売を2027年11月で、保守を2034年12月で終えると公表した。富士通は2030年度に製造・販売を終え、2035年度で保守を終える方針を公表している。BIPROGY（旧日本ユニシス）も販売・保守を終了する方針であることが、2026年7月に報じられた。これで、国内でメインフレーム事業を継続するのは日本IBMとNECの2社になる。

　ただしBIPROGYは、終了の時期をまだ示していない。日程がない分、いつ動き出すかの基準を自分で決めるしかない。

　この数字だけを見ると、まだ余裕があるように思える。2034年も2035年も、8年から9年先の話だ。実際、筆者が訪問する企業でも「2030年を過ぎてから考えます」という反応は珍しくない。

　そもそも「保守終了」とは何が終わるのか、を確認しておきたい。その日にシステムが止まるわけではない。終わるのは、ハードウェアが壊れたときの部品供給と、OSの修正提供と、問い合わせの窓口である。

　動くには動く。ただし、障害が起きたときに直せない状態になる。基幹システムでそれを許容できるかどうかは、技術の問題ではなく経営の問題だ。監督官庁の検査や内部監査に、どう説明するのかという話にもなる。

　なお、全てのベンダーが同じ日程で動いているわけではない。継続を表明しているところもある。まずは自社が使っている機種の日程を正確に押さえるところから始めることになる。

　だが期限は1つではない。ベンダーが定めた保守終了は一番外側の壁に過ぎない。その内側に工程から逆算した「着手の期限」がある。これはあまり語られないのだが、さらにその内側に「人の期限」がある。この3つを分けて考えなければ、残り時間を測り間違える。

逆算すると、判断の期限は手前にある

　移行プロジェクトの工程を順番に並べてみる。

　まず意思決定と調達だ。方針を固め、予算を通し、パートナーを選ぶ。ここだけで1年から2年かかる。次にアセスメント。資産を棚卸しし、方式を決め、計画を作る。ここに半年から1年費やす。そこから設計、変換、テストが続き、規模によるが3年から5年。最後に新旧を同時に動かし結果を突き合わせる並行稼働と切り替えで、半年から1年かかる。

　意思決定と調達に1年から2年、というのは長過ぎるように見えるかもしれない。だが実際には、方式を比較する調査に半年、その結果を持って経営に諮り、次年度の予算に計上するのにさらに数カ月かかることが多い。予算が通ってから調達手続きに入り、提案を受けて評価し、契約する。年度という単位で動く以上、途中で1年待ちが発生することも珍しくない。ここを短く見積もった計画は、たいてい最初の1年で狂う。

　並行稼働も、軽く見られやすい工程だ。月次だけでなく年次の処理まで確認しようとすれば、それだけで1年を要する。決算期をまたぐ必要があるからだ。ここを削れば、切り替えの後に見つかる問題が増えるだけになる。この期間に実際に何が起きるのかは、第14回で書く予定だ。

　合わせると、短くて5年、長ければ9年になる。

　保守終了の日から逆算すると、着手すべき時期が分かる（図1）。日立製作所の保守終了である2034年12月を終点にして、5年で収まるなら動き出しは2029年。9年かかるなら2025年の12月、つまりすでに動き出していなければならなかった。

図1　保守終了から逆算した、移行の着手時期（提供：アクセンチュア）

　ここで気を付けたいのは、9年というのが特別に段取りの悪い会社の話ではないことだ。銀行の預金や為替、融資といった中核業務を担う勘定系システムや保険の契約管理のように、業務を止められず、外部との接続が多く、監査の目も厳しいシステムでは、このぐらい長くなることは珍しくない。むしろ5年で収まる方が、条件に恵まれている。

　「まだ8年ある」と「もう時間がない」。同じ2026年の景色でも、どちらに見えるかは自社のシステムの規模と難しさで決まる。

もっと早く来る期限がある

　筆者がより深刻だと考えているのは、別の期限の方だ。

　1985年に稼働を始めたシステムを考えてみる。開発当時に25歳から30歳だった人は、2026年のいま66歳から71歳になっている。2025年4月から希望者全員が65歳まで雇用されることになったが、それでも65歳を超えている。多くはもう社内にいない。

　1990年前後の改修に関わった人でも61歳から66歳。1995年前後なら56歳から61歳で、定年が視野に入る年代だ。

　システムについて実際に話を聞ける最後の世代は、2000年問題の対応に関わった層ということになる（図2）。あれは、日付を2桁で持っている箇所を洗い出して直す作業だった。特定の機能を作るのではなく、全プログラムを横断して1本ずつ中身を確かめる。だからこの層は、システム全体を一通り見ている。当時25歳から30歳だった人が、いま51歳から56歳。開発当初は知らないが、全体に手を入れた経験がある。「なぜこうなっているのか」を、断片的にでも語れる一番若い世代だ。

図2　そのコードに触った世代は、いま何歳か（提供：アクセンチュア）

　実際、有識者へのヒアリングの場に出てくる方は、この年代が中心になってきた。「そこは私の前の代の話なので」と言われることが、目に見えて増えている。

　そしてこの期限には、猶予の交渉ができない。ベンダーの保守終了は、条件次第で延長される可能性がゼロではない。延長された例がないわけでもない。だが人の退職は、こちらの都合では延ばせない。

　聞けるうちに何を聞いておくのか。これは連載の後半で詳しく扱うが、優先順位ははっきりしている。仕様書に書けるようなことは、後からでもコードから復元できる。先に聞くべきは、コードにも文書にも残らないことだ。なぜその判断をしたのか、どの部門の要請だったのか、何を避けようとしたのか。

　第1回で書いた、1円の丸め処理の話を思い出してほしい。あれを決めた人は、もういなかった。同じことが、これから数年で加速度的に起きる。