元号が平成から令和に変わって既に1ヶ月が過ぎて、全然タイムリーな話ではなくなってしまったのだが、思ったところを書いておこうかなと思います。やっぱりちょっとしたシステムトラブルは、世間的にもそれなりにあったみたいですね。

平成の時代に新規に構築されたシステムの場合、それに関わるほとんどの人は昭和から平成の元号の変更を記憶としてあるはずなので、元号は変更されうるもの、という事がわかって設計しているだろうし、おそらく日付データの年はシステム内部的にはできるだけ西暦で保持して、どうしても和暦で扱わないといけないところだけ、インタフェースなどで対処する、という形になっているのではないかと思う。

私がこれまで関与したシステム構築案件でも、ある程度仕様を踏襲すべき旧システムにはいろんなところに和暦があったものだが、基本的にシステム内部は西暦で統一する活動をするのが普通だったと思う。

私の経験の中で、どうしても和暦を扱わざるをえなかったのが、銀行の入出金取引明細を全銀協フォーマットで取り込むところだった。インタフェースで外から来るものが和暦だというのだから、対応はせざるを得ないものだった。しかし、このフォーマット、日付項目が年部分2桁の6桁で、年部分2桁は和暦による年だと定義されているのだが、元号を示す値はないという、ある意味致命的なレイアウト。システム内部では西暦で保持する為に和暦⇒西暦の変換が必要なのだが、どの元号かが示されなければ、正しい変換はできるわけないよね。

現実的なところでは、このデータフォーマットで大幅に過去や未来の日付を扱う事はないという前提のもとに、年2桁部分から元号を判定するのが妥当なところなのだと思う。例えば、「30年以上なら『平成』、30年未満なら『令和』」みたいなロジックになるようにして、ここで判定に使う年数とか結果の元号を設定でコントロールできるようにしておく、ような感じで。こうしておけば、令和29年までか、もしくは次の改元が見えてくる時まではそのまま対応可能で、その頃には平成30年のデータなどこのフォーマットでは扱う事はなくなっているので、基準年や元号などの設定を変えればよい、という事になると思う。これも今になって思えば、という話で、私が実際の案件で対応した時もそんなふうにはできていなかったなぁ、と思う。

しかし改元のタイミングに実際に立ち会わないと中々現実的に妥当な対応は考えられないものですね。改元がいつ来るのか見えていない状況で平成の時代に構築されたシステムでは、一応「元号は変わりうるもの」として考慮はしていて、全く何も考慮せずにハードコーディングしているなんてことはそうそうないとは思うが、実際に改元の時期にどんな感じのデータが発生しうるのかの考慮が足りていない事が結構ありそうな気がする。だから例えば「その元号の設定は4月30日のしかるべきタイミングに変える必要がある」みたいな話になったりする。
上記で例に挙げた入出金取引明細で言えば、銀行によって切替のタイミングが微妙に違うとか同一ファイル内に「31年4月」と「01年5月」が混在しうるとかがあるので、単一的に「現在の元号」を設定可能にしておくだけでは対処できなかったようですね。まあ、よく考えればわかることなのだろうけども、そこまで考えて対応できているケースは現実的にはあまり多くなさそうで、具体的にシステム改修まではせずに、改元前後の「運用でカバー」というケースが実際多いのだろうなぁと思います。また、前の「昭和から平成」の時には、先に元号が変わってしまって、システム対応は事後的に行ったのだろうから、必要な対応は今回とはまた違ったんだろうな、とは思う。

というわけで、なかなか滅多にない事なので、システム対応を万全にしておく、というのも難しいのでしょうね。それこそ「運用でカバー」するしかない、というか、すればよい、と済ませてしまう事になりがちなんでしょうね。