元ゲームプランナーで時代遅れの昭和kidsが、親爺となった今の視点で語る、懐かし雑記ブログ

ども、のすたる爺です。

システム系プログラムには詳しくないんだけど、税率適用する際に0％を想定せず、除算（割り算）を使ったお馬鹿がいたら、デバッグ及びシステム検証に膨大な時間がかかります。コレ、すべてのシステムの途中で1箇所でもエラーが出れば何が起きるかわかりません。消費税を0％にするのは頭で考えるより大事なんです。

消費税率が「0%」になる際、税率を分母にして逆算する計算式（例：税額 \(\div \) 税率）がプログラムに残っているとゼロ除算エラー（ZeroDivisionError）が発生し、システムが停止します。これを防ぐには「税率が0の時の例外処理」や「除算の回避」などのプログラム改修が必要です。

私も専門学校でプログラムを学びましたし、簡単なプログラムを組んだこともあり、ゲーム業界で様々なプログラマーと組んで（お世話になって）きたので、一般の方にも多少の知識はあります。その中で一発でシステムを止めかねないエラーに0除算（割り算）エラーというのがあります。0を乗算（かける）なら0になるだけなので数学的に問題は少ないのですが、割り算は想定されていないので致命的エラーになるのです。これを回避するなら事前にそうならないように組むか、そうなった時の例外処理で回避する歩y歩yがありますが、後者は煩雑でリスクが高いので普通は使わないはずです…が、何処の誰かが0除算エラーの潜んだプログラムを組んでいた場合、税率変更した時に時限爆弾的にエラーがシステム止める恐れもあるのです。

なので、消費税率ゼロのレジ改修に一年というのは、一般とは遮断された独自の開発環境でエラーが出ないかデバッグ完了までにかかる期間を逆算で、不測の事態対応への余裕を織り込んで一年という期間を取っている可能性もあります。1％なら半年というのも0除算エラーが無いため猶予を半分と見積もったに過ぎないと思います。

とかく、ザイム真理教こと財務省の罠で語る陰謀論者が多く感じますが、こんな素人でも予見できるエラーが潜在的にある可能性もゼロではないんですね。システムプログラマーは不測の事態への対応という金にならない作業をしたがりません。ある意味、契約時の要件定期が絶対です。外部に発注した場合、よりこの傾向が強くなります。違うシステムの銀行ATMが連携時に不測の事態で停止したことがあったようにプログラムに潜む罠はいくらでもあるんです。

いやぁ、情報化社会って色んな意味で便利ですが怖いですね。レジ改修に1年もかかるはずはないは、一台のレジスターの問題ではなく国内全部のレジシステムが問題なく稼働するまでの時間、この切り口で語る人って極めて少ないですよね。たぶん、0除算エラーなんて知る由もないし、ましてやデバッグ（テスト運用）機関というのも想定できないんでしょうね。財源よりもこっちの方が根深い問題な気もします。