vol.42 「2038年問題」とITリテラシー

今回は、少しだけ技術的な話から入ります。しばらくお付き合いください。

ずいぶん前に私が開発に関わっていた某小規模システム（正確には、某社主体で開発された際、第三者として技術アドバイスや保守運用を行なったシステム）について、久しぶりにトラブルシューティングの問い合わせがありました。

あるアプリを個々のユーザがいつまで使えるかを管理する、いわゆる「アクティベーションキー」と「有効期限」の管理をするサーバ上のプログラムです。

そのシステムはすでにメンテナンスされなくなって久しいはずで、それでもまだ現役で稼働している（してしまっている）んだ…という事実にびっくりしつつも、とりあえずメール上で話を聞いてみることにしました。

曰く、web上の管理画面から有効期限を設定し、新しいキーを発行する操作をしたのに、キー一覧をCSV出力してもその中に含まれない、とのこと。数年経ち辛うじて残る記憶では、当該一覧CSVファイルには「まだアクティベート（利用開始）されていない、または、有効期限がまだ残っている」キーを抽出するロジックになっていたはずです。

だから、有効期限を未来の日時に設定したキーをたった今発行したのに、そのキーがCSVファイルに出てこないのはおかしい、というわけです。

管理画面上でキーの一覧表示をさせてみると、確かに有効期限がなぜか「0000-00-00 00:00:00」となったものがあります。これはいかにもあやしい。ぱっと思いつく可能性は2つありますが、まずはデータベース上にどのように保存されているかを覗いてみますと、やはり有効期限が「0000-00-00 00:00:00」として保存されています。さらにデータベースの定義ファイルを確認し、ほぼ原因が理解できました。

ここで実際にコードを読み解いてみると、やっぱりそうでした。技術的な対応方法もほぼ自明です。

有効期限を表す年月日時分秒のデータを、フロントエンド（≒Webアプリのフレームワーク）上では「2021-09-09 07:01:35」のように文字列として扱っており、これを MySQL というデータベースに保存しているのですが、その際timestamp 型が使われていたのです。ここに「2038年問題」（値が 2038-01-19 12:14:07 を超えると、不正な値として扱われ 0000-00-00 00:00:00 になってしまう）がある、というわけなのです。いわゆる「2038年問題」の典型例です。

・・・

さて、適度に要約しながら、当該事案の技術的な説明をしてきました。このコラムの読者で、エンジニア/プログラマではない方々にとってはなんのことやらさっぱり分からない内容だったかもしれません。ここまでお疲れ様でした（笑）

皆さんに考えて頂きたいことは、ここからです。

この例は純粋に技術的な問題と捉えられますし、技術的解決方法ももちろん存在します。一方で、技術とは異なる側面から解決・解消する方法もありますし、そもそも解決以前に考慮すべきポイントや視点もたくさんあるはずです。例えば…

・・・

この他にも、沢山の要考慮ポイントや視点がありえますね。皆さんだったら、どのようなことに思いをめぐらせられるでしょうか。

顧客側（ここでは発注側）にとって最重要だと私が考えるのは、実は広義の「ITリテラシー」の有無です。

エンジニアに対して「会社という組織や経営についてもっと理解してもらいたい」と思っている方は多いはずです。同様に、非エンジニアの方々に「開発の流れやその仕組みについてもっと理解してもらいたい」と思う人も多いのです。

「2038年問題」という分かりやすいキャッチーなバグが見つかった際に、「なぜそんな問題がコンピュータ上で起きてしまうのか」「それを直すにはどのくらい大変そうか（大変でないか）」など、専門的とまではいかないまでも概要を理解できていると、費用や作業日数以外にも判断材料が増え、エンジニア側からの説明を含めてより多面的に問題を理解でき、結果として取りうる選択肢は増えることになります。

今回のケースの場合、幸い先方のITリテラシーもあって、技術的な説明もスムーズに行えましたし、先方のいろんな事情も鑑みて「とりあえずは運用でカバーする（2038年問題にヒットしないように使うことで問題を回避する）」と落ち着きました（笑）　エンジニアとしてはきれいに直したいところですけどね。

51年以上生きてきた私にとっても世の中はいまだに知らないことだらけ。これからも知らないことをますます貪欲に学び続け、多くのことを吸収していきたい、そして多くの方々と互いの知識を共有していきたい、と改めて思ったメールのやりとりでした。