前回の記事のあと、少し消費税０％について調べてみた。世の中には本当に0%に対応できていないシステムがたくさんあるらしい。正直ちょっとびっくりした。消費税0%の壁は本当にシステム改修に時間がかかるというのが理由である可能性がでてきた。

ある記事では軽減税率を0%に設定すると標準税率の10%が適用されるということが書かれていた。軽減税率が0ではないというのが軽減税率を適用するフラグになっている仕組みなのだと思われる。「税率0に特殊な意味を勝手に持たせただけでは？意味の違う変数を流用するべきではないというのは基本では？」というのが感想であった。寧ろキチンとフラグを新設した方がバグを作り込みにくいのではないか。

また、ある記事では税率で除算をして税額を算出する処理があり0で除算するとエラーになるからと書かれてあった。一定の理解はできるが、こちらも「除算処理の分母が変数である場合には事前に変数値をチェックするのが基本では？」と思う。

なんなら軽減税率の導入時に生活必需品は0%にすべきという議論もあったと記憶している。0%になりえる可能性は容易に想像できたはずだ。その時、考慮されていれば今回のような問題は起きなかったはずである。

ぶっちゃけて言うと、0%にできないのが本当にこういったことが原因なのだとすれば、これは政府の責任というよりもIT業者の能力不足が原因だと思う。

と思ったのでチャッピーと話してみた。

今回のテーマ：なぜ税率0%を想定してないのか？

まとめ：システム開発の企業が良くなかった。今やらなければ将来0%は難しくなる可能性がある。

(私)  世の中には本当に0%を想定していないシステムがあるらしい。0%を想定しないということになってしまう動機として考えられることは？

(チャッピー) 0%を想定しない動機として考えられるもの
  1. 「0%」を税率ではなく“課税対象外フラグ”として使っていた
  2. 「課税取引なら税率は正の値」という業務前提で作っていた
  3. レシート・帳票の印字ルールが「0%＝表示しない」前提だった
  4. 商品マスタ・税区分マスタが「税率番号」で設計されていて、0%用の意味づけがない
  5. インボイス・会計連携が「0%課税売上」を別物として扱えない

(私) 軽減税率の導入時に0%の可能性も容易に想定できたはずだが何故対応されなかった？

(チャッピー) 短く言うと、「想定できたはずなのに対応されなかった」のは、0%の可能性を知らなかったからというより、2019年の軽減税率対応プロジェクトの目的が“将来のあらゆる税率変更に強い設計に作り直すこと”ではなく、“8%と10%を期限までに動かすこと”だったから、と考えるのが自然です。

　　中略

(私) 軽減税率導入時の要件は8%と10%に対応することではなく
 1．軽減税率を導入する
 2. 軽減税率は変更可能
 3. 標準税率も変更可能
ではなかったか？

(チャッピー) **本当に必要だった要件は「税率を変更可能にする」だけではなく、「税率ごとに区分して処理できること」**です。
 より厳密に言うならこうです。
1. 複数税率を扱えること
    標準税率と軽減税率を併存させられる
2. どの取引にどの税率を適用するか判定できること
    食品／外食／新聞などの判定
    同じ食品でも持ち帰りか外食かで変わる場合への対応
3. 税率ごとに区分して記帳・集計・請求書発行できること
    区分経理
    税率ごとの請求書・レシート・元帳表示
4. 税率値を固定値ではなく変更可能にしておくこと
    標準税率も軽減税率も、将来の改定に備えて設定可能にする

「軽減税率導入時の要件は8%と10%に対応することではなく、軽減税率という制度を導入し、その税率値も変更可能にすることではなかったか？」
というあなたの指摘は、かなり筋が通っています。

(私) あなたの言う要件が満たされているなら今回問題は起きていないのでは？

(チャッピー) はい。かなり率直に言えば、その通りです。
少なくとも私が先ほど挙げたレベルの要件がきちんと満たされ、その趣旨どおりに実装されていたなら、今回の「0%は大改修」という問題は本来かなり起きにくいはずです。

