改暦のはざまで　…1月8日では遅すぎる

突然の改暦
1988年秋、「天皇陛下の容態悪化」というようなニュースが連日報じられるようになった．

その頃私はある会社の商品の見積りシステムを開発中だった．
まだ打ち合わせ段階で、プログラムの製造には入っていなかった．それまでの打ち合わせでは年号の表記は和暦にして欲しいとの要望だったが、いつ「昭和」が終了してしまうかわからないという状況になってきた．顧客には改暦に対応したシステムにするだけの予算も期間もなかった為、このニュースを聞いて再確認し、西暦表記に変更することになった．システムが完成した頃には平成になっており、ほっと胸をなでおろしたものだった．

こういう場合はとても気を遣う．重要人物が亡くなることを想定すること自体をけしからんと思う人が少なからず存在するからだ．この時も、ニュースには触れずに、和暦のままで本当に大丈夫かと念を押すだけで済ませた．

改暦後の開発
別のシステムでは、担当プログラマーが1989年1月7日までは昭和表記、1月8日以降は平成表記をするべきだと勝手に決めつけて苦しんでいた．年・月・日を個別に比較するロジックを何十本ものプログラムに組み込むため、テストに膨大な時間が必要となるからだ．
業務内容によってはそんな必要はなく、1989年は元日から平成表記で構わない場合も多い．そうすれば「年」の比較だけで済み、格段に楽になる．実際、多くの企業が昭和64年は存在しないものとみなして仕事をしていたように思う．
そのシステムもそうだったので、プログラマーがSEにも顧客にも確認せずに必要以上に複雑なプログラムを作ろうとしていたことを叱った．不要なロジックを入れることで間違いなく納期に間に合わず、バグが多発するのが目に見えていたからだ．

そういう意味では、昭和64年がほとんど経済活動のない松の内に終わってしまったことは、プログラム開発の視点ではラッキーだったと言える．7月頃に改暦されたりしたらそうはいかなかったはず．

★考察

改暦処理の問題点
特定の人物の生死と元号・改暦が密接に結びついている、日本特有(?)のこの仕組みは、開発期間数カ月というような小規模なシステムでは開発費や開発期間などからみてかなり負担になっていた．

・改暦前
プログラムの運用期間中に改暦があるかどうかは未確定で、事前に作り込んでおいても使われないまま廃棄される可能性も大きいので、改暦を想定して改暦処理を作り込んでおくことはほとんどされない．

1つの伝票に昭和と平成を混在して表記しなければならない業態では常に西暦と和暦の変換が必要になる．実際の改暦日を想定できないので、様々な日付でのテストをすることになり、テスト工数(つまり開発費用)などがかなり増加する．
上記の事例の様に年だけ判別すればよい場合もある．でもこれは改暦後でないと判明しない．

コンピュータ史上初の改暦で、昭和が60年以上も続いていたこともあり、開発者も顧客も改暦なんて頭になかったということもある．結局現在の元号を固定で使っているシステムは結構多かった．

・改暦後
いざ改暦した時は急いで対応する必要があり、プログラムを修正した頃には不要になる場合もあるので、顧客も改修予算をつけにくい．
特定の1人のプログラマーにとっては、改暦時期のプログラムの開発には一生に一度しか遭遇しないし、教えを請うための先輩も未経験だったりするので、経験を応用することもできず、完成度の低いプログラムになりやすい．

改暦に合わせてプログラムの改修をしようとしても、製造時のプログラマーは退職後で修正箇所を見つけるのも困難、あるいは開発会社自体が倒産していた、という事態も珍しくないだろう．

現在の対応
現在では、WindowsならOSに西暦と和暦の変換関数があるらしいので("和暦変換API"で検索)、きちんとその機能を使って作られたプログラムならあまり問題にならない…と安心して良いのだろうか．

たぶん新元号はWindowsのアップデートなどで追加されるんだろうが("windows 元号 アップデート"などで検索)、それは何カ月もかからず迅速におこなわれるのだろうか？その際、メインストリームサポートが終了してしまったWindows 7やそれ以前のOSもサポートされるのだろうか．
もし対応が遅かったり対応されなかったりしても、上記の様な理由でプログラムの改修ではとても対応できそうにないので、新OSへの買い換えと動作チェックが必要になり、これはこれで社会問題になりそうだ．

世の中、優秀なプログラマーばかりではないのは、あらかじめ日付がわかっている2000年問題の時ですら世界中で大騒ぎになったことからも明らかだ．Windowsの変換関数を知らないか面倒がって使わずに、プログラムに「平成」と固定的に記述されてしまっているシステムも多分まだあるだろう．この改修もきっと問題になるだろうな．
また、データ入力の時に和暦で入力しているシステムで、元号入力の選択肢がなく平成固定になっている場合は、間違いなく改修対象のはずだ．

【警告】 元号を扱うソフトウェア(特に自社専用の特注アプリケーション)を使っている会社は、改暦への対応状況を製造元に確認しておくべきだね．Windowsの日付に依存している場合は、マイクロソフト社やPCの購入先にアップデートの有無などを確認しておいた方がいいのではないかと思う．
今後開発を依頼する場合は必ず改暦対応を視野に入れておこう．

★オマケ

杞憂?
今後、人の寿命が100年を越えるのが当たり前になる可能性があるが、それでも「一世一元」を続けるのかなあ．そうすると和暦が3桁になったりするし．早ければ次の和暦でそうなるはず．まあ問題が顕在化するのは100年以上先だけど．

奇妙なカレンダー
・ Windows 7の設定を和暦表示にして、カレンダーで1989年1月7日を表示させると昭和64年1月のカレンダーが7日までしか表示されないし、1月8日にすると平成1年1月が8日以降しか表示されない．こんなに厳密に表示されるなんて、頑張って作り込んだんだね．でも1カ月全部の日が表示されないなんて、カレンダーとしては欠陥品だけど．

・ Windows 7のカレンダーは1900年から2099年まで表示できる．1900年は明治33年、2087年は平成99年と表示されるが、2088年は平成0年と表示される．やっぱり和暦の3桁には対応してなかった．

・ Windows Live メール 2012のカレンダーも調べてみたら、和暦設定にすると西暦の英語で表示されるというとんでもないバグを見つけた．こんな基本的なバグがユーザーからのクレームもなく(？)何年も残っているなんて、結局誰も使ってないということなんだろうなあ．