COBOL技術者の高齢化と2030年問題｜今から始める移行計画IT人材79万人不足時代に備え、レガシーシステムの移行計画を今から立てるべき理由と進め方

COBOL技術者の引退が迫る——「まだ動いている」では済まない時代に

COBOL技術者の高齢化とIT人材不足は、レガシーシステムを抱える企業にとって「いつか来る問題」ではなく「今すぐ手を打つべき問題」です。本記事では、2030年に最大79万人と予測されるIT人材不足を踏まえ、COBOLで構築された基幹システムの移行計画を今から立てるべき理由と、具体的な進め方を解説します。

日本の基幹システムの多くは、1959年に開発されたプログラミング言語COBOLで構築されています。銀行の勘定系システム、保険会社の契約管理、製造業の生産管理など、企業の根幹を支えるシステムがCOBOLで動いているケースは今でも珍しくありません。そして、これらのシステムを開発し、長年にわたって保守してきた技術者の多くは、すでに50代後半から60代に差しかかっています。

経済産業省が2018年に公表した「DXレポート」では、レガシーシステムを構築した技術者の多くが2025年以降に引退期を迎えることが指摘されました。COBOLに精通した技術者が退職すれば、システムの仕様を正確に理解できる人間がいなくなります。設計書が不十分なまま運用されてきたシステムであればなおさら、保守が事実上不可能になるリスクが現実味を帯びてきます。

2030年問題——IT人材が最大79万人不足する未来

COBOL技術者の高齢化に追い打ちをかけるのが、IT業界全体を襲う人材不足の波です。経済産業省がみずほ情報総研に委託して実施した「IT人材需給に関する調査」（2019年公表）によると、2030年にはIT人材が最大で約79万人不足すると予測されています。

この79万人という数字は、IT需要の伸び率が高く、労働生産性の上昇率が低い場合の最悪シナリオですが、中位シナリオでも約45万人の不足が見込まれています。つまり、楽観的に見積もっても数十万人規模の人材不足は避けられないということです。

さらに注目すべきは、不足するのが「先端IT人材」——AIやクラウド、データサイエンスなど新しい技術に対応できる人材——である一方、COBOLのような従来型技術に対応する「従来型IT人材」は需要そのものが縮小していくと予測されている点です。レガシーシステムの保守に必要な技術者は市場から姿を消していくにもかかわらず、レガシーシステム自体は企業の中で動き続けている。この需給のミスマッチこそが、2030年問題の本質です。

端的に言えば、COBOLシステムの保守を担う技術者は、退職で「いなくなる」だけでなく、市場からも「調達できなくなる」のです。外注しようにも、COBOL技術者を擁するベンダー自体が減少しているため、保守委託の費用は年々上昇しています。ある時点で「誰にも保守できないシステム」が社内に残る——これが、COBOL高齢化問題の最悪のシナリオです。

なぜ「まだ動いている」が最も危険な判断なのか

レガシーシステムの問題を先送りにする最大の理由は、「今のところ問題なく動いている」という現状認識です。しかし、この判断には3つの致命的な見落としがあります。

1つ目は「属人化リスク」です。COBOLシステムの多くは、特定の技術者だけが仕様を把握している状態で運用されています。その技術者が退職すると、なぜその処理が必要なのか、どのデータがどこに影響するのかを誰も説明できなくなります。システムは「動いてはいるが、触れない」状態に陥ります。

2つ目は「保守コストの高騰」です。COBOL技術者の減少に伴い、保守を委託できるベンダーの選択肢は狭まり、単価は上昇の一途をたどっています。「動かし続けるだけ」のコストが年々増えていく構造は、経営にとって見えにくいが深刻な負担です。IT予算の大半がレガシーシステムの維持管理に消えてしまい、新しい投資に回す余力がなくなる——経済産業省が「2025年の崖」として警鐘を鳴らしたのは、まさにこの構造です。

3つ目は「移行に必要な時間」です。基幹システムの移行は、計画から完了まで通常3年から5年を要します。2030年の人材不足が本格化してから動き出しても、移行を完了させるための技術者を確保すること自体が困難になります。つまり、移行を決断するなら「今」が最後のチャンスに近い時期なのです。

COBOLシステムの移行計画——5つのステップで進める

