改元対応よりも大変? IT業界でうわさの「昭和100年問題」とは (1/2ページ)

 平成からの改元対応に追われるIT業界だが、ネット上では「昭和」の残滓を引きずったある問題のうわさが注目を集めている。昭和の時代に導入したコンピュータシステムが、「年」の処理を正常に扱うことができず、2025年に誤作動を引き起こすのではないか--という問題だ。2025年が昭和100年にあたることから「昭和100年問題」として、界隈で話題になっている。(山崎潤一郎,ITmedia)

昭和100年問題とは?

 昭和100年問題は、「年」の情報を2桁で取得しているアプリケーションソフトウェアの内部処理において、平成(1989年1月8日)以降も昭和が連続していることとし、「昭和〇年」として扱う場合に起きるといわれている。例えば、プログラム上で日付の処理を「yymmdd」と記述する際、平成2年3月1日を昭和換算し、「650301」として処理しているようなケースだ。

 おそらく画面表示や帳票印字の時には「平成」に置き換えていると考えられるが、内部では年を2桁で処理しているので「991231(昭和99年12月31日)」の次は、「000101(昭和00年1月1日)」と数字が一巡してしまい、これが誤作動の原因になる可能性があるという。考え方としては、約20年前に世間を騒がせた「2000年問題」(※)と同じだ。

 (※)2000年問題:日付を扱う際に西暦の下2桁のみを処理対象としたことで、2000年にコンピュータが誤作動を起こすといわれた問題。1999年から2000年になると、下2桁が99→00と一巡することが原因とされている

2桁処理は1ビットの節約に頭を悩ませた時代の名残

 ではなぜ、西暦ではなく和暦で処理していたのか。何人かのエンジニアに聞いてみたところ、システムを構築していた当時としては、西暦(2000年で下2桁が一巡)と比べて、和暦(2025年で下2桁が一巡)の方が25年間“猶予期間”があり、それが有利な点として認識されていた面もあったようだ。

 部外者からすると「いずれ一巡することは分かっていたはず」「なぜ西暦4桁で処理するシステムを構築しなかったのか」といった物言いをしたくなるが、昭和に構築された古いシステムだけに、これには相応の事情が絡んでいる。

 現役をしりぞいたあるエンジニアは「当時は64~128キロバイトの世界で勝負しており、1ビットをいかに節約できるかに頭を悩ましていた」と話す。メモリをどう節約するかはエンジニアの腕の見せ所であり、「年」を2桁で表現するのも1つの対応策だった。

 「それならハードウェアのスペックが良くなってからシステムを改修すれば良かったのではないか」とも思ったが、「30~40年前のことだけに、仕様書やソースコードが行方不明」という悲惨なケースもあるようだ。ソースコードがあったとしても、改修につぐ改修で解読不能な“スパゲティコード”になっている--といった嘆きも聞こえてくる。

 構築や保守管理を担当していたエンジニアに確認しようにも、定年を迎えて離職しているケースがほとんどという。ちなみにこれは「2007年問題」としてIT業界で話題になったことがある。1947年生まれを中心とした団塊世代の定年退職者が最も多かったのが2007年で、レガシーなシステムを保守管理する技能を持った人々の多くが現場から去ってしまったのだ。

2000年問題や改元対応の知見を生かせるか