あまりにもお粗末な料金請求プログラム

「明治３３年から延滞」、入力ミスで高速料金過剰請求(朝日新聞) - goo ニュース

一般の方は、「へー、入力ミスでとんでもないことがあるんだな。」とか、
「100年以上も前から請求されちゃ大変だ。」とか、
「コンピュータもいい加減だなぁ。」なんて思われるかもしれませんね。

私は、いつものようにちょっとうがった見方をしてみましょう。

コンピュータがいい加減なわけではありません。
コンピュータはプログラムの指示に従って計算しただけ。
プログラムが悪い。

もちろん、入力ミスがその直接の原因ですが、
こんな低レベルのミスを検知できないプログラムは低レベル、
そのプログラムを組んだ人は、はっきり言ってプロレベルにない。

入力がどのようになっていたかは知りませんが、
いくつかのミスのタイプを考えてみます。

・起算年を入力しなかったので、０として認識し、０＝１９００年とした。

・年を２００２年などと４ケタでいれるべきなのに、０２や和暦の１６と入れ、
　小さすぎるので、自動的に１９００年と置き換えた。

・年は西暦下２ケタで、０２などと入れるべきなのに、２００２と入れたため、
　下２ケタが無視され、上２桁の２０と認識され、現在の０７より
　大きい数字なので１９００に置き換えた。

・年は西暦下２ケタでいれ、２１世紀の１から１０までは、２０００を足す。
　それ以外は、２０世紀と判断し、１９００を足す。
　この結果、入力を間違って００や２０と入れ、１９００年と判断した。

・年月日を西暦下２ケタと月日の計６桁で、
　例えば２００２/０３/０４は、０２０３０４とすべきところ、
　２００２０３０４のように８ケタでいれたため、２０/０２/０３と判断、
　２０（＝２０２０）は現在より大きいため、１９００年と置き換えた。

まあ、プログラムがどのような作りで間違えたかは大した問題ではありません。
要は入力する人間はミスをするものだ、という前提に立って作るべきなのです。

いくら間違っても起算日を１９００年と入れる人なんていないでしょう、
とは思いますが、でたらめに入れても検知する仕組みが必要です。

上の例でいえば、
・起算年が入力されなかったら、エラーとして扱う。
・起算年の下限を論理的に保持しておき、それより少ない値はエラーとする。
・現在より先の日付を起算年としたらエラーとして扱う。

また延滞金請求の場合、「時効」があるはずですから、
いくら時効延長の手続きをしていたといえども１００年はおかしい。

人がおかしいと思う「感覚」をプログラムすることは難しいですが、
プログラム的におかしいと思える下限があるはずです。

例えば、１９６３年に初めての高速道路が開通していますから、
それ以前の起算日の料金延滞金はあり得ません。

東北道なら１９７２年以前は東北道自体が無いし、
本宮ＩＣができたのは１９８１年だとか、
いろいろチェックすべき日付があるわけです。

これらの処理を入れても、プログラムは数行から数十行増えるだけでしょう。
相当複雑な判断を入れてもたかだか１００行２００行の追加ですむはずです。

しかし、いくらプログラムで工夫しても論理的にあり得る間違い、
例えば、２００３年を２００２年と入力するエラーは検知できないので、
・入力された日付を表示し、これでよいか確認すること、
・計算結果にも起算日や計算した期間を表示し、
　請求書にも起算日や期間を表示すること、

などの処理が必要です。

でも、こんなのは初歩の初歩、やっちゃいけないレベルのミス。

フェイル・セーフとフール・プルーフという言葉があります。

これは「仮に間違っても間違いを発見したり正したりできる」仕組みと、
「間違った操作ができないようにする」仕組みのことで、
特にお金や安全に絡むプログラムでは絶対に忘れてはいけない。