💡Listoru(リストル)は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
正常終了しているのに「減らない」リスト
リストルには、企業データに国の法人番号を突き合わせる機能があります。
法人番号は、国が会社に1つずつ割り当てている13桁の番号です。
同じ会社名が全国にいくつあっても、番号は重なりません。
株式会社が前に付くか後ろに付くかも、番号には関係ありません。
つまり、会社名や電話番号での照合と違って、「同じ会社かどうか」を迷わずに決められる。
会社名と住所を手がかりに、公開されている一覧から番号を探して、付ける。数十万件を一度に処理することはできないので、500件ずつ、区切って回しています。
ある日、何度回しても番号の付かない企業が残っていることに気づきました。
処理は毎回、正常に終わっています。
最後まで走り、件数が表示され、完了と出ます。
エラーは、一度も出ていません。
にもかかわらず、番号の付かない企業が、いつまでも減りきらない。
回すたびに、完了の表示を確かめて、残りの一覧に目をやります。
昨日も見た気がする社名が、今日も同じ場所に並んでいる。
その繰り返しでした。
名前が特殊で見つからないのだろう。
最初はそう思いました。
実際、そういう会社はあります。
屋号と登記名が違う。支店名が入っている。
旧社名のまま登録されている。
そういう会社は、機械では見つけられません。
だから、残るものは残る。
そう考えて、いったん片付けかけました。

「見つからなかった」のではなく「探されていなかった」
ただ、残った一覧を眺めていて、また手が止まりました。
ごく普通の会社名が、混じっているのです。
読み方に迷うところもない。支店でもない。住所もはっきりしている。
その会社を、手で調べてみました。
会社名で探して、住所で確かめる。
それだけの、普通の探し方です。
番号はありました。
探すまでもなく、あっさり見つかりました。
1件だけなら偶然です。
何件か試して、全部見つかったところで、話が変わりました。
見つからなかったのではない。
探されていなかったのです。
この違いは、大きいものでした。
見つからなかったのなら、探し方の問題です。
比べ方を賢くすれば、いつか見つかります。
探されていなかったのなら、探し方は関係ありません。
どれだけ賢くしても、その会社の順番は来ません。
私たちは、しばらく前者の方向で改善を考えていました。
社名の整え方を細かくする。住所の突き合わせ方を工夫する。
どれも、意味のない作業でした。
処理するたびに「列が縮む」ロジックの罠
ここから、調べ方を変えました。
「なぜ番号が付かないのか」ではなく、「その会社は、いつ処理されたのか」を見る。
処理の記録を、最初の回までさかのぼって確かめました。
答えは、拍子抜けするほど単純でした。
一度も処理されていませんでした。
原因は、区切り方にありました。
処理は、こういう順番で動いています。
まず、「まだ番号の付いていない企業」を並べる。
その列から、「何番目から500件」と数えて取り出す。
取り出した500件を処理する。
次は「その次の500件」を取りに行く。
紙のリストを上から順に片付けていく感覚です。
ごく自然な作りに見えます。
ところが、この処理には、ひとつだけ特徴があります。
処理に成功すると、その会社には番号が付きます。
番号が付いた会社は、次からは「まだ付いていない企業」ではなくなります。
つまり、列から抜ける。
一度目に500件を処理したとします。
そのうち6割に番号が付いたとします。
300社が、列から抜けます。
列が、300社ぶん縮む。
そして二度目は、「501番目から」を取りに行きます。
縮んだあとの列の、501番目を。

