年金問題、生年月日の日付を丸めて記録？？ 142
ストーリー by nabeshin
翌年分は大丈夫ということは 部門より
翌年分は大丈夫ということは 部門より
seeds 曰く、
なにかと年金問題が取りざたされていますが、asahi.comの『生年月日まるめて記録〜』によると、
プログラムミスによって生年月日をそれぞれ丸めて記録されていたのではないか？
というような話が出てきていますが、これって「プログラムミス」？
COBOLのバグ？ というか、受け入れテストしてなかったの？
ワタシ的には（意図的だったら）なんでわざわざそんなことしたの？ですが。
1日～9日が０日ならミスも考えますけど (スコア:5, すばらしい洞察)
２０～２９ → ２０
３０～３１ → ３０
これは日の１の位を落とすだけなのでプログラムミスもあるかな～と思いますが
１～９→１
に丸まってる時点で『そういうコードがある』としか思えないですねぇ。
何のために？と聞かれると、「阿呆と天才の考えることははかりしれん」としか答えようが無いですが。
# １～９を０に丸めた後、日付チェックで不正な日付として強制的に１日にしてる(エラー吐けよ)可能性も排除できませんが
Re:1日～9日が０日ならミスも考えますけど (スコア:2, すばらしい洞察)
文字列項目から年・月・日それぞれの数値項目に分解する時、文字の桁数で指定して代入っていうのはよくやることで、これを間違えて日付の十の桁だけが日付として扱われているっていうのはありうるバグだし、それが整形されて 1 日っていうのもありえる。
特別に指定できなきゃいけない日付として「月初」と「月末」っていうのは割と定番で、たぶん 32 を「月末を意味するデータ」とかにして 0 を「月初を意味するデータ」とかにしていたんじゃないかな？
-- Where your reading book is, there will your heart be also 天戸 司郎 (Silo Amato)
Re:1日～9日が０日ならミスも考えますけど (スコア:2, 参考になる)
追加で新しいデータも記録することになったのに，レコード長が足らない。
しょうがないので重要性の低い生年月日の日付その他を切り詰めて空きスペースを作り出した。
個人の識別は名前と生年・月があれば十分だから，こりゃグッドアイデアだ！
↑は冗談にしろ，大昔のCOBOLで作ったシステムではまれに似たような話が出てくる。
（実際に製造管理システムの識別コード桁長増・データ追加にからむプログラム全面改修の話が爆発して，
EDPシステムの担当者が激怒・椅子を蹴って立ち上がり会議から出ていこうとしたのを目撃したことがある）
言われた通りに実装しただけではないかと (スコア:5, すばらしい洞察)
ここでプログラマーやっているみなさんも、そんな意味不明な仕様を出されても、そのまんま実装しちゃいますか？ それとも、仕様作成者につっこみますか？ それとも、出したところでつっこみは無視されますか？
Re:言われた通りに実装しただけではないかと (スコア:3, おもしろおかしい)
> それとも、仕様作成者につっこみますか？ それとも、出したところでつっこみは無視されますか？
そこで仕様作成者がドロンですよ
@ytnobody
Re:言われた通りに実装しただけではないかと (スコア:2, おもしろおかしい)
普通はそのまま作るでしょう。言ったとしても軽く突っ込む程度でしょう。で、笑い話の種になる。
> それとも、出したところでつっこみは無視されますか？
普通、無視されるでしょう。仕様としてプログラマにくるまでにここまでバカな仕様が議論されずに仕様になるわけないですから。
Re:言われた通りに実装しただけではないかと (スコア:2, すばらしい洞察)
馬鹿は、「馬鹿な仕様」が「馬鹿な仕様」であることを認識できないので、議論しません。
賢者は「馬鹿がお客様の場合は」、そのようなポイントを議論しません。
自分が出す発注物の仕様がこうだった場合のみ、議論します。
結論としては、「発注元に賢者はいなかった」という事が今回露呈したわけです。
fjの教祖様
Re:言われた通りに実装しただけではないかと (スコア:1)
仕様を考えた人のミスということもあるので、
お互いのために確認は入れます。
結果として、そのままという結論になって、
後々不具合になった場合に、「以前に確認していますよ。」と
言えるようにはしています。
たまにお互いに気づかずにスルーして、最後の最後でひっくりかえることも
あるにはあるのですが。
かなり勝手な予想。 (スコア:4, 参考になる)
一回仕事で使いましたが、無駄にややこしい法律です。
（かなり失念気味、間違えていたらご指摘ください。）
要するに4月1日生まれは早生まれというアレです。
誕生日から徴収開始月を求める場合、日まで正しく入力される必要があります。
いい加減に丸めた数字では正しく徴収できないはずです。
仕様書作成に関わった人が全員素人でも無い限りありえないと思うんですけどね。
さて、リソースが超絶少ない頃の業者の思考で進めると誕生日から毎回計算は大変。
徴収の管理が目的なら正しい生年月日ではなく、入力時に丸めてしまえとなるわけです。
例１)19500331生まれの場合は195003
例２)19500401生まれの場合は195003
例３)19500402生まれの場合は195004
計算機側で丸めて保存するのか、入力時に人間が丸めるかはわからないですが、
このデーターだと月差で年齢が出せるので、計算のリソースが少なくて済むよねという訳。
あくまで私の予想なので実際どうなのかはわかりませんけどね。
#あとは2000年問題のときに桁が足りないから恐ろしいことをやって誤魔化したとか。
理由？ (スコア:3, おもしろおかしい)
ダメでしょうね
誕生日なんて飾りです (スコア:3, すばらしい洞察)
まるめる？ (スコア:3, 興味深い)
一般的な用語だったのでしょうか。
IT系の現場ではごく当たり前のように使われていますが、
世の中的にはどうなのでしょう
Re:まるめる？ (スコア:2, 興味深い)
一般的では無いのかも。
そもそも、何で「まるめる」って言葉になったんでしょうね。
英語では、四捨五入することをround〜 といういい方をするようですが、
round → 円形 → まる → まるめる!
というようなあたりが語源なんですかねえ。
以上、オフトピでした。
@ytnobody
Re:まるめる？ (オフトピ) (スコア:3, 興味深い)
とても疑問だったわけですが、後にキャリーフラグ・ボローフラグって言葉を聞いて
ああ、英語からきたんだなと納得したわけですが。
でもなんで、英語でも「借りる」なの…？
# 「その十は返さなくていいんだ！」
Re:まるめる？ (オフトピ) (スコア:3, おもしろおかしい)
Re:まるめる？ (スコア:1)
Re:まるめる？ (スコア:1, 参考になる)
Re:まるめる？ (スコア:1)
いかなる髪の長さであっても「頭をまるめる」ことにより
みな同じ坊主頭となることから、細かな差を捨てるという
意味になったのです。
# もちろん適当
rond et rond (スコア:1)
ずばり、英語の"rounding"の直訳じゃないですかね。（さらに遡ると仏語のrondかな？）
端数処理の用語としての使われ方は、ITが世に現れるよりはるか以前、金の貸し借りで利息計算がされるようになった頃からあるのではないかと思います。（ちょっと用例を調べきれなかった…）
Re:まるめる？ (スコア:2, 参考になる)
Re:まるめる？ (スコア:1)
Re:まるめる？ (スコア:4, おもしろおかしい)
Re:まるめる？ (スコア:1, 参考になる)
あまり一般的ではないのかも知れません、その後アナウンサーが四捨五入や切り捨て/切り上げを
そんな風に言うことがあると補足してましたが
昼飯休憩の時に何となく見ていただけなので、微妙に間違ってたら失礼
Re:まるめる？ (スコア:1)
Re:まるめる？ (スコア:1, すばらしい洞察)
ITな人には“ディービー”って言っても通用しません。
“デービー”って発音しないと。
別に聞き返されたことはないので言い直したこともないけど。
どう考えても (スコア:3, すばらしい洞察)
#ゴジラ風に
節約 (スコア:2, おもしろおかしい)
Re:節約 (スコア:3, すばらしい洞察)
Re:節約 (スコア:1)
現在、問題に上っている仕様で
保存するデータは、4種類(1日、10日、20日、30日)
なので2Bit
通常の仕様(1日から31日)で
保存するデータは、31種類(1日から31日まで)
なので5Bit
その差は3Bit
ビット詰をしないと、両方1Byteなので節約になりませんね。
Re:節約 (スコア:1)
cat_kei@
アサヒって無い？ (スコア:2, おもしろおかしい)
まるめただけでデータが宙に浮く要因になるってのも理解できない
(「重複データが多い」とかなら分かるけど)
Re:アサヒって無い？ (スコア:1)
丸まったデータと丸まってないデータが時期の違いにより混在，両者が異なる人間に帰属される
ものとして認識されるから，当人にきちんと帰属できないデータが生じる．
って事もソース元に書いてありますが．
Re:アサヒって無い？ (スコア:1)
１月１日を１月２日生まれにしたなんて聞いたことないの？
Copyright (c) 2001-2014 Parsley, All rights reserved.
可能性の一例 (スコア:2, 興味深い)
汎用性を考えるとパックは使ってないと思われるので、1文字1バイトで格納。
すると、例えば1980年12月31日なら、16進で表すと、と、最終桁のみ微妙に違う。
COBOLでは相互の型変換は自動で行われる為に支障はまず起きないが、バッチシステムなどではひとつのプログラムで処理を全て行うことはまれで、単機能のプログラムの処理結果をユーティリティで繋ぐのが一般的。SORTとかね。
そこでパラメータの設定不備があると、符号の含まれた末尾一バイトが飛ぶ。
個々のプログラムがうまく動いてもデータが壊れる例なんてざらだったよ。
結合テスト不備だな。
Re:可能性の一例 (スコア:2, 興味深い)
当然のように元号です。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:可能性の一例 (スコア:2, 興味深い)
16進のダンプリストを見る時は楽なのですが、これをプログラムで扱おうとすると、非常に面倒です。 そのため、DBから取り出した後はサイン付きパックに変換しています。
で、更にこれを通常の10進数の変数に代入することで、年、月、日を取り出せるようにします。どこかで1桁くらい失われたりとかありそうです。変換と言ってもCOBOLなので、データ定義のREDEFINEを多用したものです。 サインなしパックのケツに'0C'をくっつけて、10で割ってサイン付きパックに代入、というもの。
# まだ私のコードが残っていそうな1960年代生まれの
SEACPIC 90. では (スコア:1, 興味深い)
ぼくの年齢も (スコア:1)
Re:ぼくの年齢も (スコア:3, おもしろおかしい)
Re:ぼくの年齢も (スコア:2)
Re:ぼくの年齢も (スコア:1)
<?
$your_age = round($_REQUEST["age"],-1);
?>
@ytnobody
妄想してみた (スコア:1)
たとえば、19701223 が 1970122 と保存されてしまった。
これを読む側のプログラマーがあれ？一桁たりねぇぞ？
しょうがねぇから、無いからゼロなんだろ、0日は存在しないから
その場合はたぶん1日だろうな・・・うん。ｹﾃｰｲ
そしてリリースの日を迎える・・・
逆に考えるんだ (スコア:1)
> 「問題の時期にコンピューターを切り替えており、（正しく入力されたデータをまるめて変換する）プログラムミスがあったのではないか」
* システムを更改して、データ移行をしようとした
* ところが、もとのデータに生年月日の「日」が入っていなかったレコードが存在
* その結果、データ移行に失敗
* 仕方が無いので、「日」の無いレコードは、10, 20, 30の様な適当な数値で補って、とりあえず処理が終わるようにした。
という可能性は？
＃ よーく探したら、19?0年も不自然に多いかもしれない・・・
Re:昭和１００年対応？ (スコア:1)
自分が担当者で無くなるぐらい先まで(笑)
------------
惑星ケイロンまであと何マイル？
Re:よーわからん (スコア:2, 興味深い)
＞６３～６６年度の４年間に就職や転職をしたり国民年金に加入したりした人のほとんどの生年月日が、そうした形で記録されていたという。
っていうことなのだから、システムを６３年と６６年に改修した記録があればプログラム側で、そうでなければ指示や通達による可能性があるよね。
その後の記事では
＞原因について、蓮舫議員が「問題の時期にコンピューターを切り替えており、（正しく入力されたデータをまるめて変換する）プログラムミスがあったのではないか」と指摘したのに対し、石井部長は「その可能性を含めて調査している」と答えた。
蓮舫議員の調査の裏を取れればプログラム側だと判断できることになるね。
どっちにしろ調査結果待ちってとこでしょう。
Re:馬鹿か？本当に馬鹿なのか？ (スコア:3, すばらしい洞察)
悪意に満ちた賢者よりも、善意に満ちた愚者を恐れよ。
前者が何をしでかすかは予測できるが、後者は予測できぬ。
fjの教祖様
Re:COBOL? (スコア:3, 参考になる)
とのことです。
Re:COBOL? (スコア:1)
Re:COBOL? (スコア:2)
Re:COBOL? (スコア:2, 参考になる)