（4）データベースへの項目追加の必要性判断

　これは特に人事系システムや会員データベースを持つシステムで注意したい点だ。従業員や会員の生年月日のデータについて、システムによっては、「明治」「大正」「昭和」「平成」とそれぞれの元号を1つの項目で管理するデータベースを持つものもある。

　その場合、5つ目の項目を追加するのか、これを機に和暦西暦の変換処理を実装するかを考える必要があるだろう。将来のシステムの在り方と、コストや時間を勘案した上で対策を考えたい。「M・T・S・H」のチェックボックスやリストボックスを持つシステムも同様だ。

（5）合字、文字コードの注意点

　元号の表記に「昭和」「平成」の2文字を合成して1つの文字コードとして表示する「合字」を使用するケースがある。

　今は「Unicode」（UCS）ベースの文字コードを使用するシステムが多く、平成は「U+337B」、昭和は「U+337C」、大正は「U+337D」、明治は「U+337E」と記述され、それぞれの合字には連番の文字コードが割り当てられていたが、新元号の合字には「U+32FF」の割り当てが予定されている。今までは末尾のアルファベットが連続していたが、新元号は従来のパターンとは異なる。連番を前提とした文字コードを用いている場合は注意が必要だ。なお、文字コードがシフトJISのシステムもまだ多くある。この場合は別途検討が必要だ。

（6）新元号でOCRが正しく認識するかどうかも確認

　これは新元号が発表後の対応となるが、業務でOCR機能を持つシステムやアプリケーションを利用する場合は、新元号が正しく読み取れるかどうかも確認したい。中にはOCRを使い、帳票処理の自動化を業務プロセスに組み込む企業もあるため、ここが意外な落とし穴となる可能性もある。