日本で消費税は1989(平成元)年に最初3%で消費税が導入、それから何度か税率が上がり、令和元年(2019年)10月には10%へと引き上げられました。
さらにそれから月日は流れ、新型コロナウイルス感染症の流行、物流費や人件費の高騰により、物価高は上がり続けている影響で、消費税を減税して欲しいという日本国民の声は多く上がってきました。
しかし、どこかの政党から

消費税の減税はシステム改修に時間がかかるので、できません。
という声があり、消費税を減税することは難しいようです。



………は?本当にそうか?
と一部で感じている国民がいるようです。
ITエンジニア視点で私は断言しますが、それは嘘です。
システム改修は必要になりますが、膨大な時間がかかるという理由で消費税を減税できないのはおかしいです。なぜなら今までに増税した際にシステム改修を行ってきましたが、膨大な時間なんてかからなかったですし、仮に増税のシステム改修に時間がかかっていたとしても、逆に言えば増税はできたのに減税はできないというのは論理的にもおかしいからです。
この記事では、私がITエンジニアとして今までに改修した増税と税制改正を伴う改修内容を紹介して、減税できない理由が嘘であることを証明したいと思います。
今までに改修した増税と税制改正を伴う改修内容


1. 消費税増税
今までに消費税は、1997(平成9)年に5%、2014(平成26)年に8%、2019(令和元)年10月から10%と税率が引き上られてきました。
私はSESエンジニアとして様々な案件を渡り歩いていますので、その時代に担当していた案件はそれぞれ異なりますが、消費税が上がったタイミングでシステムを改修してきました。
2014(平成26)年に8%に上がったタイミングで担当した案件では、消費税の税率はソースコードの計算式に直書きされていました。
例えば、1997(平成9)年の5%にはこんな感じでした。
- 税込み価格=税抜き価格×1.05
- 消費税=税抜き価格×0.05
これを2014(平成26)年に以下に書き換える必要がありました。
- 税込み価格=税抜き価格×1.08
- 消費税=税抜き価格×0.08
恐らく直書きされていた理由は、消費税が上がることを想定されて開発されていなかったか?運用保守のことを考えずに開発されてしまっていたのか?……理由は様々あると思いますが、ともかく書き換えなければならなかったので、ソースコード内で消費税率が使用されている全ての個所をひたすら「1.05→1.08」と「0.05→0.08」に書き換えるという作業を行いました。
本当は後述で紹介する10%と税率が引き上げられた時と同じ方法で対応したかったのですが、消費税増税対応しなければならない期間まで時間がなく、予算も工数もかけられないということでクライアントの指示によるものですので、PMや私の独断ではないということをお見知りおきを…。



まー、でも「1.05→1.08」と「0.05→0.08」に書き換えるのなんて誰でもできるじゃん
非エンジニアの方であれば、そうお思いの方もいらっしゃると思いますが、そんなに単純なものではありません。
まず、膨大なソースコードの中から設計書などを参考に消費税率が使用されている箇所を調査しなければなりません。案件によっては設計書がないということもありますので、ソースコードを検索したり、地道に調べなくてはなりません。金額に関わるシステムなので対応漏れは許されないので、慎重に行う必要があります。
対応箇所を調べた後でも「1.05→1.08」と「0.05→0.08」に書き換える作業を間違わないようにしなければなりません。大体、こういったケースは一括置換を行うので、間違えることはないのですが、あまりにも対応箇所が多くて複数人で分担して作業が必要になった場合には、誰かが対応するかと思ってしていなかった漏れが発生する場合がありますし、誰かが税率を誤ってしまったらとんでもないことになってしまいます。
極端に言えば、「1.05→1.08」に書き換えるべきところを「1.05→1.80」にしてしまった場合とかです。この場合は、税込み価格は8%……ではなく80%になります。
80%ですよ……税抜き300万円の車は消費税8%で税込み324万円のはずだったのに、消費税80%で税込み540万円になってしまうということです。
これは、利用者や会社に大損害が出ることは誰にでも想像ができるとは思います……。
だから数字を書き換えるというのは単純作業にように見えますが、一つのミスや間違いで大変なことになってしまうということで非常に怖いことなのです。
ソースコードの修正でそういったミスが起きた場合でも気づくことができるようにテストをするのですが、テストをする工数と人件費がかかるので、ソースコードの修正だけでなく、テストやリリース時の作業など、様々な手間がかかってしまうということで容易なことではありません。それでも、2014(平成26)年に8%を対応したときは1ヶ月程度で対応はすることはできたと記憶しています。
次に2019(令和元)年10月から10%と税率が引き上られたときは、データベースの税マスタテーブルに格納されている消費税の値をSQLというデータベースを書き換える言語で「0.08→0.10」にUPDATEするだけで改修作業は終わりました。
なぜそれだけで済んだのかといえば、システム全体のソースコードがデータベースの税マスタの消費税率を参照して税込み価格が計算されていたからです。
運用保守を考えたシステムであったため、改修はデータベースの書き換えのみ、その他の作業としては本当にデータベースの書き換えだけで済む簡単な調査とテストするぐらいで1~2週間あれば余裕だったので、5%に増税されたときよりは軽微な対応で済むことができました。
以上が消費税が増税されたときのシステム改修に伴う対応になりますが、作業期間はともかく対応はできたという事実があります。
消費税減税はそれの逆をやればいいだけの話ですし、データベースの書き換えだけで済むなら大きく見積もっても1人月かかるような作業ではありません。
消費税の増税はできて減税はできないというのはおかしいでしょう?
2. インボイス制度
インボイス制度とは、 令和5年(2023年)10月1日からスタートした 税率が複数あっても、事業者の方が消費税を正確に納めるために消費税の金額等を書いた請求書・領収書等を基に計算する仕組みになります。
日本政府が始めた制度で特にフリーランスに影響を与えることになり、一部の人からは批判が殺到しました。
私が担当していたシステムでは会計が関わっていたので、インボイス制度の対応をしなくてはならず、改修をすることになりました。
具体的には、インボイス制度にのっとって、請求書を「交通費」と「交通費以外」に分けるという改修です。
消費税の増税よりも手間がかかる対応で、既存の処理を「交通費」と「交通費以外」に分けた上で、会計の合計処理が合うような改修が必要になってしまったので、既存の計算処理に手を加えることになってしまったので苦労した記憶があります。
金額に関わる処理のため、消費税と同じく、ミスは許されない作業だったのですが、テストでは単純ミスや修正漏れ、計算ロジックの間違いなど様々な不具合が発生して大変でした。もしテストで気づかずにスルーしていたら大変なことになってしまっていたと思います。
大変でしたという言葉で察した人もいるかと思いますが、案の定、期間も少なく炎上プロジェクトになってしまったので、夜遅くまで作業することになって、体に悪影響も出てしまいました…。


