「でも、改元なんて、いつか発生することでしょう。きちんと対応していればよかっただろうに」という意見も出てくるかもしれない。 　ええ、予算があれば……。 　たとえば、車を買う場合に、全ての付属部品を最高級なものにするだろうか？　それとも支払うお金を減らすために、安価に済ませるだろうか？　よほどお金が余ってない限り、予算削減に気持ちが傾くはずだ。 　企業が、プログラムの開発を発注する時も同様だ。今回の改元は、前回の改元から30年以上経っている。今は平成31年。10年以上継続する企業は少ないと言われている。そうした環境の中で、20年後30年後のことを考えて、コストを割くだろうか？ 　現行のプログラムを更新するのかという問題もある。そもそも、動いているものの更新に、予算は付きにくい。現状問題のない機械を捨てて、新しい機械を入れる。手放しで賛成する人は少ない。多くの企業で、古いWindowsが使われているのが、その証拠だろう。 　ここ10年ぐらいで作られたシステムであれば、様々な日付の問題を想定しているかもしれない。問題は、平成の初期や昭和に作られたシステムなのだ。改元があった前後なら、「そこにコストを割かなければならないと、分かっていただろう」と考えるかもしれないが、その時期には、今とは違う問題があったのだ。 　平成元年（昭和64年）は1989年だ。Windows95が出たのが1995年なので、その6年前になる。その頃は、コンピュータは一般的なものではなく高価なものだった。記録媒体の容量も小さく、計算力も乏しいものだったのだ。 　富士通が、CD-ROM標準搭載のパソコン「FM TOWNS」を発表したのが1989年。それ以前は、家庭用パソコンでは、フロッピーディスク（1MB程度）が一般的だった。フロッピーディスクさえなかった時代もある。今から見ると貧弱な環境の中で、色々とやりくりをしていたのだ。 　2000年問題というのを覚えているだろうか？　1999年を「99」年と記録していたせいで、2000年になると「0」年になってしまうという問題だ。当時は、今ほどコンピュータの環境がよくなかった。そのため、保存するデータ量を減らすために「1999」年という4桁の西暦を「99」年と2桁で保存していたのである。それだけで、数字2文字分のデータ量が減らせるから、である。 　また、日付の記録も統一されていなかっただろう。そうした中では、たとえば日付を元号で記録しており、その元号の違いを、コンピュータの2進数「00」「01」「10」「11」で表しているケースもあっただろう。「明治、大正、昭和、平成」の4つの元号を、それぞれの数字に割り当てるわけだ。 　こうしたシステムでは、次の元号が来ることが想定されていない。改良するには、保存されているデータを、全て書き換える必要がある。そして、対応するプログラムも書き直さないといけなくなるのだ。 　世の中には、昭和100年問題というものもある。年数を昭和で記録しているために、100年になった時に0年に戻るという問題だ（参照：Wikipedia : 昭和100年問題）。 　あるいは、元号をアルファベットで表していることもある。明治は「M」、大正は「T」、昭和は「S」、平成は「H」。もし、次の元号の頭文字が「MTSH」のどれかだった場合は破綻する。その場合は、頭文字ではない文字を割り当てるなどして、対応することになるだろう。 　それだけではない。元号が3文字になった場合に、帳票からはみ出るという問題が発生するかもしれない。また、コンピュータで簡単に表せない文字の元号が採用され、どう対応するか苦労するかもしれない。 　いずれにしても、プログラムを直したら、それが正しく動作するのか、テストする必要があるのだ。30年稼働しているシステムなら、30年分のデータで問題が発生しないか確認した方がよいだろう。途中でデータの形式が変わり、プログラムの処理が分岐している可能性もある。 　大きなシステムなら、修正箇所が何万とあるだろう。その全ての修正で問題がないか、テストを行うわけで、気が遠くなる……。