COBOL技術者の減少と、技術の「時限爆弾」に我々はどう向き合うべきか　～「昭和100年」を前に～【フォーカス】

「昭和100年問題」と呼ばれる年問題があります。西暦ではなく、元号である「昭和」を用いて、年の値を数字2桁固定で処理しているシステムが、COBOLなどで記述された企業や自治体の一部ソフトウェアに存在することに起因します。

当時の仕様のまま今も昭和換算で運用を続け、無理やり「2024年＝昭和99年」などとみなしている場合、ちょうど昭和100年にあたる2025年に入ると、こうしたシステムが2桁超えの「100」を正常に処理できず、甚大なエラーを起こすのでは――。この懸念が、「昭和100年問題」です。

情報セキュリティの専門家で立命館大学情報理工学部教授の上原哲太郎さんは、「『昭和100年問題』は、大したことにならないでしょう。ほとんどの組織では改修済みのはず」と見ます。

一方、「これで安心」ともいかないようです。私たちの社会を支えるシステムには、まだまだ「時限爆弾」が潜んでいるのだといいます。組織に使われるようになった技術がいずれ直面する、避けられない宿命とは何か。そして、私たちはCOBOLエンジニアの減少やレガシーシステムに、どのように対処するべきなのでしょうか。上原さんに取材しました。

• keyboard_arrow_down ユーザー企業もベンダーも「COBOL人材不足」にあえぐ
• keyboard_arrow_down そして誰もいなくなった：システムの“寿命”とは
• keyboard_arrow_down 真に恐ろしきは「2038年問題」
• keyboard_arrow_down 今こそ「延命のための痛み」と向き合うとき

――師走の忙しい中、取材を受けていただきありがとうございます。もうすぐ2025年を迎えますが、「昭和100年問題」をどう見ていますか？

上原：一部メディアやSNSでこの問題を危惧する声をよく耳にしますが、実際はそれほど深刻でなく、ほぼ問題にならないだろうと思っています。

というのは、2019年に平成から令和へ改元したタイミングで、多くの組織は内部システムが年をどうカウントしているか見直したはずだからです。いまだに「昭和」ベースかつ2桁で年を認識しているシステムがあった場合、普通に考えれば、改修にあたるメンバーが「あ、数年後の2025年にまた年問題が起きるな」と気づきますよね。その時に、しかるべき対応を済ませたかと思います。

ただ、単なる令和対応に比べると昭和100年対応は大きな工数がかかるのは確かです。ですので、社内で使う内製システムの令和対応時に「本格改修は面倒だし予算も超過するので、7年後にもう一度考えよう」と先送りにした後に、さらにおざなりにしている組織があれば、一部は大変なことになるかもしれません。

一方で、金融機関のシステムなど、エンドユーザーの目に触れるような範囲ではそれなりに予算も積まれたでしょうから、ほとんど問題は起きないでしょう。

――そうなんですね。ネット上の各所で懸念する声を見かけるので、意外です。

上原：もちろん問題が全く起きないとは言えません。小さな事故は各所で起きると思います。ですが、社会的に重要なシステムでは問題はほぼ残ってないだろうと見ています。

とはいえ、「これで安心」というわけにはいきません。知っての通り、COBOLでつくられたレガシーなシステムには、他にもいくつかの懸念材料が潜んでいるからです。

最大の問題は、COBOLベースのシステムは今後もしばらく存在し続けるのに、COBOLを扱えるエンジニアの人口が減り続けていることです。

今回の「昭和100年問題」に限らず、システムを長く運用するには、定期的な保守が必要です。しかし、メンテナンスのできる人間自体がこれまで以上に不足していくわけで、多くの組織が対応に苦心することになるでしょう。

例えば、富士通はメインフレーム（企業の基幹システムやデータ処理を行う大型コンピュータ）事業から2030年度末に撤退すると宣言しました。これまで金融機関や官公庁、大企業など大量のデータ処理が必要となる組織でこのメインフレームが導入され、COBOLで書かれたアプリケーションが数多く稼働してきました。

なので富士通機で動くCOBOLアプリケーションに依存してきた組織は、委託先を同じくメインフレームを提供しているIBM等に切り替えたり、最近いくつかの事業者が提供するオープン系のCOBOL環境にリホストする必要がありますが、当然ながらこうした会社でも「では、どうやってCOBOLエンジニアを確保するか？」が課題となってくる。

――これまで様々な組織を支えてきたベンダーでも今後COBOLの保守が難しくなっていくとなれば、委託している企業にとっては大変な状況ですね。

