元号が変わるとSEが死ぬ理由

2019年4月2日 2019年8月6日

元号が変わるとSEが死ぬ

そう多くのメディアでまことしやかに言われてきました。
しかし何故死ぬのか？今回の新元号「令和（れいわ）」発表のケースだと何が問題だったのかを、(できるだけ)素人にも分かりやすく書いてみようと思います。
ちなみに、Kixiは官公庁向けのとあるシステム改修(20年選手の継ぎ接ぎだらけの古いシステム改修)に携わりましたが、なんとかデスマーチを回避しました。

そもそも何故システムに影響が出るの？

めちゃくちゃわかりやすい図。
あらゆるシステムで「和暦」を使っているもの。
特に国系のシステムや古いパッケージを使っているとよく出会いますね。
「なんだプルダウン増やすだけか～」
と思ったら大間違いです。
まず、こういったシステムは元号が増える事を想定していない事が多々あります。
例えば、平成をラベル(文字)で出していて、年、月だけプルダウンが用意されていたり…
そうなれば、日付の大小比較をしてエラーチェックをしているような処理は当然影響が出るし、画面⇒ロジック(処理)の間でそもそも元号の値が渡っていない事も想像できます。
最悪の場合、古いシステムだと年を和暦2桁で持ってたりするので、新元号のタイミングでデータの持ち方から大きく変更する必要が出てきます。

SEが死ぬ理由

そもそも、「日付」というものは、システムに密接に関わっています。
見た目以上に、内部に影響を及ぼす事を知らない人がとても多いのです。
修正していると芋づる式に大量の修正箇所が出てきて、それを再調査したり、修正したり、ちゃんと修正できたかテストしたり…。
それが、画面数分(項目数分)、帳票数分、あるいは夜間バッチ処理やデータ取り込み用のファイルにまで広く影響し、当初「画面くらいか～」と思っていたSEが絶望したり、あまり分かっていない営業が恐ろしい契約を取ってきたりする訳です。
これを加速させる要因の一つが、新元号発表の猶予期間1ヶ月。

元号発表を1ヶ月前に発表する事による無駄な作業について

大きなシステムでは、1ヶ月で元号を全て修正して、全機能をテストするのは至難の業です。デスマ不可避です。
対処法としてよくあるのは、下記2つでしょうか。

当て字方式

「新元」「＠＠」「安久」など、それっぽい字で仮作成し、動作だけ確認します。
最後、元号発表後に、全て当て字を差し替えて再テストを行います。
無駄が多いです。
1年前から発表してくれていたら、当て字の置換も、再テストも不要です。
大変な経済的損失になっている気がします。

ライブラリ化方式

元号の設定箇所を一元化します。
例えば、DBの特定の項目に設定し、全ての元号を参照する機能はそこを見るようにするなど。
XMLなど設定ファイル系が多いですね。
すでにライブラリ(共通)化しているものは、修正が比較的ラクです。
ただし、毎回標準ライブラリ(例えばJavaのDateクラスなど)で元号変換してるようなシステムだと、Javaのライブラリが対応してくれないと下記の作業が必要になります。
①元号用のライブラリを作成
②何千箇所もある旧(新元号非対応)ライブラリの呼出箇所の修正
無駄が多いです。
しかも結局再テストは必要です。