軽減税率がITに与えるインパクト

http://www.nikkei.com/article/DGXDZO50933940U3A120C1MM8000/

どうやら本格的に複数税率が消費税に適用されるようです。まだ、決定でもないし、今後の業界の猛烈な反対もあるだろうから、どうなるか分からないのですが、その辺を部外者的に（かつ元関係者的に）記録として書いておきますよ。

この軽減税率で、もっとも変更のコストがかかる「仕組み」の一つはITであることは、多分論を待たないと思います。特に、税率を複数適応する羽目になる流通・サービス系のITは下手をするとかなりのコスト負担になるところも出てきます。またか！またコストですか！いや、これこそがITなのですよ。

まず影響が出てくるところ予想すると、事の大小はありますが、ほぼ大抵のところで手を入れる必要がある気がします。んで、例によって、多分この辺が正確に予想できている、CIOを除く経営陣は皆無か絶無に近いわけです。（例外は勿論ありますが）

1.POSやら商品マスターやら
　PLU・商品マスター周りはそれなりに手を入れる必要があります。普通は課税・非課税・対象外程度の税区分で処理をこなしているはずで、それ以上の判定ロジックを実装しているところはとりあえず見たことがないです。よって、テーブルの修正やら画面・バッチの修正を一発追加する必要もあり、ま、正直あまり触りたくないところに手を入れる羽目になります。これは泣けます。
　またこれは、店舗周りの仕組みからなにから、商品マスターの同期処理から見直すことになります。んで、PLUにしろ、マスター処理にしろ、処理的には必ず追加の結合処理やらなんやらが一回は入るので、多分パフォーマンスは落ちる。これも泣けます。予想するに、めんどうくさくなって、「ま、所詮二種類なので、課税5%と課税8%とかにして、必殺のハードコードを増やせばいいんじゃね」で緊急対応する作戦がほとんどですね。ていうか、多分それ以外に手がないでしょう。・・・ところが、多分税率設定ってきっとカテゴリーベースなんですよ。さらに、措置法なんかで適当に対応品目が変わった日には目も当てられません。さらに、そもそも2種類程度ならまだいいですが、段階やら対象やらが複雑になってくるともう手の打ちようがないですね。

　いずれにしろ、結果的には先の事は考えない作戦になります。そもそもいろいろ作った当初の段階では、他の事が手一杯で、税率なんて普通にまともに先の事なぞ考えてないのが実情です。んで、さらに、そのツケは今は払いたくなので、利子をつけて、そのままコストを最小限にして先送りモード全開にしたい。隠れ債務を膨らませる結果になるが、後のヤツが考えればいいわ。多分、もう俺いないし的なアレが、またや発生するわけです。

　もういっそのことパッケージで入れ替えるか？という話も出てきますが、「あ、当然カスタマイズっすよ？」で撃沈確定も例のごとくかと。まずいのは、最近パッケージとか入れたところですね。当然対応とかあまり考えてないので・・・これは厳しいです。
　なんにしろマスターに手を入れるってのは辛いですね。

2.仕入伝票周り
　これは致命的にヤバいところが出てきます。何しろ、ほとんどの実態は明細レベルでの処理ではなくて、伝票計での税額処理。非課税・課税が混在した場合の伝票処理・レイアウト・バッチ処理はまったく考えていない。要は明細レベルで、課税額が変わる、なんてことは毛ほども考えてないところに、「いや、それ全部変わるから」となる。この辺りは実装をやっていた人であれば、聞いただけで逃げ出すぐらいの厄ネタになることが、簡単に分かります。ただし、禁断の必殺技があってそもそも税率で伝票を分けるという作戦があります。ありますが、これは後述しますが微妙な政治ネタになります。
　消費税って話だと一般受けはフロント周りが注目されますが、バックエンドの方が影響が当然大きいです。