では、なぜ問題が起きているのか
1. 要件が実はそこまで明確に定義されていなかった
2. 要件はそれっぽく書かれていたが、実装がその趣旨を満たしていない
3. POS本体は対応できても、周辺システムが同じ前提で作られていない

私の見立てを一番短く言うとこうです。

もし軽減税率導入時に、本当に「標準税率・軽減税率を任意に変更可能な複数税率制度」として正しく要件化・実装されていたなら、今回の0%で“特別に大きな問題”は起きにくい。
今回問題が起きているということは、どこかでその要件が欠けていたか、文書上はあっても実装がそのレベルに達していなかったか、あるいは周辺システムを含めた全体整合が取れていなかった可能性が高い。

(私) 今対策しなかった場合、今後0%にしたい場合に問題が再浮上すると考えられる。今対策した場合としなかった場合の予測は？

(チャッピー) 
今対策しない場合
   次回0%議論が出たとき
      再び「0%は特別で難しい」が論点化
      ベンダー影響調査をやり直す
      1%や給付案が再浮上
      実施時期が遅れやすい
      時限措置の延長・終了でも毎回揉める
   中長期の状態
      技術負債が残る
      政治的にも「0%は難しい」が既成事実化
      1%→0%や再減税のたびに追加コスト
今対策する場合
   次回0%議論が出たとき
      論点は「対象範囲」「開始時期」「期間」に寄る
      システムは税ルール変更＋テスト中心
      1%→0%の移行も比較的素直
      期間限定・延長・恒久化にも対応しやすい
   中長期の状態
      0%を通常税率として扱える
      将来の税率変更コストが下がる
      政策議論で「レジの壁」が使いにくくなる

今対策する場合、短期的には当然コストがかかります。
   POS本体の改修
   レシート/帳票確認
   会計連携修正
   本部集計やBI確認
   商品マスタ運用の見直し
   0%→8%戻しまで含むテスト

将来また0%をやる可能性が高いなら今対策しないのは、ほぼ確実に将来へ問題を繰り延べるだけです。
しかも次回は、
   今回の議論のやり直し
   既存システムに積み上がった追加パッチの整理
   1%→0%の差分対応
まで加わるので、むしろ複雑になる恐れがあります。

0%は難しいというのが既成事実化するのは凄く嫌ですね。

最近はAIの進歩が素晴らしいので人と議論するのは億劫だったりセンシティブな話題についてよくAIと議論する。相手はもっぱらチャッピーである。要約・抜粋して残していこうと思う。

今回のテーマ： 消費税を0%にするか1%にするか問題

まとめ： 0%だと時間がかかることについての説明が足りねえ

(私) 消費税を0%にするとシステム改修に時間を要するという主張は正しいのか？税率1%も0%も消費税の計算が100円×0.01になるか100円×0.00になるかの違いであり、税率を変えるだけで変更可能では。0だからと言って殊さらに特異点となる理由があるのか？

(チャッピー) あなたの疑問はかなり本質的です。
「100円×0.01と100円×0.00の違いなのだから、税率テーブルを書き換えれば終わりでは？」
これは技術的には多くの場合正しいです

ではなぜ「システム改修に時間がかかる」と言われるのか

理由は主に3つです。

1.全国の事業者が対応する必要がある
2.システム改修よりテストと監査が大変
3.税率変更ではなく制度変更まで含めて議論されることがある

特に政治家や官僚が言う「改修」は、単にプログラムの変更ではなく、「全国数百万事業者の運用変更」を含んでいることが多いです。

(私) システム改修と言っているが制度設計の変更に時間がかかるという方が正しい？


(チャッピー) その可能性はかなり高いです。
実際、「システム改修に時間がかかる」という言葉は、政治や行政の議論ではしばしば「制度設計・法改正・運用変更・周知・テストまで含めた全体の対応に時間がかかる」という意味で使われます。

なぜ「システム改修」を前面に出すのか

制度設計の話をすると複雑になります。政治家や官僚は「システム改修に時間がかかる」という分かりやすい表現を使うことがあります。


(私) 税率1%と0%で対立が起こっているのであれば、より正確な説明をすべきではないか。


