高市首相、日本の融通の利かないレジシステムを「国家の恥」と一喝
5月11日に開催された参議院決算委員会において、高市早苗首相は、食料品への2年間の「消費税率0%」導入に向けたレジシステムの改修に膨大な時間を要する現状について、「日本国として恥ずかしいことだ」と述べた。
高市首相は、現在進められている減税議論を機に、様々な税率に柔軟かつ迅速に対応できるシステムの開発を加速させるよう求めた。この発言は、野党・れいわ新選組の、大島九州男氏の質問に答えたものである。
スーパーやコンビニなどで使用されるレジシステムのメーカー各社は、消費税減税などを議論している超党派の「社会保障に関する国民会議」に対し、食料品を税率0%にするための改修には約1年かかると説明している。
海外の反応
コードがどんだけ骨董品レベルなのか想像してみろよｗ
変な話だよな。ソフトのアップデートなんて大層なことしなくても、保守のおっちゃんがパパッと設定変更できるような変数にしとけよって思うわ。
消費税率をソースコードに直接書き込んでるとか、もし本当ならバカすぎて草も生えない。
白黒パッケージのポテチの件もそうだけど、政府がいちいち首突っ込むような話かよ。
普通は事前に「税率変わるからよろしく」って各企業に通知して、あとは店側がリース会社に頼んでレジの設定変えてもらうだけだろ。知らんけどｗ
お前分かってないな。
税率の設定自体はできるんだよ。ただ「0%より大きい数字」じゃないとダメ仕様になってる。
あと、たとえ「いつもの」税率変更でも、全国一斉にミスなく反映させるには数ヶ月単位の準備とテストが必要なんだわ。会計システムとの連携とかレポートの整合性とか、チェック項目は山ほどある。
（何百もの企業が足並み揃えて一気に切り替えるってことを忘れるなよ）
今回の「0%にする」っていうのは、想定外の追加難易度なんだ。これに対応するにはコードの書き換えが必要で、1年以上かかる可能性もある。
いや、分かってるって。そもそもなんでそれが「問題」になるのかが理解不能って言いたいだけｗ
例えばカシオのレジとかググってみ？
消費税率なんてユーザーが自分で設定できる項目だぞ。
つまり店長が自分でポチポチ変えれば済む話だろ。無理ならベンダーの保守員を呼べばいい。
デカい店ならネットワーク化されてるし、サーバー側で一発だろ。
Squareとか使ってる店ならもっと楽勝なはず。
確かにアプデが必要な場所は多いけど、一人の作業員が全国回るわけじゃないんだし。どのみち定期的にやってることだろ。
もし本当にレジのコードが「0%」を想定してないんだとしたら、当時の開発者は何を考えてたんだよ。変数なんて0から100、なんならそれ以上の範囲で動くようにしとくのが常識だろ。
まあ、現場は阿鼻叫喚だろうなｗ
悪いけど、やっぱお前分かってないわ。
さっきも言ったけど、ルーチンワークの変更ですら準備に数ヶ月かかるんだ。そこらのおっちゃんがカシオのレジをいじるレベルの話をしてるんじゃない。
もう一回言うぞ。
たとえ「いつもの」税率変更でも、全国一斉にミスなく反映させるには数ヶ月単位の準備とテストが必要。
問題は、変数を一つ変えること（0以外の数字にね）じゃないんだ。
大手チェーンを例に出すと：
まず法務チームが法改正の中身を精査して、どの商品が免税対象でどれが対象外なのか、条件を洗い出す。これだけで数週間。
次にテスト環境で、財務かITチームがERPとか財務システム、あるいは税率マスターのテーブルに、将来の適用開始日を設定する。
それからQA（品質保証）チームの出番だ。マスターのデータがレジのサーバー、個別のレジ端末、会計システム、データウェアハウスまで正しく流れるかチェックする。レシートの印字や会計レポートが正確かも確認が必要だ。
さらにイレギュラーなケースもテストする。「増税前日に買って、増税当日に返品したらどうなるか」とかな。
全部OKなら、ようやく本番環境への反映を計画する。
適用当日（T+0）、レシートやデータ、中間報告が正しいかリアルタイムで監視. 開店前にテスト決済もやるだろうな。
まだ終わらないぞ。その日の夜には決済処理が正常か確認。翌日（T+1）には全日のレポートを再確認して、照合システムが動いてるかチェック。
月末には会計フローが滞りないかまで見る。
これら全部が「日常的な」作業だけど、調整と準備に膨大な時間がかかるんだよ。
そこに「消費税0%」なんていう特殊な要素が入ってみろ。ベンダーや顧客企業をまたいだ作業は、数四半期、下手すりゃ年単位のプロジェクトになる。
記事にはそんなこと一言も書いてないぞ。
レジメーカーが「技術的な問題がある」って言ってるだけだ。
お前が言ってるのは、それぞれの企業の中の事情だろ。
ワロタ。エクセルの数値を書き換えて計算が合うかテストするのに、そんなに時間かかるのか？
100円入れてよし。150円入れてよし。162円入れて……よし。これに何ヶ月かけるんだよｗ
ほんそれ。
政府がポテチのパッケージにまで口出すのは、腐敗した資本主義が順調にいってるフリを邪魔されたくないからだろ。ちょっとした衝撃で崩れる砂の城なんだよ。その脆さが露呈するのをビビってるわけだ。
まさにそんな感じだな。
前にレジシステムの保守会社の面接受けたことあるけど、COBOL使えるやつ探してたわ。
金のやり取りは全部COBOLだよ。日本に限った話じゃなくて世界中どこでもな。
昔、物理学の修士持ってる知り合いがいたけど、シミュレーションで使ってた言語が金融機関のバックエンドと同じだったっていう理由だけで採用されてたわ。
別に日本だけって言いたいわけじゃない。古いCOBOLで動いてるシステムが多いのは事実だしな。
世界共通とか絶対にない。俺の国の銀行はずっと前にCOBOLなんて捨てたわ。
だから24時間365日、誰にでも無料で即座に送金できるんだ。日本みたいに自分の金を引き出したり送金したりするのに手数料取られたり、アプデで一週間金が止まったり、クソみたいなアプリを使わされることもない。
手数料に関しては、ただの強欲だろうな。
ソニー銀行なら振込無料だしな。てか、GWにATM止める銀行なんて今時あるか？
数年前にゆうちょがシステム改修で止めたのが最後だろ。もう止まらないようにするための工事だったし。
ソニー銀行、連休中しょっちゅう止まるだろｗ
24時間365日リアルタイム、かつ振込手数料が「無制限」で無料になってから出直してこい。
COBOL自体が悪いわけじゃない。ただのプログラミング言語だ。
大抵のことは、できる人間を見つけられない経営側の失態。金を積めば人間は動く。給料さえ良ければ、案外みんな文句言わずにやるもんだぞ。
俺も最近の研究プロジェクトで数百万件のログイン記録を処理するのにCOBOLを検討してみたけど……まあ、他の言語と比べたらマジで不快だったわｗ
俺はCOBOL嫌いじゃないけどな。ただ古いってだけで。
まあ時間かけて慣れれば、ガリガリ書けるようにはなるんだろうな。俺も興味本位で触ってみたし。「ビジネス上の課題」を解決するには向いてるのかもな。
俺の場合は、データの準備段階で発狂しそうになったけどｗ
でも面白いよな。俺の仕事の多くは結局「数百万のレコードを処理して出力する」っていうバッチ処理に行き着く。汎用機じゃなくて、普通のPCの仮想環境とかで動く現代的なMVSスタイルのOSがあればいいのにな。
1995年当時、65歳だった俺の親父は結局69歳まで働いてたわ。専門がCOBOLだったからな。給料が良すぎて辞められなかったらしい。90年代初頭の不況も、米軍の契約社員として通常の3倍の報酬で乗り切ってた。
……30年も前の話だけどな。
年金受給が65歳、大学卒業が25歳、なのにインフラの核心を担うコードが40年前のものって、日本は独特の詰み方してるな。
今って卒業25歳なの？
別に日本だけじゃないだろ、そんなの。
多くの国じゃ修士まで行くのが普通だから25歳卒業ってイメージなんだろうけど、日本はそうじゃない。院に行くのは1割程度で、25歳の頃にはみんな社会人3年目とかだぞ。
ソースコードはフロッピーディスクにバックアップされてます。
8インチのやつなｗ
たまらん。
恥ずかしすぎ。
日本のスーパーはJANコードで商品を読み取ってるだろ。
そのデータベースには税区分とかの情報が紐付いてるわけだ。
やるべきことは、8%（軽減税率）を0%に変えるだけ。10%（標準税率）はそのままでいい。
変数一つ変えるだけの単純なシステムアプデだろ。日本さんよぉ……。
いいアイデアだ！
来年一年かけて会議を20回開こう。順調にいけば、プランを半年間ファックスでやり取りして確定だ。会議のスケジュールを見逃さないようにポケベルは常に持っておけよ。質問があるなら、適切なサイズの便箋に手書きして判子を押して郵送してくれ。
スーパーだけじゃねーよ。全国のレジ、券売機、POSシステム、オフラインで手動アプデが必要な田舎のオンボロ店まで全部だ。
あと、レポーティングシステムはどうなる？
バカげた話だけど、開発者が「0%はありえない」って前提でシステムを組んでる可能性はある。
誰も中身を知らない「動いてるからヨシ」の遺物コードの上に新しいシステムが乗っかってる可能性も高いしな。
日本のITを煽るのは俺も大好きだけど、銀行も含めて、手を付けなきゃいけないレガシーコードの山はガチでヤバいぞ。
2019年に増税した時は、こんなに騒いでなかった気がするけど。
コンピューターの世界じゃ「0」は特別な意味を持つことが多いからな。
文脈によって、文字通りの「ゼロ（0%）」なのか、「データなし（Null）」なのか、「適用外」なのかが変わる。
もしレジの設定を0%にした途端、レジ側が「おい、税率が入力されてないぞ」ってエラーを吐くかもしれない。「0」を「入力忘れ」だと勘違いしちゃうわけ。
増税の時は、新しい数字も「ゼロ以外」だからこの問題は起きなかった。
減税だって1%とかなら大丈夫なんだよ。だから1%への引き下げ案が出てる。
でも「0%」への対応を想定してないコードが書かれてたら、そりゃ大問題だわ。
北米やヨーロッパだと、逆に「通常の税率（0より大きい）」と「税率0%」と「非課税（これも0%だけど扱いが違う）」を使い分けるからもっと複雑だけどな。マイナス税率（還付金みたいなやつ）に当たらなかっただけマシだわ。
>「0%はありえない」って前提で組んでる。
それがバカだって言ってるんだよ。もっとフィールドを増やせよ。
こういうシステムは、メモリを贅沢に使えるWebアプリとかとは制約の厳しさが違うんだろ。
仮に2000アイテムあるとして、特殊なケース用に1バイト追加したところで、たかだか2KBだぞ。0.002MBだ。
フィールドを増やす必要すらない。JANコードのデータベースには最初から税率の項目がある。商品によって8%か10%かが決まってるんだ。
JANコード（スキャンするやつ）に入ってる主要な情報は2つだけ：
1. メーカーコード
2. 商品コード
スキャンされたら、データベースを見に行って税率を引っ張ってくる。
税率を0にすると不具合が起きるって理屈は分かるけど、具体的に何が壊れるのか想像つかん。エンジニアが一日で直してファームウェア更新すれば済む話だろ。
普通、計算式はこうだ：
最終価格=元の価格*
(1 + 税率)
税率が0になったところで、計算が破綻するようなケースが思い浮かばないんだけど。
効率的に考えようなんて失礼だぞ！
そのせいで仕事がなくなる人の身にもなれ！ｗ
誰かが責任逃れしようとして、例の「日本しぐさ（誰かのせいにする）」を発動してるだけだろ。
恥ずかしいのは、実現可能かどうかも確認せずに戦略を発表しちゃうところだよ。紙に書く前に、普通ちょっとは調べるだろ。
経営管理ビザの要件を「資本金3000万円＋従業員1名」に引き上げようとして、既存のビザ保持者の95%が脱落して企業が日本から逃げ出すことに後から気づいた件と同じだな。
で、結局「3年間延期」して、ほとぼりが冷めた頃にこっそり撤回しようとしてるっていうね。
実現は可能だろうな。他国からレジを買ってくればいいだけだし. また日本の産業が中国に負けるだけ。
おいおい、2000年問題の再来かよｗ
