ITエンジニアが知っておきたい、軽減税率制度（のイヤなところ）

はじめに

僕の妻は兵庫県西脇市で「Coupé Baguette（クープ バゲット）」という小さなパン屋さんを営んでいます。
その関係で、先日国税庁から消費税の軽減税率制度に関するお知らせが届きました。

「軽減税率制度？あ〜、なんかそんな話もあったような」と思いながら資料を読んでみたところ、「げげっ、軽減税率制度ってこんな面倒な仕組みになってたの！？」とビックリしました。

というわけで、このエントリでは軽減税率制度の概要（と、ITエンジニアが困りそうなポイント）をざっくりとまとめてみます。

おことわり

僕自身は税理士のような税金の専門家ではないため、100%正しく理解しているとは限りません。
エントリ内に怪しい内容があればコメント欄等でご指摘いただけると助かります。

国税庁の資料から抜粋した、軽減税率制度の主なポイント

我が家にも届いた「よくわかる消費税軽減税率制度（平成30年7月）」（PDF/4,879KB）という資料から、個人的に気になった軽減税率制度の主なポイントを抜粋してみます。

一部の品目だけ消費税が8%に据え置かれる

2019年10月1日から消費税が10%に変わりますが、一部の品目だけ8%のまま据え置かれます。
これが軽減税率制度です。

上の画像にもあるとおり、8%のまま据え置かれる品目は以下の2品目です。

• 酒類・外食を除く飲食料品
• 週2回以上発行される新聞（定期購読契約に基づくもの）

請求書やレシートの出力フォーマットを変更する必要がある

品目によって税率が変わるため、請求書やレシートでは8%の場合と10%の場合で別々に金額を出力する必要があります。

テイクアウトとイートインで価格表示を変える必要がある（統一するのも可）

飲食料品は8%ですが、外食する場合は10%になります。
そのため、イートインスペースがある小売店などでは、「テイクアウトなら162円（=8%）、イートインなら165円（=10%）」というように、同じ商品でも価格表示を変える必要があります。

ただし、上の図の一番右にあるように、同一の価格表示にするのも良いそうです。

その他、ややこしいルールがいっぱい

このほかにも軽減税率制度にはいろいろと複雑なルールが定められています。
詳しくは国税庁の公式ページにある各種資料をご覧ください。

軽減税率制度とは（リーフレット等）｜国税庁

軽減税率制度、こんなところが困る

我々ITエンジニアにとっては、軽減税率制度のこんなところが困ります。

消費税率の一括変更、だけでは済まない

前述の通り、軽減税率制度では品目によって税率が変わります。

既存の情報システムでは「単純な消費税率の変更」には対応しているものが多いと思いますが、品目に応じて消費税率を変える仕組みまでは用意していないのではないでしょうか。
（さらに同じ品目でも、イートインとテイクアウトで税率が異なる場合がある！）

そのため、異なる消費税率の品目が混在するシステムにおいては、システムの改修を入れないと軽減税率制度に対応できません。

請求書やレシートの出力フォーマットを変えなければならない

請求書やレシートの表示も8%の品目と10%の品目で表示を分ける必要があります。
そのため、システムから請求書を自動生成している場合やスーパーのレジなどでは、システムの改修や機器の入れ替えが必要になりそうです。

その他もろもろ

このブログに書いた話は氷山の一角で、このほかにも軽減税率に関わるさまざまな特殊ルールがあります。
そのため、商品の仕入れや販売に関わる情報システム（いわゆる勘定系システム）ではそれに合わせて仕様変更を実施する必要が出てくると思います。

情報システムに関係しそうな考慮ポイントについては、こちらのブログによくまとまっています。

軽減税率がITに与えるインパクト - 急がば回れ、選ぶなら近道

また、国税庁が作成した「よくわかる消費税軽減税率制度（平成30年7月）」（PDF/4,879KB）という資料にも、以下のようなチェックリストが載っています。

まとめ

というわけで、この記事ではITエンジニアにとって面倒くさそうな軽減税率制度のポイントについて、ざっくりと要点をまとめてみました。

軽減税率制度といい、サマータイム導入や新元号の公表タイミングの問題といい、何かと情報システムに負のインパクトを与える話題が妙に多いと感じる今日この頃です・・・。

