パスワードを忘れた? アカウント作成
354575 story
バグ

療養費の通知書に桁違いな記載ミス、不適切な入力が原因? 117

ストーリー by hylom
このシステムを作ったのは誰だープロマネを呼べー 部門より

papa-pahoo 曰く、

東京都後期高齢者医療広域連合は、療養費の通知書1万879通について、実際の支給額より高額な書面を送付していたという。中には3兆5100億円と誤記された例もあったそうだ(朝日新聞の記事都広域連合によるお詫び)。

通知書作成時の操作ミスが原因とのこと。支給額は13桁で入力しなければならず、たとえば「1351円」を入力するには「0000000001351」と入力しなければならないのだが、ここに「1351」と入力してしまうと「3510000000000」、つまり3兆5100億円になってしまうという。そのほか、月はかならず2桁での入力が必要なのだが、「08」と入力するところを「8」と入力したために「80月」になってしまった、という例も多いそうだ。

0を入力し忘れるだけで先頭の1を消してしまうUIの設計の方に興味を引かれてしまった、不謹慎なタレコミ子であった。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2011年08月17日 20時31分 (#2004768)

    /.では言わずもがなだけど、あえて書くなら「不適切な入力が原因」じゃなくて、「不適切な仕様」「設計」「検収テストの不備」が原因だよね。
    百歩譲って固定桁入力を強制する仕様であるとしても、入力桁数が足りないのにエラーとせずに処理を続けるとか、そもそも支給額の入力に国際的大企業の年間売り上げに匹敵するような金額の入力桁数が必要な理由とは何だ? とか…。
    それが元々のシステムから潜んでいた不具合だとしても、システムの更新の際に修正されなかった理由とか、いろいろと不可解な点が多過ぎる。
    ちゃんとしたニュースとして扱うなら、そっちを掘り下げるのが筋じゃないのかな。

  • 今後の対策 (スコア:3, 興味深い)

    by ILH (11814) on 2011年08月17日 16時15分 (#2004571) 日記

    http://www.tokyo-ikiiki.net/topic/data/kougakugokisai_110817.pdf [tokyo-ikiiki.net]によると、今後の対策は

    東京都後期高齢者医療広域連合において、業務に用いるマニュアルを再整備すると
    ともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。

    との事。
    アプリケーションの改修は?

    • Re:今後の対策 (スコア:5, 参考になる)

      by Anonymous Coward on 2011年08月17日 22時23分 (#2004816)

      「東京都後期高齢者医療広域連合としては」、現状ではその対策しか取れないからでしょう。
      なぜなら、広域連合は、国が作った糞システムを高い金を払って使わされているからです。

      下のページを見れば分かりますが、広域連合も市町村も国が用意したシステムを使っているだけです。
      http://www.wel.ne.jp/doc/feature/healthcare/kouki2/3.html [wel.ne.jp]
      カスタマイズ部分だけ、広域連合や市町村が金と責任をもって開発することになっています。

      そして、この国が作ったシステムですが、当初からバグだらけで本当に糞システムだとの話です。
      厚生労働省の仕様書が公開されて、翌日には差し替えになったという、最初からダメダメな臭いがするプロジェクトでした。

      システム研究会やらを作って広域連合の意見を吸い上げるなんてこともしてましたが、それでもこの糞仕様という有様。
      矢面に立たされる東京都後期高齢者医療広域連合としては、はらわたが煮えくり返っていると思います。

      親コメント
    • by Anonymous Coward on 2011年08月18日 8時13分 (#2004964)
      件のシステムとは無関係ですが、お役所関連のシステムに関わった経験から言えば、ありがちな不具合ですね。
      一見して「これはマズいだろ」的な仕様上の不備を見つけて指摘しても「この指定なので、これでお願いします」のゴリ押しなんですよ。
      根本的な理由は知りませんが、製造工程の下請けがとやかく言っても議論の余地がありませんのです。
      実装を終えるとその仕様通りに機能していることを確認して検収させるわけですが、何かあったときに実装した下請に責任転嫁されても困るので、今回の件のような「入力ミスを犯したらとんでもない結果を招くこと」も試験項目に揚げて検収させてます(弊社の場合)。
      アホな下請けはそこで手を抜いて痛い目に遭うようですが。

      >業務に用いるマニュアルを再整備すると
      >ともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。

      なにしろ仕様は誤っていないというのが大前提なのですから、錯誤があるとしたら運用の側ってことです。
      お役所仕事らしさ100%ですね。
      親コメント
    • Re:今後の対策 (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2011年08月17日 18時02分 (#2004643)
      > アプリケーションの改修は?

      「作業者の不注意」以上に突っ込んだ話にしたら、
      仕様確認や検収でハンコ押した人を処分しなきゃいけなくなるじゃないですか。
      親コメント
  • 似たような話 (スコア:3, 参考になる)

    by sillywalk (15002) on 2011年08月17日 18時44分 (#2004689) ホームページ 日記
    個人宅に水道代17億円請求 / 後に玄関に置手紙 [youpouch.com]
    使用水量が55,555,470[m3]とか計算されたら、検針用ハンディターミナルは
    さすがにエラー表示を出せよと思ったw
    --
    And now for something completely different...
  • まさかとは思うけど、計算は別の所で?
    どんだけ税金泥棒させてんだよ。

    • by Anonymous Coward on 2011年08月17日 20時18分 (#2004760)
      結構あるんですよね、特に文系の経理の人とか疑問に思わないらしいです。
      昔、研修で経理で金額の入力業務を任された時の事です。その元の伝票が
      既にプリンタで打ち出されているの物でしたので、「この下のデータは、どこに
      あるのですか?」と聞いたところ、その女性の先輩はキョトンとしていました。

      データベースからデータベース(請求書か?)は、プリントして手入力してんじゃ。
      この税金泥棒め!
      親コメント
      • しかし...この時点でコメントが42あるのにデータフローの話してるのここの2つだけで残りはほとんどUI話とか、どうなってんだ?

        親コメント
      • 人から聞いた話ですが、行政関連のシステム化、システム刷新のプロジェクトは「現行の業務フローを一切変更しないこと」という前提がついていることが多いらしいです。
        業務を変えるためには法律や条例を変える必要があるので云々、と聞きました。
        詳細な業務手順まで法律や条例で決められているとはとても思えませんが、組織構成・役割分担は規定されてそうですし、そのへんのしがらみで業務フローの改善を盛り込みにくいというのはあるかもしれません。
        その上役所系は単年度会計なので中長期的な投資効率は無視されてしまいがち、予算獲得が重要視される一方でコスト削減が軽視される、その結果、面倒くさい手続きを踏んでまで業務フローを変えるモチベーションが生まれないというのは無理もないです。

        業務フロー、データフロー以前に、行政の制度設計自体が時代に合わなくなっているというところまで遡らないといかんともしがたいんでしょうねえ・・・。
        親コメント
  • by Technobose (6861) on 2011年08月17日 18時22分 (#2004667) 日記
    こういう、ミスは起き続けると思うな。
    公的機関に限られるのかわからないけど、大型機やオフコンベースで開発された
    システムの操作性って、直感的でないというか呪術的な操作方法のものが多い気
    がしますね。
    で、入力データのチェック方法も入力画面を目視でチェックするしかないとか、
    ユーザーに不便を強いるのが当然みたいなシステムが多すぎ。
    それも独自開発したものだけでなく、大手SIerのパッケージ商品でもそう。
    で、根本的な問題は導入するユーザー側の意識なんだよね。
    更新時に、操作性の改良とか、他システムとの接続で自動化を進めるといったこと
    は全くしないし、そもそもそういう非機能要件の調査すらしている気配はないし、
    いってしまえばベンダーの言うがままになっている。
    ユーザー側が、対象業務を分析してどういうシステムが必要かユースケースで説明
    できる位のスキルは必要だと思う。

    ・・一応、病院のオーダリングシステムとその関連業務システム導入の担当計画を
    たてて導入事業を担当したことがあるけど、業務分析をしたら「そんなことをした
    職員は初めて」とか言われた経験が・・・。
    たぶん、費用対効果分析したのも私ぐらいだろうなぁ。
    実質、担当者が一人だったので、情報処理技術者試験のプロジェクトマネージャの
    テキストを参考にやりました。
    私の担当したオーダリングシステムは導入して、かなり効果があったようなので、
    偉そうにいってみる。(--;)
  • 計算機入力の人間学―打鍵入力信頼性技法 [amazon.co.jp]
    T. ギルブ、G.M. ワインバーグ 著
    木村 泉、米沢 明憲 訳
    共立出版 (1986/07)
    ISBN: 4320022556

    …が、古典だと思うけど残念ながら品切れ。

  • by cudjo (2713) on 2011年08月17日 18時45分 (#2004693)

    もしかしてこれは、コンピュータが真の知性を持ったことを現わしているんじゃなかろうか。
    「月は無慈悲な夜の女王」の月世界中央コンピュータが知性と自意識を獲得して最初にやったのが、
    月政府の雇用する清掃係に桁違いの莫大な給与明細を発行することだったはず。
    彼と唯一心を通わせたコンピュータ技術者は、そういう一回だけしか面白くないジョークは
    やめるよう説得していた。

  • by eukare (2230) on 2011年08月17日 18時51分 (#2004700) 日記

    単純に不足桁分の0を後ろに追加してしまうだけならまだ分からんでもないのだが、
    (タレコミにもあるけど)先頭の1を消してしまうというのはどういう作りなんだろう?

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...