開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2019/02/15

「新元号切り替え」は他人事ではない あらかじめ“業務アプリの挙動”を調査する方法

連載:山市良のマイクロソフトEYE 第12回

4月1日の名称公表、5月1日からの切り替えが迫っている新元号について、WindowsとMicrosoft Officeの対応状況はどうなっているのでしょうか。今回はこの話題にもう少し踏み込んでみたいと思います。Windowsのカレンダーを和暦にしていないから影響ない、という単純な話ではありません。

フリーライター 山市 良

フリーライター 山市 良

IT 専門誌、Web 媒体を中心に執筆活動を行っているテクニカルライター。システムインテグレーター、IT 専門誌の編集者、地方の中堅企業のシステム管理者を経て、2008年にフリーランスに。雑誌やWebメディアに多数の記事を寄稿するほか、ITベンダー数社の技術文書 (ホワイトペーパー) の制作やユーザー事例取材なども行う。2008年10月よりMicrosoft MVP - Cloud and Datacenter Management(旧カテゴリ:Hyper-V)を毎年受賞。岩手県花巻市在住。
主な著書・訳書
『インサイドWindows 第7版 上』(訳書、日経BP社、2018年)
『Windows Sysinternals徹底解説 改定新版』(訳書、日経BP社、2017年)
『Windows Server 2016テクノロジ入門 完全版』(日経BP社、2016年)
『Windows Server 2012 R2テクノロジ入門』(日経BP社、2014年)
『Windows Server 2012テクノロジ入門』(日経BP社、2012年)
『Windows Server仮想化テクノロジ入門』(日経BP社、2011年)
『Windows Server 2008 R2テクノロジ入門』(日経BP社、2009年)
など

photo
新元号への対応、業務アプリケーションは大丈夫か?
(©playwalker - Fotolia)

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

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

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

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

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

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

2019年5月の新元号への変更に関する更新(KB4470918)
https://support.microsoft.com/ja-jp/help/4470918/

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

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

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

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

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

日本の元号の変更について - KB4469068
https://support.microsoft.com/ja-jp/help/4469068/

 このテストの目的は、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シートの検証例

OS ジャンルのトピックス

OS ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!