と思ったら、Rubyのパパとして有名なMatzさんも同じことをつぶやいておられました。

軽減税率といい、改元といい、サマータイムといい、IT 業界を苦しめたいか、生産性を高めるのを阻害したい勢力が政治をコントロールしている陰謀論を信じたくなるな。

— Yukihiro Matsumoto (@yukihiro_matz) 2018年8月18日

いやあ、全く同感ですね😣

あわせて読みたい

サマータイム導入問題についても、個人的に思うところをこちらのエントリにまとめています。

おまけ

もし軽減税率制度に対応したレシート出力機能をシミュレートしたらどんなコードになるのかな〜？と思って、Rubyでサンプルプログラムを作ってみました。
が、案の定、考慮点がたくさんあってかなり大変でした・・・。

動作イメージはspecディレクトリのregister_spec.rbをご覧ください。

祝！増刷 ＆ Ruby版のRailsチュートリアルを目指していた「プロを目指す人のためのRuby入門」の裏話

お知らせ：第3刷の増刷が決定しました！

僕が執筆したRubyの入門書、「プロを目指す人のためのRuby入門」（通称チェリー本）の増刷が決定しました！
2回目の増刷なので、今回は第3刷となります。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

・・・といっても本の執筆者と出版関係の人ぐらいしか、「増刷」なんていうキーワードには興味がないかもしれません。
（僕も本を出す前は興味がありませんでした💧）

増刷というのは簡単にいえば「本の在庫がなくなってきたので、まとまった単位で本を印刷し直して在庫を補充すること」です。
つまり、増刷がかかるということはそれだけ本が売れていることを意味します。
つまり、著者としては増刷の連絡がもらえるのは、とても嬉しいわけです！！😆

これもひとえに「プロを目指す人のためのRuby入門」を購入していただき、周りの方々にオススメしてくださったみなさんのおかげです。どうもありがとうございました！
そして、引き続き「プロを目指す人のためのRuby入門」をよろしくお願いします！

MARUZEN＆ジュンク堂書店　梅田店にて。直筆ポップを置いてもらってます！

制作裏話：切っても切れない？「Railsチュートリアル」と「プロを目指す人のためのRuby入門」の関係

ところで、Twitter等で「プロを目指す人のためのRuby入門」の反響を見ていると、Railsチュートリアルをやった後、またはRailsチュートリアルをやる前に「プロを目指す人のためのRuby入門」を読まれている方が多いようです。

そして、「Railsチュートリアル」と「プロを目指す人のためのRuby入門」の組み合わせは、RubyやRailsの勉強を進める上で、かなり学習効果の高い組み合わせになっているように思います。

チェリー本やってからのRails tutorialがほんとにサクサクで楽しい。全然苦しくない。今まで躓いてたところも「こんな使い方もあるのね」くらいでどんどん吸収できてる気がする。もっといろんなこと知りたい勢いでこのまま夜更かし。。。

— janham@緑のジャングル (@janhampino) 2018年8月12日

プロを目指す人のためのRuby入門(2周目)でrubyの文法を復習中。railsチュートリアルを経ての2周目だからこそ得られる気づきが多い！

— Kスケ@rails勉強中 (@k_s_k_1222) 2018年8月12日

Railsチュートリアルと一緒に「プロを目指す人のためのRuby入門」を読んでもらえるのは、個人的にとても嬉しいです。
それはなぜでしょうか？その理由を以下に書いていきます。

初期の原稿ではRailsチュートリアルのスタイルを踏襲していた

実は「プロを目指す人のためのRuby入門」は、もともと「Ruby版のRailsチュートリアル」を目指して執筆を開始しました。
一番最初に書いた原稿では、Railsチュートリアルを参考にして「例題のコードをチュートリアル形式で読者に書いてもらいながら、一緒に構文や文法を説明する」というスタイルを取っていました。

一番最初に書いた原稿の一部。このときはコードを書きながら構文や文法を説明していました。

ただ、このスタイルだとなかなか例題の説明が進まなかったり、文法の説明と例題の説明が混在してわかりづらかったりする問題があったので、結局ボツになりました。
コードを書きながらRailsの説明を同時進行させても、読みやすさやわかりやすさが損なわれないRailsチュートリアルは偉大ですね！

