アカウント名:
パスワード:
http://www.tokyo-ikiiki.net/topic/data/kougakugokisai_110817.pdf [tokyo-ikiiki.net]によると、今後の対策は
東京都後期高齢者医療広域連合において、業務に用いるマニュアルを再整備するとともに、二重チェックを徹底し、確実な点検作業を実施する体制を構築する。
との事。アプリケーションの改修は？
まぁUIだけ改善しても普通にタイプミスしたら同じことだし(むしろ致命的な誤差が無くなり発見が遅れやすい)、チェック強化はいいことだと思う。こんなCOBOL臭い仕様で設計する奴らなんだから、手入力箇所の削減や、他のDBを参照しての自動検算の追加とかは難しいだろうし。# 仕様上はそれらもやってる事になっていた、とか言われたらもう知らん。
まぁUIだけ改善しても普通にタイプミスしたら同じことだし(むしろ致命的な誤差が無くなり発見が遅れやすい)、チェック強化はいいことだと思う。
人間の注意力には上限があるので、余計な注意が必要になればなるほどミスは増えます。システムで防げるものはシステムで防止すべき。「1351円」を入力するのに、'1' '3' '5' '1'と入力するのが極普通と思われ,そういう入力でミス率が最低になろうということは容易に期待できます。0000000001351を000000001351としてもミスに気づきにくいが、1351を13510にミスすることはまずないでしょう。大抵のものは[はい] だけクリ
本入力と確認入力の間に違うことをする注意力散漫な人間が少なからずいるから（33字）
＞システムで防げるものはシステムで防止すべき。チェック機構ゼロの状態だって事を忘れちゃダメです。UIを修正するしないに関わらず、チェックの強化は必須です。今回ミスが公になった原因が"金額がケタ違いだったから"だとして、UIだけ改善して解決した気になったら"桁違いじゃないミス"が蓄積して悲惨なことになるのが眼に見えてます。その上で、UIの修正をするべきかどうかですが…どのみちこのシステム作った側は無能でしょうから、マトモな額でマトモに修正する事は期待できません。クソUIの修正にリスクとコストしか発生しないなら、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
今後の対策 (スコア:3, 興味深い)
http://www.tokyo-ikiiki.net/topic/data/kougakugokisai_110817.pdf [tokyo-ikiiki.net]によると、今後の対策は
との事。
アプリケーションの改修は？
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の修正にリスクとコストしか発生しないなら、