bookこの広告は、90日以上更新していないブログに表示しています。システム(ドラッグストアのバックエンドシステム)のリプレース案件に携わりました。昔の同僚に聞いたお話では、私が開発に携わったシステムが今ちょうど新システムにリプレースされる見通しのようです。その頃を懐かしみながら書いてみます。して「日報」と呼んでいました。内(厳密には店舗の金庫へお金が移動することもある)にある現金収支の生データが送られてきて、その生データを集計し、帳票のフォーマットで収支項目を出力、又は合計値を計算するというものでした。システム的にも複雑な仕組みではなく、帳票に出力する収支項目も一般的なものです。これが大きなトラブルを引き起こしました。基幹システムのリプレース後、出力された日報には数値の間違いが目立ちました。集計出力したレシートを検算して、数値の正当性を確認していました。旧システムでは、帳票の間違いが1日1〜2店舗程度の頻度だったのに対して、リプレース後は1日数十店舗に増加したようです。実際の修正作業はパートタイマーさんが行っていましたが、その業務が追いつかず、日報検算後の経理データへの反映が大幅に遅れ、月次業務の運用に支障をきたしていました。当社でも、経理部から間違い内容が伝えられ、プログラムを修正し対応しました。「日次売上高」という項目の間違いが目立ちました。支出」の金額で良さそうな気がしますが、どうもそうではないようです。間違い内容からある収支項目の加減算を行った結果、今度はそれまで正しかった店舗の数値がおかしくなり、そこを直すと、また違う店舗の数値がおかしくなるという状況が発生しました。それを2回繰り返した後、そもそもの正しい仕様を再確認する必要性に迫られました。調査の結果、以下の内容が判明しました。現在の経理担当者は日次売上高の計算式を知らない検算や修正をするパートタイマーさんは、レシートの数値と比較して検算した結果、間違っていることは分かるが、基幹システムでどのような処理が行われているか分からないので計算式を提示できない旧システムの仕様は分からない旧システムの帳票の開発会社は、開発費削減のためにドキュメントを作成しないという契約で開発したため、仕様はソースコードにしかない(顧客も了承済みだった)旧システムの帳票のソースコードは提示できないそれを踏まえた上で顧客の要件はこうでした。日次売上高の計算式は分かりません。