僕自身もRailsチュートリアルのお世話になっていた

そもそも、なぜ僕が「Ruby版のRailsチュートリアル」を書こうとしたのかというと、その昔、僕自身がRailsチュートリアルのお世話になったからです。

僕もRailsを勉強し始めた頃はRailsチュートリアルを使っていました。
当時はまだ英語版しかなかったのですが、それでもチュートリアル形式でフレームワークの使い方を学ぶという体験が初めてで、すごく斬新でした。
Railsチュートリアルを使って勉強すると、勉強しながらWebアプリケーションができあがっていくので、「これはすごい！そして面白い！」と非常に感銘を受けました。

ただし、RailsチュートリアルはあくまでRailsがメインで、Rubyというプログラミング言語の説明は控えめです。
そこで、「Railsの習得はRailsチュートリアルにまかせて、僕はRubyを習得するためのRubyチュートリアルを書こう！」と思い、「プロを目指す人のためのRuby入門」の執筆に取りかかったのでした。

Railsチュートリアルと自分の書いた本がリンクするのは嬉しい

このように僕個人としては「Railsチュートリアルがあったからこそ、プロを目指す人のためのRuby入門が生まれた」と言っても過言ではないぐらい、（一方的に）縁やゆかりを感じています。

なので、Railsチュートリアルと一緒に「プロを目指す人のためのRuby入門」を読んでくれている読者さんを見かけると、とても嬉しくなります。

また、日本語版のRailsチュートリアルには「読み物ガイド」の項に「プロを目指す人のためのRuby入門」を載せてもらっています。
（ついでにいうと、僕が翻訳した「Everyday Rails - RSpecによるRailsテスト入門」も載っています！）

Railsチュートリアルにお世話になった人間としては、これも非常に嬉しい出来事でした。

もちろん、「プロを目指す人のためのRuby入門」の参考文献にもRailsチュートリアルを掲載させてもらっています。

まとめ

というわけで、今回のエントリでは「プロを目指す人のためのRuby入門」の増刷のお知らせと、Railsチュートリアルに関連した制作裏話を書いてみました。

そういえば、去年の今頃は自宅に届いた「プロを目指す人のためのRuby入門」のゲラ（試し刷り）をチェックして、原稿を校正している真っ最中でした。

去年の夏はゲラを読みながら校正作業をしていました

当時はまだ本当に出版されるのかどうかすら半信半疑な状態だったので、自分の本がどれくらい読んでもらえるかなんて全く予想が付きませんでした。
ですが、実際に出版してみると、予想をはるかに上回る好評価をいただき、売れ行きも好調で筆者として非常に嬉しい限りです。

欲張りかもしれませんが、もっとたくさんの人に読んでもらいたいので、まだ購入されていない方はぜひ書店で手に取ってみてください！

また、本の感想も随時募集中です。
ご自身のブログやAmazonレビュー等で書評を書いてもらえると大変ありがたいです。

みなさん、「プロを目指す人のためのRuby入門」を今後ともよろしくお願いします！😄

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

お客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうすべきか？

はじめに

東京オリンピックを2年後に控え、日本のIT業界に突然降って湧いた「日本でもサマータイムを導入するかも？」という問題。
この話、数日経てば「そんなのうそぴょーん」とか「すいません、前言撤回します」みたいなオチで終わるだろうと思ってたのですが、このブログを書いている時点ではそういう気配はなく、むしろ前向きに検討しているような雰囲気で「おいおいおい！」と思っております。

こんな「ピカーン💡いいこと思いついちゃった！」的なノリで突然サマータイムを導入するのが、技術的にどんなに無茶な話なのかは、他の専門家のみなさんが論じてくれているのでここでは書きません。
そのかわりに、もしこんな話が僕が勤めている株式会社ソニックガーデンの「納品のない受託開発」で巻き起こったら僕はどんな対応をするか、という思考実験をしてみようと思います。

前提知識：「納品のない受託開発」の開発スタイルについて

「納品のない受託開発」ではその名の通り、お客様の要望に応じて専用のシステムを開発する「受託開発」でありながら、システムを全部最後まで作ってお客様にお渡しする「納品」がありません。