(チャッピー) その指摘には一定の合理性があります。特に、あなたが指摘したように、「1%なら大丈夫だが0%はシステム上難しい」というニュアンスで受け取られると、技術的には疑問が生じます。多くのシステムでは税率はパラメータであり、1%も0%も数値としては同じように扱えます。したがって「0という値そのものが特異点である」という説明は、少なくとも一般的なシステム論としては説得力が弱いでしょう。

「システム改修が大変」の方が説明しやすいため前面に出ることがあります。しかしその結果、技術に詳しい人からは「本当の論点を隠しているのでは？」という不信感を招きやすくなります。

例えば、「税率を0%にするシステム改修自体は可能だが、法改正や事業者対応に数か月～1年程度必要である」という説明なら、技術面と制度面を区別しています。

(私) 専門的な話を簡略化した結果であったとしても、一度はそれについて触れなければ不誠実と言えないか。

(チャッピー) 簡略化そのものは避けられません。すべての制度的・技術的背景を毎回説明すると話が進まないからです。しかし、あなたが指摘しているのは、簡略化した結果、本来の論点とは異なる印象を与えてしまっているのではないかという問題です。これは単なる説明不足ではなく、説明責任の問題として考えられます。

例えば、「0%はシステム的に難しい」「システム改修に時間がかかる」だけを繰り返し説明し、実際には「制度設計が主な課題」「法改正が主な課題」「一時的な税率変更の運用が主な課題」であることを一切説明しないのであれば、聞き手は「コンピュータの都合で0%にできないのだな」と理解する可能性があります。その理解が実態と異なるなら、説明としては不十分でしょう。

(私) 今回の消費税0%についてシステム改修に時間がかかるという主張の本当の内容について記載されている情報源は存在するか？

(チャッピー) 現時点で公開されている情報を見る限り、「システム改修に時間がかかる」の本当の中身を詳細に説明した一次資料は、あまり公開されていません。というのが実情です。報道で確認できるのは、レジメーカー、POSシステム事業者、小売業界団体へのヒアリングで、「食料品を0%にするには1年程度必要」「0%は初めてなのでテストに時間がかかる」という説明があったことです。

（ここで仮設が３つ提示された）

(私) 制度側の問題であればシステム会社とは関係がないので、システム会社からの見通しが0%と１％で大きく異なる理由が理解できない。仮説１(システムが0を想定していない)については問題点が明らかであり改善に１年もかかるはずがない。仮説２(運用テストに時間がかかる）については1%でも0％でも同程度のテストが必要であり大きな差が出るはずがない。仮説３(対応するエンジニア不足)についても現在のシステムにもメンテナンス要員がいるはずであり、そこまで大きく追加要員が必要になるとは考えられない。いずれも否定可能に思える。

(チャッピー）
もし本当に
1%は短期間
0%は長期間
という見積もりが出ているなら、差が生まれる理由はむしろ「税率」ではなく「税区分」にある可能性があります。

例えば多くの会計システムでは

課税
非課税
免税
不課税
を区別しています。
0%になると、利用者や運用担当者が「これは課税取引なのか？」「非課税なのか？」「免税なのか？」を混同しやすくなります。つまりシステムの計算ではなく、業務ルールや運用設計の問題です。

しかしそれでも疑問は残る
「税率0%」という概念自体は会計システムの世界で既知です。

私が現時点で最も可能性が高いと思うのは、「システム改修」という言葉の中に、技術作業以外の業務変更・運用変更・ベンダー調整・認証作業が大量に含まれているケースです。

ただし、その場合でも、「1%なら数か月、0%なら1年」という差の根拠は依然として不明です。

むしろ現在の問題は、「0%が難しい」という主張そのものよりも、なぜ難しいのかの技術的・業務的内訳が十分公開されていないことにあります。そこが明確にならない限り、「本当に0%だけ特別なのか」という疑問は残り続けるでしょう。

私自身は消費税が０％でも１％でも構わないと思っています。ただ単純に０％だと難しいと言っていることに全く納得できていないです。上記のように制度や運用上の話であればそのように説明して欲しいところです。