IT事業部の山田です。
新元号が発表されましたね。いよいよ平成も残すところあと1ヶ月となり、色々と感慨深いこともあるわけですが、ついつい考えてしまうのが「システムの新元号対応」の事。
残り1ヶ月という限られた時間の中で、「令和」という新元号に対応する必要があるわけです。
「え？ それってそんなに大変なの？」
そう。実はそんなに大変ではない「はず」なんです。
でも、既に動いているシステムというのは、非常に厄介でして。
システムを構築したときに、どんなルールで「平成」を実装したかによっては、非常に大きな改修が必要になるケースもあるわけです。
例えば。
「このシステム、昭和と平成だけに対応しておけば大丈夫でしょ。次の元号までこのシステムが動いているとも限らないし」
なんて設計思想でつくられたシステムだと、元号選択は2択しか考慮されておらず、それを今回の対応では3択に増やす必要が出てくるわけです。
例えば。
㍼←これ、とか。㍻←これ、とか。
合字、とよばれる仕組みです。（機種依存文字なので、ご覧の環境ではきちんと表示されていないかもしれませんが）
これを使っていると、とにかく厄介なんです。
先程わざわざ「機種依存文字なので」と注釈を追加したのは、システム上で動作する文字コードというものの取り扱いが非常に厄介だから。
例えば。
今年の5月以降は、2019年を和暦で表すと「令和元年」と呼びますよね？
でも、プログラムの内部で「1年」を「元年」と置き換える必要があるわけで、これをきちんと対応するのは非常に面倒だったりもします。
「01年」と表示したいケースもないわけではありません。（銀行の通帳など）
さらに。4月末までは「平成31年」なので、その条件分岐も必要になることもあります。
ちなみに、これ。
大手のMicrosoftですらやらかしてしまう問題なので、日本のエンジニアの能力不足によるものではないことだけ付け加えておきましょう。
上記に上げた「たとえ話」は、一つ一つは些細な問題です。
でも、「そんなに長い期間使うシステムじゃないから、今動けばいいや」なんて考えで作られたシステムが今も可動している場合、こういったことを考慮しなければならないわけです。
大手銀行の通帳の日付が、昨年末からそれまでの和暦表示から西暦表示に変更されたそうです。
おそらく、1ヶ月の元号対応のリスクを考慮して、先に対策をしたんだと思います。
「新元号対応、そんなに大変なの？」とお考えの方に、その大変さが伝わればと思います。
（と同時に、新元号対応が大変なシステムってのは、そもそも「安かろう悪かろう」というものも多いんですよ、という皮肉も込めて）