スラッシュドット・ジャパン

１０～１９ → １０
２０～２９ → ２０
３０～３１ → ３０
これは日の１の位を落とすだけなのでプログラムミスもあるかな～と思いますが

１～９→１
に丸まってる時点で『そういうコードがある』としか思えないですねぇ。

何のために？と聞かれると、「阿呆と天才の考えることははかりしれん」としか答えようが無いですが。

# １～９を０に丸めた後、日付チェックで不正な日付として強制的に１日にしてる(エラー吐けよ)可能性も排除できませんが

そんな改造をしてもプログラマーの作業量は減りませんので、プログラマーの独断でそのようになったとは考えにくいです。要求仕様でそのように指示されたからやっただけでないかと。プログラマーも意味不明な仕様だなといぶかりながらも、自分の責任で無いからと、言われたとおりそのまんま実装したのではないかと思います。

ここでプログラマーやっているみなさんも、そんな意味不明な仕様を出されても、そのまんま実装しちゃいますか？ それとも、仕様作成者につっこみますか？ それとも、出したところでつっこみは無視されますか？

年齢に関する法律 [wikipedia.org]というのがありまして。
一回仕事で使いましたが、無駄にややこしい法律です。
（かなり失念気味、間違えていたらご指摘ください。）
要するに4月1日生まれは早生まれというアレです。

誕生日から徴収開始月を求める場合、日まで正しく入力される必要があります。
いい加減に丸めた数字では正しく徴収できないはずです。
仕様書作成に関わった人が全員素人でも無い限りありえないと思うんですけどね。

さて、リソースが超絶少ない頃の業者の思考で進めると誕生日から毎回計算は大変。
徴収の管理が目的なら正しい生年月日ではなく、入力時に丸めてしまえとなるわけです。
例１)19500331生まれの場合は195003
例２)19500401生まれの場合は195003
例３)19500402生まれの場合は195004
計算機側で丸めて保存するのか、入力時に人間が丸めるかはわからないですが、
このデーターだと月差で年齢が出せるので、計算のリソースが少なくて済むよねという訳。
あくまで私の予想なので実際どうなのかはわかりませんけどね。

#あとは2000年問題のときに桁が足りないから恐ろしいことをやって誤魔化したとか。

「それがぼくには楽しかったから」じゃダメですか？
ダメでしょうね

当時の担当者も、まさか誕生日がなにかのデータ処理に使われるとは思わなかったからじゃない？

データを端折ってしまうことを「まるめる」というのは
一般的な用語だったのでしょうか。

IT系の現場ではごく当たり前のように使われていますが、
世の中的にはどうなのでしょう

「あのミスが最後の一匹だとは思えない」

#ゴジラ風に

1バイト節約した

ソース元がasahi.comなだけに

まるめただけでデータが宙に浮く要因になるってのも理解できない
(「重複データが多い」とかなら分かるけど)

当時のシステムを考えると、データの格納は多分EBCDEC。
汎用性を考えるとパックは使ってないと思われるので、1文字1バイトで格納。
すると、例えば1980年12月31日なら、16進で表すと、

文字型・符号なし数値型:F1 F9 F8 F0 F1 F2 F3 F1
符号あり数値型(正の値):F1 F9 F8 F0 F1 F2 F3 C1

と、最終桁のみ微妙に違う。

COBOLでは相互の型変換は自動で行われる為に支障はまず起きないが、バッチシステムなどではひとつのプログラムで処理を全て行うことはまれで、単機能のプログラムの処理結果をユーティリティで繋ぐのが一般的。SORTとかね。
そこでパラメータの設定不備があると、符号の含まれた末尾一バイトが飛ぶ。

個々のプログラムがうまく動いてもデータが壊れる例なんてざらだったよ。
結合テスト不備だな。

初歩的なタイプミスと思われますが。

まるめてください

誕生日のフィールドには、年月日で8桁のはずが、7桁までしか保存されなかった。
たとえば、19701223 が 1970122 と保存されてしまった。
これを読む側のプログラマーがあれ？一桁たりねぇぞ？
しょうがねぇから、無いからゼロなんだろ、0日は存在しないから
その場合はたぶん1日だろうな・・・うん。ｹﾃｰｲ

そしてリリースの日を迎える・・・

プログラムミスが取りざたされてますが・・・

> 「問題の時期にコンピューターを切り替えており、（正しく入力されたデータをまるめて変換する）プログラムミスがあったのではないか」

