【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと

【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと:

https://togetter.com/li/1306814

という記事を見ての職業プログラマ歴３年程度の若造の過剰反応です。

まとまっていないポエムのようなものなので、

こんなことあるんだなっていう程度に思っていただいたら幸いです。

作ったプログラムを保守しているとは限らない

まずはこれが大前提。

「作ったやつが無能」だとか「あらかじめ予想していなかった人が問題」だとか、

いろいろ思うことは当然私にもないとはいいませんが、

そういうことは後続の人が云ってはいけないと思っています。

なぜそうなったかの原因究明は必要ですが、悪口を言うための究明なら時間の無駄でしかない。

考慮ができていない「おかしなプログラム」を直すのが我々保守の一端、おざなりにしてはいけない。

１か月でリリースは難しい

そもそもプログラムに直接書き込まれていて、

なおかつオフラインで運用されているシステムが、全国各地にある場合にある場合、

たった１か月で「調査→修正→テスト→納品」できるんでしょうか。

「１か月で修正」じゃないんです、「１か月でテストまでやって納品完了」なんです。

納期確認しないとかほんとに職業プログラマなのかなって。

そして、そういったプログラムが自分たちがメンテナンスできる範囲にあるとは限らない。

発表されてから改元を頼めばいいやと思ってソースを渡してくるお客さんもいるでしょう。

規模にもよるでしょうがどういう風に組まれているかわかんないプログラムを組み替えるのは

簡単とは到底思えないですね。

条件分岐で解決できるとは限らない

「ＩＦやＳＷＩＴＣＨ書けばいいんでしょ？」

そういう修正をして実はここもでしたなんてデグレードバグ、さんざん見てきました。

他にもバリエーションはありえるのに「分岐すればいいんでしょ」というのは早計過ぎる。

以下はJavaScriptでの実例

実例１

// 配列（リスト）のeraNum番目から値を取得する 
var era = ['明治', '大正', '昭和', '平成'][eraNum]; 

配列とか固定長が前提なのに１個増やすとか影響点の観点であんまり考えたくない。

（長さが変わったら狂う可能性）

実例２

// 連想配列（マップ）の場合 
var era = {M: '明治', T: '大正', S: '昭和', H: '平成'}[eraNum]; 

連想配列だとキーとなるであろう「英字一字」が重複しないとも限らない

（例えば明治のＭは不要として新元号と被る可能性（あまりないとは思う））ので、

そもそも仕組みを変える可能性がある。そして年号がわからないと変えにくい。

実例３

// 文字列の場合 
var era = "明治大正昭和平成".substring(n * 2, (n + 1) * 2); 
var era = "MTSH".substring(n, n + 1); 

文字列のパターンは２字の方だとあまりないだろうけど

アルファベットの方はあるだろう（というかあった、ふざけんなって思った）

似たり寄ったりの実例ですが、別に条件分岐がなくても作れるよっていう話です。

そしてこいつらは１行で書ける故に、分岐よりも使いやすく量産されるんだろうなって。

今からこれやられたらモジュール化しろとキレるとは思いますが。

元号が数字など分かりやすい形で管理しているとは限らない

皆さんも利用している某システムは「昭和」と「平成」を真偽値で保持しているそうです。

直接関わっていない案件ですが聞いたときは笑いました。

「年号判定」を「データベース」に「真偽値」で保持してるんです。

１億件以上もあるデータに対して、「最低３つの年号を保持できる型」に置換する勇気はありますか？

私にはないです。

格納している値の型を変換できたとしても、年号を代入してる変数は全部型変更が必要です。

※ 一応ＳＱＬの真偽値は３値論理（https://ja.wikipedia.org/wiki/3値論理 ）なので

やろうと思えばできなくもないのですが「新元号」を「unknown（null値みたいなもの）」で扱うのって

ものすごい皮肉でもあるのですが、絶対に後々めんどくさいことになります。

そもそも元号がいつから有効なのかわからない

「５月１日」からだっていうツッコミをしたら多分この問題に気づいていないかもしれない。

元号は「元号法」という法律によって運用方法が決まってます。

元号法をここに公布する。

　（略）

元号法

１　元号は、政令で定める。

２　元号は、皇位の継承があつた場合に限り改める。

附　則

１　この法律は、公布の日から施行する。

２　昭和の元号は、本則第一項に基づき定められたものとする。

元号は政令で定めるものなんです。

これは当然、平成になったときも公布されています。

それが以下の「昭和６４年政令第１号」通称「元号を改める政令」です。

元号を改める政令をここに公布する。

　（略）

元号を改める政令

内閣は、元号法（昭和五十四年法律第四十三号）第一項の規定に基づき、この政令を制定する。

元号を平成に改める。

附則

この政令は、公布の日の翌日から施行する。

施行とは法律が有効になる日のことです。

