💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
目次
- 名寄せの土台を「先に全部消す」という自然な手順
- 35万件の読み込みで力尽き、土台が空っぽになった事故
- エラーを出さずに静かに間違え続ける「見えない消失」
- 「消してから作る」を改め、古い状態で動き続ける設計へ
- 壊すのは一瞬で、作るには時間がかかる
名寄せの土台を「先に全部消す」という自然な手順
この回は、実際に起きた事故の話です。
被害の範囲は限られていましたが、気づくのが遅れていれば、大きくなっていました。
そして、原因になった作りは、ごく普通の書き方でした。
どこまでが普通で、どこからが事故だったのか。
この回は、その境目の話でもあります。
名寄せには、下ごしらえがあります。
会社名を、比べられる形に整える作業です。
- 株式会社を取り除く。全角と半角を揃える。
- 中黒や記号を落とす。空白を詰める。
- 住所も同じように整えます。
こうして作った「比べるための文字列」を、あらかじめ全件分用意しておきます。判定のたびに毎回作っていては間に合わないからです。
先に作って、しまっておく。
問題は、この下ごしらえの作り方を変えたときです。
たとえば、記号の扱いを1つ変える。
それだけで、全件分作り直す必要が出てきます。
作り直す処理は、こういう手順でした。
まず、いま入っている下ごしらえを全部消す。
次に、企業データを読み込む。
そして、新しい規則で作り直して、しまう。
自然な手順に見えます。
古いものと新しいものが混ざったら困るので、先に消すのは、理にかなっています。
この下ごしらえは、名寄せの土台です。
ここが揃っていないと、同じ会社を同じ会社と見抜けません。
つまり、下ごしらえが欠けている状態は、名寄せが動いていない状態と、ほぼ同じです。
そして、名寄せが動いていないことは、画面のどこにも表示されません。
「一致しませんでした」という結果が返るだけです。
35万件の読み込みで力尽き、土台が空っぽになった事故
ある日、この処理が最後まで終わりませんでした。
途中で止まりました。理由は、読み込み方にありました。
企業データを、35万件、一度に読み込もうとしていたのです。
数千件のころは、それで足りていました。
一度に読んで、順に処理して、しまう。
素直な作りです。
35万件になると、一度に抱えきれません。
抱えようとして、力尽きます。
ここで、まずいことが起きます。
止まったのは、読み込みの最中でした。
つまり、消す作業は、もう終わっています。
古い下ごしらえは、消えている。
新しい下ごしらえは、まだ、ない。
このときシステムの中には、比べるための文字列が、1件も残っていませんでした。
積み上げてきた土台が、まるごと空でした。
エラーを出さずに静かに間違え続ける「見えない消失」
止まったこと自体は、記録に残っていました。
処理が完了しなかった、という1行です。
ただ、その1行が意味するところまでは、書いてありません。
「途中で止まりました」と「途中で止まったので、いまデータが欠けています」は、まったく違う知らせです。
前者は、あとで流し直せば済む話に見えます。
後者は、いますぐ手を打つ話です。
書いてあったのは、前者でした。
記録は、事実を書いていました。
ただ、事実の重さまでは、書いていませんでした。
この状態でも、システムは動きます。
企業データ本体は、無事です。
画面も開きます。検索もできます。
ただ、名寄せの判定だけが、何も見つけられません。
比べるための文字列が、ないからです。
新しく取り込んだ会社が、既存の会社と一致しない。
同じ会社が、別の会社として増えていく。
エラーは出ません。
「一致するものがありませんでした」と、静かに答えるだけです。
第2話と同じ形の怖さです。
失敗しているのに、失敗の顔をしていない。
気づいたきっかけは、名寄せの結果でした。
新しく取り込んだ会社が、既存の会社と一致しない件数が、急に増えていました。
その日だけ、極端に多い。
最初に疑ったのは、取り込んだデータのほうでした。
その日のファイルだけ、何かが特殊なのだろう。
自分たちの側ではなく、相手が変わったと考えるほうが自然です。
中身を見ました。いつもと変わりません。
自分たちの土台が消えているという可能性は、疑う順番の、いちばん最後にありました。
土台は、普段、疑う対象にすら入っていないからです。
一致しない理由を1件ずつたどっていくと、比べるための文字列が存在しないところに行き着きました。
「消してから作る」を改め、古い状態で動き続ける設計へ
直したことは、2つあります。
ひとつは、読み込み方です。
35万件を一度に抱えるのをやめ、少しずつ取り出しては処理する形に変えました。
どれだけ件数が増えても、一度に抱える量は変わりません。
もうひとつが、順番です。
「消してから作る」を、やめました。新しい下ごしらえを、先に作ります。
全部できあがったことを確認してから、古いものと入れ替える。
こうすると、途中で止まっても、古いものがそのまま残ります。
判定は、少し古い規則のまま続きます。
それは正しくないかもしれませんが、何もないよりは、はるかにましです。
この考え方には、名前を付けました。
「途中で止まっても、前の状態で動き続けられるか」
新しい処理を作るとき、必ずこれを聞きます。
止まらないように作るのは、無理です。
サーバーは再起動しますし、回線は切れますし、想定より大きいデータは、いつか来ます。
止まらないようにするのではなく、止まっても壊れないようにする。
そのためには、順番を変えるだけで済むことが、思ったより多くありました。
この件のあと、似た作りを全部見に行きました。
「作り直す」と名前の付いた処理は、いくつもあります。
集計をやり直す。索引を作り直す。一時的な表を組み直す。
どれも、最初に消していないかを確認しました。
消していたものは、順番を入れ替えました。
入れ替えられないものには、「途中で止まったら分かる印」を付けました。
作業中であることを記録し、最後まで終わったら消す。
その印が残っていたら、前回は完走していない。
そして、その印を、朝の確認に加えました。
夜間に動く処理は、誰も見ていない時間に走ります。
完走したかどうかを、翌朝に人が知る必要があります。
以前は、失敗したときだけ知らせていました。
止まり方によっては、失敗の知らせも出ません。
力尽きた場合、知らせる処理まで到達しないからです。
だから、成功したことを知らせる形に変えました。
知らせが来ないことが、異常です。
壊すのは一瞬で、作るには時間がかかる
「作り直す」という言葉は、前向きに聞こえます。
古いものを捨てて、新しく良いものにする。
そこに反対する理由はありません。
けれど手順に落とすと、たいてい「壊してから作る」になります。
壊すのは一瞬で、作るには時間がかかる。
そのあいだ、何も無い時間が生まれます。
うまくいっているうちは、誰もその時間に気づきません。
気づくのは、そこで止まった日です。
この「何も無い時間」は、他の作業にもあります。
古い形式から新しい形式へ移すとき。
置き場所を変えるとき。
名前の付け方を変えるとき。
どれも、途中に「どちらでもない状態」が生まれます。
その時間を、どれだけ短くできるか。
短くできないなら、その時間でも動くようにできるか。
作業の設計とは、だいたい、この2つを考えることでした。
そして、うまく設計された作業ほど、何も起きなかったように見えます。
「無事に終わりました」としか、記録に残りません。
何も起きなかったことを、成果として説明するのは、なかなか難しい。
今回、被害が小さく済んだのは、気づくのが早かったからです。
夜間の処理が完走しなかったことに、名寄せの結果をたどって、翌朝気づきました。
もし気づかずに数日過ぎていたら、そのあいだに取り込まれた会社は、すべて重複として登録されていたはずです。
そして、重複した会社を後から統合するのは、簡単ではありません。その苦労は、第20話で書きます。
35万件を、一度に抱えようとしていました。
抱えきれずに手を離したとき、棚は、すでに空になっていました。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第9話「見えない門番」
送ったはずのデータが、突然、届かなくなりました。
こちらの作りは、何も変えていません。
相手の作りも、変わっていません。
あいだに、誰かが立っていました。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