上原：はい。ただ、組織が内製で開発・運用してきたCOBOLベースのシステムでも、楽観視はできないでしょう。最初の開発者がすでに定年や転職で去ってブラックボックスと化してしまい、現在の担当者では中身がどう動いているか、どんな技術的リスクを内包しているのかわからなくなってしまっている事例もあるからです。

特に、官公庁におけるCOBOLの技術的負債は深刻かもしれません。

2019年には厚生労働省で不適切な統計が行われ、約2000万人に支払われる保険給付金の内訳に誤りが生じたというスキャンダルが浮上しました。あれは、数十年前の職員が自力でCOBOLを使い統計用のプログラムを記述したのが発端です。

その後、後任の担当者がプログラムを引き継ぐたびに、その人なりに必死に勉強し、「今年は調査方法が変更されるから改修しなきゃ」と変更が加えられた。しかし、その工程において、厚労省内にCOBOLがわかる人間が不足していたために適切なレビューが行われず、いつの間にか深刻なバグが生じていたのです。問題となるバグが生じた改修は2004年に行われたのですが、その時点でもすでに、省内でCOBOLがわかる人は2人しかいなかったそうですよ。

これは一定の透明性を有する公的機関だから外部に露見し記者会見が行われましたが、ひょっとすると民間企業でも「COBOLベースのシステムがバグを引き起こすようになったが、まだ誰もそれに気づいておらず、表沙汰になっていない事例」というのがゴロゴロ存在するのではないでしょうか。

こうしてCOBOLシステムの改修が自組織の手に負えなくなると、結局はベンダーを頼らざるを得なくなることも大いにあると思います。

――いずれCOBOLを扱えるエンジニアがいなくなり、様々なシステムが破綻を迎えることもあり得るのでしょうか？

上原：さすがに、完全にいなくなることはないと思いますよ。今もベンダーの現場なんかを訪問すると、しっかりとCOBOLを理解して扱えている若手エンジニアがたびたびいらっしゃいますし。

ただ、極端なCOBOL人材の不足により、保守や改修に関するベンダーへの委託コストがすさまじく高騰していくかもしれません。そうなると、いよいよ既存のシステムを捨て、別のプログラミング言語で新たなものを1からつくり直し、COBOL資産からどうにかしてデータを引っ越しさせる。こうした移行の必要性に迫られる組織が、ポコポコと出てくるかと思います。

――IPAが2016～2021年のソフト開発プロジェクト1476件を調べたレポートによれば、1位のJava（42.4%）に次ぎ、COBOL使用率は16.3%で2位でした。様々な課題が表出する中でも、COBOLベースのシステムを使い続ける組織が一定数存在するのはなぜですか。

上原：移行にも、大きなコストがかかるからだと思います。

言うまでもなく、本来は「そのまま使い続けた方がいずれ膨大なコストが発生し得る」からこそ、早いうちにシステム移行を検討する必要があります。

しかし日本の官公庁や伝統的な大企業といったエンジニア文化とは縁遠い組織では、そうした技術的知見に基づく経営判断が難しいことが多いんですよ。

こうした組織ではエンジニアが経営者になることは珍しいですし、論理的な問題解決能力にばかり特化した人よりも、コミュニケーション能力にすぐれ組織をまとめる力のある人が出世しやすい傾向にあるからです。

トップ層の技術的知見が薄いと、長期的にはより多くの費用がかかり得ると頭ではわかっていても、真剣には受け止められず、目先のコストを重視してしまうことがあります。基幹システムがただのコストセンターとして軽視され、「そのCOBOLとかいうので動いてるシステム、今すぐ移行が必要なわけじゃないんでしょ？　じゃあもうしばらく使い倒して、本当にまずくなったときにまた考え直そう」などと判断してしまうわけです。

で、気楽に構えている間にも、COBOLエンジニアは急減していきます。ある時「システムエラーが頻発し、業務に支障が出てきた。いい加減、まずいかも…」と気づき、慌ててベンダーに移行を手伝ってくれと泣きつくも、高額な料金を提示されるか「今はどうにもできません。COBOL人材をかき集めるのでしばらくお待ちください」と返されることもあるでしょうね。

――そんなに悲痛な未来も予想されるとは…。いったい、どうすればいいのでしょうか。

上原：やはり、システム担当者が、現状がいかに深刻かをわかりやすく噛み砕き、トップ層に直接改善の必要性を訴えることが重要です。実際に現場の人の多大な努力が実り、トップが考えを改めた事例はすでにいくつもあるかと思います。こうなればベストです。

ただ、問題となる典型的なパターンもあります。システム導入時から在籍し、「COBOLで書かれたシステムやソフトウェアが潜在的に抱えている課題を理解していた人間」が、すでに定年や転職でいなくなってしまっているケースです。すると、もはや現在の担当者自身がシステムの全容もソースコードの詳細もわからないため、技術的な知見に基づいた適切な意見を経営層に上申できません。

