ブログご訪問ありがとうございます。

新元号のシステム対応

平成も残りわずかとなり、平成時代に青春時代を送ってきた身としてはどこか寂しさを感じてしまいます。
とは言え必ずやってくる新しい時代に思いをはせつつ、われわれシステム屋としては、目下の問題である「今平成って出ているシステムって大丈夫なの？」と言う問題について考えなければいけません。
今回は自分たちの対応のための前準備を含めて、PHP/VB/Accessと言う当社が抱えるシステムについての対応を書いていきます。

①現状の表示方法を確認する
弊社ではサーバーを用いるWEBシステムについてはPHPで作成しています。
そもそもの作りとして抽出される書面は西暦で表示されているのですが、やむを得ず和暦を使うものについては、以下のようなフォーマットを作成し、対応してきました。

//新元号元年（2019年5月1日以降）
if ($date >= 20190501) {        
	$wareki = "不明";
	$year = 2018;
//平成元年（1989年1月8日以降）
} else if ($date >= 19890108) { 
	$wareki = "平成";
	$year = 1988;
//昭和元年（1926年12月25日以降）
} else if ($date >= 19261225) { 
	$wareki = "昭和";
	$year = 1925;
//大正元年（1912年7月30日以降）
} else if ($date >= 19120730) { 
	$wareki = "大正";
	$year = 1911;
//明治元年（1868年1月25日以降）
} else if ($date >= 18680125) { 
	$wareki = "明治";
	$year = 1867;
} else {
	$wareki = "西暦";
}

上記のように$dateの日付に合わせて和暦の表示が変わるよう関数を作成し、commonファイルに入れておけば汎用的な対応ができて便利です。
弊社では和暦表示についてはPHPもVBも原則同じフォーマットを利用して表示させるようにしています。

これについては設計した先人の知恵で感謝の他ありませんが、意外と何も設定をしていないのが、AccessやVBなどの和暦返還を書式変換和暦：GGGE"年"MM"月"DD"日"で対応してしまっているケースです。
Accessなどではレポートなどでも書式変換がされていれば簡単に変わってしまうので、わざわざ上記のようなソースを書かなくてもよいというメリットがあります。（Functionにしてしまえば呼び出すだけなんですけどね。）

②Accessでの和暦表示
Accessで書式変換和暦：GGGE"年"MM"月"DD"日"で対応してしまっている場合は、マイクロソフト社からの修正プログラムによって新元号が使えるようになる予定です。（2018/12/03現在段階）
但しサポートが続いている場合が前提であり、サポートが終了しているOSやOfficeを使っている場合は、修正プログラムが行われず変更ができません。
具体的にいうとOSについてはWindows7、Officeは2007以降であればサポートはされますがそれ以前のものはサポートがされていないため、そのままにしておくと、いつまで経っても平成のまま時は過ぎて行ってしまいます。

③サポート終了のものはどうすればよいのか
当然冒頭に書いたようなプログラムを作成するのが一番です。
ちょっとしたメンテナンスができるようでしたら、例えばAccessのレポートなどは書式変換されている場所を、和暦から西暦に変更されるのが無難です。
メンテナンスができない場合については新しくプログラムを修正するか、まだ見ぬ平成32年以降も気にせずに使い続けるしかありません。

④まとめ
今回はシステムの新元号対応で、注意すべき点を考えてみました。

和暦の帳票があるかどうかを把握する
修正が新元号の追加で済むのか、または修正バッチだけで直るのかを把握する

システム作成時には「変わるものは変わった時の事を考えて対応を行う」のが原則ですが、作成者の意図によって変更のプログラムが必要になったりするケースもあります。変化のある時にはキチンと作成者に仕様を聞いて、直前になって慌てないよう前もって準備を進めておきましょう。

もしAccessでの改修や管理にお困りごとがあれば弊社までお問い合わせください。
担当者がいなくなったシステムや、よくわからない機能がある、作り変えたいけど費用も抑えたい、などご要望にお応えさえていただきます。