システムで元号を使うのはやめよう！

言い方を変えてもう一度。
システムで処理されるものに元号表記を求めることはやめよう！

改めて。
システムで元号を使うのはやめよう！！

※ 厳密には、ここでの「元号」は、「和暦」のことを指しています。

改元後、最初の営業週が終わりました。
私は、幸運にも、改元対応に入ることなく過ごすことができましたが、改元対応に関わった方、大変おつかれさまでした。
(プログラムだけではなく、問い合わせ対応も含めて)

今回は、ちょうど良いタイミングなのでこの話を書くことにしました。
対象は、システムやソフトウェアです。
(紙の書類等については対象にしていません。すみません)

改元に伴い、様々なシステムやソフトウェアが、令和に対応しました。
例えば、Microsoft では、↓のサイトで元号変更について情報提供しています。

・Microsoft
2019 年 5 月の日本の元号変更に関する更新プログラム
https://support.microsoft.com/ja-jp/help/4470918/updates-for-may-2019-japan-era-change

ただ、↓のような懸念もありました。
Windowsの令和対応パッチ配信が始まらず、10連休に間に合わない懸念も
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04809/

Microsoft の他にも例はたくさんありすぎるので↑だけにしておきますが、「見送る (改元後に対応)」と判断されず、改元に間に合わせるように対応することになっていたものについては、連休が長い (これ自体は、基本的には良いことだとは思います) ことによる追加の検討 (バッチ処理が終わらないかも。。。改元後の負荷が心配。。。など) も付いた上で、連休返上で対応したケースもあったのだろうと思います。

それでもやっぱり、さまざまなところで不整合は起きました。

↓こんな特集が組まれてしまうほどに。
(あ、念の為ですが、記事そのものには肯定的ですよ)

令和のシステム障害特集

令和のシステム障害第1号はどこだ？改元後のトラブル10連発まとめ
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00735/050800004/

一部引用しながら、↓にコメントします。

仕様のずれに気付かず「31年5月」を印字、第1号は上天草市

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00735/050800004/

上天草市が新元号に対応した基幹系システムを稼働させたのは10連休に入った2019年4月27日だった。これに対し、水道局の事務所でハンディー端末に検針年月などの和暦データを取り込んだのは10連休前の4月23～24日とタイミングが早かった。

うーん、あるあるですね。多くの人やシステムが関わっているので、タイミングを合わせるのは、結構難しい。というか、無理だったり。それぞれ事情がありますからね。

相模原市は臨時開庁日に印鑑登録システムが2時間停止

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00735/050800004/?P=2

　システム障害の原因は、連休中に実施した元号対応における設定漏れだ。印鑑登録システムそのものの元号対応は完了したが、「詳細は明かせないが（区役所で使う）スキャナー側の設定を変更し忘れていた」（区政支援課）。

どうしても、システム本体に意識がいってしまいがちですね。わかります。

10連休明けに大阪、名古屋、仙台で相次ぎシステム障害

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00735/050800004/?P=2

　大阪市は午前9時10分ごろから約1時間にわたり、システム障害により「平成31年5月7日」と印字した戸籍証明書11枚を交付した。

　大阪市には戸籍証明書発行用に約230台のWindows 7パソコンがある。大半は5月7日朝の起動時にサーバーから設定ファイルを取得できたが、3台だけ取得できなかった。当日中に再起動したところ取得できた。取得に失敗した原因は調査中である。

まぁ。。。一部の PC だけ設定ファイルを取得できないなんてこと、普通にあるでしょうね。
これ、調査中らしいですが、個人的には、そんな労力をかけるほどのものなのか、疑問があります。

　名古屋市は午前8時45分から保険証や医療証の発行年月日や生年月日がオールゼロやオール9などで印字されたため、交付できなくなった。