3.在庫管理系
　加えて、製造周りが入ってくると、税額の紐付けとかできないので、まずは、全部税剥がし一直線になります。表示のときに再結合するのか、と思うと持ち回りたい気分満開ですが、ぐちゃぐちゃになるのは目に見えているので、我慢でしょう。ここまではまだ良いです。総額表示で無駄にいろいろやった経験があるので、それほどでもないです。だがしかし、原価算入できないものや商品・製品に直接・間接でアタッチされるヤツは泣きそうになります。どーすんの？課税種別で明細分けて処理するという事も可能ですが、そーなると在庫管理系はマスター変換や明細の合流処理をしていない場合は、速攻で手が詰まる。
　そもそも弁当の本体と弁当のトレー・箸なんて感じものはどう扱うのか？別々？一緒？最近の流れは、可能な限りkittingしてもらうのが原則なので、伝票周りではどうするのかも問題になる。さすがにこのあたりは、公の指針は出てくるだろうとは思いますが、微妙なヤツは全部現場判断になりそうな気もします。仕組みとして対応しないと大変なことになりますね。全部手でやります、なんて話になったら殺気立った経理様からマジで刺されかねません。

4.卸関係では出荷・売上・請求周り
　さて、一番微妙なところがここになります。買い手サイドの最後の必殺技はいつの時代も、取引先への「ご協力のお願い」になります。要は納品（または受発注）時点で、課税種別単位で伝票を全部スプリットしてくれ、というヤツです。データレイアウトも含めてこのカタチでやってくれ、と。取引先は多分、大抵は悲鳴を上げる。特に卸関連。お疲れさまのフルバッチ追加＋コスト増の上級者コースが確定になります。マスターとかもうね。アレすぎて卒倒しますよ。
　さて、この「ご協力のお願い」は超絶微妙です。特に取引先が下請法適用の場合は、かなり微妙なバトルや鞘当てが起こる。公取委も興味しんしんでしょう。これ見ようによっては、完全にコストの付け替えですからね・・・なんかこう、強制的に法律で決まったりする可能性もゼロではないのですが、そうなるともはやギブアップでしょう。
　いや、そもそもいっそのこと懸案のインボイス方式したら、なんて意見も再燃するでしょうから、仮にそうなったら悲鳴どころか絶命しかねないところも出てきます。実態はとにかくアレ過ぎるので。・・テストとか本気でやったか？これは？という例のアレです。

という以上の話を、開始期限までにやらないとまずい。これは痛い。さらにやったうえで、関係者ならわかると思うが、「また変な負債が増えたわ」と思う事、天罰テキメンな感じになります。関係者ほぼ全員、天を仰いでいると思います。「やりたくねー」

5.場外戦もヒートアップ
　さらに面倒なのが、ここぞとばかりにITベンダーも「お仕事ですね！お見積もり作らさせてイタダキマス！」モード直行になる。IT部長・CIO系の方々も頭が痛い。下手をすると、単年度だけみると、ITのコストが軽減差額を越える可能性すら発生するでしょう。そんなシミュレーションでもやった日には、稟議審査や経営会議で嫌みや、つるし上げや、反対意見のオンパレードになります。「これはアレか？軽減税率を全部無視して、大幅に超過消費税を過剰に払った方が、まだ安いって言ってる？」というところすら出てくる。もうね。どうしろと。

でもですよ。これは先を見なかったユーザー・ITベンダー双方の責任もあるわけですよ。ユーザー様におかれましては、あのまま、消費税が普通に3-5%で行くと思っていましたか？欧州を見れば一目瞭然でしょう。想像ができなかったとは、それはあまりに発想が貧困でしょう。ベンダー様に置かれましては「使わない機能は作らない」というWebサービス系の金言を都合良く、まさに金科玉条の毎に使い回した結果でしょう。「使わない機能は作らない」ということと「柔軟なアーキテクチャにしない」は同義ではございません。

　もっとも、「んじゃー、ここで偉そうに能書きたれてるお前の関わった某標準はどうなのか？」とか言われるとアレですが、確か対応しているはずです。してなかったら、それは多分事務局の(ry

6.例によって置いて行かれるのは・・・お客さんです。
最後に、何が凄いって、こういう騒動になってもですね、最終のお客さんから見るとまったく付加価値が上がっていないってことですよ。届ける先のお客さんの利便性が多少でもあがるってんだったら、コスト増も負担するってのは、確かにありです。が、「まったくない」ってのは非常にダウナー感溢れるお仕事になります。とはいえ、シニカルに言えば、まさにコレこそが「日本の景気対策」なのかも知れません。どーなんですかね・・・・・消費税狂想曲再びですわ。

かくもITというものは、世相の混乱を映す鏡です。アジャイルが普及しようが、クラウドで便利になろうが、先を見通す力がなければ、地上からデスマは消えないわけですよ。(遠い目

でわでわ。