💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
目次
- 会社を「同じ」と見抜くための候補集め
- 説明責任を果たすための「まるごと保存」
- 1件161キロバイト。全体を鈍らせる「見ない記録」
- 運用に入ってから「一度も開いていない」という事実
- 40〜50倍の削減と、片付けにかかる数週間の手間
- 残す判断は1人、消す判断は全員。「念のため」の罠
- 机の上に「下書き」を積んだままにしない
会社を「同じ」と見抜くための候補集め
リストルには、同じ会社を同じ会社と見抜く機能があります。
世の中の企業データは、書き方が揃っていません。
株式会社が前に付く会社と、後ろに付く会社。
㈱と書かれているもの、（株）と書かれているもの。
本社の住所が入っているもの、営業所の住所が入っているもの。
ビル名まで書いてあるもの、番地で終わっているもの。
これらを人が見れば、同じ会社だと分かります。
機械には、分かりません。
だから、判定します。
会社名を比べ、住所を比べ、電話番号を比べ似ている度合いを点数にして、
確信があれば統合し、迷ったら人の判断に回す。
このとき、機械は必ず「候補」を集めます。
この会社に似ている可能性のある会社を、まとめて引っぱってくる。
その中から順に比べていく。
候補は、1社とは限りません。
よくある社名だと、何十社も並びます。
「同じ読みの別会社」が全国にいくつもある業種もあります。
この判定の記録を、私たちは残していました。
説明責任を果たすための「まるごと保存」
なぜこの会社を「同じ」と判断したのか。
なぜこの会社は「保留」にしたのか。
あとで説明できるようにしておきたい。
おかしな統合が起きたとき、原因を追えるようにしておきたい。
その考え自体は、間違っていません。
残し方は、こうでした。
判定に使った候補の一覧を、まるごと保存する。
候補として引っぱってきた会社の情報を、点数も、比較の中身も、全部。
1件の判定につき、1つのかたまりとして。
説明できるように、という目的に対して、全部残すのは、いちばん確実で、いちばん考えなくて済む方法でした。
1件161キロバイト。全体を鈍らせる「見ない記録」
ある日、データベースの中身を大きい順に見ていて、
その記録の欄が上位に来ていることに気づきました。
1件あたりの大きさを測りました。
161キロバイト。
測るまでは、この記録の大きさを、誰も意識していませんでした。
1件がどれくらいかを見たことがなかったからです。
保存する処理を書いたときには、中身の量ではなく、残すかどうかだけを考えていました。
結論そのものは、ごく短いものです。
同じ会社か、違う会社か、保留か。
どの会社と結びついたか。
点数はいくつだったか。
数十文字あれば足ります。
その数十文字を出すために参照した材料が、161キロバイトありました。
数十文字は、付箋1枚に収まる量です。
161キロバイトは、その付箋のために、机いっぱいに広げた資料の山でした。
そして、判定は1件では終わりません。
数万件、数十万件と処理していきます。
掛け算をした結果が、そのまま容量になっていました。
容量が増えると、困るのは置き場所だけではありません。
データベースは、大きくなるほど動きが鈍くなります。
検索するときに読む量が増える。
控えを取るのに時間がかかる。
別の場所へ移すのにも時間がかかる。
つまり、見ない記録のために、毎日の動作が少しずつ遅くなっていました。しかも、その遅さは、どの機能のせいなのか分かりません。
全体が、なんとなく重い。
いちばん見つけにくい形の遅さです。
運用に入ってから「一度も開いていない」という事実
どこかが壊れていれば、そこを直しに行けます。
全体が重いだけのときは、どこへ直しに行けばいいのか、分かりません。
ここで、当たり前の質問を自分たちにしました。
この記録を、これまで何回見たか。
答えを出すのに、時間はかかりませんでした。
一度もありませんでした。
正確に言えば、開発中には見ています。
判定の仕組みを作っているときは、必ず見ます。
どこで点数が伸びなかったのか、材料を見ないと分からない。
けれど、運用に入ってからは、一度も開いていませんでした。
おかしな統合が起きたとき、どうしていたか。
結論と点数を見て、その場でもう一度判定を走らせていました。
そのほうが早いからです。
材料は、その場で作り直せる。
作り直せるものを、私たちは全件分保存していました。
ここに、ひとつ判断の基準が見つかりました。
もう一度作れるものか、作れないものか。
もう一度作れないものは、残します。
お客様が入力した内容。連絡した記録。人が決めた判断。
これらは、失えば戻りません。
もう一度作れるものは、残さなくてよい。
計算した結果。集計した数字。判定の材料。
必要になったら、その場で作ればいい。
この区別は、容量の話に見えて、実は「何を守るべきか」の話でした。
守るべきものと、作り直せるものが混ざっていると、どちらも同じ重さで扱うことになります。
そして、たいてい、作り直せるもののほうが量が多い。
40〜50倍の削減と、片付けにかかる数週間の手間
直したことは、単純です。
候補一覧の丸ごと保存を、やめました。
代わりに残したのは、結論と、点数と、どの項目が一致したかという短い記録だけです。
「なぜそう判断したか」は、これで十分に説明できます。
説明できないほど込み入った判定は、そもそも人が確認する「保留」に回っています。
結果として、この記録の容量は――
40〜50倍の削減。
古い記録の片付けにも、少し時間がかかりました。
すでに保存されている161キロバイトの塊が、何万件分も残っています。
一度に消すと、負荷がかかります。
第3話と同じで、大きくなったものは、消すのも大変です。
夜のあいだに、少しずつ消しました。
消し終わるまでに、それなりの日数がかかっています。
作るのは一瞬で、片付けるのは数週間。
この比率も、覚えておくべきことでした。
残す判断は1人、消す判断は全員。「念のため」の罠
消しているあいだも、判定は毎日動いています。
新しく増えるぶんは、もう軽い。
重いのは、過去に積んだ分だけでした。
この変更で、判定の結果は1つも変わっていません。
同じ会社は、同じ会社と判定されます。
保留になるものは、保留になります。
人が見る画面も、そのままです。
変わったのは、見ないものを持たなくなったことだけです。
「あとで見るかもしれない」は、強い言葉です。
捨てる判断より、残す判断のほうが、いつも安全に見えます。
残しておいて困ることは、めったにありません。
だから、残ります。
そして、増えます。
増えたことに気づくのは、たいてい容量を見たときです。
もうひとつ、厄介なことがあります。
残すのは一瞬で決められますが、消すのは、なかなか決められません。消してよいかを確認するには、誰も使っていないことを確かめる必要があります。使っていないことを証明するのは、使っていることを証明するより、ずっと大変です。
だから、判断は先送りになります。
先送りされたものは、そのまま残ります。
残す判断は1人でできて、消す判断には全員の確認が要る。
この非対称が、データを太らせていました。
机の上に「下書き」を積んだままにしない
いま、私たちは記録を残すとき、1つだけ先に決めるようにしました。
これを、誰が、どんなときに開くのか。
答えられないものは、残しません。
判断の記録については、別の形に落ち着きました。
全件を残すのではなく、人が確認した「保留」の分だけ、詳しく残します。
保留は、もともと人が見るために作られた箱です。
そこには、判断の材料があったほうがいい。
件数も限られています。
自動で処理が終わったものは、結論だけ。
人が関わったものは、材料まで。
濃淡を付けたら、量は劇的に減りました。
全件を同じ濃さで残そうとしたことが、そもそもの間違いでした。
「あとで見るかもしれない」で残したものは、だいたい、見ません。
161キロバイト。
その全部が、たった数十文字のための下書きでした。
下書きは、書いているあいだは必要です。
終わったら、机の上には結論だけが残る。
私たちは、机の上に下書きを積んだまま、次の仕事に取りかかっていました。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第6話「順番待ち」
ある処理を回しながら別の画面を開くと、
画面が固まりました。
サーバーも、データベースも、元気でした。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは270以上のWebサイトから企業リ
