日本だけの問題ではないITの新元号対応

　新元号への切り替えは、コンピューターにとっては時間の扱い（入力、表示、計算）に影響する可能性があります。

　同じような問題としては、過去に2000年問題がありました。これは西暦を下2桁で扱うシステムが2000年を1900年と誤判断することに起因するシステムの誤動作の問題でした。今後も、2025年問題（2025年は昭和100年であることに起因）や2038年問題（UNIX時間が古い時間型でオーバーフローすることに起因）など、既に可能性が指摘されている問題が後に控えています。

　新元号への切り替えもまた、これらの問題と同様のリスクをはらんでいます。現在、世界中で元号を用いているのは日本だけですが、ITのグローバル化、多言語化が進んだ現在、これは日本だけに閉じた問題ではありません。

　たとえば、WindowsやMicrosoft Officeに対して行われる新元号対応は、日本版だけの問題ではなく、使用言語に関係なく、サポート対象のすべてのWindowsやMicrosoft Officeに対して行われます。これはまったくの想像ですが、WindowsやMicrosoft Officeの新元号対応のための修正に取り組んでいる開発担当は日本人ではないでしょう。しかも、Windowsにとって、新元号の切り替えは今回が初めてのことであり、何かしらの問題が生じると予想しています。

　マイクロソフトの製品およびサービスについては、以下のサポート情報のリンク先で新元号に対応予定の製品やサービス、現時点の対応状況（関連する提供済みの更新プログラム）が案内されています。


　原則として、マイクロソフトのサポートライフサイクルポリシーに従って、サポート期間内にある製品およびサービスに対して新元号の対応が予定されています。Windowsの場合は、Windows 7 SP1以降とWindows Server 2008 R2 SP1以降で、.NET Framework 3.5以降との組み合わせで新元号への対応がサポートされる予定です。Microsoft Officeの場合は、Office 2010 SP2以降がサポートされる予定です。

業務アプリケーションに問題がないかどうか事前検証を

　マイクロソフトは自社の製品とサービスに対して新元号対応を進めていますが、それが完了すれば問題解決というわけでは決してありません。Windows上で利用するアプリケーションが対応している必要があるからです。

　たとえば、ある業務アプリケーションは日付情報を「日付/時刻型」で保存していたとしても、入力のためのドロップダウンリストには「明治」「大正」「昭和」「平成」の4択しか用意されていないかもしれません。またある業務アプリケーションは和暦の日付をテキスト型で保持していて、独自の入力チェックを行っているかもしれません。元号の切り替えを挟んだ日付計算が、開発時には想定していなかったため、まったく誤った結果を返すかもしれません。

　以下のサポート情報に示されているように、最新状態に更新済みの複数のWindowsバージョン（すべてのバージョンではありません）において、現時点でも新元号への対応をテストできる状態になっています。


　このテストの目的は、Windowsのカレンダーの和暦表示をテストすることではありません。Windowsを西暦表示で使用していても、アプリケーションレベルで和暦で入力や表示をできる、あるいは要求する場合があります。Windows上で動作するMicrosoft Officeアプリケーションや業務アプリケーション（Officeベースや.NET Frameworkベースなど）、市販のアプリケーションの対応状況をテストして、問題が生じないかどうかを確認することができます。市販のアプリケーションの場合は、開発/販売元に確認するほうが早いかもしれませんが、独自にカスタマイズしている部分が無いとも限りません。

　そこで、2018年12月時点で最新の更新状態のWindows 10バージョン1809（OSビルド17763.195）とMicrosoft Office 2016（バージョン1811、ビルド16.0.11029.20108）の環境を使用して、新元号の日付入力と表示の簡単な検証を行ってみました。

【次ページ】AccessデータベースとExcelシートの検証例