当社の開発部の回答はこうでした。顧客から正しい計算式を提示しない限り一切対応しない。当時、私は運用部署に所属していて、ユーザ窓口であり、且つ顧客の業務をサポートするのがお仕事でした。仕様は分からない、開発部は動けない、そこで私は以下の提案をしました。言うことをやろうと考えました。120店舗分の日報の修正された正しい数値を調査してもらうように依頼しました。1ヶ月間お願いした理由は、毎日、全ての収支項目の数値が発生するとは限らず(2週間1回しか発生しないとか)、ある程度長期的に見ないと考慮漏れが発生するからです。実際には調査するのも大変なので15日分で勘弁してくださいと根をあげられました。個のサンプリングデータが得られました。個(1店舗あたり20個の収入、20個の支出項目がある)そこからは当てずっぽうです。ような計算式を適当に作って算出された数値と正しい数値を120店舗分比較しながら考察しました。送られきた生データの数値と同じか外税か、内税か旧システムの開発会社や店舗への問い合わせ、当社の関係者に協力してもらい、その結果、以下の誰も知らなかった仕様が判明しました。採用店舗は外税でデータが送られてきていたこれらの要因による数値の誤差を考慮に入れて、さらに計算式を当てずっぽうで作っていきました。以上の店舗で正しい数値が得られました。ここで一旦、調査を打ち切り、これまでに判明した内容からプログラム修正を行ってリリースし、その後、さらに同様のサンプリング調査を行うことにしました。程度は私が把握していない差異が発生する可能性がありました。実際には店員さんが本当に運用ミスをすることもありますし、もともと1日1〜2店舗は何らかの要因で修正していたそうなので問題にはなりませんでした。経理担当者からも問題ないとの回答を得て、日次売上報告書のタダシイ仕様を基本設計書に反映し、このトラブルは収束しました。この運用サポートは、私の中では大きな達成感がありましたが、顧客からも社内からも特に評価されないものでした。基幹システムの管轄部署は情報システム部なので、経理部が困ってても特に関与しません。社内からもお節介なことをやってるな程度の扱いでした。それでも経理担当者やパートタイマーの方々の業務が軽減されたことには間違いありません。活用する目的は業務の効率化や生産性の向上なので、評価の如何や正否に関わらず、システムの不備に立ち向かって行く人間の意志が大事だったかなと今になって思い返したりします。