　原因はプログラムの「設定の誤り」（保険年金課）。名古屋市は出生届を受理した際などに住民基本台帳ネットワークシステム（住基ネット）から生年月日などのデータを名古屋市の保険年金システムに取り込む。この際、住基ネット側の8桁の西暦データを保険年金システムの7桁の和暦データ（元号コードと和暦の年月日）に変換する。
　変換プログラムには、2018年12月31日までの元号を「平成」と扱い、2019年5月1日以降を「令和」と扱うという誤りがあった。結果、2019年1月1日から4月30日までの日付データが保険年金システムに取り込まれず、日付データが存在しない状態となり、日付の印字を誤った。保険年金システムの改修はNECに委託しており、設定が誤っていた理由は分かっていない。

これは確認不足かもしれませんが、普通にやっていれば変換プログラムの誤りには気付いたのでは。。。プロジェクトにそもそも無理があった？

　仙台市は国民健康保険料の分割納付書に「平成1年度」と記載するトラブルがあった。納付書の用紙にはもともと「平成　年度」と印刷してある。交付時にシステムで空白部に「31」と打ち出すはずだったが、「1」と打ち出した。

印刷される紙に記載されている文字は結構罠ですね。
システム上は正しいように見えても、後から不整合が発覚したりします。

トラブル判明後は納付書の「1」を手書きで「31」に修正して交付した。原因は日立製作所を代表構成員とする「仙台市国保・医療助成システム改修企業連合」に委託した情報システムの改元対応漏れだ。詳細は明らかにしていない。

仙台市の郡和子市長は2019年5月7日の定例記者会見で「改元に伴い、100余りのシステムについて改修を進めてきた。

100余り！多いところはもっと大量にあると思いますが、考えたくないですね。。。
本当におつかれさまです。

基本、不整合は発生します

↑に記載しているものはほんの一部ですが、やっぱり不整合は発生します。当然だと思います。システムやソフトウェアの開発なんて、基本うまくいかない (これについては後日) のに、それに加えて、現在のシステムやソフトウェアの規模や複雑さ、人手不足の中での改元なんて、誰一人として経験したことないでしょうし。万が一 (億が一？) 経験していたとしても、試せる機会もほぼ無いですし、ごくたまーにしか使わないものを意識するなんて、そもそも無理な話です。それに、そんなことにリソース (記憶力とか、時間とか) を使うなら、もっとリソースをかけるべきものは他にいくらでもあります。

え？システムとかプログラムって、仕様書が作られていて、それを見ればわかるんじゃないの？

はい、あります。理論上は。幸運な場合、形式上は。とんでもなく幸運 (気持ち的には、ロト 7 に当選するくらい？) な場合、そのシステムが将来どのように変貌するか考えられる想像力を持つ人があらゆるパターンを考え抜いて、とてつもない労力を注ぎ込んで作り上げた、およそそのシステムで考慮する必要があるかもしれないすべての事柄が記載されたとてつもない完成度 (と同時に悲しい) の仕様書に巡り会えるかもしれません。
どういうことかというと、まず、色々な事情で、仕様書が作成されないケースはあります。怠慢？うーん、そこだけ見ればそう見えるかもしれません。次に、仕様書が作成されていたとしましょう。でも、根本的には、文章ですべての意図を表現するのって、とてつもなく難しいですよね。なので、形式上は存在していても、そこから十分な情報を得られるとは限りません。その仕様書が将来どのような観点でどのような人に読まれるか、そんなこと誰にもわかりません。それに、何年も前、もしくは何十年も前の時点のものですし、機能拡張したり、接続する別システムが増えた時に、しっかり更新されているかといったら、まぁ、されていないケースの方が圧倒的に多いと思います。なんでって？忙しくて手が回らない。。。以外の理由として、プロジェクトの費用を圧縮するために、仕様書などのドキュメント類にかける費用が目をつけられやすく、削られてしまうからです。誰が悪い？誰でしょう。これは結構複雑な課題。。。いえ、これは問題と言ってよさそうです。
ちなみに、これはプログラムの仕様書ですが、それ以外の仕事でも、資料にかかれている意味がわからないとか、引き継ぐことになったけど資料も何もない、とか、そんなことざらにありますよね。それと同じだと思います。

でも、プログラムって、うまく動いているものを流用できるように作られてるんじゃないの？

