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