それでもインボイス制度の対応は無事に終えて、リリース後も特に大きな障害は発生することなく、今もそのシステムは動き続けていることでしょう。
もう二度とやりたくないという対応でしたが、日本政府が決めた制度なので、改修はできましたし、対応期間として3か月程度と記憶しているので、システム改修に膨大な時間はかかったといううちには入らないと思います。
というより、インボイス対応ができるならもっとシンプルな消費税の減税ができない理由にはならないですよね?
3. 定額減税
令和6年度税制改正に伴い、令和6年分所得税について定額による所得税額の特別控除(定額減税)が実施されることとなりました。
正直、この制度は複雑すぎて無能なITエンジニアである私には理解が追い付いていません。
会計事務の人も事前に研修を受けたりして大変そうでした。
個人的な意見ですが、こんな複雑なことをするなら、給付金配った方が楽だし、もらう方も有難いのになんでこんな複雑なことをしたんでしょうか?
どっかの増税メガ………ではなく、まあどうしてもやりたかった理由があるんでしょう?知らんけど!
そして、この定額減税というインボイス制度よりも複雑な制度のおかげでシステムを改修エンジニアとしては苦しめられることになったのです。
………と言いたいところですが、私は無能すぎて定額減税の改修を任されることはありませんでしたので、実際にどのような改修をしたのは全然分かりませんので、説明できることもありません。
ただ、対応した有能なエンジニアの人にヒアリングしたときには改修もテストも大変だったと言っていました。既存の消費税の増税、既存の請求書の会計を分けるというインボイスのような既存の計算方式ではなく、新しい概念の計算方式に伴うシステム改修なんだからそれは複雑にもなるし、大変な改修だったに決まっています。
それでもその有能な人達の手で定額減税の対応の改修は無事に完了していました。
ただ、定額減税はたった半年程度の精度だったらしく、それだけのために苦労して改修していたことに怒り心頭していましたが…。
逆に言えば、たった半年程度の税制改正のための改修なのにも関わらず、複雑な改修にも対応できるということです。
システム改修に膨大な時間はかからない理由


ここまでの記事を読んで分かって頂けたと思いますが、システム改修に膨大な時間はかかりません。
少なくとも、消費税の減税に膨大な時間がかかるということは100%ありえません。断言します。
なぜなら、消費税の増税に膨大な時間なんてかかっていないからです。
データベースのマスタやソースコードでも税率を一箇所で管理しているシステムであれば、その税率を変えて改修は終わります。
それを否定してもいいですが、それではなぜ消費税の増税だとそれができるんですか?
なぜ、消費税の減税だと急にできなくなるんですか?



おかしいでしょ?



……いや、おかしいだろ??
100歩譲って消費税を0%にするなら大変かもしれませんが、消費税を10%から8%や5%に減税するだけなら元に戻るだけだろ?
8%や5%のときはそれで動いてたじゃねえか?



嘘を言うのも大概にしろよ?ふざけんな!(すみません、言葉遣いが……熱くなって取り乱してしまいました…)
まとめ
この記事では、減税をできない理由がシステム改修に膨大な時間がかかるは嘘!現役エンジニアが断言する理由について紹介しました。
シンプルに言えば、増税ができるんだから減税もできるじゃんということです。
消費税の増税どころか、インボイス制度の対応や複雑な定額減税が伴うシステム改修だって多くのITエンジニアの人たちが苦労して対応を行ってきたのですから。
「消費税は減税ができない」とか「減税だとシステム改修に膨大な時間がかかる」と言っている人は、エンジニア視点の私にはただの言い訳にしか聞こえないですね。



それか、どっかのざいm……おっと、誰か来たようだ……………。