「納品のない受託開発」の特徴を簡単にまとめると以下のようになります。

• プログラマとお客様が毎週定例のミーティングを開き（通常はビデオ会議）、その週に開発するシステムの仕様を決める
• プログラマは次回のミーティングまでに、お客様に成果が見えるプログラムを実装する
• 翌週のミーティングで開発したプログラムをお客様とレビューする。そして、また次の週に開発するタスク決める
• レビューが済んだプログラムは随時本番環境にリリースされる
• ソニックガーデンは毎月定額の開発費をお客様からいただく
• プログラマは毎週、一定量のタスクを実装する。納期についてはあくまで「ベストエフォート」でしか約束できないので、「xx月xx日までのリリースを死守してほしい」というようなご要望には原則として応じない

上の流れを見てもらえばわかるとおり、「納品のない受託開発」ではプログラマが直接お客様と対話し、話をした本人がプログラムを書きます。
SEとプログラマが分かれていたり、間に別の会社が入ったりすることはありません。

「納品のない受託開発」の詳細についてはソニックガーデンのホームページ、もしくは弊社代表の倉貫が書いた以下の著書をご覧ください。

「納品」をなくせばうまくいく

もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら

さて、ここからが本題です。
現実にはあり得ませんが、もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら、僕はどう返事をすればいいでしょうか？

「それは無理です。絶対にできません」？
「仕様を教えてください。それから見積もりいたします」？
「サマータイムを導入するのがどんなに大変なことか、ちょっと説明させてください」？

いいえ、どれも違います。
最初に返す言葉は、

「なぜサマータイムを導入する必要があるんですか？その理由や背景を教えてください」

です。
「やりましょう」でも「無理です」でもなく、「そもそもなぜサマータイムの導入が必要なのか」を確認します。

報道などで伝え聞くところでは、「マラソンの開始時刻を2時間早めたいから」という理由があるようですが、もしお客様がそのように回答してきたら、「では、そのまま素直に開始時刻を2時間早めればいいんじゃないでしょうか」と提案します。
そこから「いいえ、それは無理なんです。なぜなら・・・」と、お客様から納得のいく理由が返ってくれば議論をさらに進めることができます。
ですが、そうでなければ「サマータイムの導入」というタスクは永遠に実行に移されません。

受託開発と言えど、ソニックガーデンのプログラマはお客様の要望を全部そのまま受け入れるわけではないのです。

「IT投資に対するソフトウェアの価値を最⼤化すること」というビジョンと、「判断に理解と納得を持ち思考停止しないこと」という価値観

ソニックガーデンのビジョンの一つに「IT投資に対するソフトウェアの価値を最⼤化すること」があります。

IT投資に対するソフトウェアの価値を最⼤化すること
SonicGardenはソフトウェアの可能性を信じています。物理的な制約を受けることのないソフトウェアは、ユーザや企業が必要とする要求に対し、最も効率よく価値を提供することができるはずです。しかし、今のソフトウェア開発には無駄が多く、投資に対する価値が提供しきれていないように思います。私たちは、業界にはびこる無駄を見直し、IT投資に対するソフトウェアの価値を最大化することを目指します。

https://www.sonicgarden.jp/company

さらに「判断に理解と納得を持ち思考停止しないこと」という価値観もあります。

「判断に理解と納得を持ち思考停止しないこと」
SonicGardenでは、言われた通りに仕事をするということを嫌います。お客様からの要望による機能を実装するにも、自社サービスの機能を設計するにも「本当に必要なのか？」という観点から考えて納得をした上で取り組むようにします。

https://www.sonicgarden.jp/company

これらを組み合わせると、プログラマは「サマータイムを導入することは本当に必要なのか？サマータイムを導入する以外に、お客様の問題を解決できる、もっとスマートで低コストな解決策はないか」ということを考えます。
その解決策を検討するために、「本当に困っていることは何か」「本質的な問題はどこにあるのか」ということを、ミーティングの中でお客様と議論しながら深掘りします。

議論の末に出てくる結論

