こんにちは。最近、開発者⇒テストエンジニアとなりました、だいだいです。
早速になりますが、皆さんは「2038年問題」ってご存じでしょうか？ え、「2000年問題」じゃないの？ と思われる方もいらっしゃると思いますが、違います。「20”38”年問題」です。
今回は、昔大きく話題になった「2000年問題」よりも深刻になり得そうな「2038年問題」について、他の似たような事象を踏まえつつ説明していきたいと思います。
「2000年問題」について覚えていますか？
かつて20世紀末の世間を大きく騒がせた「2000年問題」。30代以降の皆さんであれば覚えていらっしゃる方も多いのではないでしょうか。
軽く「2000年問題」について説明すると、当時のシステムでは年を西暦の下２桁で管理していたため、2000年を1900年として扱ってしまう……というものでした。
どれほど大騒ぎになったかというと、
- 2000年になった瞬間、あらゆるシステムが誤作動するのでは。航空機が墜落するのではという憶測が飛び交う。
- 世紀末ということもあり、ノストラダムスの大予言（1999年、7の月 空から恐怖の大王が降ってくる）と関連付けて、ミサイル誤発射から世界大戦勃発……という飛躍した噂が流れる。
結局は各企業が総出で対応を行い、2000年を迎えても大きな障害トラブルは発生せず平和に年明けを迎えることができたそうです。ただ念のため、正月は当番制で会社に出勤していたというお話も聞きました。（知り合い談）
今回のテーマである「2038年問題」という名前から、この「2000年問題」と似ていると思われるかもしれませんが、実は全然違う原因による問題だったりします。そこを含めて、出来るだけ丁寧に説明していきます。
2038年問題の前提知識
「2038年問題」は大雑把にいうとOSやシステムに深く関わる問題となります。そのため、出てくる専門用語を予め説明します。
UNIX時間
名の通りUNIX、Linux系OSのシステムで使われる時間データのこと。多くのシステム・プログラミング言語で採用されている。基準値「1970年1月1日0時0分0秒」からの経過秒数を保持しており、例えば「2024年1月1日0時0分0秒」なら基準時間から1704034800秒が経過したということ。
上記の基準時間はUTC（ロンドン基準）となっており、日本の場合はUTCから時差の9時間が進んだJSTを扱う。
int型
正式名称は「32bit符号付き整数型」で、名の通り32bit分の整数値を保持する箱のこと。マイナス値も格納できるため、値の範囲は「－2147483648〜2147483647」。
レガシーシステム
IT用語で「過去の技術や仕組みで構築されているシステム」のこと。古いシステムのため利用された技術・仕組みについてブラックボックス（実態が不明）化しているシステムも多い。
ランタイムライブラリ
プログラムの実行に必要な前提のプログラム、共通して利用できるプログラムを１つにまとめたモノのこと。共通して利用できるプログラムとしては数値計算などが挙げられる。身近なものならExcelの関数（SUM関数、MAX関数など）もランタイムライブラリに当てはまる。
「2038年問題」ってなに？
UNIX時間をint型で保持している場合、その限界値が「2038年1月19日12時14分7秒」となる問題のことです。
「2038年1月19日12時14分7秒」から1秒でも経過すると、int型の限界値を超えてオーバーフロー（桁あふれ）を起こします。そうなるとint型の値が上限値「2147483647」⇒下限値「-2147483648」となります。
結果、「1970年1月1日0時0分0秒」から2147483648秒前の日時……つまり「1901年12月14日5時45分52秒（JST計算）」と扱われてしまうんですね。
ある日突然、システムの日時が「2038年1月19日」⇒「1901年12月14日」になってしまう。それがこの「2038年問題」なんです。
「2038年問題」は「2000年問題」より深刻になり得る
「2000年問題」はアプリケーションレベルでの修正が可能だったため、各会社の対応により無事に乗り切ることができました。しかし「2038年問題」は上記で説明した通り「UNIX時間」……つまり、アプリケーションではなくOS・プログラミング言語といった、システムの深い層に潜む問題となります。
システムの深い層の問題ということは開発会社であれば解決可能という訳にもなり辛く、対応するにしても重大なリスクが付き纏います。
こういった理由から、私は「2038年問題」をより深刻に捉えたほうが良いのではと考えました。
「2038年問題」の対策（開発者目線）
オフィスコンピュータを始めとするレガシーシステムの多くが、この問題の対象となる可能性を秘めています。その対象と理由、対策方法について下記にまとめてみました。ただし、あくまで私個人の意見のため、参考程度にご覧いただけると幸いです。
| 対象システム | 対策 | 理由 |
|---|---|---|
| 32bit版のUnix・Linux系OSを使用しているシステム | OSを64bit版にするか、日時管理を64bitで保持するバージョンにアップデートする | OSによっては日付型を32bitで保持しているため |
| 日時計算を独自処理で行っているシステム | 開発者がアプリケーションレベルの修正を行う | 「2038年問題」を考慮していない（int型に格納など）可能性があるため |
| C／C++などの古いランタイムライブラリを用いているシステム | 「time_t」を使わないこと | 古いランタイムライブラリは日付型を32bit符号付き整数型で保持しているため （C／C++の場合は特に「time_t」を利用しているアプリケーションが対象） |
補足
なぜ32bit版のUnix・Linux系OSに限定しているかというと、32bit版のWindowsは「2038年問題」は発生しないためです。実はWindowsXPの時点で32bit版でも日付型を必ず64bitで保持するようになっているんですね。
日時計算を独自処理で行うシステムについてはアプリケーションレベルの修正となりますが、日時計算を独自で行うシステムの大半はレガシーシステムだと思われます。つまり処理自体がブラックボックス化している可能性があり、修正に対して相応のリスクはあります。
C／C++などの古いランタイムライブラリに関しても、上記のリスクに加えてそもそも有識者が少ない問題もあるため、修正に対するリスクは高いように思えますね。
「2038年問題」の対策（テストエンジニア目線）
では品質管理を担保することが目的のテストエンジニアの場合、どのようなことを考慮すれば良いでしょうか。
１．設計ドキュメントレビューの観点として盛り込む
これは早期に問題を発見できる、最適なアクションでしょう。例としてレビュー時に目を通すべき場所、問題発見時の対応について幾つか上げたいと思います。
実施環境OSの確認
記載されている実施環境のOSが引っかかっている場合は、まず起こり得る「2038年問題」に対する対策を行っているのか確認する必要があります。
対策を行っている場合は、対策の確実性を担保するため日付を取り扱う処理に対してのテスト優先度を高くできます。
対策を行っていない場合は、開発側が「2038年問題」を把握していないことを考慮し、問題の説明を行いつつ対応してもらえるよう促せます。
開発言語の確認
開発言語が古いランタイムライブラリを利用していることもあり得るため、確認はしたほうが良いでしょう。特に組込み機器はC／C++を多く利用しているため注意が必要です。
発見した場合はOSと同様、どういった対応を行っているのか確認する必要があります。ただ組込み機器の場合は、そもそも2038年までの使用を想定していないこともあり得ます。
２．探索的テストを利用する
テスト実施を行う際に日付を「2039年」などにして、2038年以降の日時が処理できるか探索的テストをしても良いでしょう。特に業務システムは長期間使用を想定していることが多いため、ひとつの長期運用の品質担保になるのではないでしょうか
（実際に20年以上使われているシステムがある ※実体験）
同様の問題について紹介
今回は「2038年問題」について詳しく紹介しましたが、実は他にも同様の問題がまだまだ潜んでいます。
2004年に起きた「2038年問題」
某通信事業会社にて「2038年問題」と同様の事象が2004年に発生しました。結果、日付（平日／休日など）による通話料金の計算処理に故障が発生し、大多数のユーザに対して割高／格安の通話料金を請求してしまいました。
2004年に「2038年問題」が起きた原因としては、システムの独自処理でUNIX時間の1秒＝0.5秒に変換していたためです。その影響で本来より半分の時間で事象が発生しました。
「2036年問題」について
コンピュータ時刻を同期するためのプロトコルである「NTP（Network Time Protocol）」が「2038年問題」と同様の理由でオーバーフローしてしまう問題のことです。
NTPの基準時間は「1900年1月1日0時0分0秒」。NTPサーバでは32bit符号なし整数型で保持しているため、4294967295後の「2036年2月6日0時54分54秒」でオーバーフローしてしまいます。
まとめ
「2038年問題」を始めとする「20XX年問題」は数多く存在します。その対象はレガシーシステムだけでなく、開発／運用中のシステムも含まれるかもしれません。特に業務関係で使うシステムは、長期稼働されることが前提となりがちです。
昨今のテクノロジー進化はとんでもなく速いことは、恐らく皆さんお気づきだと思います。何せ1980年にはショルダーフォンが生まれ、1990年代には携帯電話（ガラケー）が普及し、2000年代後半ですでにスマホとなっています。
現代ではSF世界の話だと思っていた量子コンピュータの実現が現実的となり、2030年代にはビジネスに利用され始めるとの話もあります。丁度「2038年問題」に直撃してるころ、量子コンピュータはビジネスシーンで利用されているかもしれない、ということですね。
上記の通り、IT業界は技術の進歩が非常に激しい業界です。そのテストエンジニアとして、私たちは将来的に起こりうるリスクも視野に入れて品質課題を捉える必要性があります。この「2038年問題」をきっかけに、その気付きを少しでも得ていただけたら幸いです。
