請求業務を改善したつもりが、構造的に詰んでいた話

はじめに

最近請求作業を実施する担当者から、いくつかの例外対応の相談を受けました。

請求作業は私が今の会社に入社して、最初のほうに実施した業務改善でした。
その後、社内の業務の流れを1年ほど経験し、改善経験も積んできた今だからこそ、1度振り返ってみてもいいかなと思ったのですが、想像よりも根底から詰んでいてびっくりしました。
本記事はそんな振り返りをまとめたものになります。

他人の失敗談として、業務改善や見直しの際に参考になれば幸いです。

改善対象：請求作業に使用する契約情報がまとめてあるExcel（および請求作業プロセス全体）

改善の内容はざっくり↑の通りです。

コピペの排除に終始しており、契約ごとに手入力していた部分を一括処理で済ませることでミスと時間を削減できました。

「1件ずつ手入力」、「1件ごとに同じ作業」、「コピペミス、漏れ抜け多発」、こういった状況は、業務改善に初めて取り組む私にとって、確実に改善できそうな格好の的でした。しかし、目先の改善に囚われ、根本の構造に対する改善は考えていませんでした。

件の例外対応は、契約期間の延長や契約期間の途中からオプションを始める場合によく起こっていました。また、当時はコピペの排除・時短が出来た結果にとても満足していましたが、改めて現状の業務内容を見ると業務の設計から見直す必要があると感じました。

いくつかの根本的な問題点を次節から書いていきます。

現状の請求管理は、1レコード＝1企業となっています。
どういうことかというと、1企業の契約内容は全て1行にまとめられているのです。

単純化してますがテーブルのイメージです

企業No. | 企業名 | 契約口数 | 更新回数 | 契約開始日 | 契約終了日 | …

つまり、その企業の「現状」しか確認できないのです。
更新回数が3回の企業があったとして、2回目の契約時の口数が今と今と比べ増えたか減ったか、契約期間が延長したかどうか、一切追えないのです。

また契約期間について、「開始日＋1年」という関数を使っているので、延長や半年のみといった例外に弱い形になっていました。

現状では解約があったとき、更新回数の欄を【解約】と書き換えてしまっています。

これでは過去契約企業の更新回数の情報を保存できません。サービスの詳細は伏せますが、再契約も珍しくないサービスなのに、解約した企業の更新情報が消えてしまうのは困る場面が多いです。

本来真っ先に契約ステータス列などを設け、業務の設計から見直すべき部分ですが、当時は気付けませんでした。

来た時に動いていた契約テーブル（上記の例のやつ）は、契約部分を削って企業テーブルとして使います。

契約部分は、1レコード＝1契約で企業No.を外部キーとして関係性を持つ契約テーブルとして分けて管理しようと思います。

同じ企業No.のレコードの数がそのまま更新回数として機能する上、契約終了日と今の日付で契約ステータスも管理できます。
また、契約期間の例外的な延長・短縮や、オプションの途中加入についても、全てレコード内に記録しておくことができます。

業務改善に取り組む際、高速化・ミスの削減だけを考えてしまうと、非効率な形を無理やり高速化しただけのゴリ押し運用を将来に残してしまう可能性があると痛感しました。

本来第一に考えなければならないのはデータの整合性であり、その基盤さえ整っていれば真の高速化や機能追加も簡単になります。

今回の例でいえば、1レコード1企業の構造の限界、残せないデータがあること、対応しきれない例外があることなどについて、最適な構成を探すことをすべきだった、ということになります。

今後も改善記と同時に改善その後レビューも上げていこうかと思っています。人の話って、成功談より失敗談のほうが、刺さること多い気がするので。