こうしたベテラン技術者のノウハウを現在、そして未来に受け継げるのは、当然、ベテランよりも若いメンバーだけです。しかし、そもそもの話、COBOLを今の時代に習得するもの好きな若者はほとんど存在しません。なにせ、面白くないからです。

――面白くない、とは？

上原：COBOLが「面白くない言語」という意味ではありません。COBOLで大規模なプログラムを1から新しく書くような仕事がこの先ほとんどないから、面白くないのです。正直なところ、「もはやメンテナンスの仕事しかない」のです。

エンジニアというのは、新しいアイデアをプログラムとして実現するために1から設計をし、システムデザインとアーキテクチャを決め、コードを記述し、思うように動くものを形にし、「はぁ～できた！」と疲れた目をこする瞬間に至上の喜びを覚える人々です。

そんな職を志す人にとって、今から覚えても保守の仕事しか転がっていないCOBOLは、残念ながら、面白みがないと思われ、習得の選択肢から外れがちなのです。また、COBOLを書き続けてプロジェクトマネージャーやテックリードに抜擢されるような昇進ルートのモデルケースが周囲にほぼいないため、キャリアビジョンの「夢」が想像しづらいというのも一因でしょう。仕方のないことだと思います。

――技術自体に現在も需要があり、今も人々の役に立ち続けていても、扱える人がいなくなってしまうことがあるのですね。

上原：はい。こうなると実質的に、世の中にあるCOBOLベースのシステムは「寿命」に達してしまった状況ともいえるかと思います。

もちろん、プログラミング言語や技術自体には、「寿命」は存在しません。しかし、システムには、あると思うんですよ。それは、そのシステムの仕組みや潜在的問題を知っている人がいなくなり、さらに、トレンドの移り変わりによって、そのシステムを動かしている技術ついて新たに学ぶ人もいなくなってしまうことです。

こうなると、もはやそのシステムは誰にも手が付けられないブラックボックスになります。改修しようにも手の施しようはなく、リプレースをせざるを得なくなります。

こうした実質的な「寿命」はCOBOLベースのシステムに限らず、普遍的に起こり得るものです。この「寿命」に目を瞑り続けていると、いずれは組織にとって、場合によっては社会にとって大きなリスクとなっていきます。

――システムの「寿命」とは、そのシステムが用いている技術を深く理解し扱える人がいなくなることなのだとよくわかりました。

上原：実は、レガシーシステムをめぐっては、もっと恐ろしい問題が存在しますよ。「2038年問題」です。端的にいうと、32ビットのコンピュータシステムにおける、時間表現の限界によって引き起こされる潜在的な問題です。

主な対象となるのは、UnixやLinuxなどのOSをベースに動作するシステムです。サーバーやパソコン上で動作するシステムと、産業機器や家電製品に組み込まれたシステムの両方が該当します。これらは、時間を1970年1月1日午前0時0分0秒（協定世界時）からの経過秒数で表現しています。いわゆる「Unix時間」ですね。ところが、32ビットで動いているシステムの場合、協定世界時で時刻が2038年1月19日午前3時14分7秒を過ぎたとたん、Unix時間が32ビットで表現できる最大の整数を超えてしまい、オーバーフローを起こしてしまうんですよ。

すると、様々な企業のハードウェアや一般家庭で使われている家電に至るまで、あらゆるシステムが停止したり、データが破損したりする可能性があります。「昭和100年問題」など比にならないほどに、影響範囲が広く深刻な問題だと認識しています。

――2038年問題を防ぐためには、どのような対応をとればいいのでしょうか？

上原：一般的には、Unix時間を格納するタイムスタンプ値を、64ビットの整数型に拡張すればいいとされます。64ビットなら途方もなく大きな値まで扱えるため、事実上オーバーフローの問題は解消されるだろう、と。

ところが、そう簡単に改修完了とはいきません。実は、タイムスタンプ値を拡張しただけでは、解決しないケースが多いからです。

具体的に言うと、プログラムの内部で、タイムスタンプ値を一時的に32ビットの整数型変数に代入し、演算処理を行うようなコードが散在している場合があります。64ビット化をしたところで、こうした代入部分が1か所でもあると、結局オーバーフローが発生してしまうかもしれないのです。加えて、ファイルシステムによっては、タイムスタンプが32ビット固定になっている場合もあります。こうなると、ファイルシステムそのものをつくり直さなくてはならない。

このように、コード全体を隅々まで洗い出して精査し、慎重に修正する必要があります。ちょうど9月に論文を発表したのですが、我々の研究室でGitHub上のC言語リポジトリの上位874プロジェクトを調査した結果、実に294プロジェクト（約34%）に、このような「64ビット化だけでは落とし穴にハマる可能性のあるコード」が見つかりました。

