平成３元年・・・何ともお粗末
こんにちは。
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04724/
世田谷区が送付した「平成30年度世田谷区私立幼稚園等保護者交付決定通知書」で、日付を「平成3元年」として対象世帯に約1万通を発送したという。原因は和暦の1の位が「1」だった場合に「元」に変換する処理が組み込まれていたため。
これはねぇ・・・もう・・・元号使用がどうのこうのではなくて、どうしてこういう「やっつけ仕事」で良しと思うのか、その神経がわからない。令和元年はいいとして令和１１年なら「令和１元年」と表記されるわけで。平成のうちに見つかって良かったというべきなのかどうか。バグというレベルでは無いですな。
PS.
私はプログラマーではないですが・・・私なら
if 和暦の値自体が「1」ならば then
「元」に置き換える
else ...
という処置をします。
23 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
ことが難しい場合があります。
「1年を元年に置換」はずさんすぎますが、01年、11年、21年、…、91年は対象外として1年を元年に置き換えという処理にせざるを得ない場合がありそうです。
当時は使っていなかったのかな。
行政関連のシステムは継続性が重要な観点ですから、刷新して「今までのデータが使えなくなってしまった」のでは単に業務が止まるだけでなく、場合によっては安全保障上の問題も発生しますから、なかなか変えられないんだと思います。
まあ、要件なり設計を決める方々からして「行政文書などの処理に西暦を使うなんて最近までは思いもしなかった」ことでしょうし、一度システム刷新の設計を行ってから実際に稼働開始するまでは少なからず年単位の期間が必要なので、しばらくは混乱が続くかもしれません。
※もともと現状のコンピュータシステムは1900年からの絶対数値で
日付・時刻を管理する設計だったり、場合によってはそれが桁あふれ
することも予測されてますからね。
＞結構深刻なものは 2036年問題(NTP)やら 2038年問題(unix time)とか。
よく見もせずに1万通発送したやつ出てこい。だって単なる通知文書ですよ?別に何年何月何日から起算して何日目だから云々という処理は無いわけです。記事見ればわかりますが文書の発行年月日と振込予定日が書いてあるだけにすぎない。だからYYYYMMDDだとか、あまり関係ないように思う。
しかも
1の位が「1」だった場合に「元」に変換する処理
なんて本当に令和元年のみ対応のやっつけ対応が見え見えの改変ですよ。
こんなお粗末なことがなぜ通るのか、コード書いた人はそもそもですけどそれを検証したり承認したりする人はいないのかと、で、印刷されたモノを確認する人、発送前に封筒にでも入れるときに気が付かないのか、とか、私が言いたいのはそういうことです。
QC(品質管理)が全くなってないんですよ。役所にこそISO9000とか品質マネジメントシステムが必要なんじゃなかろうか。
役所の書類に元年生まれが生年月日描くときは、元号に丸して1と描くのが普通だよね。
プログラムに関しては門外漢ですがnがintegerだとだめですね、それ(笑)
if($nenn = 1){ $nenn = "元";}
とか?
わからんw
>「和暦の値だけ取り出す」ことが難しい
このプラグラムに関しては前述したようにそんなに難しい処理をしているように思えないので、和暦の値を変数にしておけば(上に書いた$nennのように)それは簡単ですね。
従って「1のときのみ元に置換」で処理できるはずで、
>01年、11年、21年、…、91年は対象外として
なんてことはしなくてもいいはず。
ですよね?(プログラマーじゃないから、わからん)
プログラミングでこういう処理させる方が難しいw
ただ、エクセルで置換えして良くこれなりますなぁw
数値にして、１の場合のみ変換でいいんだけど
桁も無視だったら令和11年は「元元年」と表記されていたんだろうか。
>数値にして、１の場合のみ変換でいいんだけど
はい、そういう意味で書いてます。
(私の、間違ってます??)
値自体ではなく「数字が1ならば」だと、３元年とか元元年とか間抜けなことになりますが。
1枚試しに印刷して、内容すべて確認しないのでしょうか？
あの水道局の時と同じ業者じゃ…
ないよね。
> これってそんな難しい - プログラム - ではないと思いますけどね。
仕様策定ってそれこそ「難しいお話」なんですよ。
実際にシステム設計を日常茶飯事に扱うと「如何に正しい仕様を提示しても拒まれるので、搦手で回避しなければならないか？」という場面を目にすると思います。
官公庁系はかなりのところでテストが必要になりますけど、おそらく今回の場合は「各元号の最初は必ず『元年』と表示させる」というものが仕様に含まれていて、もともと西暦管理されていなかったために起きたことでしょう。
※本来は「平成までの元号に対応していて、かつ今年は５月から
元号が変わることは事前に判っていた」ので、４月末までと５月以降を
シームレスに処理するためのロジックが必要だったはずです。
しかしながら平成31年＝令和元年であったため、簡単に済ませるよう、
「元号フラグ」として「平成２」とか「平成１」とかがあって、さらに
下１桁に関して「元号の10年代(2桁目)フラグが上がってない場合、
1年は元年と表示させる」とかしていたように見えます。
→つまり、再現テストが不十分だったので簡単にわかりそうなエラーを
見落とした、ってことだと思いますけどね。今回の直接的原因は。
昔は１ビット節約するだけでもコード実行時のメモリ占有容量がかなり変わりましたし、私自身は経験もないですけど汎用機(大型コンピュータ)の場合は可能な限りそれらの処理にかかるメモリ容量を節約しないと他の処理が止まってしまう可能性もありますので、古くからの仕様を引き継いで改修せざるを得なかったんでしょうね。
むしろこういうところの修正が「難しくない」と考えられる場合は、他システム連携などを考慮しないで「単体で動作するプログラム」だったら修正・改修も楽だと思います。なにせ「他のデータを参照しなくても単体で完結する」訳ですから。
世の中の業務システムってそんな「難しくない構成」をしてるもののほうが特殊だと思います。必ず何らかの形でデータを参照して処理しているはずですので。
※なので仕様策定が非常に重要ですし、本来は「システム全体の処理を
観て設計レビューする」とかが必要なんですけどね。
釈迦に説法かもしれませんが、
>仕様策定ってそれこそ「難しいお話」なんですよ。
仕様書がどうあれ、アウトプットがこれじゃダメでしょ?って話です。
>もともと西暦管理されていなかったために起きたことでしょう。
西暦管理しようと和暦管理しようとこのプログラムは1が元に置き換わるだけのように思えます。文字での扱いだからです。値で1ならこうはならないはず。
>見落とした、ってことだと思いますけどね。今回の直接的原因は。
見落としというか検証の不足ですよ。見落としたって検証すれば再現するはずなので。ありとあらゆるケースを想定して検証するということをしていない、検証が不足したとしても１万通もそのまま送ってしまうという失態はどこから来るのか。単なる怠慢ですよ。
>昔は１ビット節約するだけでも
だから元号をMTSHに省略してなおかつ２桁管理してきたわけですよ、伝統的に。西暦にすると4ビット使うし。でも今回のそれはもう元号も漢字になってますから当てはまらないですね。
>※なので仕様策定が非常に重要です
仕様がどうあれ結果がこうだとお粗末だという話をしています。
お役所は数字も英字も全角ですから。
>全角なのも影響あったのでは。
有り得る話ですね!
文字列でやっていたとしたらなおさら(数値には変換できませんから)。
横から入ってごめんなさい。
今回、区役所が印刷業者に渡したのは西暦のデータです。
印刷機のシステムで和暦に変換した際のバグです。
そして、印刷業者と区役所の人が立ち合いでテストをして
印刷物を確認しましたが
データがダミーデータだったので、検出できなかったというお話です。
（データが2018年だったら、平成30年になるので問題が見えない）
>ありとあらゆるケースを想定して検証するということをしていない
おっしゃる通りでする。
2019年から10年分、一か月刻みのパターンで試験すれば見つかりますので
お粗末なのはかわりません。
テストケースの不足です。
ちなみに自分だったらEpoch時間に直して比較します。
Epoch時間は1970年1月1日0:00からの経過時間なので
2019年5月1日 0:00(令和元年) -> 1556636400秒
2020年1月1日 0:00(令和二年)-> 1577804400秒
になります。
nを日付をEpoch秒に直した整数だとすると
if ((n >= 1556636400) && (n < 1577804400)){
// 元年の処理
} else {
// 元年以外
}
上記は令和元年だけ対応ですが、平成でもif文を増やせば同じです。
あと、全角数字でもC/C++/Java/C#はやろうと思えば数値にできますよ。
他の言語はわかりません。
単に元号改定に伴い処理を入れた結果、バグってしまったということですよ。
こんな変更を入れるのはたぶん新人に近い若いプログラマーさんでしょう^^;