過去の苦労話・第1８回：回収予算なんて入力してられるかｗ
うちの会社には、毎月ちょっとした“手間のかかる作業”があった。
営業20人分、数百社に及ぶ得意先の「回収予算」を作る業務だ。
得意先ごとに異なる回収サイト（翌月末、翌々月末など）をもとに、
売掛金がいつ入金されるかを見立てて、月ごとの回収額に割り振っていく。
いわば、「未来の入金を人力で組み立てる」作業だ。
この入力を、事務担当が営業のメモをもとに基幹システムへ登録していた。
もちろん業務の本丸は別にある。
売上締めの伝票処理のほうが、よほど神経を使うし、作業量も多い。
ただ、この回収予算の入力も、地味に厄介だった。
「システムでできない？」の裏側
「これ、システムでできない？」
軽く言われる一言。
でも、この手の話はたいてい単純じゃない。
SEがハマる「計算に入れたくなる罠」
真面目なエンジニアほど、こう考える。
「回収予定なんて、ロジックで出せるはずだ」
売上データと回収サイトを紐づければ、入金タイミングは計算できる。
一見、正しい。
でも現場は、そんなに綺麗じゃない。
一部だけ先に入る内金
請求とズレる入金
端数調整
営業の見込みや感覚
こうした“揺らぎ”を全部ロジックに取り込もうとすると、
システムは一気に複雑になる。
そして、あのループに入る。
「このケース、どう扱う？」
引き算という設計
そこで僕は、割り切った。
全部を説明するのはやめる。
やったことはシンプルだ。
現在の売掛残高を取得する
未請求分を除く
サイト上、まだ回収対象にならない分を除く
ここまでで止める。
それ以上は、やらない。
あえて完成させない
そして残った数字を、そのまま営業に渡した。
「ベースはこれ。違うところだけ直してください」
完成形は出さない。
叩き台だけを出す。
Webに寄せた理由
ここで用意したのは、すべてWebの画面だった。
Excelでもなければ、メールのやり取りでもない。
営業も上司も、同じ画面を見る。
その場で修正し、
その場で確認し、
その場で承認する。
この「一箇所に寄せる」という設計だけで、流れは驚くほどシンプルになった。
「無責任」がうまく回る理由
結果として、こうなった。
営業は、自分の案件だけを見て必要な修正をする。
上司は、それを確認して承認する。
承認されたデータは、そのまま基幹DBに反映される。
転記がない。
再入力もない。
だから、ミスが入り込む余地がない。
実は「責任を戻した」だけ
この仕組みは、無責任に見えるかもしれない。
でも実際には逆だ。
「この数字を作ったのは誰か？」
それがはっきりしただけだ。
責任は、現場に戻った。
少しだけ、思うこと
今では後任者が普通に運用している。
「ボタン押すだけで更新されるんで、楽ですね」
そうだろう。
でもその裏には、
計算に入れたくなる誘惑
それを断ち切る判断
現場との折り合い
そういう積み重ねがある。
そして何より、
あの“地味に面倒だった作業”が消えたときの実感は、もう自分しか知らない。
作る側は大変で、使う側は楽をする。
それでいい。
動けば官軍だ。
今日もシステムは、何も言わずに動いている。
それを見ながら、少しだけ「残念だな」と思って、コーヒーを一口すする。
コメント