呼び出し番号だけが頭上を通り過ぎる
列は縮んだのに、数え方は縮んでいません。
一度目に処理した500件のうち、番号が付かなかった200件は、列の先頭に戻ってきます。その後ろに、まだ手つかずの500件が続きます。
そして二度目は、その列の501番目から取ろうとする。
けれど列は、もう700件しかありません。
取り出せるのは、最後の200件だけ。
あいだの300件は、まるごと飛ばされます。
1,000社で試算すると、飛ばされる企業は――
300社。
1,000社のうちの、300社です。
列の3割が、呼ばれないまま立ち続けている計算になります。
しかも、飛ばされた300社は、次の回に拾われるわけではありません。
三度目は「1001番目から」を取りに行きます。
列は、さらに短くなっています。
一度飛ばされた企業は、次も、その次も、呼ばれない。
飛ばされた企業は、列を離れたわけではありません。
呼ばれる番号のほうが、頭の上を通り過ぎていくだけです。
そして画面には、ずっと「完了しました」と出ています。
件数も出ています。処理した件数は、確かに正しいのです。
ただ、処理していない件数を、誰も数えていませんでした。
処理の記録には、こう残ります。
対象500件。処理500件。付与300件。
どの数字も、正しい。
どこにも矛盾がありません。
足りないのは、この1行です。
「今回、一度も見られなかった件数」
その数を出すには、列の全体を知っていなければなりません。
区切って処理する仕組みは、全体を見ないために作られています。
全体を見ないための仕組みが、全体が減っていることに気づけない。
当たり前といえば、当たり前でした。
数えるのをやめ、「しおり」を挟む

直し方は、数えるのをやめることでした。
何番目か、ではなく、どこまで見たかを記録する。
最後に確認した企業より先だけを、次に取る。
会社には、それぞれ固有の番号が振られています。
その番号を、しおりとして使いました。
こうすると、途中で何社抜けようと、しおりの位置は動きません。
列が縮んでも、こちらの立っている場所は変わらない。
同じ条件で試算し直すと、飛ばされる企業は――
0社。
正しい処理同士が組み合わさった「盲点
似た作りが他にもないか、全部見に行きました。
区切って回す処理は、この機能だけではありません。
「処理すると対象から外れる」ものと、「外れない」ものがある。
外れないものは、今までどおりで問題ありません。
外れるものだけを、しおり方式に直しました。
見分け方は、こう考えます。
処理したあと、その行はまだ対象一覧に残るか。
残るなら、列は縮みません。何番目で数えても大丈夫です。
残らないなら、列は縮みます。数えてはいけません。
言葉にすれば単純ですが、作っているときには、まず意識しません。
区切って処理する、という部分と、処理すると対象から外れる、という部分は、たいてい別々の日に書かれます。
それぞれ単体では、間違っていません。
組み合わさったときに、はじめて意味が変わります。
あとで足した1つの条件が、先に書いた処理の前提を壊す。
しかも、壊れたことは、どちらの側からも見えません。
区切る側は、正しく数えています。
外す側は、正しく外しています。
正しいもの同士が組み合わさって、間違いが1つ、できあがっていました。
この形は、他の場所でも何度か見つかりました。
黙って成功するエラーを見つけ出す
順番待ちの列は、後ろの人が抜けても、こちらの位置は変わりません。
抜けるのが前の人だと、話が変わります。
前の人が抜けたぶん、列は前へ詰まる。
けれど呼ばれる番号は、前へ詰まってくれない。
探しに行く方法は、ひとつだけ見つけました。
数が合っているかを、確かめることです。
- 対象は何件あったのか。
- そのうち、何件を処理したのか。
- 残りは、なぜ処理されなかったのか。
3つ目が答えられない処理は、たいてい何かを落としています。
いまは、この3つ目を必ず出すようにしました。
出せない作りのものは、出せるように直しました。
エラーで止まるものは、直せます。
黙って成功するものは、探しに行かないと見つかりません。
300社は、ずっと並んでいました。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第3話「47ギガバイト」
消したはずの記録が、消えていませんでした。
ファイル1つで、47ギガバイト。
スイッチは、たしかに付いていたのですが。
━━━━━━━━━━━━━━━━━━━━━━━━
⚙️リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」

営業リスト収集ツール「Listoru(リストル)」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化!Listoruは270以上のWebサイトから企業リストを自動収集。今すぐ無料で体験!www.listoru.com


