システムの新元号対応について

ちらほらとですが、企業システムの新元号対応の依頼が弊社にもきております。

以下、今年5月の「BCN+R」での関連記事の抜粋になりますが、やはりさまざまな影響が出ることが想定されますね。

新元号の発表は、2019年5月1日の改元の半年前と言われていた時期もあったが、新聞報道によると、政府会合では改元1カ月前に発表する方針で固まったようです。

民間企業の日常業務では西暦を使うことが多いが、官公庁、金融機関、公的機関に提出する文書等では、まだまだ和暦が使われており、日々の業務で使われている
システムが新元号に正しく対応できるかは、業種を問わずあらゆる組織における関心事になっている。

マイクロソフトは、新元号対応に関する情報をまとめたサイト「Japan New Era Name Support Blog」で、「合字」の問題を指摘している。

合字とは、例えば「平成」という複数の文字を、1字分の文字で記号のように表現したものだ。これは元号のほか、単位や法人格でもよくみられる。

和暦の表示にこのような合字を使用しているシステムが「相当数存在」するという。
国際的な文字コード標準化団体のUnicodeコンソーシアムでは、日本の新元号のためにコード位置を確保するようすでに提案が行われており、コード「U+32FF」が割り当てられる見込みだ。

当然のことながら、新元号の発表後にフォントのアップデートが行われるまで、U+32FFは字体が存在しない“空き地”だ。

フォントを更新した環境では新元号が表示されるが、それ以外の環境では空白や他の記号などになってしまうだろう。

個人や限られた範囲で利用する文書ならともかく、役所や銀行が発行した書類の日付が「〓01年05月01日」というわけにはいかない。

各端末のフォントのアップデートとテストだけでも、トータルの作業量はそれなりのものになりそうだ。

単に表示や印刷ができないだけではない。明治から平成までの合字はコード位置が連続していたが、その前後にはすでに別の文字が割り当て済みなので、新元号は飛び地に割り当てられている。

西暦から和暦合字に変換する処理の中で、合字のコードが連番であることを前提にしたプログラムが書かれていた場合、複雑な改修が必要になる。

複数のデータを日付順に並べ替える、新元号を含むデータを検索するといった処理も、正しく動作しない可能性がある。

また、元々のデータが和暦で作成されていると、対応はさらにやっかいだ。

日付を西暦でなく和暦で管理しているシステムが今どき存在するのか疑問だったが、朝日新聞の5月18日報道によれば、

政府は「システム間のやり取りを西暦で統一するよう、関係省庁に中長期的な改修も指示した」といい、

現在でも一部でシステム連携に和暦が使われているようだ。
（古いプログラムでは現在もまれに昭和2ケタで日付を管理しており、3ケタにあふれる2025年の誤作動が懸念される「昭和100年問題」もあるという）

手書きの書類をスキャンして、文字認識によってデータを入力するような業務でも、認識エンジンの新元号へのチューニングが1カ月で行えるかはわからない。

そのほか、新元号が3文字以上になったり、ローマ字表記の頭文字がこれまで略称として使われてきたM・T・S・Hと重複したりするかもしれない。

ここまで挙げたすべての問題は「あくまで可能性がある」水準のものだが、業務に使うシステムである以上、きちんとテストする必要がある。

改修作業そのものよりも、検証により多くの手間と時間を要するケースも多いだろう。
また、国内では大企業も含めほとんどの組織が、情報システムの保守・運用を外部のITベンダーに委託している。

仮に1件ごとの改修・検証は短時間で済むとしても、来年4月はITベンダーに改修依頼が集中するため、案件をさばききれなくなる恐れはある。

「そもそも改元を想定していないシステムが悪い」「和暦でデータを入力するユーザーが悪い」といった意見はもっともだが、そのようなシステムやデータが現実に存在する以上、何とか対応しなければならない。

エンドユーザーとしてはITベンダーにまかせるしかないわけだが、単に設定ファイルに1行書き加えれば済むというものではないことは知っておく必要があるだろう。