メタエンジニアの戯言 : i-Learning アイ・ラーニング

i-Learning 株式会社アイ・ラーニング



松林弘治のコラム メタエンジニアのの戯言

 2021年9月8日

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年問題」の典型例です。

・・・

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

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

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

  • このシステムがどれだけの利益に貢献しているかによるが、ここで改修コストをかけることは得策か?(顧客側の目線)
  • 「こんなにすぐに原因が分かったんだったら、すぐに直せるよね?そんなに大変じゃないよね?」とトラブルシューティング/保守運用という仕事を軽々しく思われたりしないか?(技術者側の目線)
  • そもそも、このシステム/サービスによる営業はこのまま続けるべきか?既存ユーザを困らせることなく新規ユーザを獲得できる、将来に向けた発展系のサービス設計・構築はありえないか?(顧客側の視点)
  • 問題をより正確に理解してもらうためには、技術的内容や発生経緯、解決の選択肢をどのようにかみくだき、相手の理解レベルにあわせてどのように伝えればよいか?(技術者側の目線)
  • 小規模システムとはいえ、何年間も保守されてきていないカスタムプログラム。そもそも、このまま2038年1月19日以降もずっと使い続けるのか?(技術者側/顧客側双方の目線)
  • 今ならば、GAS (Google Apps Script) や各種ローコードツールを使えば同様のサービスが自作できる可能性はないか(技術者側/顧客側双方の目線)

・・・

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

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

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

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

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

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

松林 弘治 / リズマニング代表
大阪大学大学院基礎工学研究科博士前期過程修了、博士後期課程中退。龍谷大学理工学部助手、レッドハット、ヴァインカーブを経て2014年12月より現職。コンサルティング、カスタムシステムの開発・構築、オープンソースに関する研究開発、書籍・原稿の執筆などを行う。Vine Linuxの開発団体Project Vine 副代表(2001年〜)。写真アプリ「インスタグラム」の日本語化に貢献。鮮文大学グローバルソフトウェア学科客員教授、株式会社アーテックの社外技術顧問を歴任。デジタルハリウッド大学院講義のゲスト講師も務める。著書に「子どもを億万長者にしたければプログラミングの基礎を教えなさい」(KADOKAWA)、「プログラミングは最強のビジネススキルである」(KADOKAWA)、「シン・デジタル教育」(かんき出版)など多数。