選挙と施行が近づき大議論を巻き起こしているインボイス制度ですが、それ自体の是非は頑張って脇に置いてエンジニアリングとして思ったことをば。 （個人的には本当に色々思うところがあるのですがこっちのブログでは抑えたいし、議論も発散するので…）
とにかくこの制度、一つの施策に様々な狙いを詰め込みすぎです。おかげで賛成派も反対派も何について賛成反対してるのか、非常にぐちゃぐちゃになってます。建前上は
- 軽減税率により厳格に対応するため、取引内容をより細かく精査できるようにする
というのが狙いではありますが、付随して、
- 取引の透明性を上げることで脱税を防ぐ
- 免税事業者と課税事業者を取引相手にもわかるように分離し、事実上益税を消滅させる
- 課税事業者の身元を取引相手に対して今まで以上に明らかにする
などなどなどの目論見があるように見えるわけですよ。
これがまさにエンジニアリングプロセス的にはアンチパターンで、「一つのコミット/リリースで複数の目標を同時に実現しようとしている」わけですよ。ある意味ではビッグバンリリースともいえると思います。
これ、ITエンジニアとしては滅茶苦茶避けたいやり方で、まずコミットログがぐちゃぐちゃになったり、一つの機能だけ切り戻すことが難しくなったり、障害時に複数の機能を並行して調査して復旧作業する羽目になったり、効果測定をしようにも同時に出ている機能の交絡の影響で原因が何かを根本的に特定できなくなったりと、とにかく問題が多いんです。
しかしながら、こういうリリースというか開発提案はよくなされており、原因としては機能改修や機能追加を10件個別に通すより、「〇〇リニューアル」にかこつけて10件同時に通す方が圧倒的にやりやすいという企画側の都合があるからでしょう。結果として起きることは今のインボイス制度議論の惨状のように、複数の機能について別個に賛成反対が各人で入り混じって、まとまった良し悪しがいえないという状況を招きます。まさしく企画側のもう一つの狙いはそのような状況を作り上げて施策自体の成否を問えないようにしてしまうことなのでしょう。本当に良いサービスを作りあげたい場合は、このような複数の狙いを同時にやる誘惑に対して歯を食いしばって抗わねばならないのでしょうね。
