案件が249件に増殖した謎、原因は返品処理の設計ミス

案件が勝手に増殖した。

ある顧客対応の管理画面を開いたとき、担当者は自分の目を疑いました。表示されていた案件数は249件。しかし実際に対応が必要なものを数え直すと、生きている案件はわずか13件しかありませんでした。実態の20倍近い件数が画面に居座っていたのです。

249件のうち、生きていたのは13件だった

この手の異常は、たいてい「入力ミスが積み重なったのだろう」と片付けられがちです。担当者が案件を閉じ忘れた、重複登録してしまった、といった運用側の問題として処理されるケースが多い。しかし今回は違いました。誰かの不注意ではなく、システムの挙動そのものが案件を増やし続けていたのです。

249件という数字は、単なるノイズではありません。対応履歴を追おうとした担当者が、どの案件が本当に動いているのかを判断できなくなるレベルの水増しです。顧客から「前回の件はどうなった」と聞かれても、どの案件を指しているのか特定できない。これは管理画面の見た目の問題ではなく、業務そのものが機能不全に陥りかけていたことを意味します。

返品するたび、対応が別物になっていた

調査の結果わかったのは、返品が発生するたびにシステムが新しい案件を自動的に切り出していたという事実でした。本来、ひとつの顧客対応は一本の履歴として続くべきものです。ところが返品という一つのイベントをきっかけに、既存の案件とは別に真新しい案件が生成される仕組みになっていたのです。

顧客が同じ商品について何度か返品や交換をやり取りしていた場合、そのたびに履歴が切り離され、対応の文脈が失われていきます。担当者からすれば「さっきまで話していた件」が突然別案件として扱われ、過去のやり取りを参照できなくなる。これは単に案件数が増えるという表面的な問題ではなく、対応品質そのものを損なう根本的な欠陥でした。返品対応が多い顧客ほど、案件が枝分かれして増え続ける構造になっていたのです。

なぜ誰も気づけなかったのか

ここまで深刻な水増しが、なぜ長らく発覚しなかったのでしょうか。理由は二つの見えにくい設計の穴にありました。

一つは、販売履歴の画面上で返品元の取引と返品自体の取引が区別されずに並んでいたことです。担当者が履歴を見ても、どれが元の販売でどれが返品なのか一目でわからず、案件が分裂している事実そのものに気づきにくい表示になっていました。この点については、返品元と返品を明確に区別して表示する改修が別途行われ、6件のファイルにわたる表示ロジックの見直しが入りました。

もう一つは、返品を元の販売とペアリングして紐づける処理が、一部の品目にしか適用されていなかったことです。対象外の品目で返品が起きると、ペアリングによる整合性チェックが働かず、案件の分裂が検知されないまま放置されていました。この対象範囲を全品目に拡大する修正も併せて行われています。

つまり、案件が増殖する根本原因が一つあったうえに、それを発見する手段そのものが不完全だったという二重の見落としが重なっていたわけです。数字の異常が長期間放置された背景には、こうした「見えているつもりで見えていない」設計の積み重ねがありました。

案件を使い回す、たった一つの是正

対応策として選ばれたのは、複雑な仕組みを新設することではなく、返品が発生しても案件を新規に切り出さず、既存の案件を継続して使い回す処理へと改めることでした。9件のファイルにわたり、288行の追加と12行の削除という規模の修正が行われ、返品イベントが案件のライフサイクルを分断しないように処理の起点を書き換えています。

この一点の是正によって、案件数は249件から13件まで収束しました。対応履歴も一本化され、顧客ごとのやり取りが時系列で追えるようになっています。原因を特定の処理に絞り込んだうえで手を入れたからこそ、大掛かりな改修を経ずに実態に即した件数へ戻すことができたのです。あわせて、記録として根本原因と母数、是正内容をまとめたドキュメントも整備され、同種の異常が再発した際にすぐ参照できる状態にしています。

件数の異常は、運用ではなく設計を疑う

この事例が示す教訓は、案件数や履行件数が想定より大幅に多い場合、まず運用のミスを疑うのではなく、イベント発生時にシステムがどう振る舞っているかを確認すべきだということです。返品、キャンセル、再発注といった「一つの取引に付随する二次的なイベント」は、設計時に見落とされやすく、放置すると件数が指数的に膨らみます。

自社のシステムで案件数や問い合わせ件数が実感と大きくずれていると感じたら、まず疑うべきは担当者の入力精度ではなく、特定のイベントが新しいレコードを生み出していないかという設計上の挙動です。表示上の区別や紐づけ処理が不十分だと、異常はさらに長く見過ごされます。件数という一見単純な指標の裏には、業務プロセスの分断リスクが隠れていることを、今回の事例は教えてくれます。