SIer で働いていた頃、流通小売系基幹システム(ドラッグストアのバックエンドシステム)のリプレース案件に携わりました。昔の同僚に聞いたお話では、私が開発に携わったシステムが今ちょうど新システムにリプレースされる見通しのようです。その頃を懐かしみながら書いてみます。
その顧客は店舗の1日の売上を集計した帳票を作成し、その帳票を「日次売上報告書」、略して「日報」と呼んでいました。システムとしては、店舗の POS 内(厳密には店舗の金庫へお金が移動することもある)にある現金収支の生データが送られてきて、その生データを集計し、帳票のフォーマットで収支項目を出力、又は合計値を計算するというものでした。
システム的にも複雑な仕組みではなく、帳票に出力する収支項目も一般的なものです。しかし、これが大きなトラブルを引き起こしました。
基幹システムのリプレース後、出力された日報には数値の間違いが目立ちました。顧客は基幹システムで処理が行われた後に出力された帳票と直接 POS が集計出力したレシートを検算して、数値の正当性を確認していました。旧システムでは、帳票の間違いが1日1〜2店舗程度の頻度だったのに対して、リプレース後は1日数十店舗に増加したようです。実際の修正作業はパートタイマーさんが行っていましたが、その業務が追いつかず、日報検算後の経理データへの反映が大幅に遅れ、月次業務の運用に支障をきたしていました。
もちろん当社でも、経理部から間違い内容が伝えられ、プログラムを修正し対応しました。特に「日次売上高」という項目の間違いが目立ちました。名前から判断すると、「収入 - 支出」の金額で良さそうな気がしますが、どうもそうではないようです。間違い内容からある収支項目の加減算を行った結果、今度はそれまで正しかった店舗の数値がおかしくなり、そこを直すと、また違う店舗の数値がおかしくなるという状況が発生しました。それを2回繰り返した後、そもそもの正しい仕様を再確認する必要性に迫られました。調査の結果、以下の内容が判明しました。
- 現在の経理担当者は日次売上高の計算式を知らない
- 検算や修正をするパートタイマーさんは、レシートの数値と比較して検算した結果、間違っていることは分かるが、基幹システムでどのような処理が行われているか分からないので計算式を提示できない
- 旧システムの仕様は分からない
- 旧システムの帳票の開発会社は、開発費削減のためにドキュメントを作成しないという契約で開発したため、仕様はソースコードにしかない(顧客も了承済みだった)
- 旧システムの帳票のソースコードは提示できない
それを踏まえた上で顧客の要件はこうでした。
日次売上高の計算式は分かりません。でも、間違っています。直してください。
当社の開発部の回答はこうでした。
顧客から正しい計算式を提示しない限り一切対応しない。
当時、私は運用部署に所属していて、ユーザ窓口であり、且つ顧客の業務をサポートするのがお仕事でした。仕様は分からない、開発部は動けない、そこで私は以下の提案をしました。
現行システムの帳票が出力する数値と実際に修正された正しい数値を 比較することで計算式は私が作る
○ + □ = 5 で、2, 3, 4 という数字が与えられたら 2 + 3 = 5 ですねと言うことをやろうと考えました。1ヶ月間、経理担当者に120店舗分の日報の修正された正しい数値を調査してもらうように依頼しました。1ヶ月間お願いした理由は、毎日、全ての収支項目の数値が発生するとは限らず(2週間1回しか発生しないとか)、ある程度長期的に見ないと考慮漏れが発生するからです。実際には調査するのも大変なので15日分で勘弁してくださいと根をあげられました。
ここで 1800 個のサンプリングデータが得られました。
120店舗 * 15日 = 1800 個(1店舗あたり20個の収入、20個の支出項目がある)
そこからは当てずっぽうです。A + ( B - C - D) * 0.05 + E のような計算式を適当に作って算出された数値と正しい数値を120店舗分比較しながら考察しました。
- どの店舗にいくら差異があるか
- 差異が出ているのはどの収支項目か
- 同じ収支項目に数値がある別の店舗で差異は出ているか
- POS から送られきた生データの数値と同じか
- 外税か、内税か
旧システムの開発会社や店舗への問い合わせ、当社の関係者に協力してもらい、その結果、以下の誰も知らなかった仕様が判明しました。
- ある収支項目に対する POS のキー入力を店舗の店員さんが誤解して運用していた
- ある店舗では、POS の収入項目に対するキーが物理的に足りないために、支出項目を収入項目として運用していた(旧システムでは特定店舗だけ支出項目を収入項目として扱うように例外対応していた)
- ある収支項目は、本当の意味の収入/支出ではなく別の用途の数値を入れるハコとして使用していた
- T 社製 POS の採用店舗は内税、K 社製 POS の採用店舗は外税でデータが送られてきていた
これらの要因による数値の誤差を考慮に入れて、さらに計算式を当てずっぽうで作っていきました。根拠を説明できない計算式ではありましたが、サンプリングデータの 90% 以上の店舗で正しい数値が得られました。しかし、残りの 10% はどうしても分かりません。ここで一旦、調査を打ち切り、これまでに判明した内容からプログラム修正を行ってリリースし、その後、さらに同様のサンプリング調査を行うことにしました。
リリース後、残りの 10% 程度は私が把握していない差異が発生する可能性がありました。しかし、実際には店員さんが本当に運用ミスをすることもありますし、もともと1日1〜2店舗は何らかの要因で修正していたそうなので問題にはなりませんでした。経理担当者からも問題ないとの回答を得て、日次売上報告書のタダシイ仕様を基本設計書に反映し、このトラブルは収束しました。
この運用サポートは、私の中では大きな達成感がありましたが、顧客からも社内からも特に評価されないものでした。基幹システムの管轄部署は情報システム部なので、経理部が困ってても特に関与しません。社内からもお節介なことをやってるな程度の扱いでした。
それでも経理担当者やパートタイマーの方々の業務が軽減されたことには間違いありません。IT を活用する目的は業務の効率化や生産性の向上なので、評価の如何や正否に関わらず、システムの不備に立ち向かって行く人間の意志が大事だったかなと今になって思い返したりします。