では、具体的にどのような手順でCOBOLシステムの移行計画を立てればよいのでしょうか。以下の5つのステップで整理します。

第1ステップは「現状の棚卸し」です。自社のCOBOLシステムがどの業務を支えているのか、プログラムの規模（ステップ数）はどれくらいか、設計書や仕様書はどの程度残っているか、保守を担っている技術者は何名で何歳くらいかを洗い出します。この棚卸しが不十分なまま移行を進めると、プロジェクト中盤で「想定していなかった機能」や「把握していなかった依存関係」が発覚し、計画が大幅に狂う原因になります。

第2ステップは「リスクの評価と優先順位付け」です。棚卸しの結果をもとに、各システムの「保守リスク」と「ビジネス上の重要度」を評価します。保守担当者が1名しかいないシステムや、設計書が一切存在しないシステムは、技術者の退職と同時に保守不能になるため最もリスクが高いと判断できます。リスクの高い順に移行の優先順位を決めていきます。

第3ステップは「移行方式の選定」です。COBOLシステムの移行方式には、大きく分けて「リライト（新言語での書き直し）」「リプラットフォーム（基盤のみの変更）」「パッケージ導入（ERPなどへの置き換え）」の3つがあります。どの方式が適切かは、システムの規模、業務の特性、予算、移行後の運用体制によって異なります。近年では、生成AIを活用してCOBOLのソースコードを解析し、仕様書を自動生成する技術も実用化が進んでおり、移行の初期工程の効率化が期待されています。

第4ステップは「段階的な移行計画の策定」です。大規模なCOBOLシステムを一度にすべて移行しようとすると、リスクもコストも膨大になります。機能単位や業務単位でフェーズを分け、段階的に移行を進める計画を立てることが現実的です。各フェーズの期間、必要な人員、予算、並行運用の方法、切り戻し手順をあらかじめ設計しておくことで、プロジェクトの失敗リスクを大幅に下げることができます。

第5ステップは「パートナーの選定と体制構築」です。COBOLシステムの移行は、自社だけで完結できるケースはまれです。COBOL解析と新技術の両方に精通した外部パートナーの選定が不可欠です。パートナーを選ぶ際には、COBOLシステムの移行実績、上流の設計力、移行後の保守まで対応可能な体制があるかを重視しましょう。

御社が今週中にできる3つのこと

移行計画の全体像は大きなものですが、最初の一歩は小さくて構いません。今週中にできることとして、3つの行動をお勧めします。

まず、自社のCOBOLシステムの保守を担っている技術者の年齢と人数を確認してください。60歳以上の技術者が保守の中心を担っている場合、5年以内に保守体制が維持できなくなるリスクがあります。次に、設計書や仕様書の現存状況を確認してください。仕様書がない、あるいは最新の状態に更新されていない場合、移行の難易度は大幅に上がります。逆に言えば、仕様書の有無を把握するだけでも、移行プロジェクトの規模感とリスクの見積もりが一段精緻になります。最後に、経営層にこの問題を共有してください。COBOLの移行は「IT部門の技術的な課題」ではなく「事業継続に関わる経営課題」です。経営層のコミットメントなしに、数年にわたる移行プロジェクトを成功させることは困難です。「保守担当者が退職したらどうなるか」「年間の保守コストが今後どう推移するか」という2つの問いを経営層に投げかけるだけでも、問題の深刻さは伝わるはずです。

まとめ：2030年に間に合わせるために、今動く

COBOL技術者の高齢化と2030年のIT人材最大79万人不足は、レガシーシステムを抱える企業にとって避けて通れない課題です。「まだ動いている」という現状は、保守不能になるリスク、コスト高騰、移行のための技術者確保の困難という3つの時限爆弾を抱えている状態に他なりません。

基幹システムの移行には3年から5年を要します。2030年に間に合わせるためには、今この瞬間から計画を動かし始める必要があります。まずは現状の棚卸しから始めて、自社が抱えるリスクの大きさを正確に把握することが第一歩です。

GXOでは、180社以上の支援実績をもとに、COBOLシステムの現状分析から移行戦略の策定、段階的な移行の設計・実行まで一気通貫で伴走しています。「COBOLシステムの保守に不安がある」「移行を検討したいが何から始めればよいかわからない」という方は、まずはモダナイゼーション支援のご相談からお問い合わせください。

GXOへのお問い合わせはこちら