元号対応はシステムエンジニア(SE)にとって悲劇?幸運?

2019年4月1日に菅官房長官より、新しい和暦「令和」が発表されました。
新しい時代の幕開けに日本中が喜びに包まれる中、IT業界は、

「ついにこの時が来てしまった」

「サマータイム導入案以来のざわつきだ。」

といった感じ。

しかも5月1日には令和が適用開始となるため、準備期間は30日未満(もちろん、ある程度は事前に対応しているだろうけど)

調査、製造、テストを1か月でこなす!

エンジニアの皆さん頑張りましょう。

僕もエンジニアとして開発しているので、過去の経験から元号対応が必要な箇所やリスクを考えてみましたので、元号対応の参考にしてみてください。

化石的なシステム対応なら元号対応の改修ポイントを事前に予習しておくべき

基本的に年号はDBから年度を取得しているだけだし、一般的なSE(システムエンジニア)が作った設計なら、先の元号対応を見越して、西暦を使っているはずですが、古いシステムや自治体システムだとまれに和暦が使用されています。

特に化石的なシステム(古くから運用されていてあまり手を付けられていないシステム)だと、良く分からない箇所に和暦を使っている可能性があります。

さらに、そのようなシステムはえてして、設計書も不親切な可能性があり、和暦箇所を見つけるのに苦労します。

だからこそ、一般的にトラブルになりそうな状況をあらかじめ考えておいた方が良いです。

エンジニアのみなさん、元号対応のバグ発生でニュースにならないようにしましょう(笑)

元号対応のシステム改修で問題になりやすい箇所はここだ

元号対応に伴うシステム改修で問題になりやすい箇所をざっと考えてみました。

これから元号対応する方は改修前に参考にしていただけたら幸いです。

元号対応の箇所①旧システムは固定値

古いシステムの改修の場合は、プログラムソースに固定値が書かれていないか確認する必要があります。初期コストをかけずに作った納期短めなシステムはその場しのぎで固定値記述があったりします。

変なところに平成と書いていますよ。

まずはどこに記載があるのか、ソース全検索から開始です。

GREP検索で”平成”と検索してみてください。

予想だにしない箇所に平成と書かれているはず。

そのまま、固定値を継続するなら平成を令和に書き変えましょう。

でも、固定値の場合は平成が使えなくなるので、年度をDBやメソッドから取ってきて分岐した方が良いですね。

というか、暦を固定値にするシステムとか、終わってますよ。

元号対応の勘所②元号切り替えは西暦に直す

担当システムが和暦なら、この機会にお客様に西暦採用を提案しましょう。

そもそも和暦を採用するメリットがありません。

西暦と独自の暦を採用しているのは日本だけではないでしょうか。

西暦に統一してもデメリットはないはず。

今後は外国人の移住が増える中、いつまでも和暦を使っていたら、外国人にも煙たがられます。
外国人にとって、2つの暦があるのって、かなり邪魔くさいみたいです。

移住を促したいなら、行政機関が積極的に西暦を使うべきだと思います。
外務省も西暦採用を推奨しています。

「それでもDBから取得した和暦を使う!」という分からずやなお客様には新たに令和を使うしかありません。

年度を使ってif文で20190429< Nendoなら、”令和”;、elseは平成(システムによっては平成と昭和を分ける必要あり)を入れてしまいましょう。 int型の年度を分岐条件に使って、昭和、平成、令和と切り替えてください。

元号対応の勘所③DB取得のデータ定義に気を付ける

DBから和暦を取得している場合は、和暦を登録しているカラムのデータを西暦にUPDATEするだけで良いはず。

どちらかと言うと、システム開発より、データメンテ作業です。この改修が一番簡単です。

でも1点落とし穴が。

その和暦が入っているカラムのデータ定義です。

データ型がもしchar(2)とかだとまずいです。

2桁しか入らないので、西暦が入れられません。

この場合はALTER文でデータ定義を変更する必要があります。さらに、西暦(=4桁)を入れることで画面表示する際に表示が崩れたり、システムエラーが起きたりしないか、をテストしておかないといけません。
一番簡単なようですが、DB定義次第では一番面倒になる可能性があります。

和暦採用は誰が得?システムエンジニア(SE)です!

和暦採用って結局のところ、いいとこなしです。(システムに限っては)

メリットが1つも見当たりません。

なのに、なぜ採用するんでしょうか。

日本っぽさを残すためですかね?

でも、それならもっとジャパニーズカルチャーに力を入れるべきだと思います。

個人的にはシステムエンジニアのためだと思っています。(笑)

和暦が変わるたびにシステム対応が求められる。

それはつまり仕事が発生するということです。

和暦を変えるだけでシステムエンジニアにお金が入ります。

特に業務効率化に貢献しているわけでもないのに。

表示を変更するだけなのに。

和暦採用って、システムエンジニアの仕事のためにあるのではないかと近頃思っています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です