メルマガ
[2024/01/15 更新]
はじめに
今回は、2038年問題についてお伝えします。
もしかすると、「2025年の崖」の次は、「2038年問題」と思った方もいるかもしれません。
2038年問題
2038年問題とは、UNIXやLinuxなどのオペレーティングシステムやプログラミング言語において、日付表現のために使われている32ビット符号あり整数が、2038年1月19日にオーバーフローを起こしてしまう可能性がある問題のことです。
これは、1970年1月1日0時0分0秒を起点としたエポックタイム（UNIXタイムスタンプ）の表現に用いられている秒数が、32ビット符号あり整数の最大値である2,147,483,647を超えるため、オーバーフローが起こるからです。
そして、この問題が発生すると、エポックタイム以降の日付や時刻が正しく表現できなくなります。そのため、システムやアプリケーションの動作に支障をきたす可能性があるのです。
ですので、2038年問題への対策としては、32ビット符号なし整数や64ビット整数の使用や、時間表現に別の方式を採用することが必要になります。つまり、該当する既存のシステムやアプリケーションの修正が必要になります。この問題の解決には、多大な労力が必要となる可能性が高いです。
レガシーシステムに与える影響
当然、レガシーシステムと関係ないシステムでは、2038年問題は関係ないかもしれません。
でも、ちょっと待ってください。日本では、32ビットアーキテクチャを採用した多くのオフコンなどのレガシーシステムが稼働しています。つまり、2038年問題はオフコンやレガシーシステムに大きな影響を与える可能性があるのです。
オフコンに限らず、レガシーシステムは、全般的に新しい技術や開発手法とは異なるため、現代の技術者が持っているスキルとは別のスキルが必要になります。そのため、レガシーシステムのメンテナンスや移行に対応できる技術者は、定年やリタイヤなどにより減っていく一方のため、見つけることが困難になります。
それに、レガシーシステムを新しいシステムに移行する場合にも、データの移行や既存のプロセスの再設計など、多くの時間やリソースが必要になります。この先、このような移行のニーズが高まると、対応できる会社に案件が集中して、期日までに対応できない状況も考えられます。
レガシーシステムの対策
2038年問題の対策として、UNIXやLinuxなどのシステムにおける32ビット整数のオーバーフローを回避する必要があります。
このためには、32ビット符号なし整数や64ビット整数の採用や別の時間表現方式の導入が重要です。
特にレガシーシステムには影響が及び、適切な技術者の確保や移行作業の時間とリソースが必要です。
対策を先送りせず、早めの対応がシステムの安定性と運用の継続性にとって重要とされています。
2038年はまだ先だからと先送りせずに、今から準備をしていくことをおすすめします。
