改元対応の実際

　新元号への移行にともなって発生する問題は、基本的には表示や印刷に関する範囲と考えられている。しかし、OSやミドルウェアの仕様によっては予期せぬエラーが発生し、業務フローの見直しが必要な場合も考えられる。

「和暦対応」製品でも仕様に注意

　前出の通り、改元が起こることを前提に設計されているシステムであれば、基本的には元号マスターのメンテナンスだけで新元号への対応は完了する。検証用の環境で仮の新元号を定義し、来年5月1日以降の日付を指定した場合にそれが正しく表示されることを確認すれば、新元号への準備は万端ということになるはずだ。

　しかし、現実の業務に当てはめると、必ずしも机上の計画通りには新元号へ移行できないケースも考えられる。

　例えば、和暦の表記が原則で、来年5月時点ではまだまだ平成表記の文書や伝票が多数存在する業務を考えてみよう。それらの情報を手作業で登録する場面などで、「平成32年1月1日」が入力された際、システムとしてはそれを2020年の1月1日として解釈するのが理想的だ。「平成32年」と書かれた文書を見た入力担当者が、それを「2020年」ないし「新元号2年」と読み替えて入力するというやり方で解決する方法もあるが、作業ミスが発生する可能性があるからだ。

　しかし、システムによっては「平成32年1月1日」が入力された場合、存在しない日付としてエラーを返す仕様になっているものもある。例えば.NET Frameworkでは、和暦をDateTimeオブジェクトに変換する処理において、「昭和65年」「平成32年」のように各元号の最終年を超える日付を許容していなかった。日本マイクロソフトではこの問題に対応するため、.NET Frameworkの更新プログラムを配布し仕様を変更する（従来の仕様で動作させることも可能）。同社製品に限らず、他の西暦－和暦間の変換を行うミドルウェアやライブラリーでも同様の問題が発生する可能性はあるので、「和暦対応」をうたう製品であっても、その仕様を調査した上で、どのような動作をユーザーが求めるかに応じてシステムの修正を行う必要がある。

　また、アプリケーションレベルで独自に和暦への対応を行っているものに関して、従来と同じ業務フローが継続できるかを検証する必要もある。

　例えばExcelでは、表示形式を日付に設定したセルについて、和暦を使用することができる。ユーザーが意識しなくても、1989年1月7日は「昭和64年1月7日」、その翌日は「平成1年1月8日」と表示され、異なる元号をまたいだ日数計算も可能だが、改元以降、新元号でも同様の機能が提供されるのか、アプリケーションの開発元に確認する必要がある。

合字を使うシステムが「相当数」存在

　さらに、日本マイクロソフトは「合字」の問題について開発者向けブログなどで指摘している。合字とは、「㍻」のように2つ以上の文字を1文字の記号として表現したもので、過去のシステムとの互換性確保のため、現在でも明治から平成までのコード位置が定義されている。同社が今年春までに調査したところによると、和暦の表示などにこのような合字を用いているシステムが「相当数存在する」という。
 
　文字コード標準化団体のUnicodeコンソーシアムは今年、新元号を示す合字のコード位置を「U+32FF」とすることを決定した。西暦－和暦の変換を行うプログラムでは、新元号の入出力に関してこのコードを扱えるようにしておく必要がある。ただし、明治から平成までのコードは連続していたが、その前後にはすでに別の文字が割り当て済みのため、今回の新元号は平成に続く番号ではなく、“飛び地”となっている点に注意が必要だ。
 
　また、新元号対応に関する一部の調達仕様書（例：厚生労働省「労働基準行政システムの新元号対応等に係るアプリケーションプログラム改修業務一式（平成30年度開始）」）を見てみると、元号を識別するコードを「明治：1／大正：3／昭和：5／平成：7」と定義しているシステムも存在している。

　新元号のコードは「9」となるわけだが、順当にいくと次々回の改元では「11」を割り当てるため、コードの2ケタ化が必要となる。実際に前出の調達仕様書では2ケタ化も要件に含まれており、改元を前提としたシステムであったとしても、やっかいな開発が必要になるケースがあることが分かる。

　ベンダー数社にあたった限りでは、新元号への対応は通常の保守契約の範囲内で、追加の費用を請求できていないケースが多いようだ。ただ、改元の度にこのように複雑な改修やテストを行っていくのは生産的ではない。「言うは易し行うは難し」かもしれないが、どこかのタイミングでユーザー側の理解も得て、和暦から西暦への全面移行を行うのが理想的だ。