元号改正

こんにちは。中野です。

最近めっきり涼しいを通り越して寒くなってきましたね。
朝夕は上着が無いと体が冷えます。

10月も半分を過ぎ、もう年末に突入、という時期。

最近テレビで良く「平成最後の○○」と言う言葉を聞きますね。

平成最後の夏、や、平成最後のシルバーウィークなどなど。

平成は30年4月30日で終わります。

改元によるシステム影響を考慮して、極力早めの発表を、
と言う話は華麗にスルーされ、1月前の発表になる模様です。

私が関わっているシステムは、法制執務という
国や地方自治体の法律や条例に関わるものです。

そのため、元号の影響をもろに受けるわけです。

まっとうなシステムでは、元号・西暦の関連付けやキー値により、
新元号への対応影響を抑えています。

例えばですが、
明治=1、大正=2、昭和=3、平成=4、としておけば、
新号=5、というデータを仮に作成して置けば、事前に試験でき、
発表と同時に、新号を書き換えれば終わりになります。

　1010101⇒明治元年1月1日
　5010101⇒新号元年1月1日


という皮算用で、1月あればシステム対応は可能、と
各省庁有識者の集まった会議で結論付けられたのでしょう。

ただし、これから入力するデータに対する対応であり、
これまでに入っているデータに関してはその扱いを検討する必要があります。

たとえば、120年ぶりの改正、と話題になった民法改正については、
平成32年4月1日施行です。これはどう扱うべきでしょうか？

上記例で言えば「4320401」として登録されることになりますが、
正しくは「5020401」ということになります。

自分のシステムとしてどちらで扱うべきか？だけでなく、
関連する全システム間でポリシーを合わせる必要があります。

場合によっては、プログラム以外の膨大なデータの修正が
必要となるかもしれません。


そもそもシステム内では西暦で扱えば良いのでは、と言う話もありますが、
実際に入ってくるデータが、官公庁は元号である場合が多く、
内部データは西暦にできても、いずこかの部分に元号が入る部分は出てきます。

システム対応、と一口に言っても、私のような業務ロジックもあれば、
印刷系、UI系、OCR等々多岐にわたり、それぞれ悩みポイントがあるだろう。



とりあえず、M/T/S/H以外で始まる元号にするところからお願いしたい。


それでは。