何が云いたいか。

公布された「昭和６４年１月７日」時点で翌日の「１月８日」は政令が有効になっていないので「昭和」で、

施行日の「１月８日」に日付が変更になった時点で、「１月８日」は「平成」に成ったということです。

いままでの崩御した時点で変更であればただの年表でよかったんでしょうが、

政令の交付の仕方によっては「新元号は５月１日になるまで使えない」かもしれません。

これ本当にただの年表や条件分岐で対応できるんですかね。

年表に施行日だとかの情報を保持する構造体へ改修する必要があるし、

今までになかった余計なロジックを組む必要があると思うんですが。

この１点だけでいえば突然変わったほうが管理上ややこしくないと不敬ながら考えてしまいます。

元号対応の為に全ソースに影響する可能性がある

「㍾」「㍽」「㍼」「㍻」って合字あるじゃないですか。

合字のせいで文字コード対応が必要なプログラムそこそこあると思います。

新元号はすでに割り当てが決まっている？

確かにそんなニュースはありました。（https://news.mynavi.jp/article/20180908-690029/ ）

これはもうすでに半年くらいに「U+32FF」が割り当てられると決まっています、Unicodeでは。

じゃあ、Shift-JISでは？？？？

WindowsでShift-JISに相当する「CP932」では「対応しないことが決まっています」。

これはCP932という文字コード自体が1992年に仕様凍結していることに由来します。

「いまさらShift-JISで動いてるプログラムはないだろ」と思う気持ちはわかりますが、

個人的に年始から元号とは関係ないですが文字コードのデータ移行をしたところです。

全ソースの文字コード一括置換して、データの文字コードを全置換。

危険な香りしかしないです。

そして依存しているプラグインがやらかす

ここ最近、Microsoftが日本のために更新プログラムで元号対応がちょくちょく行われていますが、

毎度のことながら迷走しています。

Excel2010が動かなくなったり
https://internet.watch.impress.co.jp/docs/yajiuma/1160935.html

予め対応していた年表を消さざるを得なくなったり
https://blogs.technet.microsoft.com/jperablog/2018/09/21/april2018update-placeholder-deletion/

そして、「新元号1年」が「新元号元年」と出力されるように修正されたり
https://blogs.msdn.microsoft.com/dotnet/2018/11/14/handling-a-new-era-in-the-japanese-calendar-in-net/#user-content-the-first-year-of-an-era

大丈夫ですか、.NET使ってるみなさんの日付フォーマット？

油断していると「1年」と出力を期待しているのに「元年」って出ちゃいますよ？

平成に改元した時点の足立区の通達を見てる限り、

公的機関の事務については、従来から原則として元号を使用しており、昭和の元号で表示されているものについては、新元号による表示に改めるものとする。

この場合に、改元期日である１月８日以後の公文書等に使用する本年の呼び方については「平成元年」とし、本年４月１日から来年３月末日までの会計年度の呼び方については「平成元年度」とする。

→ https://jorei.slis.doshisha.ac.jp/reiki/c1801-131156-65368538

となっているため、元年を使うほうが基本なんだろうなとは予想していましたが、

Microsoftがそんな対応を入れてくるとは思いませんでした。

帳票、半角プロポーショナルのみを想定していたら枠をはみ出る気がしますね。

そうじゃなくてもフォントが切り替わって大きさがだめになる可能性もあります。

---

上記が理由でどうも『システム屋は「無能」』とは思えないです。

これら全部できてるプログラムなんて全部あるんですかね。

大体予期してできているならば２０００年問題は発覚した時点でみな直っていたはずで、

システム障害なんて起きなかったはずです。

メモリサイズだとかインタプリタだとか処理速度の問題で、

間に合わせの対応しかしていなかった付けが回ってきているだけで

そこまで長い期間運用するつもりがないプログラムは適当に書きがちです。

そして実際には１０年運用されていたなんて言うのもままあることです。

２、３年がかりで元号変えようとしていていよいよラスト数か月なのに未だ着手してないのは

遅すぎると思いますが。

でもまぁ泣いても笑っても平成は残り数か月の見込みです。

みなさん、後世に平成最後の大障害だなんて後ろ指差されないように気張っていきましょう。

---

蛇足的な話ですが最初のリンクで

「自分のシステムは元号年表どころかサマータイム制度導入想定まで完備だから」と云ってる人もいましたが、

じゃあ「神武天皇即位紀元（皇歴）」は？とか思います。

世界的にはキリスト教でないゆえに西暦と別の暦と併用していることも多く、

何らかのきっかけで法律が変わって使用されるようになるなんていうこと可能性は捨てきれません。

（個人的にはないと思ってますけどね）

「神武天皇即位紀元」はもう実用されることないから対応するだけ無駄？

じゃあそのサマータイムはなんなんだよ。