Hiroshi Yano（矢野 浩史）

冨安健洋がW杯へコメント🇯🇵 「たくさんの⼈に⽀えられてきたからこそ今の⾃分がいます。 W杯という舞台に⽴ちたくても⽴てない選⼿もいる中で、選出されたその責任を感じながら⽇本の為にプレーします。 ⽇本の⽬標である優勝に貢献できるよう、今僕が持っている全てを出し切ります」

高市総理の「さまざまな税率に柔軟に変更できるシステム開発を急いでもらいたい」という答弁は、消費税率変更に伴うレジ改修だけでなく、IT業界が何度も繰り返してきた構造的な課題だと思います。 2000年問題では、西暦を2桁で持つという前提が社会全体の大改修につながりました。 改元対応、軽減税率、インボイス制度、2038年問題、IPv6移行、IE・ActiveX依存、証明書期限切れなども、本質はよく似ています。 つまり、将来変わり得る前提を、システムの奥深くに固定値として埋め込んでしまう問題です。 税率も同じです。本来、消費税率、軽減税率、ゼロ税率、非課税、免税、災害時特例、時限減税といった制度条件は、プログラムに直接書くべきものではありません。 Javaで言えば、Facadeで税計算の複雑性を隠蔽し、Strategyで税率・丸め・免税・軽減税率などの計算ロジックを差し替え可能にし、Builderで取引条件を安全に組み立てる。さらに、税制ルールを外部化し、有効期間、根拠、バージョン、監査ログを持たせる設計が必要です。 POSやEC、会計、インボイス、販売管理がそれぞれ独自に税率を持つのではなく、共通の Tax Policy Engine / Tax Calculation Service を参照する。これにより、制度変更時にコード改修ではなく、ルール変更として対応できるようになります。 変わるものを固定値にしない。 制度変更を想定して設計する。 監査可能で、安全に差し替えられる仕組みにする。これが、2000年問題から何度も学ぶべきだったITアーキテクチャの基本だと思います。