人気のスレッド
ニュース速報+
128
1768.6
1281768.6
ニュース速報+1141405.1
1141405.1
ニュース速報+3231164.2
3231164.2
ニュース速報+62995.7
62995.7
ニュース速報+20859.3
20859.3
ニュース速報+59782.8
59782.8
ニュース速報+50721
50721ニュース速報+63666.7
63666.7
ニュース速報+12644.4
12644.4
ニュース速報+708597.3
708597.3もっと見る
減税時：レジの改修で景気が冷え込む
笑わせんな
しかも飲食の問題まで発生してたのに強行したわけで
もはややるかやらないかは気分
単に数字を書き換えるだけ。
やれよ
早く
さっさと
たったそれだけで国民の支持は爆上がりだ。
遅ければ遅いほど支持は下がってゆく。
アホなこと言い出す。
金持ちが得しようが、俺らにはカンケーねえんだよ。
俺らから取るのをやめろっつーの。
導入したからこそ、数字変えるだけでできるんだろうが。
さっさとやれ。
意味わからん。
大企業でさえ消費税には四苦八苦してる。
子会社、関係会社に発注するだけで
消費税取られるんだから。
これまでの増税の時に準備期間１年とかかかってたっけ？って話で…ｗ
あほか
いらんことやめろっての。
上下水道、治水、道路などのインフラ
そして消防、警察などの治安
これらに金がかかるのはわかる。
これらのために税金が必要なのもわかる。
それら以外のことをやめろ。
いらんことやりすぎなんだよ。
教育、医療もカネかけすぎ。
笑える
税金は自民党の金だからな
もううるせえっての。
嘘は死刑で
コメンテーターが言ってたけど何か違うのかね
いつまで待たせる気だよ
すぐに決まるのだろうね
定額給付もらったほうがええよ。
それかキャッシュレス還元。
アメリカは州ごとに消費税率が違うらしいな。
基本的には無い。
一カ所直せば全部終わりやんか
最も重要なのはシステムエラーを起こさないことなのでは？
変えるのは可能でもその後、エラー出まくりでてんやわんやで、
またそのパニックに乗じて悪事を働くやつが出て、、、という目も当てられない惨状になるかも？
1年前からの計画だったのか知らなかったぜ
バーコード張り替えてるからでしょ
消費税率変更でトラブル出すようなベンダーはこの世に不要
業界人ならみんな分かってる話
設計がまともならテスト込みで3日かからんよ
コードなんか直すところないし
野党がやるというとレジは間に合うというんだよ
エラーが起こったら
まともなやつじゃなかった！訴えてやる！
と？無責任な思考なんですよね基本的に
というか、今までの0.08って書いてあったところを
0にするだけ。それ以外の作業が必要だとしたら、その
システムは捨てて最初からやり直した方が早くて安い
ぶっちゃけ、AIの出番すらない、初心者でも簡単に出来る
仕事ですってやつだよ
そこが問題なんだよ
今までよく対応してこれたな。消費税なんて定期的に変更されてるのに。
それではAIさんに聞いてみましょう
A.エンジニアやシステム開発の現場を知っている身からすると、**「理屈としては分かるけれど、現実はそんなに甘くないよね」**という、
いわゆる「理想論」や「現場を離れた人の極論」に近い印象を受けます。
いくつかポイントを絞って考察してみます。
◆1. 「0.08を0にするだけ」という主張の危うさ
書き手は、消費税率の変更（あるいは撤廃）を単なる定数の書き換えだと捉えています。
確かに、設計が完璧な「モダンなシステム」であれば、税率設定ファイルを1箇所直すだけで済むかもしれません。
しかし、現実は以下のようになりがちです。
①* **影響範囲の広さ:** 請求書、領収書、過去の履歴データとの整合性、会計ソフトへの連携など、修正箇所が多岐にわたる。
②* **ハードコーディング:** 古いシステムだと、あちこちのプログラム内に直接「0.08」と書き込まれており、一括置換すると無関係な数値まで変えてしまうリスクがある。
③* **端数処理:** 税率が変わる（特に0%になる）際、四捨五入や切り捨てのロジックが誤作動しないか、徹底的なテストが必要。
◆2. 「最初からやり直した方が早い」の現実味
「作り直した方が早い」というのはエンジニアがよく口にする言葉ですが、
実際に数千万円、数億円かけて動いている基幹システムを、税率変更のためだけに作り直すのは**コスト的にも時間的にもほぼ不可能**です。
① * **サンクコスト:** すでに多額の投資をしているシステムを捨てる経営判断は非常に重い。
② * **隠れた仕様:** ドキュメント化されていない「秘伝のタレ」のような仕様が詰まっているため、ゼロから作ると必ず以前できていたことができなくなるバグが発生します。
◆3. 「初心者でも簡単にできる」という評価
「作業自体」は初心者でもできるかもしれませんが、
**「その修正が他のどこにも悪影響を与えないことを保証する」**のは、熟練のエンジニアでも神経を使う作業です。
◼️結論としての感想
この書き込みは、システムの「美しさ」や「あるべき論」としては正論ですが、
**ビジネスとしての責任やリスク管理**という視点が抜け落ちているように見えます。
「3日で終わるはずだ」と言い切る姿勢は、現場のエンジニアからすると「じゃあ、もし何かあったら責任取れるの？」と、
42番のレスが指摘するように「無責任」と感じられてしまうタイプの発言ですね。
wittyに言えば、**「理論上、理論と実践は同じだが、実践においてはそうではない」**という典型例のようなコメントだと思います。
なんだ、素人さんか、、
言っとくけど、テストのための政治的根回し（奴隷の夜勤が
発生するとか、ダウンタイムを取るのに社長決裁がいるとか）
は考慮してないよ。プロのエンジニア視点での話なんでな
A.「割引シールを貼るように、一律で8%マイナス（割引）として処理すれば簡単じゃないか」という発想ですね。
ユーザー側の感覚としては非常に合理的で賢いアイデアに見えます。
しかし、システム開発や会計実務の視点から見ると、実は**「税率設定を0にする」よりも遥かに難易度が高く、火に油を注ぐような解決策**になってしまう可能性が高いです。
その理由をいくつか分解して解説しますね。
◆1. 「税金」と「割引」は計算の優先順位が違う
会計システムにおいて、金額の計算順序は厳格に決まっています。
①* **通常の流れ:** 商品価格 → 割引適用 → **（最後に）消費税計算**
② * **提案の流れ:** 商品価格（税込） → 8%割引
もし「8%割引」として処理してしまうと、その「割引かれた後の金額」に対して、
さらにシステムが自動で「現在の消費税（例えば10%など）」を計算しようとしてしまい、計算結果がグチャグチャになります。
◆2. 「端数処理」の壁
これが一番の厄介者です。
消費税計算では、1円未満の端数を「切り捨て」にするのか「四捨五入」にするのか、法律や企業の規約で厳密に決まっています。
①* **税率変更の場合:** 単に計算式の中の係数を変えるだけ。
② * **割引処理の場合:** 「割引額」を計算し、その端数を処理したあと、さらに本体価格から引く……という工程が増えます。
この過程で**「本来の税額と1円ズレる」**という現象が頻発します。1円のズレでも、数万件の取引になれば決算書が合わなくなり、監査で大問題になります。
◆3. 帳票と法律の整合性
レシートや請求書には、「どの項目が税抜きで、どれが消費税か」を明記する義務があります（インボイス制度など）。
「割引」として処理してしまうと、帳簿上は**「消費税はしっかり取っているけれど、なぜか一律で謎の割引が発生している」**という不自然な記録になってしまいます。
これは税務署から見れば「脱税」や「不適切な会計処理」を疑われるリスクがある、非常に危うい状態です。
◼️まとめ
「割引シール」作戦は、**「表面上の帳尻を合わせる」**には手軽ですが、
**「裏側のデータの整合性を保つ」**には、むしろシステムの深部まで改造が必要になる「禁じ手」に近い対応と言えます。
結局のところ、43番の書き込みが言うように「0.08を書き換える（＝税率定義そのものを変える）」のが最も正攻法なのですが、
それでも「どこにその数値が隠れているか分からない」のが、古い巨大システムの恐ろしいところなんです。
**たとえるなら…**
「家の時計が全部5分遅れているから、全員が5分早く動く（割引対応）」よりも、
「家中の時計の針を5分進める（税率設定変更）」ほうが、最初は大変でも最終的には混乱が少ない、というイメージに近いかもしれません。
ガソリンと一緒で補助金め値段下げたら
需要が上がって物価上げに拍車かけるから。
ええ、だから現実的ではない
机上の空論だと言われるのでしょう
廃止は楽なのよ。税率をゼロにするだけだから（そんなんでも
0ディバイド出す腐れシステムはあるけどさ）。ないところに
付け足すのは大事。
それは会社の事情による。
少なくとも消費税変更ごときで重役決裁が要る現場には
入ったことがないし、人月200万円でも断る
ていうか、お前は働いたことないだろ？
話のそこかしこに無職の臭いがちりばめられてる
つまり>>42でしょう？
もういいかな。
何が？