はじめに
昨今、「消費税減税」というキーワードがニュースなどから聞こえてきます。
それに関連して、「消費税減税はシステム対応に時間がかかる」という意見もあれば、「税率マスタを変えるだけだろう」といった声もあり、様々な意見が見受けられます。
みなさんは消費税変更のシステム対応と聞いて何を思い浮かべるでしょうか。
ある人はレジで設定をちょっと変えればいいと言うかもしれません。
またある人は、税率マスタを変更すればすべてのシステムに配信されると思うかもしれません。
ただ、世の中そう簡単にいかないかもしれない。そんなお話を書きたいと思います。
前提
登場する用語
- 私（この話の張本人）
文系出身、経理部門から情報システム部門に異動して2年ほど経ったくらいの時期。
会計システムの更改プロジェクトの佳境に差し掛かった頃だったが、並行して消費税10%対応を実施。 - Aプログラム（仮称）
後述のBシステムで管理される売上を、会計システムへ連携するためのストアドプロシージャ。
会計システム内に存在し、手動で実行するもの。一度実行すると完了までに2～3時間を要する。
売上を仕訳に変換するものだが、肝心の変換ロジックがマスタ化されておらず、数千行に及ぶIF分岐で実装されていた。
※別システムから単純移植されたため、会計システムベンダーの保守も受けられない状態 - Bシステム（仮称）
法人顧客の売上を管理するシステム。
毎月の運用
当時、以下のような運用を行っていました。
- 月初の深夜に、Bシステム担当者が締め処理を実施
- 締め処理完了後、私がAプログラムを手動で実行
- 仕訳作成時に頻繁に発生する"プログラムで解消できないエラーデータ"を手修正した上で再実行
- エラーが解消されたことを確認して帰宅
上記の2番以降の運用は、前任者の退職により私のみが対応できる状態でした。
毎月エラー内容が違うことから手順書作成・引継ぎもままならず、私が経理の知識を頼りに対応するという、いわゆる属人化状態でした。
問題の発生
時は2019年11月。
消費税が8%から10%となった翌月、消費税対応後に初めてAプログラムを実行する日でした。
事前に行っていた消費税10%への対応は以下の通りでした。
- 会計システムベンダーへ確認をとったうえで、会計システムへ消費税マスタを追加
- Bシステムのサンプルデータを用いて、消費税が10%で連携されることをテスト
これらの対応を行っていたことで、「大きな問題は発生しないだろう」という甘い考えのもと、いつも通りBシステムの締め完了を待っていました。
そしてBシステムの締めが完了し、会計システムよりAプログラムを実行しました。
しかし、処理完了後、完成した仕訳を見ると、
- 一部に消費税が付与されず、貸借が合わなくなったレコード
- 消費税が8%のままとなったレコード
このような事象が大量に発生した、見るも無残なデータが生成されました。
このままでは売上が会計に反映されません。つまり売上が"飛ぶ"わけです。
通常のリミットは翌営業日中であり、早急な原因特定が必要でした。
この時点ですべてを察し、上司にエスカレーション（なお深夜なので返信無し）をしつつ、原因調査を開始しました。
難航する原因調査
この時点で、消費税マスタ追加だけでは不十分＝Aプログラムに何かしら問題があることは察しが付いていました。
しかし、
- 生成されたデータは100万行近く、そのうち問題があったレコードは数千行を超える
- Aプログラムには前述の通り数千行のIF分岐が仕込まれており、その分岐ひとつひとつを追う必要がある
- 自分自身のIT部門での経験も浅く、深夜のため判断力も読解力も鈍っている状況である
このような状況下で、調査は難航しました。
最終的には、プログラムを眺めているだけでは埒が明かず、
- 原因と思しきところを修正
- 再実行（実行中にAプログラムを再確認）
- 結果確認
- 再修正・再実行
を数回繰り返したところで、朝が来ました。
原因の判明と解消
朝になり、改めて上司へ説明をしつつ、後続の経理部門への遅延のお詫びを行ったうえで、引き続き原因調査を行っていました。
深夜から続く確認・突合を進めた結果、いくつかの原因が見えてきました。
- 一部の項目で、マスタではなくAプログラム上のハードコードで消費税を付加するパターンがあること
- そのパターンも複数種類あり、8%と10%を混在させる必要がある特殊なケースもあること
これらを考慮しつつAプログラムを改修することで、最終的に想定通りの仕訳にたどり着くことが出来ました。
事象が発生してから20時間以上は経っていたと思います。
結果として、後続の経理業務を遅延させ多大な迷惑をかけてしまいましたが、売上を飛ばすという最悪の事態だけは免れることができました。
本件で問題だったこと
一言で言えばテスト不足です。
- Bシステム側からは「消費税10%の項目を追加しただけ」との回答があり、その項目がAプログラムで変換できればよいというテストしかしていなかった
- 最終的に問題となった特殊なパターンは誰も存在すら認知できておらず、仕様の理解が甘かった
- （言い訳）会計システム更改プロジェクトの担当をしており、佳境に差し掛かったあたりだったため、検証に割く時間が取れなかった
- （言い訳）他にお願いできる人もおらず、この状態が当時の自分の限界だった
この対応の大変さを理解し、何とか時間を捻出して全件テストを行っていれば、当日に気付くという事は避けられたはずです。
改修が間に合ったかは置いておき、少なくとももっと早めに検知できたケースだったとは反省しています。
余談ですが、このAプログラムは半年後に更改プロジェクト内で改修され、無事消費税ロジックも全てマスタ化されました。
ただ、たまたま更改プロジェクトで見直す予定があったから良いものの、その時に"現行踏襲"をしていたら今でも同様の問題を抱えていた可能性があります。
このケースから言いたかったこと
冒頭で触れた通り、税率なんてマスタ管理されていて当然と思われがちです。
しかし、世の中にはそうなっていないシステムが転がっていることがあります。
そしてこのようなケースは、費用対効果が見えづらいために予算を付けづらく、簡単な仕組みに変えることすらできていない可能性があります。
「消費税減税のシステム対応なんてすぐできる」という言葉を耳にしたときに、簡単ではないシステムもあるんだという事が、誰かの頭の片隅に残ったらいいなと思います。