また、組み込みシステムの場合は、物理メモリの制約でそもそもハードウェアが64ビットに対応していない場合もあり、対応は非常に困難を伴います。全ての組織が2038年問題を回避するには、恐らく10年は作業時間が必要だと見ています。

――となると‥‥「今から対応すればなんとか間に合うのでは」ということでしょうか…？

上原：そうではあるのですが、この問題には、COBOLと同じような深い落とし穴が潜んでいると思っています。システムの「寿命」ですよ。

つまり、各組織において、かつてUnix系システムの開発や、組み込みシステムの入ったデバイスの導入を担当した人間がすでにいなくなってしまい、しかも後任者がよく理解できていないパターンです。このような技術的知見の不足した組織は、2038年問題の深刻さを理解できず、迅速な行動ができません。

もう、2025年に入るわけですよね。悠長にしている暇はありません。作業時間に10年かかるとしたら、向こう3年間が、この問題を回避できるかの極めて重要な山場になります。

――では、今すぐ何から始めるべきでしょうか？

上原：まず、組織のメンバー全体が、レガシーシステムが内包するリスクを理解すること。そして組織内のあらゆる使用デバイスや技術スタックを見直すこと。これしかないです。

普段何気なく使っているデバイスでも、製造のタイミングによっては2038年問題でトラブルを起こす製品が紛れ込んでいます。こうした機器を片っ端から見つけ出して見直す。尻に火が付いたような思いで、この作業に本気で取り組むことが急務です。

こうして真剣に動いてもらうためにも、私のような人間が「あなたの職場の壁裏のネットワークハブはいつ設置されましたか？　それは2038年問題を回避できる製品ですか？」ということから、地道に発信をしていかないといけないと思っています。

きっと、「2038年を超えられないデバイスやシステム」が、どこの職場にも一定数あるはずですから。

――この先、エンジニア文化に馴染みの薄い伝統的な企業や官公庁は、新たな技術を取り入れる際、何に留意するべきだと思いますか？

上原：まず、どんな情報システムにも「寿命」があると、社会全体で認識しなくてはいけません。扱える人がいなくなることで「寿命」を迎えるし、その終末期には、しばしば大きなトラブルが発生するのだと。

ほとんどのシステムは、健全に「延命」するためには、定期的に大規模なコストを投下してリプレースをする必要があります。それが経営上どんなに苦痛を伴う事実だとしても、見て見ぬふりをやめて、この痛みと向き合わなくてはなりません。

組織固有の機能をカスタマイズ等で加えたシステムでは、この「延命」を完全外注にすると、あまりにもコストが大きすぎる。なので、ベンダーに任せきりにせず、技術に明るい人間を組織に迎えないと、立ち行かなくなるでしょう。これも、すぐにクリアできる課題ではありませんが…。

「伝統的な会社かもしれませんが、エンジニアが輝ける場所も用意していますよ！」などと、企業自らが積極的に訴求しなくてはならない時代です。さもなければ、とんでもない末路を迎えることになりかねません。

――技術にしろ、採用方法にしろ、伝統的な問題の解決はやはり一筋縄ではいきませんね。

上原：はい。私としては今後も、情報セキュリティに関わる人間として、レガシーシステムが抱える課題について地道に警鐘を鳴らし続けていきます。

余談ですが、かつて「Windows 95」の拡張パックから「XP」までOSに同梱され、一部ユーザーに人気を博していた「Windows 3D ピンボール」というゲームがありました。でも、「Vista」以降のOSには収録されませんでした。聞くところによると、あれは32ビット版から64ビット版へソースコードの移植作業を行った時に、「発射した球がそのまま壁を貫通してしまいゲームが成立しなくなる」バグが発生してしまい、Vistaのリリースまでに誰も修正できずそのまま収録を断念したそうなんですよ。

些細な話に思えるかもしれませんが、このように誰の手にも負えなくなってしまったソフトウェアやシステムは、私たちの社会の至る所に潜んでいるのではないでしょうか。

それらが見落とされ続けると――。いつの日か「時限爆弾」として大爆発し、企業やエンジニアのみならず、電子機器と共に生きる全ての人々の日常を根底から揺るがすかもしれません。

だからこそ、私たちは今、2038年問題のような潜在的なリスクに目を向け、対策を講じる必要があります。ひとりでも多くの人にこの問題を知ってもらい、日本中に散らばる「時限爆弾」の解除に少しでも貢献したいと考えています。

取材・執筆：田村 今人
編集：光松 瞳
撮影：赤松 洋太