パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

住基ネット、1人削除に最大3500万円」記事へのコメント

  • 先生質問! (スコア:4, おもしろおかしい)

    by Anonymous Coward
    先生!質問!

    1.データの削除に3500万円掛かるということは、データの登録にはいくら掛かりますか?
    2.データの削除に3500万円掛かるシステムの構築にいくら掛かったのですか?
    3.データの削除に3500万円掛かることに今頃気付いたのは何故ですか?
    4.データの削除に必要な3500万円はどこに支払われるのですか?
    5.プログラムの仕様決定は誰が行ったのですか?責任追及はしないのですか?
    6.プログラムの発注責任者は誰ですか?責任追及はしないのですか?
    7.プログラム作成請負企業はどこですか?責任追及はしないのですか?
    8.もし帰国子女が国籍を選択する際、外国を選ばれたら削除には3500万円掛かるのですか?
    • by Anonymous Coward
      > 8.もし帰国子女が...

      そんなややこしそうな例を上げなくても、
      「だれか死んだらその度に3500万かかるんですか?」
      で十分やろ...
      んで今のシステムは、人が死んでも永遠にデータは消えないのだろうか....
      • by Anonymous Coward
        ソース読め、死んだ場合は問題ない。
        • Re:先生質問! (スコア:1, 参考になる)

          by Anonymous Coward
          まあ、確かに「ソース読め」の一言で終わらせてもいいですが、
          「1人削除に最大3500万円」って表現も悪すぎると思いますね。
          これだと、2人削除なら7000万円かかると誤解しかねない。

          実際には、現行のシステムでは
          ・「住民が死亡した場合か、日本国籍を離脱した場合」以外は、データを削除できない
          ・システムを改修するのに1500万円~3500万円かかる
          という話なわけで。
          • by Anonymous Coward
            >・「住民が死亡した場合か、日本国籍を離脱した場合」以外は、データを削除できない

            御上の決めたことに従わないなら、
            非国民として日本国籍を離脱した扱いすればデータを削除できるんじゃないですか?

            しかしまぁ、一人削除しただけで、サーバダウンの可能性ですか
            「住基ネットは、日本国民全員の力で構成されています!
             誰か一人欠けただけで、日本という国は大混乱になります!
             皆ひとりひとり、生きてる意味があるんです!」
            といって、自殺抑制に繋げることはできないかしら?

            ----
            死亡したらあっさり削除
            • システム上、亡くなったことにしてしまえばOKでは?
              リアルに殺したらまずいけど・・・

              ・・・もしかして件の高裁判事は、行政がネット離脱の召せ締めのために刺客を・・・(゜_゜;)
              • Re:もっと簡単に (スコア:5, 参考になる)

                by Anonymous Coward on 2006年12月11日 23時33分 (#1073819)
                どこにぶら下げようかと思いましたが、とりあえずここに。

                住基ネットの仕様も、箕面市の住民関係のデータベースがどういう仕組みになっているのかも、よく知りませんが、
                 1.住基ネットの上位DB(この場合は大阪府)と下位DB(箕面市)とで、定期的にデータマッチングを行う
                 2.下位DBから上位DBに吐き出すデータは、他のDBからの自動生成
                 3.データに齟齬があるにも関わらず、異動に係るフラグ(移転・死亡・国籍離脱など)が立っていなければエラーが出る
                という構造を想定すれば、「市側の住民関係データベース全てからデータを削除」しない限り、3.のエラーが永遠に出続けることは容易に想像できると思います。
                #タレコミ中の記事を読む限りでは1と3は正しそう。
                #2については、包含関係(「自治体の住民関係DB」⊃「住所、氏名、生年月日、性別のみの住基ネット」)にある2つのDBに別に手入力する間抜けなシステムがあるとも思えないので、多分正しい。

                問題は、「市側の住民関係データベース」ってのが極めて膨大に存在する、ということで、思いつくだけでも、
                 ・戸籍のDB
                 ・住民基本台帳のDB(必要レコードはこれ [e-gov.go.jp]を参照)
                 ・個人住民税のための所得DB
                 ・国民健康保険のDB(無保険者を避けるため、成人であればレコードが必ず発生)
                などがあります。

                そして、これらのDBが相互にリンクして巨大な一つのDBとして機能しなければ、自治体として最も基本的な住民サービス(住民票の写しの発行や国民健康保険にかかる医療費支払いなど)が提供できないことも容易に想像できます。

                というわけで、「市側の住民関係データベース」も無矛盾になるよう、データが相互参照され、「特定のDBにだけ登録されない人」の存在を許す構造にはなっていないと思われます。

                したがって、「特定の誰かのデータを住基ネットに登録しない」解決策としては、
                 ・「住基ネットには登録しない」というフラグフィールドを「市側の住民関係データベース」に新たに追加し、全レコードをリビルド。さらに、住基ネット上位側に吐き出すデータの生成時にはこのフラグフィールドを参照する仕組みを新規構築。
                 ・「住基ネットに登録してほしくない」という人のデータを、自治体の全データベースから削除し、その人にかかるデータについては全部紙で別管理する。
                と、タレコミの記事中にある2つの方法以外、無いことになります。
                #ので、「全部紙管理」に切り替えれば、システム改修コストはかからないが、この住民に行政サービスを提供するためには、継続的に気の遠くなるような人件費が消尽される…。

                で、メインフレームな12万件もデータが詰まったDBに対し、新規フィールドを追加定義しDBをリビルドする作業を、休業日中に他のバッチの合間を縫って行うことにどれくらいコストがかかるかを考えれば、3500万という数字はそれほどぶっ飛んだ数字ではないと思います。
                #まぁ、高いっちゃ高いけど

                というわけで、DBの要件定義をチロっと想像すれば分かるようなことを考えもせずに、既存システムが腐っているという結論だけを導き出したがるのか、ちっとも理解できませんです。
                #まぁ、この場に「俺様システム」以外のシステムを構築・運用経験が無い人が山ほどいるのはよくわかりますけどね…。
                親コメント
              • Re:もっと簡単に (スコア:1, すばらしい洞察)

                by Anonymous Coward on 2006年12月11日 23時59分 (#1073844)
                私も元ACの考察に全面賛成。誰か+3ぐらいモデしてあげて。

                消すだけなら簡単。
                消した後も住人が存在し続け、しかもサービスを滞りなく提供しないと
                いけないから難しい。
                親コメント
              • by Anonymous Coward
                いやー悪いけど全然分からないや。
                マスタ情報の論理削除と何が違うの?
                こんなものどのシステムでもよくある話では?
              • by akudaikan (26016) on 2006年12月12日 9時52分 (#1073944)
                今ある論理削除フラグ(死亡、国籍変更、職権消除等)では市役所側のシステム上でも削除されたことになるから、新たに住基ネットにデータを流さないようにするだけのフラグが必要だってことだよ。
                # 今ある論理削除フラグの領域を流用してもいいけど、下流システムへの影響が把握できないから新規に作成すると思う。
                同市の住民は12万人だけど、メインフレームの古いシステムだと外国人や過去の蓄積を同一DBで運用している場合もあるから、30万から40万件ぐらいになるかもしれないし、最近は休日だって稼動している場合もあるので下手すれば年末年始作業になるかもしれないし、元ACが指摘している作業条件より厳しい可能性もあると思うよ。
                親コメント
              • by Anonymous Coward
                元から、”異動に関わるフラグ"に"銃器ネット離脱・削除"があればいいだけの話では?
                死亡や国籍離脱は必ず地方自治体側から提出されますから、現在対応できてるものと同じ同期タイミングで”レコードを無効”にできます。
                後はどこかのタイミングでお互い"無効データの削除"をすればいいだけ。

                無効データの削除に関しても同期が取れてなければエラーになる場合は、どう見てもシステムのつくりが悪い。無効なデータは無視して同期するようになっていれば問題ないはず。無効なデータ(エラーデータ)はシステム上必ず存在するもの。

                エラーデータがある時点でサーバーダウンするのは作りが屑と言われて当たり前。

                エラーデータは、弾いて警告を出し、サーバーと基幹業務自体は常に継続。基幹系業務のプログラムでは当たりまえのことですが?

                大きな会社で各支店ごとにサーバー建てて、1支店のエラーデータが会社全体麻痺させるなんて聞いたことありますか?
              • 今回の件は、以下の2つの問題が絡んでいるわけですが、この二つを混同しては行けないと思います。

                ●地方自治体の持つ住基ネット向け住民基本台帳データベースと、国側の住基ネット情報データベースの整合性の問題
                データを削除するとサーバがダウンする、という問題です。元々想定していない事態が起きているのでしょうか? [srad.jp]
                こちらの問題については、確かに「死亡」相当の処理を行えば、住基ネット側の情報を消すことは可能でしょう。

                ●地方自治体内で、住民票データベースと住基ネット向けデータベースの整合性の問題
                まず大前提として、住民として存在する以上、地方自治体内で必要な「住民票」データを削除してしまうことはできません。

                やらなければならないのは、「住民票」データを、「住基ネット」データに反映させないことです。
                現状ではそれができるようなシステムにはなっていない(住民票データベースにある情報は全て住基ネットに流れるようになっている)ために、
                対応策としては、
                ・システム改修を改修し「住基ネットには情報を流さないフラグ」を作る(1,500万円~3,500万円かかる)
                ・電子的な住民票データベースからは削除し、その住民については紙の住民票で管理するようにする
                のどちらかしかないという状況になっているわけです。

                つまり、この状況下で「マスタ情報の論理削除」という対応は、それだけに留まらず、
                地方自治体内のデータベースからも削除し、紙で管理する、という対応を意味するわけです。

                親コメント
              • by Anonymous Coward
                >> #1073819さんへ。

                企業のシステム構築現場で働いてますが。
                ”エラーデータ1件で上位サーバーも含めてサーバーが落ちる可能性がある”設計・実装のどこが屑でないのか教えていただけますか?

                実際のDBの同期方法に関する考察は私も #1073819に一行も反論するものではございませんが、"1レコード削除自体がエラーとみなされる"事が”システムの不具合でない理由には #1073819はまったくなっていません。

                理論的には企業の商品マスタやエラートランザクションの削除とおなじものと思われますので。
                各支店毎にサーバーを建て、夜中に発注情報や新規マスタの前者同期などは一昔前いくらで
              • by Anonymous Coward
                >理論的には企業の商品マスタやエラートランザクションの削除とおなじものと思われますので。

                企業の商品マスタと戸籍情報マスタが同じだと思うのであれば、その理由を挙げてみてください。

                  #まあ戸籍もとあるところでは売り買いできるようだから、商品の一種かもしれんけど

                >ほかの方も言及してますが、”間違った戸籍を登録した場合、死亡扱いにするのですか?”。
                >削除ができないのは明らかにシステム設計のミスです。

                戸籍法ぐらい調べてから発言しましょう。
                システムが扱う情報の特性すら調べずに発言するのはバカです。
              • ユニオンショップ制の労働組合で、労組から脱退したら解雇、ってぇのと同じですかね。
              • by Anonymous Coward
                「特定のDBにだけ登録されない人」の存在を許す構造にはなっていないと思われます。

                それこそが問題の根本で、設計不具合の何者でもないとおもいますが?

                ほかの方も言及してますが、”間違って登録された場合、死亡にするのですか?改名?”どちらも"生まれてない人が生まれて死んだことになる。””改名してないのに改名したことにされる”等の問題がありますね。

                システムの入力は人の手が解する以上、エラーデータがある事は前提に設計すべきです。エラーデータの削除も通常はシステムの必須用件です。

                エラーデータが1件あるだけでサーバーがダウンする可能性があるシステムは間違いなく、欠陥システムです。

                大体、エラーがあっても無視してログ吐くだけにしとけば何の問題もないんじゃないの?

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

処理中...