佐賀市が基幹システムのバグで課税ミス、去年はデータを手直し？ 77
ストーリー by yoosee
あまりに場当たりすぎる対応 部門より
あまりに場当たりすぎる対応 部門より
気持ちはわからないでもないAC曰く、"asahi.comの記事によると、佐賀市は19日、市独自の基幹システムで、バグを原因とする課税ミスがあったと発表したとの事。
記事によると、国民健康保険税は世帯ごとに国保加入者の合計の年間所得に課税されるが、プログラムでは今年度に65歳になる国保以外の健康保険に加入している世帯主の所得も誤って加算していたため、本来よりも高い税額になったという。プログラムは16日に修正し終えたとのこと。
…ここまでなら、ただの良くあるバグの話題なのだが、実はこのシステムは '05年4月から運用されており、昨年は問題が起きていなかった。
この基幹システムは 同市が韓国のサムスンSDSと共同開発したものだが、運用開始直後は約50人の同社員がエラーをチェックしていたという。どうも昨年はデータがおかしい事に気づいた人が居たものの、データだけ手直して、プログラムはそのまま放置されたらしい。
まずいとは思いつつもこっそり修正、というのはデスマーチでは見かけないこともない光景だとは思うが…、データだけ直してもプログラムがそのままじゃ、いずれ再発して発覚するとか考えなかったのだろうか？"
わからないでもないです (スコア:5, 興味深い)
会計システムなんですけど、まともに動いてなくて、事務の人がやたらとデータベースに詳しかったりしました。
テーブルを全て把握してるのは勿論、リレーションとかトランザクションとか、そんな話も普通に通じたりして。
別にコンピュータが趣味ってわけじゃない普通の事務員さんが、そこまで詳しくなっちゃった経緯はあまり想像したくないのだけど。。
まあ、バグを承知で、運用でカバーしましょうってぐらいはよく聞く話ですよね。
多分、世の事務員さん達は日々、怪しげなシステムに翻弄されながら果敢に電卓を叩いているのでしょう。
がんばってー
そして、ごめんなさーい。
こんな光景が浮かんだ (スコア:4, おもしろおかしい)
ん？あぁっーー！・・・と、とりあえずデータ直して見なかったことにしよう。もう知らん！何も知らん！
マイノリティはつらい (スコア:0)
まぁ、たしかにしんどい仕事を互いに慰め合うのは必要なんだけどね。でも、しんどい仕事ってのはいくらでもある。しんどいって意味もいろいろある。たしかに、ここはスラドなので人口比率からいってIT関係者が多数を占めて、デスマーチで共感を覚える人が多いんだろうけどさ。
Re:マイノリティはつらい (スコア:1)
余裕が無い時は思いやる心が持ちにくいものです。
ヒースキット山口 heath yamaguchi
Re:マイノリティはつらい (スコア:0)
>しんどいって意味もいろいろある。
ですよね〜
ウチの社長（や部長）もよくそう言ってます。
Re:マイノリティはつらい (スコア:1)
>>しんどいって意味もいろいろある。
>ですよね〜
>ウチの社長（や部長）もよくそう言ってます。
それって、ただ単に内臓疾患なのでは?
先に社長がコロッと逝く可能性は少ないでしょうけど
Re:マイノリティはつらい (スコア:0)
>>しんどいって意味もいろいろある。
>ですよね〜
>ウチの社長（や部長）もよくそう言ってます。
良かったじゃないですか。
社長や部長がよく世間を知っている人で・・・。
Re:マイノリティはつらい (スコア:0)
Re:マイノリティはつらい (スコア:0)
などと思ってる人間は勝手に自沈していきますから、
巻き込まれないように生暖かく眺めておけばよいと思いますよ。
自沈しているくせに周囲のせいにしたがるのはうざいけどね。
後で発覚してもいいんですよ (スコア:3, おもしろおかしい)
＃日本の企業では無理なのでID
Re:後で発覚してもいいんですよ (スコア:2)
・引き渡しから一年以内のバグは無償修正
・それ以降は明らかなバグでも有償修正
だからなんとか金とれるよう一年間ごまかそうとしたんでは？
Re:後で発覚してもいいんですよ (スコア:1)
ヒースキット山口 heath yamaguchi
Re:後で発覚してもいいんですよ (スコア:1)
Re:後で発覚してもいいんですよ (スコア:1)
ソースライセンスってことは修正するとばれるわけで。
先に謝ってからじゃないと修正できない気がする。
子供の喧嘩みたいな話だけど、本当に有りそう。orz
#（バグを）探してください、佐賀県
テストデータの網羅性って重要だよね (スコア:3, 興味深い)
シミュレーションでもわざと確率分布をツイストして稀少事象を発生させることってありますよね？うちの上司は確率とか統計とかのこと勉強しなかったんだろうか。一応かなりの一流大学の経済系出身と聞いてるんだが。
屍体メモ [windy.cx]
Re:テストデータの網羅性って重要だよね (スコア:2, おもしろおかしい)
＞うちの上司は確率とか統計とかのこと勉強しなかったんだろうか。
＞一応かなりの一流大学の経済系出身と聞いてるんだが。
その上司の存在がきしょい^h^h^h^h稀少事例では？
/* Kachou Utumi
I'm Not Rich... */
Re:テストデータの網羅性って重要だよね (スコア:2, 興味深い)
とあるデータウェアハウスシステムの開発中、
2億件中3件ぐらい特殊なデータが発生する事が判明。
顧客は「グラフで大局をつかむ」的な用途とのことで
無視することにしました。
グラフにすれば1ピクセルにもならないデータです。
「ちゃんとテストする」のは大事ですが
「そのテストが妥当かどうか」考えるほうがもっと大事かも。
Re:テストデータの網羅性って重要だよね (スコア:1, おもしろおかしい)
それ、開発じゃなくてパラメータ調整だよね？
Re:テストデータの網羅性って重要だよね (スコア:2, 興味深い)
昔々に居た会社では、
「テストなんて金に成らないんだから、前回の分でも使い回せば良いんだ！」
と堂々とのたまった上司がいました。
で、当然売り上げは上がる訳で、そういう人が「切れ者」とか言われていたり。
後はサポートに全部投げてしまって、サポート部隊相手の対応がタイヘンになってしまった覚えも。
他にも「おまえらは試験しなけりゃ使えない物なんか作っているのか！」とか名言には事欠かなかったなぁ。
勿論、「んなものアタリマエだ！」って言って喧嘩して退社したが。
＃一つだけ評価してたのは、彼は自分で断言したこと。
＃そこは同じことを言うのでもネチネチと言って、部下の口から言わそうって奴よりはマシだった。
Re:テストデータの網羅性って重要だよね (スコア:1, 興味深い)
経済学部の人間にとっては、統計は人を説得するための武器であり、自己を省みるものではありません。
社会学部の人間だとその傾向はさらに強くなります。
彼らは大学ではそのスキルを身につけるのです。
これは良心とかの問題ではなく、純粋に文化の違いの問題です。
ですから、当然彼らは良心の呵責など感じていません。
出身学部は関係ないでしょ (スコア:2, すばらしい洞察)
経済学部はどーのこーの、社会学部はどーのこーのって...
スラド特有の学部差別ですか？
理工系でアバウトな上司と情報系でスーパーアバウトな嫁に悩まされてる経済系で管理部門な俺としては釈然としないなぁ
Re:テストデータの網羅性って重要だよね (スコア:1)
コメント全体として云いたいことは分かりますけど、経済学部・社会学部以外の人間にとっても、統計は「自己を省みるもの」ではないでしょう。
# 統計学的反省術？
あと、まあ、過度の一般化はやはりよろしくないかと。
理系の学会でも（まあ正直そんなにレベルの高い学会じゃありませんけどorz）、相関関係と因果関係を無邪気に混同しているオジサンなどは時々見ますよ。統計とかよく分からないけど、とにかく統計解析ソフトにデータ入れて計算してみました、ってな舞台裏が透けて見えるような発表もけっこうアリガチですし。昔は（今でも？）統計学は必ずしも理系の必須知識とは見なされていませんでしたからねぇ。
# 必修科目じゃありませんでしたもの。
課税ミス、徴収ミスはよくあること (スコア:3, 興味深い)
佐賀市の例だけ取り上げるのはいかがなものかと。
税制が複雑で毎年コロコロ変わるというのが遠因でしょう。
Re:課税ミス、徴収ミスはよくあること (スコア:4, 参考になる)
本来は国民健康保険「料」とするのが正しいのですが、それだと義務感が薄くなって納付率が低下するので「税」として徴収することも認められており、それによって強制力を高めています。
税金であれば税率などを条例で予め決めておかなくてはいけませんが、国保税ではそれをやっていない自治体もありました。
税率がその年に議会を通さずにいきなり変えることができると、住民はたまったものではありませんよね。
保険「料」とすると租税ではないので自治体は課率を変動させやすい反面、徴収は大変です。
保険「税」とすると徴収は楽ですが自治体のほうも税金として扱う必要があるので不便なところもあります。
基本的に、老人や自営業、無職、フリーターのような低収入で保障の少ない人々が強制加入・徴収される保険税ですが、低収入なのに医療費がたっぷりかかる老人の割合がかなり大きいために、支払う人たちの負担は大きくされてるわけです。
予め税率を定めていない自治体が存在するのは、そのように老人医療で徴収額以上に支出があったときに即座に対応できるようにしているからかもしれません。
また所得だけに応じた通常の税とは違い、世帯の人数などでも課税額が変わる「人頭税」に似た部分も含まれている自治体もあるので、計算は複雑です。
そういう「税」としては変な保険税ですから課税ミスが起きやすいのかもしれませんね。
だから売り上げが毎年計上できるんです (スコア:2, 興味深い)
ただし、あくまで「売上計上」ができるだけであって、 「利益計上」とは限らないところが難点ですが。
MIYAZAKI Yasushi
Re:課税ミス、徴収ミスはよくあること (スコア:1)
普通の自治体だと「瑕疵担保？知るかんなもん」とばかりに即(もしくは次に使うときまでに)システムを修正させるでしょう。
＃バグがあって計算間違えた、だけなら(タレコミにあるとおり)よくある話だけど。
Re:課税ミス、徴収ミスはよくあること (スコア:1, 参考になる)
シンドラー社のエレベーター事故のあと、「エレベーターに３０分閉じ込められた」とかいうのがやたらと報道されましたが、あんなの全国で毎日１件くらいは起きているんですがね。福知山線脱線事故のあとのオーバーラン３ｍとか。
次はエスカレーターで死亡事故があったときかな？ もっとも、全国で１５ヶ月で１０００人の怪我人 [tokyo.jp]を出してるんですけどね、エスカレーターってやつは。
なおすの？ (スコア:2, 興味深い)
でもね… ダメなコードは [srad.jp]
「そのままスルー」とか「存在をもみ消す」にもけっこう票が集まっていたり…
----------------------------------------
You can't always get what you want...
なおしちゃいけない (スコア:2, 興味深い)
組織も含めたシステムの種類にもよりますが, 場合によっては正しい処理を行うことよりも以前と同じ結果になることが優先されることがあります. 下手に修正すると過去に遡って責任が追求されるため, それを避けるためらしいですが. こういう組織には「過ちを正すに憚ることなかれ」なんて言葉は無いのでしょう.
過去に一度だけ, そういう事例を経験しましたが, その組織は後に大問題を起こしてます.
Re:なおしちゃいけない (スコア:1, 興味深い)
「プログラムを最適化して精度誤差を減少させました」
「すると何かね、今までのプログラムは間違っていたということかね？」
「いえ、間違っていたわけじゃなくて、誤差があったのです」
「じゃあどうして同じ結果が出ないんだ」
で、泣く泣く前と同じ結果が出るようにオプションを追加させられたり…
これが理工系の大学の先生だから恐れ入る
Re:なおしちゃいけない (スコア:2, 参考になる)
計算物理系なら誤差の無いプログラムは無理・・・
#よっぽど特殊な場合を除き。
Re:なおしちゃいけない (スコア:2, すばらしい洞察)
分野によるかと．
物理計算系なら当然誤差の評価も行ってますから，別に無駄にはならんでしょ．
計算精度が上がって前と違う結果が出るんなら，（計算が収束していく類の
ものなら）前回の結果が間違っていただけで，精度を上げて悪いわけでは無い，
というか悪い精度で計算を続けるのは間違い．
#精度を上げたせいで（結果はほとんど変わらず）時間がかかる，
#ってんなら問題ですが．
Re:なおしちゃいけない (スコア:1, 興味深い)
目の前にあるのは旧システムのソースだけ。
ある責任者は…
「旧システムのソースは解かりづらくなってるから、解りやすくなるように作り替えていいよ」と言う。
ある責任者は…
「途中の処理はともかく、目に見える結果だけは旧システムと同じになるように」と言う。
ある責任者は…
「旧システムの(ある)動きはまちがいなくバグだから、結果がこうなるようにしてね」と言う。
もちろん、責任者同士での調整作業はほとんど無し。
…いや、まぁ、最終的に俺が責任とれる問題じゃないし、どーなろうといいんだけどさぁ。
外注組が激しくやる気を失ってる現状にも気づいてないみたいだしなぁ…
Re:なおすの？ (スコア:1)
ダメはダメだけど、一応正しく動いているなら、(見なかったことにして)そのままスルーとします。
でも、バグってたら直すしかありませんもの。 ええ、泣きながら直しますよ。
の
Re:なおすの？ (スコア:2, おもしろおかしい)
1 よいコードできちんと動くプログラムを書く者
2 悪いコードできちんと動くプログラムを書く者
3 よいコードで動かないプログラムを書く者
4 悪いコードで動かないプログラムを書く者
1と4を把握することが最優先課題ではあるが、2と3をいかに有効利用するかが全体の生産性を大きく左右する。
また、例外的なカテゴリとして、
5 よいコードできちんと動くが、多くの人（たいていは本人以外の全員）が理解に苦しむ奇特な構造を好む者
がおり、1との判別が意外と難しいので注意すること。
Re:なおすの？ (スコア:1)
/.にタレこまなかったのは非常に残念な事だ。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
2004-08-05 のTmaxSoftのプレスリリース (スコア:2, 興味深い)
これって西日本新聞の記事と同じだけど、文中にはそのような表記はない。ひょっとして西日本新聞の記事って広告みたいなもの？
第2の佐賀市って佐賀市に続くミスった市町村を探す？(^^;
[これはひどい]ミスリーディング? (スコア:1)
おーい。朝日の記事は
> 市情報政策課は「昨年度もエラーはあったはずだが、データを手直ししただけで、プログラム自体を修正しなかった可能性が高い」と話している。
と言っているに過ぎないぞ。
Re:[これはひどい]ミスリーディング? (スコア:0)
Re:[これはひどい]ミスリーディング? (スコア:1, すばらしい洞察)
・この不具合ならデータ上去年も起きていたはず
・この件に関する修正報告を受けていない
ってことでしょ。
もちろん実際には調べなきゃ分からないけど。
課税ルールは複雑すぎる (スコア:1)
解決策: 人頭税
---- 末は社長か懲戒免職 なかむらまさよし
同社員ってことは (スコア:1)
ってことは、サムスンの責任か・・・。
行政もなんでこんな大事なものを海外に発注するのかね…。
// せめて「お金がからんでいる」ものぐらい日本企業にしてくれ・・・。 //
// 「安いから」って言っていう言い訳だけはやめて。 //
Li-ion DC 1.2V（定格：3.7V) 500mA 乾電池はリサイクルへ
Re:同社員ってことは (スコア:1, 参考になる)
大手メーカーのべらぼうに高い金額を吹っかけられる上、ブラックボックスを押し付けるなどいろいろな問題からオープンシステムという条件をつけたという話だったとおもいます。
記憶があいまいなので、過去の日経をさがしてみてください。
詳しくかかれているかと思います。
ユーザーも仕様書くらい書けるようにしよう (スコア:2, 興味深い)
おそらく仕様書すらないまま「こういう風に計算してください」と行政の担当者から言われて開発、あとで「これではまずいので手直し」といったことを経験しているので、本来の工数に手直し分を最初から含んで見積もりしているからだよね（ここまでは良く聞く話）。
けどユーザーからしたら、システム開発のための仕様書なんてそうそう書く訳でもないし、普段使わない用語や概念を交えて文章化しなければならない。
そもそも役所の場合、業務の手順や判断基準の文書化すらできてないところが大半では。まず業務手順の文書化（モデル化）から始めないといけないですね。
で、ここでまた「普段やり慣れていない業務の用語や概念」という問題が出てきます。思うにシステム化に限らず、業務効率化はできるはず。しかし、それを実行するためには「業務の見直し（その前準備としてのモデル化）」などが絶対必要です。しかし、このために必要な知識って、未経験者が簡単に身につけられるようなものではないと思う。
なので業務のモデル化を手助けする担当者を配置して、まず業務の文書化から始めたらどうでしょうか。
そしてシステム化の時は、まずシステム化が必要なのか、システム化によってどのような効果があるのかの検討、仕様書やテストケースの作成、仕様書通りに作られているかなどまで業務担当課と二人三脚で担当していけば、こういうミスは減らせると思います。
少なくともシステム開発のユーザー側担当者がユースケースとクラス図くらい理解できるようになれば、かなり改善できると思うけど。
初めて自分たちで確認して (スコア:0)
昨年はベンダー任せだったとか。
下っ端事務屋としては (スコア:0)
なんでその後プログラムを修正しなかったのか不思議。
Re:下っ端事務屋としては (スコア:1)
マラソンで二位を抜いたら何位？
Re:事務屋さんが手直しで終わったのでは？ (スコア:1)
それで終わった可能性も。
自治体のシステム (スコア:0)
Re:出力結果の手直しかぁ (スコア:1)
・直したつもりで直ってなかった
・直したらそのせいで別のバグが出た
・直したけど気づいていない別のバグもあった
という可能性もあるかも．