議論ではお客様とプログラマの双方が心の底から納得がいく結論を出す必要があります。
先ほど述べたとおり、「お客様が本当に困っていること」を探り出すのも重要ですし、我々プログラマもお客様に対して「もしサマータイムを導入しようとしたら、どれくらい大変なのか、実際にどれくらいの工数がかかるのか」を説明し、お客様にその大変さやサマータイム導入によるメリット・デメリットを理解してもらわなくてはなりません。

このようにお客様とプログラマが、お客様のビジネスを成功させるために本音で意見をぶつけ合い、最終的な結論を導き出します。
「サマータイムを導入するか否か」というテーマであれば、大きく分けて「導入しない」もしくは「導入する」という2種類の結論が出てくると思います。

「サマータイムを導入しない」という結論の場合

お客様が「本当に困っていること」を理解し、それを解決するもっと良い方法が「サマータイムの導入」以外にもあるなら、我々プログラマはその方法を提案し、お客様に納得してもらいます。
場合によっては「全くコードを書かない（つまり、何もしない）のがベスト」という結論に至ることもあります。

普通の受託開発では「コードを書かない＝儲からない」ということになりますが、「納品のない受託開発」は毎月定額で料金をいただくことになっているので関係ありません。
むしろ、「サマータイムを導入しない代わりに、お客様にとって、もっと価値の高い別のタスクに取り組む」という、お客様とプログラマの双方にとって有意義な選択肢を採ることができます。

「サマータイムを導入する」という結論の場合

一方、議論の結果「なるほど、そんな事情があるのなら、サマータイムを導入することもやむを得ない。いや、むしろサマータイムを導入することには十分な理由と価値がある！」という結論に至る可能性もゼロではありません。

しかし、その場合でもソニックガーデンでは「毎週、一定量の成果を出す」というルールを変えることはありません（つまり、プログラマは体を壊すようなハードワークをしません）。

なので、あまりにも無茶な内容だと、「見積もりした結果、お客様が希望する納期に間に合わない」という問題が発生します。
その場合は「無駄な要件を可能な限りそぎ落とし、本質的な問題を解決できる要件だけを残して、納期に間に合うように努力する」という選択肢を採ります。

とはいえ、「日本にサマータイムを導入する」というレベルになると、何を削ったら納期に間に合うようなボリュームに落とし込めるのかイメージが沸きませんが・・・。
ですが、実際の「納品のない受託開発」では「要件のスコープ」を調整することで、お客様の希望する納期に間に合わせることがよくあります。

まとめ：で、結局「サマータイムを導入して本当に解決したい問題」は何？

というわけで、このエントリでは「納品のない受託開発」でお客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうするか？という思考実験をしてみました。
実際に「日本にサマータイムを導入したい」なんていう話をし始めるお客様はいませんが、そこまでいかなくても「それ、本当にやろうとしたら大変な工数になりますよ」というようなご要望をいただくことはよくあります。
そういう場合は上に述べたような議論を通して、我々プログラマはお客様にとって最も費用対効果の高い形にタスクを落とし込むようにしています。

ところで最初の話に戻りますが、僕らは普段こんなふうに仕事をしているので、「マラソンの開始時刻を2時間早めたい。だから日本にサマータイムを導入したい」という話がいまいちピンと来ないんですよね。
僕はどう考えても「マラソンの開始時刻を早めたい」なんていうのは表面的な理由で、「本当は何かもっと本質的な理由や目的が背後に隠れているはず」と思ってしまいます。
ですが、報道ではそのあたりの情報がハッキリ明示されないので、サマータイム導入に関する昨今の議論を見てても非常にモヤモヤしてしまいます（「そもそも」の話がしたいのに、それができなくてモヤモヤする）。

少なくとも僕個人としては「うーん、今見えている理由だけだと、ちょっとサマータイムを導入するのは無理（＝プログラマとして受け入れられない）ですね」というのが、現時点での答えになると思います。

あわせて読みたい

このサマータイム導入問題は、以前読んだ「失敗の本質」にどこか通じる話があるんじゃないか、という気もしています。
結局、戦争が終わってから70年経った今でも「声の大きい人の意見が通る」とか「非合理的な精神主義で、現場が無茶を強いられる」といった行動パターンから抜け出せないのだとしたら、非常に残念です。