療養費の通知書に桁違いな記載ミス、不適切な入力が原因? 117
ストーリー by hylom
このシステムを作ったのは誰だープロマネを呼べー 部門より
このシステムを作ったのは誰だープロマネを呼べー 部門より
papa-pahoo 曰く、
東京都後期高齢者医療広域連合は、療養費の通知書1万879通について、実際の支給額より高額な書面を送付していたという。中には3兆5100億円と誤記された例もあったそうだ(朝日新聞の記事,都広域連合によるお詫び)。
通知書作成時の操作ミスが原因とのこと。支給額は13桁で入力しなければならず、たとえば「1351円」を入力するには「0000000001351」と入力しなければならないのだが、ここに「1351」と入力してしまうと「3510000000000」、つまり3兆5100億円になってしまうという。そのほか、月はかならず2桁での入力が必要なのだが、「08」と入力するところを「8」と入力したために「80月」になってしまった、という例も多いそうだ。
0を入力し忘れるだけで先頭の1を消してしまうUIの設計の方に興味を引かれてしまった、不謹慎なタレコミ子であった。
「原因」が不適切な入力? (スコア:5, すばらしい洞察)
/.では言わずもがなだけど、あえて書くなら「不適切な入力が原因」じゃなくて、「不適切な仕様」「設計」「検収テストの不備」が原因だよね。
百歩譲って固定桁入力を強制する仕様であるとしても、入力桁数が足りないのにエラーとせずに処理を続けるとか、そもそも支給額の入力に国際的大企業の年間売り上げに匹敵するような金額の入力桁数が必要な理由とは何だ? とか…。
それが元々のシステムから潜んでいた不具合だとしても、システムの更新の際に修正されなかった理由とか、いろいろと不可解な点が多過ぎる。
ちゃんとしたニュースとして扱うなら、そっちを掘り下げるのが筋じゃないのかな。
Re:「原因」が不適切な入力? (スコア:1)
このような案件じゃ名の通った大手なんて費用が倍額以上
違ったりするので入札でふるい落とされますよ
今後の対策 (スコア:3, 興味深い)
http://www.tokyo-ikiiki.net/topic/data/kougakugokisai_110817.pdf [tokyo-ikiiki.net]によると、今後の対策は
との事。
アプリケーションの改修は?
Re:今後の対策 (スコア:5, 参考になる)
「東京都後期高齢者医療広域連合としては」、現状ではその対策しか取れないからでしょう。
なぜなら、広域連合は、国が作った糞システムを高い金を払って使わされているからです。
下のページを見れば分かりますが、広域連合も市町村も国が用意したシステムを使っているだけです。
http://www.wel.ne.jp/doc/feature/healthcare/kouki2/3.html [wel.ne.jp]
カスタマイズ部分だけ、広域連合や市町村が金と責任をもって開発することになっています。
そして、この国が作ったシステムですが、当初からバグだらけで本当に糞システムだとの話です。
厚生労働省の仕様書が公開されて、翌日には差し替えになったという、最初からダメダメな臭いがするプロジェクトでした。
システム研究会やらを作って広域連合の意見を吸い上げるなんてこともしてましたが、それでもこの糞仕様という有様。
矢面に立たされる東京都後期高齢者医療広域連合としては、はらわたが煮えくり返っていると思います。
Re:今後の対策 (スコア:1, 参考になる)
国会で揉めていたのは記憶にありますが
官僚だろうがSEだろうが、思考速度というものは早くなりません。 [fc2.com]
後期高齢者医療制度は整備不良のバスで行うチキンレースである [fc2.com]
これはもう本当にダメかもしらんね(戦地に赴く前の遺言) [fc2.com]
システムつくりも修羅場だったのですね。
厚労省ってIT利用の本質を理解していない (スコア:1)
はかるなんていう、ごく一般的な常識すらないと感じてました。
あそこは業務分野ごとに、医務薬事行政・医療介護行政・医療介護保険運営、
労働行政とか分割して組織の意志決定と風通しをよくして、なおかつ業界の利
害が影響しにくくなるような体制を整えてるべきだと思いますね。
Re:今後の対策 (スコア:4, 興味深い)
一見して「これはマズいだろ」的な仕様上の不備を見つけて指摘しても「この指定なので、これでお願いします」のゴリ押しなんですよ。
根本的な理由は知りませんが、製造工程の下請けがとやかく言っても議論の余地がありませんのです。
実装を終えるとその仕様通りに機能していることを確認して検収させるわけですが、何かあったときに実装した下請に責任転嫁されても困るので、今回の件のような「入力ミスを犯したらとんでもない結果を招くこと」も試験項目に揚げて検収させてます(弊社の場合)。
アホな下請けはそこで手を抜いて痛い目に遭うようですが。
>業務に用いるマニュアルを再整備すると
>ともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。
なにしろ仕様は誤っていないというのが大前提なのですから、錯誤があるとしたら運用の側ってことです。
お役所仕事らしさ100%ですね。
Re:今後の対策 (スコア:2, すばらしい洞察)
「作業者の不注意」以上に突っ込んだ話にしたら、
仕様確認や検収でハンコ押した人を処分しなきゃいけなくなるじゃないですか。
Re:今後の対策 (スコア:1)
Re:今後の対策 (スコア:1)
血税=徴兵ってのは半分だけ正解ですね。
http://dic.yahoo.co.jp/dsearch?p=%E8%A1%80%E7%A8%8E&stype=0&dt... [yahoo.co.jp]
-- う~ん、バッドノウハウ?
Re:今後の対策 (スコア:1, おもしろおかしい)
そんな予防線を張っても駄目ですよ。容赦なく突っ込ませていただきます。
×最も
○尤も
Re:今後の対策 (スコア:2)
こんな糞仕様に耐えて作業していたのを、優秀と言えないなー。
Re:今後の対策 (スコア:1, すばらしい洞察)
言いたいことは数あれど、それを言ったら契約解除。
Re:今後の対策 (スコア:2)
有りがちだけど、入力欄を二つにするっていうのは、どうだろう。
Re:今後の対策 (スコア:1)
1回目と2回目の入力が異なると,キー入力の直後にアラートが表示されます。 別の人が同じ箇所を同じように間違える確率は低いので,それなりにチェックできます。
# 間違えた人にはペナルティ
Re:今後の対策 (スコア:1, 興味深い)
Re:今後の対策 (スコア:1, おもしろおかしい)
それだっ!
「1351円」を入力するのに、'1' '5' '3' '1'と1の位から上位桁に向かって入力する仕様にすれば上位桁は勝手に0パディングされるじゃん!
オレ天才かも。特許とか取れるかな。
似たような話 (スコア:3, 参考になる)
使用水量が55,555,470[m3]とか計算されたら、検針用ハンディターミナルは
さすがにエラー表示を出せよと思ったw
And now for something completely different...
参考に・・・ (スコア:3, 参考になる)
その水量は大体猪苗代湖 [wikipedia.org]一杯分の貯水量ぐらいです・・・
水を飲むと屁(CH4)をこきます
Re:参考に・・・ (スコア:2)
東京ドーム 約45個分 [google.co.jp]ですか…。
Re:参考に・・・ (スコア:2)
霞ヶ関ビルでお願いします。
#どっちも、ピンとはこない。
Re:参考に・・・ (スコア:1)
いや、その1/100ぐらいです。
http://www.google.co.jp/search?rlz=1C1GPCK_enJP435JP435&sourceid=c... [google.co.jp]^3%E3%82%92km^3%E3%81%A7
さすがに東京ドーム45個が猪苗代湖とつりあうとはおもえなくて
思わず計算しました。
Re:参考に・・・ (スコア:1)
失礼。リンクがうまくはれなかったようで。
http://goo.gl/9jQcS [goo.gl]
てーか、なんで金額を入力? (スコア:2, 興味深い)
まさかとは思うけど、計算は別の所で?
どんだけ税金泥棒させてんだよ。
Re:てーか、なんで金額を入力? (スコア:1, 興味深い)
昔、研修で経理で金額の入力業務を任された時の事です。その元の伝票が
既にプリンタで打ち出されているの物でしたので、「この下のデータは、どこに
あるのですか?」と聞いたところ、その女性の先輩はキョトンとしていました。
データベースからデータベース(請求書か?)は、プリントして手入力してんじゃ。
この税金泥棒め!
Re:てーか、なんで金額を入力? (スコア:2, 興味深い)
しかし...この時点でコメントが42あるのにデータフローの話してるのここの2つだけで残りはほとんどUI話とか、どうなってんだ?
Re:てーか、なんで金額を入力? (スコア:1)
データフローを変更するって話じゃないよ。
「そもそもなんでデータフローの途中に人間が入ってて、つまんねー入力ミスしてるわけ?」って話だからここは。
で、みんなはなぜか「つまんねー入力ミス」の前についてる「(クソUIで)」の部分をつっついてる。
Re:てーか、なんで金額を入力? (スコア:1)
業務を変えるためには法律や条例を変える必要があるので云々、と聞きました。
詳細な業務手順まで法律や条例で決められているとはとても思えませんが、組織構成・役割分担は規定されてそうですし、そのへんのしがらみで業務フローの改善を盛り込みにくいというのはあるかもしれません。
その上役所系は単年度会計なので中長期的な投資効率は無視されてしまいがち、予算獲得が重要視される一方でコスト削減が軽視される、その結果、面倒くさい手続きを踏んでまで業務フローを変えるモチベーションが生まれないというのは無理もないです。
業務フロー、データフロー以前に、行政の制度設計自体が時代に合わなくなっているというところまで遡らないといかんともしがたいんでしょうねえ・・・。
ユーザー組織が考えを改めないと (スコア:2, 興味深い)
公的機関に限られるのかわからないけど、大型機やオフコンベースで開発された
システムの操作性って、直感的でないというか呪術的な操作方法のものが多い気
がしますね。
で、入力データのチェック方法も入力画面を目視でチェックするしかないとか、
ユーザーに不便を強いるのが当然みたいなシステムが多すぎ。
それも独自開発したものだけでなく、大手SIerのパッケージ商品でもそう。
で、根本的な問題は導入するユーザー側の意識なんだよね。
更新時に、操作性の改良とか、他システムとの接続で自動化を進めるといったこと
は全くしないし、そもそもそういう非機能要件の調査すらしている気配はないし、
いってしまえばベンダーの言うがままになっている。
ユーザー側が、対象業務を分析してどういうシステムが必要かユースケースで説明
できる位のスキルは必要だと思う。
・・一応、病院のオーダリングシステムとその関連業務システム導入の担当計画を
たてて導入事業を担当したことがあるけど、業務分析をしたら「そんなことをした
職員は初めて」とか言われた経験が・・・。
たぶん、費用対効果分析したのも私ぐらいだろうなぁ。
実質、担当者が一人だったので、情報処理技術者試験のプロジェクトマネージャの
テキストを参考にやりました。
私の担当したオーダリングシステムは導入して、かなり効果があったようなので、
偉そうにいってみる。(--;)
Re:ユーザー組織が考えを改めないと (スコア:2, 興味深い)
お勧め書籍 (スコア:2, 参考になる)
計算機入力の人間学―打鍵入力信頼性技法 [amazon.co.jp]
T. ギルブ、G.M. ワインバーグ 著
木村 泉、米沢 明憲 訳
共立出版 (1986/07)
ISBN: 4320022556
…が、古典だと思うけど残念ながら品切れ。
1回だけ面白いジョーク (スコア:1)
もしかしてこれは、コンピュータが真の知性を持ったことを現わしているんじゃなかろうか。
「月は無慈悲な夜の女王」の月世界中央コンピュータが知性と自意識を獲得して最初にやったのが、
月政府の雇用する清掃係に桁違いの莫大な給与明細を発行することだったはず。
彼と唯一心を通わせたコンピュータ技術者は、そういう一回だけしか面白くないジョークは
やめるよう説得していた。
不思議UI (スコア:1)
単純に不足桁分の0を後ろに追加してしまうだけならまだ分からんでもないのだが、
(タレコミにもあるけど)先頭の1を消してしまうというのはどういう作りなんだろう?
Re:不思議UI (スコア:1, 参考になる)
先頭1桁の和暦記号は、明治=M、大正=Tとかではなく、明治=1、大正=2、昭和=3と振っておくです。
役所の書類は和暦で表記されるので、書類をコンピュータに入力するUIも和暦である必要があります。
この方式は、和暦を直接テンキーから手を離さずにパンチ可能な方法として一般的と思われます。
Re:不思議UI (スコア:1)
申請書類なんかで「『1.明治 2.大正 3.昭和 4.平成』で番号に○を付けろ」みたいなのは良くあるので
日付項目であればそれなりに納得いくのですが、この場合は金額(数値項目)ですからねえ。謎だ。
Re:不思議UI (スコア:1)
それまでにシステムの方に寿命がきている自信があるのでしょう。
#まんま2000年問題を彷彿とさせるけど、今システム設計する立場だったら私も自信あるな。
#そーとー長く見て50年もののシステムだったとしても、それまでにその回数代替わりする状況って、多分日本が終わってる。
Re:不思議UI (スコア:1)
一世一元の詔のシステム自体が変わるという発想も必要では?
これが流石に、「何年かのうちにすごい宗教家が出てきて、BC, AD使わなくなるよ」というのなら杞憂だと思いますが、
歴史的には現状のシステムの方が短いので、突拍子もないとまでは言えないですし。
Re:不思議UI (スコア:1)
> 一世一元の詔のシステム自体が変わるという発想も必要では?
まったく必要ないです。
何故なら、そうなれば元ACの想定する「不敬」を気にする必要がなくなるから。
(視野狭窄的回答)
何故なら、それは十分に変事なのでシステムの改修費用、期間を別途貰って対応できるから。
(理想論的回答)
何故なら、中途半端に対応可能にしておくと
「こんな事もあるわけですし、年月日は西暦で扱うように変更しましょう」
と言ってまっとうな仕様に変更する、非常に貴重な機会を無為に失うことになるから。
(逆説的回答)
Re:性別マスター (スコア:2)
よって、
1:男性 2:女性 3:トランスジェンダー 0:ヒ・ミ・ツ
という感じにしてはいかが?
Re:不思議UI (スコア:1)
安田生命がそうだったらしいですね。Wikipedia にも記述があるし、
探してみると、こんな記事 [itmedia.co.jp]もありました。
Re:不思議UI (スコア:1, 参考になる)
40年先送りできただけなのに「先見の明」とまで言うこの感覚が判らない。1971年時点で平均寿命が男でも70歳超えているのに。
#ちょうど俺も寿命になる頃だ。安田生命には入っていなかったとは思うが...
何がなんでも1Byteにこだわるなら、パック10進じゃなく符号付バイナリでさらにあと28年先延ばしできたのに。
Re:作ったことがある (スコア:1)
右に同じ。
時刻で数字四桁なのに「:」を入力させたり、二ますにわけて「TAB」を打たせたりする方が嫌われるかと。
そういうオペレータさんからすれば年月日で8桁数字入力だって朝飯前みたいですよ。
Re:いずれにせよ (スコア:1)
請求ではなくて、国からの支払いについても同じのを使うと面白いのだけどね。
そういう方面では使っていないのかな?
Re:いずれにせよ (スコア:1)
>医療費の支給額で13桁を用意しているってのも凄いけど。
>普通じゃあり得ない10兆円弱の支給まで想定しているってこと?
ハイパーインフレを想定しているのかもしれません。
Re:いずれにせよ (スコア:1)
Re:いずれにせよ (スコア:1, 参考になる)
えっと、それが左詰めという問題ということになるかと。
別コメントで"COBOL臭い仕様"と言ってた方がおられましたが、そういうことです。
今時ならFortranでも可変長readが出来るみたいですが、古えの機械では固定長が原則の時代があったのです。空白と0の同一視とか。
#フロントエンドの入力もメインフレームでやってるってこと?
ITに限らず (スコア:3, すばらしい洞察)
けず無理・無駄が多くて、やばいことが多いですよね。
件のところは天下りで仕事をもらうのではなく、制度上、業務を独占し
ているところのような気が(儲かっているかは微妙)・・・・
Re:作った人は起立 (スコア:1, 興味深い)
市町村システム導入で死にそうになったのでAC
Re:作った人は起立 (スコア:2, おもしろおかしい)
拝承。
Re:作った人は起立 (スコア:1)
NTTデータが並んでるのも違和感あります。
「作る」っていう意味ならNTTデータが「作る」より、
NTTデータの下で富士通が作るとか、そんな感じが普通ですよね。