* システムを更改して、データ移行をしようとした
* ところが、もとのデータに生年月日の「日」が入っていなかったレコードが存在
* その結果、データ移行に失敗
* 仕方が無いので、「日」の無いレコードは、10, 20, 30の様な適当な数値で補って、とりあえず処理が終わるようにした。

という可能性は？

＃ よーく探したら、19?0年も不自然に多いかもしれない・・・

年金記録５２４万件、生年月日ずさん管理 [yomiuri.co.jp]
氏名がわからないんじゃ、生年月日がわからなくても不思議はないじゃないか。

日付としての妥当性チェックか（これは当然やってない）
各自治体の住民基本台帳で確認（これをやってれば問題は起きない）
ぐらいしか、確認しようがないですからねえ。

まだ、しばらくは２桁で大丈夫！
自分が担当者で無くなるぐらい先まで(笑)

ちょっと引用すると
＞６３～６６年度の４年間に就職や転職をしたり国民年金に加入したりした人のほとんどの生年月日が、そうした形で記録されていたという。

っていうことなのだから、システムを６３年と６６年に改修した記録があればプログラム側で、そうでなければ指示や通達による可能性があるよね。

その後の記事では
＞原因について、蓮舫議員が「問題の時期にコンピューターを切り替えており、（正しく入力されたデータをまるめて変換する）プログラムミスがあったのではないか」と指摘したのに対し、石井部長は「その可能性を含めて調査している」と答えた。

蓮舫議員の調査の裏を取れればプログラム側だと判断できることになるね。
どっちにしろ調査結果待ちってとこでしょう。

悪意ある人間には腹も立つけど、ここまでの馬鹿にはもう憐みしか感じない。

悪意に満ちた賢者よりも、善意に満ちた愚者を恐れよ。
前者が何をしでかすかは予測できるが、後者は予測できぬ。

7月1日のサンデープロジェクトで、公明党の斉藤鉄夫政調会長に話を聞いた。
彼は東京工大を出て、日本の国会議員の中で、最もコンピュータシステムに詳しいといわれている。

彼がいうには、いまだに社保庁のシステムはCOBOLというプログラム言語を使っているという。
これは彼が学生時代に使っていたもので、40年も前のものだ。

http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/ [nikkeibp.co.jp]
とのことです。

以前ちょっと関わってたものですが 確かにCOBOLなんですが、上流設計はSmalltalkでできたツールを使用しており それからCOBOLコードを吐くようになってたと思います。

それよりは、元号記号(M,T,S,H)を入れろ、の方があり得そう。
＃大化=0とする元号番号…だと、1バイトでは足りんのかな？南朝もあるしな。

>陪審員制度とかより
つまり、国民から抽選で数人選び出し、プログラムを書かせる、と。

うんうん。
データ入力のための予算が十分取れなくて、雇えるバイトさんが
少ないと、入力データを一部省略しちゃうことはよくある。

予算が確保できなかったので業務が完了できません、と言えない
ところが役所の悲しいところ。
現場の実態などお構いなしに、雲の上の方で予算が削られるのも
役所の悲しいところ。
システムの変更や入力データの一時的な急増に対して柔軟な予算
措置なんて考えられないからな。

結果、自分の担当の時に問題が生じなければいい、と考える輩が
出てくる。2-3年で異動しちゃうからね。過去の不始末も全て現
在の担当者がかぶる、というのが長く続いてたし。
過去の担当者を処分するようになったのは、ここ数年の話じゃな
いかな。(これは非常にいい傾向だ!!)

私は運が悪いのか、そんな不始末の後処理ばかりしているような
気がするよ。orz

厚生労働省ですな。
薬害エイズ、C型肝炎、ホワイトカラーエグゼンプション問題、年金問題、グリーンピア等
どれも厚生省キャリアが問題を起こしているわけだし。
どうも国民を大切にしようという意識が無いように思う。


横領した自治体職員の告訴をがんばっているようだけど、本当に追求すべき人間は御咎めな
しになっている事例が多すぎ。問題の論点をそらしているとしか思えない。
特に今回のC型肝炎のリスト隠蔽問題なんて犯罪ではないか？
なぜ、ねずみ男大臣は「厚生労働省の役人は信用ならん」と怒鳴らないんでしょうね。

社会保険庁のデータ入力作業では，一日のタイプ数が制限されていたという話があるそうなので，タイプ数を減らすためなんじゃないの?