SEから見た社会保険庁システム問題
年金記録未統合問題については、制度発足時に神の目で見渡すことが出来ない以上、申請主義等の手だてにより最悪の事態は回避した結果が現在ではないか、といったような趣旨のことを以前書きましたが、いかんせんシステム関係については素人のwebmasterですから、それがどこまで当を得たものであるかは疑わしかったとは言わざるを得ませんでした。幸いなことに、この問題についてのSEからのご発言がありました。
複数の年金手帳，オンライン前の処理の杜撰（ずさん）さ，アルバイト入力…。基礎年金番号を統合することで表面化した凄まじい件数の宙に浮いたデータを目の当たりにして，社保庁のSEたちはどのように感じたでしょう？ 少なくとも，バラバラの台帳では出現しなかった潜在的問題が露呈したのは，コンピュータ統合した効果です。複数回にわたる名寄せ統合で，日本の総人口よりも多かった3億件の被保険者番号は絞り込まれ，宙に浮いた年金番号は5000万件にまで絞り込まれました。今後どのように問題を解決していくのか？そのプロセスに関しては相当の議論が重ねられたと思います。
過去からの様々な杜撰（ずさん）な措置が積み重なった結果が，5000万件の宙に浮いた年金番号です。一挙に解決するのは不可能です。おそらく，社保庁の決断は「年金の裁定申請時に決着させる」だったでしょう。少なくとも，オンライン化で社保庁の業務運用の品質レベルが下がったわけではありません。今までの杜撰さの本質的（？）解決は，裁定時決着しかない。私が社保庁の担当者であっても，そう考えてあきらめただろうと思います。
（略）
ここに「社保庁次期システム構想」があります。2006年の情報ですから，年金が国を揺らすような大問題になるなんて想像だにしていません。かなり詳細なデータです。これを見てNTTデータが悪いと簡単に言えるでしょうか？
この中で，宙に浮いた5000万件の年金番号に関係する記述を探しました。もちろん，宙に浮いたデータがあるなんて言えるわけもありません。ぼかしながら「年金裁定時までに…（略）…確認整備を行っている」とだけあります。裁定時に決着するから，と軽く考えているわけでもないようです。社保庁システム全体の規模は，2100万ステップです。紛れもなく大規模システムです。何と700万ステップのプログラムもあるようです。Web2.0とかマッシュアップとかの問題ではありません。基幹システムの複雑性は，尋常ではないのです。
COBOL言語とメインフレームは堅牢性に関して，オープンシステムの比ではありません。堅牢性は年金システムに求められる重要な視点です。ただ，制度改正や政治問題からバンバンにシステム変更があると思います。ユーザーである社保庁は，納期なんてほとんど聞いてくれなかったでしょう。
8月 4th, 2007 at 0:19:43
プログラム１本（？）で700万ステップっていったい。
大きすぎるとメンテが大変ですよ。
プログラム分割を図った方が。
うちのは大きいのでも2000ステップくらいかな。
と、他システムに口を出すより育児短時間勤務制度対応で頭抱えてます。
法公布から施行まで3ヶ月、法施行10日前で人事院規則や給実が出ても仕様検討は間に合いません。
支給対象者が僅少な手当については対応しない方向で本省の了解は得ましたが。
＞制度改正や政治問題からバンバンにシステム変更があると思います。ユーザーである社保庁は，納期なんてほとんど聞いてくれなかったでしょう。
給与システムもおんなじようなもんです。
人事給与システム開発のあおりで予算が付かないから、「私がexcelマクロで計算作るから、そっちは給与明細に載るようにメインフレーム側の取り込みインターフェースだけ作って」なんてのも。
8月 4th, 2007 at 0:29:47
これ、システム構築の問題じゃないですよね。システムが導入されなくても、同じ事は起きていたわけで。単に統合してデータベースに入れようとしたら、元々抱えていた問題が表面に出てきて、件数が数えられるようになっただけで。
担当者はそれぞれの立場で良かれと思ってやってきたことが、逆に不信感をもたれる結果になっちゃったという面はあろうかと思います。慎重になりすぎて陥る罠ですね。
政治問題・選挙問題化した時点で、システム屋にしても社保庁にしても、既に現場の手は離れているんだと思います。「年金は怪しい」というのが完全に定着しちゃいましたから、絶対に怪しくないというコミットをどういう形でするのかですね。
8月 4th, 2007 at 0:48:51
この記事、何が言いたいのかよく分からない記事だと思いました。杜撰であったことを前提として、システム屋は悪くないという趣旨だったのでしょうか。
せめて
>おそらく，社保庁の決断は「年金の裁定申請時に
>決着させる」だったでしょう。
裁定時決着で、何が問題なのかを教えて欲しかったです
8月 4th, 2007 at 4:54:40
>裁定時決着で、何が問題なのか
元記事の方の考えは不明ですが、「裁定時決着」の問題は、「保険料を納めた」vs「保険料を納めていない」の対立が起こった場合に解決できないという問題。まさに、世間で騒がれている通り。
2〜3年程度前の話であれば、「領収書を持っていないからダメ」で却下できるものが、裁定時(つまり何十年も経過した後)まで先送りしたため、「そんなに昔の領収書を保存している訳がないだろ！」という論が通ってしまい解決できず、「性善説」だとか「性悪説」というように、問題が宗教化してしまうことだと。
8月 4th, 2007 at 7:57:44
>COBOL言語とメインフレームは堅牢性に関して，オープンシステムの比ではありません。
最古の高級言語の一つっすからねー。それだけでもジャワ(だっけ?)とか何とかとは格が違う。
>申請主義等の手だてにより最悪の事態は回避した
役所の原則的にはありがちというか正しいし、役所にとっての最善の解決であることは確かとしても、受給権者からしたら「消えた」記録にかかる申請の難しさが並ではないのは、5年を越える記憶はもとより領収書まで必要になるなどのポイント。(俺なんざ半年前の領収書でも持っていないことが多い。orz)
五千万件の中では記録上の超高齢者の比率が高いと言われるので、受給権者には優しくない事態が既に多々起きてきたことをうかがわせます。
8月 4th, 2007 at 11:21:37
>もさん
>2〜3年程度前の話であれば、「領収書を持っていないから
>ダメ」で却下できるものが
却下できないと思います。却下された人がその理由で納得される事はないでしょう。
数十年前の話だろうが、数年前の話だろうが、スパンはどうあれ「払った」と「払ってない」の対立は常に生じますし、そのような問題が発生した時に、解決は難しいと考えます。
>そんなに昔の領収書を保存している訳がないだろ！」と
>いう論
一般論として、個人の領収書の保存期間というのはどの程度のものなのでしょう。また、第三者機関による裁定では、特に領収書というものは必須ではなくなっていると思いますが。
8月 4th, 2007 at 22:41:08
＞電算機専門官さん
お疲れ様です・・・まあでも、そういう事態が起こらないように現場に配慮すると、それが数十年後にはそんなふざけた勤務実態だから、なんて社保庁のようなことになるやもしれず・・・。
＞鍋象さん
といいますか、システム化していなかったらもっと悲惨なことになっていたのは間違いないでしょうし。
＞bn2islanderさん
未統合問題について、複数の加入記録を統合するのは裁定時でいい（裁定前に統合できなかったとしても許容する）という運用を行ってきたこと、と私は理解しました。
なお、領収書は、税法上は5年が一般的ではないでしょうか（個人事業の場合）。
研究会の件については、情報提供ありがとうございました。
＞もさん
補足いただきありがとうございました。なお、私は社会保険労務士がいなければ事態は格段に悲惨な状況になっていたと考えていまして、そこへの相談の段階で必要な書類等のチェックが働いていたことで、相当程度の問題解決が図られていたのではないでしょうか。
＞BUNTENさん
職権認定で、異論は最初から不服審査へ、という制度よりはよほどマシだったのでは、という趣旨です＞申請主義による最悪の事態の回避。
8月 5th, 2007 at 0:10:07
>>bewaadさん
そもそも統合していなければ、被害範囲は極小化されていたのではないかと思ったりして。
>>BUNTENさん
堅牢性もさることながら、「（事実上）バージョンアップが無い」あるいは「サポート打ち切りが無い」事の方が大きな利点ですね。COBOLは確かアメリカ国防総省でまとめた仕様がきっかけで、拡張性を無視したフィックスした仕様を持っていまして、処理系の持つ癖（仕様と言い張る不具合）みたいなのも聞いた事がありません。年がら年中アップデートしながら新しいバグを組み込んだり、バージョンアップして数年経つと旧バージョンのサポート打ち切りにする某社や某社の言語とは違います。
メインフレームでやるような基幹業務は最低でも１０年、普通は２０年以上動かしますので、サポートきられたら死ねます。サポートきられる都度再構築させられたら、それだけで会社がつぶれます。スピードが大事だからWEB系でなければとか言えるのは、システム自体が営業組織となっているネット系の会社だけじゃないかと。
そういや、Win98SEがついに使えなくなりそうです。OSのサポートはとっくに切れていましたが、安定バージョンだったのでそのまま使っていたのですが、某ウイルス対策ソフトが対応してくれない事になりましてorz。
これで、Celelon300とかのパソコンが全部Inter Coreとかに切り替えとなるわけですが用途は一緒、早さも大差なし・・・。サーバはまだしも、クライアント利用のPCについては、俺はヘドニック法を認めないぞｗ
8月 5th, 2007 at 23:31:28
> 鍋象さん
> COBOLは確かアメリカ国防総省でまとめた仕様がきっかけで、拡張性を無視したフィックスした仕様を持っていまして、処理系の持つ癖（仕様と言い張る不具合）みたいなのも聞いた事がありません。
これは何かの勘違いではないでしょうか。
近年になっても標準の改定は繰り返されています。また、処理系独自の拡張機能というのも存在します。たとえば、Wikipedia の以下の記述にもその一端が現れています。
http://ja.wikipedia.org/wiki/COBOL#.E6.A8.99.E6.BA.96.E...
つまるところ、「COBOL」とか「メインフレーム」とかに特別な技術が含まれているわけではなく、それらが使われるプロジェクトでは堅牢性とか安定性とかに大きなお金をかけることが許されることが多いということに過ぎません。
8月 5th, 2007 at 23:54:46
＞鍋象さん
分離したままだと、厚生年金（もちろん私の場合は共済年金ですが、とどのつまりは被用者年金）に加入した後においてなお、一階部分はそれに含まれず別途国民年金に加入し続けなければならないわけで、ちょっとそれはいやだなぁ（笑）、と。
＞Cereさん
情報提供ありがとうございました。
8月 6th, 2007 at 3:33:52
>>Cereさん
失礼しました。「サポート打ち切りが無い」という事を強調するあまり余計な事を書いてしまいました。「バージョンアップ」については利用者側の実感として、自身のプログラマとしてのライフサイクル内では、バージョンアップでシステム再構築に近い作業をしなければならない羽目にはほぼならないだろうという事で。
＞つまるところ、「COBOL」とか「メインフレーム」とかに特別な技術が含まれているわけではなく、それらが使われるプロジェクトでは堅牢性とか安定性とかに大きなお金をかけることが許されることが多いということに過ぎません。
堅牢性・安定性でお金をかけてるのはメインフレームであって、COBOLにはお金はそれほどかかっていませんよね。COBOLに期待されているのは、長期間利用できてプログラマが多いという点ではないでしょうか。お金がかかるのは、むしろバージョンアップが頻繁で、クライアントライセンスを必要とする比較的新しい言語やDBの方だと思います。
株屋さんたちからすると、色々な会社の株価に影響する後者が偉く見えちゃうんだろうけど、変わらない事のよさってのもあるということで。
8月 6th, 2007 at 18:22:06
＞鍋象さん
俗に言う「枯れた」ものが望ましい分野がある、ということですよね。