アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
先生質問！ (スコア:4, おもしろおかしい)
1.データの削除に3500万円掛かるということは、データの登録にはいくら掛かりますか？
2.データの削除に3500万円掛かるシステムの構築にいくら掛かったのですか？
3.データの削除に3500万円掛かることに今頃気付いたのは何故ですか？
4.データの削除に必要な3500万円はどこに支払われるのですか？
5.プログラムの仕様決定は誰が行ったのですか？責任追及はしないのですか？
6.プログラムの発注責任者は誰ですか？責任追及はしないのですか？
7.プログラム作成請負企業はどこですか？責任追及はしないのですか？
8.もし帰国子女が国籍を選択する際、外国を選ばれたら削除には3500万円掛かるのですか？
Re:先生質問！ (スコア:0)
そんなややこしそうな例を上げなくても、
「だれか死んだらその度に3500万かかるんですか？」
で十分やろ...
んで今のシステムは、人が死んでも永遠にデータは消えないのだろうか....
Re:先生質問！ (スコア:0)
Re:先生質問！ (スコア:2, おもしろおかしい)
一瞬、ソースコードが流出しているのかと思った。
Re:先生質問！ (スコア:1, 参考になる)
「1人削除に最大3500万円」って表現も悪すぎると思いますね。
これだと、2人削除なら7000万円かかると誤解しかねない。
実際には、現行のシステムでは
・「住民が死亡した場合か、日本国籍を離脱した場合」以外は、データを削除できない
・システムを改修するのに1500万円～3500万円かかる
という話なわけで。
Re:先生質問！ (スコア:1)
そんなのリテラシーの問題だろ
あくまで1人削除するのに3500万円としか書いていない
これではn人削除するには3500万×n円という証明にはならない
常に伝聞は疑ってかかれ
必ず一次ソースに当たれ
＃と か い わ れ た ら ど う し よ う という思考テスト
=-=-= The Inelegance（無粋な人） =-=-=
Re:先生質問！ (スコア:0)
御上の決めたことに従わないなら、
非国民として日本国籍を離脱した扱いすればデータを削除できるんじゃないですか？
しかしまぁ、一人削除しただけで、サーバダウンの可能性ですか
「住基ネットは、日本国民全員の力で構成されています！
誰か一人欠けただけで、日本という国は大混乱になります！
皆ひとりひとり、生きてる意味があるんです！」
といって、自殺抑制に繋げることはできないかしら？
----
死亡したらあっさり削除
もっと簡単に (スコア:1)
リアルに殺したらまずいけど・・・
・・・もしかして件の高裁判事は、行政がネット離脱の召せ締めのために刺客を・・・(゜_゜;)
Re:もっと簡単に (スコア:5, 参考になる)
住基ネットの仕様も、箕面市の住民関係のデータベースがどういう仕組みになっているのかも、よく知りませんが、
１．住基ネットの上位ＤＢ（この場合は大阪府）と下位ＤＢ（箕面市）とで、定期的にデータマッチングを行う
２．下位ＤＢから上位ＤＢに吐き出すデータは、他のＤＢからの自動生成
３．データに齟齬があるにも関わらず、異動に係るフラグ（移転・死亡・国籍離脱など）が立っていなければエラーが出る
という構造を想定すれば、「市側の住民関係データベース全てからデータを削除」しない限り、３．のエラーが永遠に出続けることは容易に想像できると思います。
＃タレコミ中の記事を読む限りでは１と３は正しそう。
＃２については、包含関係（「自治体の住民関係ＤＢ」⊃「住所、氏名、生年月日、性別のみの住基ネット」）にある２つのＤＢに別に手入力する間抜けなシステムがあるとも思えないので、多分正しい。
問題は、「市側の住民関係データベース」ってのが極めて膨大に存在する、ということで、思いつくだけでも、
・戸籍のＤＢ
・住民基本台帳のＤＢ（必要レコードはこれ [e-gov.go.jp]を参照）
・個人住民税のための所得ＤＢ
・国民健康保険のＤＢ（無保険者を避けるため、成人であればレコードが必ず発生）
などがあります。
そして、これらのＤＢが相互にリンクして巨大な一つのＤＢとして機能しなければ、自治体として最も基本的な住民サービス（住民票の写しの発行や国民健康保険にかかる医療費支払いなど）が提供できないことも容易に想像できます。
というわけで、「市側の住民関係データベース」も無矛盾になるよう、データが相互参照され、「特定のＤＢにだけ登録されない人」の存在を許す構造にはなっていないと思われます。
したがって、「特定の誰かのデータを住基ネットに登録しない」解決策としては、
・「住基ネットには登録しない」というフラグフィールドを「市側の住民関係データベース」に新たに追加し、全レコードをリビルド。さらに、住基ネット上位側に吐き出すデータの生成時にはこのフラグフィールドを参照する仕組みを新規構築。
・「住基ネットに登録してほしくない」という人のデータを、自治体の全データベースから削除し、その人にかかるデータについては全部紙で別管理する。
と、タレコミの記事中にある２つの方法以外、無いことになります。
＃ので、「全部紙管理」に切り替えれば、システム改修コストはかからないが、この住民に行政サービスを提供するためには、継続的に気の遠くなるような人件費が消尽される…。
で、メインフレームな１２万件もデータが詰まったＤＢに対し、新規フィールドを追加定義しＤＢをリビルドする作業を、休業日中に他のバッチの合間を縫って行うことにどれくらいコストがかかるかを考えれば、３５００万という数字はそれほどぶっ飛んだ数字ではないと思います。
＃まぁ、高いっちゃ高いけど
というわけで、ＤＢの要件定義をチロっと想像すれば分かるようなことを考えもせずに、既存システムが腐っているという結論だけを導き出したがるのか、ちっとも理解できませんです。
＃まぁ、この場に「俺様システム」以外のシステムを構築・運用経験が無い人が山ほどいるのはよくわかりますけどね…。
Re:もっと簡単に (スコア:4, おもしろおかしい)
#ごめんなさいごめんなさい
Re:もっと簡単に (スコア:1, すばらしい洞察)
消すだけなら簡単。
消した後も住人が存在し続け、しかもサービスを滞りなく提供しないと
いけないから難しい。
Re:もっと簡単に (スコア:0)
マスタ情報の論理削除と何が違うの？
こんなものどのシステムでもよくある話では？
Re:もっと簡単に (スコア:1)
# 今ある論理削除フラグの領域を流用してもいいけど、下流システムへの影響が把握できないから新規に作成すると思う。
同市の住民は12万人だけど、メインフレームの古いシステムだと外国人や過去の蓄積を同一DBで運用している場合もあるから、30万から40万件ぐらいになるかもしれないし、最近は休日だって稼動している場合もあるので下手すれば年末年始作業になるかもしれないし、元ACが指摘している作業条件より厳しい可能性もあると思うよ。
Re:もっと簡単に (スコア:0)
死亡や国籍離脱は必ず地方自治体側から提出されますから、現在対応できてるものと同じ同期タイミングで”レコードを無効”にできます。
後はどこかのタイミングでお互い"無効データの削除"をすればいいだけ。
無効データの削除に関しても同期が取れてなければエラーになる場合は、どう見てもシステムのつくりが悪い。無効なデータは無視して同期するようになっていれば問題ないはず。無効なデータ(エラーデータ)はシステム上必ず存在するもの。
エラーデータがある時点でサーバーダウンするのは作りが屑と言われて当たり前。
エラーデータは、弾いて警告を出し、サーバーと基幹業務自体は常に継続。基幹系業務のプログラムでは当たりまえのことですが？
大きな会社で各支店ごとにサーバー建てて、1支店のエラーデータが会社全体麻痺させるなんて聞いたことありますか？
Re:もっと簡単に (スコア:1)
●地方自治体の持つ住基ネット向け住民基本台帳データベースと、国側の住基ネット情報データベースの整合性の問題
データを削除するとサーバがダウンする、という問題です。元々想定していない事態が起きているのでしょうか? [srad.jp]
こちらの問題については、確かに「死亡」相当の処理を行えば、住基ネット側の情報を消すことは可能でしょう。
●地方自治体内で、住民票データベースと住基ネット向けデータベースの整合性の問題
まず大前提として、住民として存在する以上、地方自治体内で必要な「住民票」データを削除してしまうことはできません。
やらなければならないのは、「住民票」データを、「住基ネット」データに反映させないことです。
現状ではそれができるようなシステムにはなっていない(住民票データベースにある情報は全て住基ネットに流れるようになっている)ために、
対応策としては、
・システム改修を改修し「住基ネットには情報を流さないフラグ」を作る(1,500万円～3,500万円かかる)
・電子的な住民票データベースからは削除し、その住民については紙の住民票で管理するようにする
のどちらかしかないという状況になっているわけです。
つまり、この状況下で「マスタ情報の論理削除」という対応は、それだけに留まらず、
地方自治体内のデータベースからも削除し、紙で管理する、という対応を意味するわけです。
Re:もっと簡単に (スコア:0)
企業のシステム構築現場で働いてますが。
”エラーデータ1件で上位サーバーも含めてサーバーが落ちる可能性がある”設計・実装のどこが屑でないのか教えていただけますか？
実際のDBの同期方法に関する考察は私も #1073819に一行も反論するものではございませんが、"1レコード削除自体がエラーとみなされる"事が”システムの不具合でない理由には #1073819はまったくなっていません。
理論的には企業の商品マスタやエラートランザクションの削除とおなじものと思われますので。
各支店毎にサーバーを建て、夜中に発注情報や新規マスタの前者同期などは一昔前いくらで
Re:もっと簡単に (スコア:0)
企業の商品マスタと戸籍情報マスタが同じだと思うのであれば、その理由を挙げてみてください。
＃まあ戸籍もとあるところでは売り買いできるようだから、商品の一種かもしれんけど
>ほかの方も言及してますが、”間違った戸籍を登録した場合、死亡扱いにするのですか？”。
>削除ができないのは明らかにシステム設計のミスです。
戸籍法ぐらい調べてから発言しましょう。
システムが扱う情報の特性すら調べずに発言するのはバカです。
つまりあれですかね (スコア:0)
Re:もっと簡単に (スコア:0)
それこそが問題の根本で、設計不具合の何者でもないとおもいますが？
ほかの方も言及してますが、”間違って登録された場合、死亡にするのですか？改名？”どちらも"生まれてない人が生まれて死んだことになる。””改名してないのに改名したことにされる”等の問題がありますね。
システムの入力は人の手が解する以上、エラーデータがある事は前提に設計すべきです。エラーデータの削除も通常はシステムの必須用件です。
エラーデータが１件あるだけでサーバーがダウンする可能性があるシステムは間違いなく、欠陥システムです。
大体、エラーがあっても無視してログ吐くだけにしとけば何の問題もないんじゃないの？
Re:先生質問！ (スコア:0)
>非国民として日本国籍を離脱した扱いすればデータを削除できるんじゃないですか？
裁判所の判決も「御上の決めたこと」なので、「従わないなら」
箕面市の関係者は「非国民として日本国籍を離脱した扱い」？
# 関係者じゃないけどガクガクブルブル
Re:先生質問！ (スコア:0)