アカウント名:
パスワード:
http://www.tokyo-ikiiki.net/topic/data/kougakugokisai_110817.pdf [tokyo-ikiiki.net]によると、今後の対策は
東京都後期高齢者医療広域連合において、業務に用いるマニュアルを再整備するとともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。
との事。アプリケーションの改修は？
「東京都後期高齢者医療広域連合としては」、現状ではその対策しか取れないからでしょう。なぜなら、広域連合は、国が作った糞システムを高い金を払って使わされているからです。
下のページを見れば分かりますが、広域連合も市町村も国が用意したシステムを使っているだけです。http://www.wel.ne.jp/doc/feature/healthcare/kouki2/3.html [wel.ne.jp]カスタマイズ部分だけ、広域連合や市町村が金と責任をもって開発することになっています。
そして、この国が作ったシステムですが、当初からバグだらけで本当に糞システムだとの話です。厚生労働省の仕様書が公開されて、翌日には差し替えになったという、最初からダメダメな臭いがするプロジェクトでした。
システム研究会やらを作って広域連合の意見を吸い上げるなんてこともしてましたが、それでもこの糞仕様という有様。矢面に立たされる東京都後期高齢者医療広域連合としては、はらわたが煮えくり返っていると思います。
国会で揉めていたのは記憶にありますが
官僚だろうがSEだろうが、思考速度というものは早くなりません。 [fc2.com]後期高齢者医療制度は整備不良のバスで行うチキンレースである [fc2.com]これはもう本当にダメかもしらんね（戦地に赴く前の遺言） [fc2.com]
システムつくりも修羅場だったのですね。
「仕様エラーの改修」ならね。「業務の改善」なら予算をとってできるんじゃないかな？
雇用対策という名の・・・
はいはい「血税」って最近知ったから言ってみたかっただけだよね。
血税っていうのは読んで字の如く「血であがなう税」つまり徴兵のことを指します。戦後になって徴兵がなくなったとはいえ、「0埋めを人間が行うようなシステムを発注すること」程度でどれだけの納税者の命が脅かされるというのでしょうか？税金のムダ自体反論できにくいものではあるが、かといってあまりにも安易に「命、命」と繋げるのにはかなり抵抗があります。
血税=徴兵ってのは半分だけ正解ですね。http://dic.yahoo.co.jp/dsearch?p=%E8%A1%80%E7%A8%8E&stype=0&dt... [yahoo.co.jp]
http://dictionary.goo.ne.jp/leaf/jn2/68391/m0u/ [goo.ne.jp]
最近由来を知って言ってみたくなった感じ？
言葉の原義（由来）と意味って別物ですよ。
徴兵制が無くなって久しい現代日本では、普通の税金のことも血税と呼ぶ用法をよく見かけるようになっています。最も、好んで使っているのはちょっと左もしくは右に傾いた方々が多いようですが。
＃個人的な印象に過ぎないことはよく分かっていますので、2行目はツッコミ禁止でお願いします。
それはともかく、一般的な感性からして言えば、人間の手でゼロ埋めしないといけないUIって、普通に仕様不備で突っ返されるレベルだと思うんですが…「常識で片付けられる部分を常識で片付けられるからと仕様に載せないでいたら、技術者にとっては許容範囲なのかも知れな
最も、好んで使っているのはちょっと左もしくは右に傾いた方々が多いようですが。＃個人的な印象に過ぎないことはよく分かっていますので、2行目はツッコミ禁止でお願いします。
最も、好んで使っているのはちょっと左もしくは右に傾いた方々が多いようですが。
そんな予防線を張っても駄目ですよ。容赦なく突っ込ませていただきます。
×最も○尤も
普通に作ればユーザがゼロ埋めしなくてよいUIができると思うので、「人間の手でゼロ埋めする仕様で作ってくれ」という要求仕様がどこかの段階であったのではないでしょうか。もしくは、ユーザが入力した"1351"という文字列をそのままシステムに食わせると 3510000000000と解釈されるという仕様を伝えられていなかったとか。
> ＃個人的な印象に過ぎないことはよく分かっていますので、2行目はツッコミ禁止でお願いします。
そんな何の意味も無い文章であれば、最初から書かないか、もしくはチラシの裏にでも書いて下さい。リソースの無駄です。
だが待ってほしい、この場合おかしなシステムを許可した責任があるのだから、処分対象になっても仕方がないのではないか。「処分ありき」ならぬ、処分無きを前提にするのは違和感がある。
なにをやらかしても処分されないのなら、不正も癒着もやりたい放題ではないか。
まぁUIだけ改善しても普通にタイプミスしたら同じことだし(むしろ致命的な誤差が無くなり発見が遅れやすい)、チェック強化はいいことだと思う。こんなCOBOL臭い仕様で設計する奴らなんだから、手入力箇所の削減や、他のDBを参照しての自動検算の追加とかは難しいだろうし。# 仕様上はそれらもやってる事になっていた、とか言われたらもう知らん。
まぁUIだけ改善しても普通にタイプミスしたら同じことだし(むしろ致命的な誤差が無くなり発見が遅れやすい)、チェック強化はいいことだと思う。
人間の注意力には上限があるので、余計な注意が必要になればなるほどミスは増えます。システムで防げるものはシステムで防止すべき。「1351円」を入力するのに、'1' '3' '5' '1'と入力するのが極普通と思われ,そういう入力でミス率が最低になろうということは容易に期待できます。0000000001351を000000001351としてもミスに気づきにくいが、1351を13510にミスすることはまずないでしょう。大抵のものは[はい] だけクリ
本入力と確認入力の間に違うことをする注意力散漫な人間が少なからずいるから（33字）
＞システムで防げるものはシステムで防止すべき。チェック機構ゼロの状態だって事を忘れちゃダメです。UIを修正するしないに関わらず、チェックの強化は必須です。今回ミスが公になった原因が"金額がケタ違いだったから"だとして、UIだけ改善して解決した気になったら"桁違いじゃないミス"が蓄積して悲惨なことになるのが眼に見えてます。その上で、UIの修正をするべきかどうかですが…どのみちこのシステム作った側は無能でしょうから、マトモな額でマトモに修正する事は期待できません。クソUIの修正にリスクとコストしか発生しないなら、
有りがちだけど、入力欄を二つにするっていうのは、どうだろう。
1回目と2回目の入力が異なると，キー入力の直後にアラートが表示されます。 別の人が同じ箇所を同じように間違える確率は低いので，それなりにチェックできます。
# 間違えた人にはペナルティ
それだっ！「1351円」を入力するのに、'1' '5' '3' '1'と1の位から上位桁に向かって入力する仕様にすれば上位桁は勝手に0パディングされるじゃん！オレ天才かも。特許とか取れるかな。
ドイツ人乙
# いや、2桁の場合だけだろ
入力欄を３つにして、間違えていた場合コンピュータに判断させるのが正しいだろ
# 嘘です
これまでミス無く仕事をやっていた末端のオペレータに敬意を表するわ旧日本軍と同じで末端優秀、責任者はアホの典型かと
こんな糞仕様に耐えて作業していたのを、優秀と言えないなー。
言いたいことは数あれど、それを言ったら契約解除。
僕と契約して、キーパンチャー（毎回9桁くらいの0入力が必要）になってよ！
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
今後の対策 (スコア: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, 興味深い)
一見して「これはマズいだろ」的な仕様上の不備を見つけて指摘しても「この指定なので、これでお願いします」のゴリ押しなんですよ。
根本的な理由は知りませんが、製造工程の下請けがとやかく言っても議論の余地がありませんのです。
実装を終えるとその仕様通りに機能していることを確認して検収させるわけですが、何かあったときに実装した下請に責任転嫁されても困るので、今回の件のような「入力ミスを犯したらとんでもない結果を招くこと」も試験項目に揚げて検収させてます（弊社の場合）。
アホな下請けはそこで手を抜いて痛い目に遭うようですが。
>業務に用いるマニュアルを再整備すると
>ともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。
なにしろ仕様は誤っていないというのが大前提なのですから、錯誤があるとしたら運用の側ってことです。
お役所仕事らしさ１００％ですね。
Re:今後の対策 (スコア:2, すばらしい洞察)
「作業者の不注意」以上に突っ込んだ話にしたら、
仕様確認や検収でハンコ押した人を処分しなきゃいけなくなるじゃないですか。
Re: (スコア:0)
「仕様エラーの改修」ならね。
「業務の改善」なら予算をとってできるんじゃないかな？
Re: (スコア:0)
というような事情があるのかもしれません。
# 作成中も予算が少なく期間も少なかったんだろうなあ、テストをしないぐらい
Re:今後の対策 (スコア:1)
Re: (スコア:0)
雇用対策という名の・・・
Re: (スコア:0)
はいはい「血税」って最近知ったから言ってみたかっただけだよね。
血税っていうのは読んで字の如く「血であがなう税」つまり徴兵のことを指します。戦後になって徴兵がなくなったとはいえ、「0埋めを人間が行うようなシステムを発注すること」程度でどれだけの納税者の命が脅かされるというのでしょうか？税金のムダ自体反論できにくいものではあるが、かといってあまりにも安易に「命、命」と繋げるのにはかなり抵抗があります。
Re:今後の対策 (スコア:1)
血税=徴兵ってのは半分だけ正解ですね。
http://dic.yahoo.co.jp/dsearch?p=%E8%A1%80%E7%A8%8E&stype=0&dt... [yahoo.co.jp]
-- う～ん、バッドノウハウ？
Re: (スコア:0)
http://dictionary.goo.ne.jp/leaf/jn2/68391/m0u/ [goo.ne.jp]
最近由来を知って言ってみたくなった感じ？
言葉の原義（由来）と意味って別物ですよ。
Re: (スコア:0)
徴兵制が無くなって久しい現代日本では、普通の税金のことも血税と呼ぶ用法をよく見かけるようになっています。
最も、好んで使っているのはちょっと左もしくは右に傾いた方々が多いようですが。
＃個人的な印象に過ぎないことはよく分かっていますので、2行目はツッコミ禁止でお願いします。
それはともかく、一般的な感性からして言えば、人間の手でゼロ埋めしないといけないUIって、普通に仕様不備で突っ返されるレベルだと思うんですが…
「常識で片付けられる部分を常識で片付けられるからと仕様に載せないでいたら、技術者にとっては許容範囲なのかも知れな
Re:今後の対策 (スコア:1, おもしろおかしい)
そんな予防線を張っても駄目ですよ。容赦なく突っ込ませていただきます。
×最も
○尤も
Re: (スコア:0)
普通に作ればユーザがゼロ埋めしなくてよいUIができると思うので、「人間の手でゼロ埋めする仕様で作ってくれ」という要求仕様がどこかの段階であったのではないでしょうか。
もしくは、ユーザが入力した"1351"という文字列をそのままシステムに食わせると 3510000000000と解釈されるという仕様を伝えられていなかったとか。
Re: (スコア:0)
> ＃個人的な印象に過ぎないことはよく分かっていますので、2行目はツッコミ禁止でお願いします。
そんな何の意味も無い文章であれば、最初から書かないか、もしくはチラシの裏にでも書いて下さい。
リソースの無駄です。
Re: (スコア:0)
だが待ってほしい、この場合おかしなシステムを許可した責任があるのだから、処分対象になっても仕方がないのではないか。
「処分ありき」ならぬ、処分無きを前提にするのは違和感がある。
なにをやらかしても処分されないのなら、不正も癒着もやりたい放題ではないか。
Re: (スコア:0)
Re: (スコア:0)
まぁUIだけ改善しても普通にタイプミスしたら同じことだし(むしろ致命的な誤差が無くなり発見が遅れやすい)、チェック強化はいいことだと思う。
こんなCOBOL臭い仕様で設計する奴らなんだから、手入力箇所の削減や、他のDBを参照しての自動検算の追加とかは難しいだろうし。
# 仕様上はそれらもやってる事になっていた、とか言われたらもう知らん。
Re: (スコア:0)
人間の注意力には上限があるので、余計な注意が必要になればなるほどミスは増えます。システムで防げるものはシステムで防止すべき。「1351円」を入力するのに、'1' '3' '5' '1'と入力するのが極普通と思われ,そういう入力でミス率が最低になろうということは容易に期待できます。
0000000001351を000000001351としてもミスに気づきにくいが、1351を13510にミスすることはまずないでしょう。
大抵のものは[はい] だけクリ
Re: (スコア:0)
本入力と確認入力の間に違うことをする注意力散漫な人間が少なからずいるから（33字）
Re: (スコア:0)
＞システムで防げるものはシステムで防止すべき。
チェック機構ゼロの状態だって事を忘れちゃダメです。
UIを修正するしないに関わらず、チェックの強化は必須です。
今回ミスが公になった原因が"金額がケタ違いだったから"だとして、UIだけ改善して解決した気になったら"桁違いじゃないミス"が蓄積して悲惨なことになるのが眼に見えてます。
その上で、UIの修正をするべきかどうかですが…どのみちこのシステム作った側は無能でしょうから、マトモな額でマトモに修正する事は期待できません。
クソUIの修正にリスクとコストしか発生しないなら、
Re: (スコア:0)
→ 人件費は２倍になるが、数週間後には担当者のチェックはずさんになり、
入力者の隣で別資料（新聞）を読んだり別作業をするようになる
→ 入力ミスが再発 → 対策として「三重チェックを徹底」と発表
→ 入力担当者は３人で → 人件費は３倍になるが、・・・
→ 大規模なデータ入力業務センタービルを建造し・・・
→ 民営化と称して財団を設立、センター長は天下り → さらなる増殖・・・
Re:今後の対策 (スコア:2)
有りがちだけど、入力欄を二つにするっていうのは、どうだろう。
Re:今後の対策 (スコア:1)
1回目と2回目の入力が異なると，キー入力の直後にアラートが表示されます。 別の人が同じ箇所を同じように間違える確率は低いので，それなりにチェックできます。
# 間違えた人にはペナルティ
Re:今後の対策 (スコア:1, 興味深い)
Re:今後の対策 (スコア:1, おもしろおかしい)
それだっ！
「1351円」を入力するのに、'1' '5' '3' '1'と1の位から上位桁に向かって入力する仕様にすれば上位桁は勝手に0パディングされるじゃん！
オレ天才かも。特許とか取れるかな。
Re:今後の対策 (スコア:1)
ドイツ人乙
# いや、2桁の場合だけだろ
Re: (スコア:0)
入力欄を３つにして、間違えていた場合コンピュータに判断させるのが正しいだろ
# 嘘です
Re: (スコア:0)
これまでミス無く仕事をやっていた末端のオペレータに敬意を表するわ
旧日本軍と同じで末端優秀、責任者はアホの典型かと
Re:今後の対策 (スコア:2)
こんな糞仕様に耐えて作業していたのを、優秀と言えないなー。
Re:今後の対策 (スコア:1, すばらしい洞察)
言いたいことは数あれど、それを言ったら契約解除。
Re: (スコア:0)
僕と契約して、キーパンチャー（毎回9桁くらいの0入力が必要）になってよ！