そうですね。おっしゃるとおり！
基本的には、そういう思想で作られています。もし、ものすごく運に恵まれて完璧なプログラムをうまく組み込めたとして、でも。。。それを組み込むシステムや、それと繋がっているシステムは、その環境固有のものです。なので、全体を考えたときにどう動くか判断できることは非常にまれです (最近の思想で作られたシステムなら、その可能性はある程度高くなるでしょう)。基本的に、調査やテスト無しでオッケー！と言うことはできません。

質問形式はこのくらいにして。。。

間接的にも、改元が存在することによるマイナス要素はあります

たとえば、システムを開発する段階で、
・改元を考慮しますか？
・考慮する場合は、これくらいの期間と費用と人員が必要です
　(もちろん、考慮する方が良いだろうけど、使うかわからないものにお金をかけるのも。。。予算も限られてるし。。。)
みたいな会話が行われているでしょう。

改元を考慮して作ったシステムが稼働中に改元されなかったら余計な費用になってしまいますが、かといって無視するわけにもいかないので、費用をかける判断になることは多いと思います。とんでもない無駄ですね。
(仮にその時点で対応しないことにしても、実際の改元時に対応することになりますので、問題の先送りにしかなりません)

また、何らかのシステムを使っていると、改元の時に、
・改元について何か確認すること、対応する必要のあるものはありますか？
・確認しますね
・うーん、無いはずですが、当時の仕様書に記載されていないので。。。
　(仕様書をメンテする余裕もなかっただろうしなぁ。。。予算もらえないし)
・メーカに問い合わせて。。。あ、保守契約がない。。。
みたいな会話が行われているでしょう。
おそらく日本中でこのようなやりとりが何度も行われたと思いますが、これだけでも、相当な時間を消費しています。

なんでこんなことやってるんでしょう

改元に伴う検討、処理や不整合、って、西暦で処理されていれば発生しない (はず) 、なんですよね。直接的には、改元に対応するための期間、費用、労力などが消費され、間接的にも、上述のとおり、多くの時間が消費されています。消費、いや、浪費ですね。この人手不足の時代に、日本だけがこのような形でリソースを浪費してしまい、やりたいことができないって、なんなんでしょうね。

しかも！

やらなくても良いようにできるものを、現状維持 (は実質マイナス) するためにがんばって対応して、うまくいっても評価されることはほぼ無くて、ほんのささいなことでも問題が発生するとそこがクローズアップされてしまう、リスクだけが大きいプレッシャーの中で、前向きになれる人なんているんですかね。いや、もちろん、それが仕事でしょ、というのは、理屈上はわかりますが、そんなこと言っても、人間は前向きになれないものに対して高いパフォーマンスを発揮できるようにはできてないと思うんですよ。これは個人の能力の問題では無くて、そういうものだと考える必要があると思います。
(では、前向きになれないものに取り組む原動力になっているものは何か？というと、それは、責任感 (であれば素晴らしい！) とか、恐怖 (解雇される、ユーザからのクレームを受ける、とか) の回避とかですかねー)

だから、

それに対して取り組んで何の影響もなく乗り切ったことは本当に素晴らしく、賞賛したい！思いです。ただ、それと同時に、そのような人達が、なくてもよい作業に取り組まざるを得なかったことが残念でなりません。もし、その労力を他のことに取り組めていたら日本はもう少し前進していたと思います。大げさですかね？

念の為

ですが、私も、元号そのものは、あっても良いのかな。。。とは思います。(私個人は、すべて西暦の方が助かりますが) これがあることによってプラスの影響を受ける人がいるのは事実ですし。これは、あくまでも、「システムで元号を使う」のはやめましょう、という話です。もちろん個人的な見解ですが、これって、地味かもしれませんが、政治のマニフェストになっても良いくらいのものだと思います。トータルで考えれば、数千億？もしかしたら兆？くらいの節約にもなるんじゃないですかね。

最後に改めて！

システムで元号を使うのはやめよう！
システムで処理されるものに元号表記を求めることはやめよう！
(え？もともと求めてないって？じゃあ。。。)