💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
コンプライアンスを遵守するスクリーニング。ボット検知機構の事前判定プロセス
フォームへ文面を届けるツールには、最初に確認する工程があります。
その会社のフォームが、そもそも送信できる形かどうか。
送信できないと分かっているなら、文面を用意する意味がありません。
時間も、費用もかかります。
だから、先に見る。
確認する項目の中に、こういうものがあります。
そのフォームに、人であることを確かめる仕組みが付いているか。
この判定が、長いあいだ、静かに間違え続けていました。
間違いには、音の出るものと、出ないものがあります。
これは、いちばん音の出ない種類でした。
どのくらい長いあいだだったのかは、いまも、正確には分かりません。
この仕組みは、いろいろな形で使われています。
- ゆがんだ文字を読ませるもの。
- 写真を選ばせるもの。
- 四角にチェックを入れさせるもの。
いずれも、送信する前に、人の操作を1つ求めます。
機械には、その操作ができません。
できないというより、してはいけない。
自動でくぐり抜けようとするのは、相手が置いた線を踏み越えることです。
私たちは、それをしません。
だから、この仕組みが付いていたら、送らない。
そう決めていました。
データクレンジング中の異常値検知。不可視型認証のサイレントな挙動
この決めごとは、いまも変えていません。
自動でくぐり抜ける方法を探すことは、しません。
そこは、技術の問題ではなく、姿勢の問題です。
変えたのは、判定のほうだけです。
ある日、送信できなかった会社の一覧を眺めていました。
理由ごとに数えると、
「人であることを確かめる仕組みがあるため見送り」が、かなりの数を占めていました。
多さには、二通りあります。
そういうものかと思う多さと、手が止まる多さ。
これは、後のほうでした。
そのうちの何社かを、実際に開いてみました。
フォームがあります。
入力欄があります。
送信ボタンがあります。
そして、人に何かを求める部分が、どこにもありません。
文字を読ませることも、写真を選ばせることも、チェックを入れさせることもない。普通に入力して、普通に送れる形をしていました。
最初は、こちらの見落としかと思いました。
ページの下のほうに隠れているのかもしれない。
送信を押した瞬間に出るのかもしれない。
実際に、最後まで進めてみました。
出ませんでした。
何も求められないまま、送信の画面に進みます。
見送りの記録には、理由が残っています。
人であることを確かめる仕組みがある、と。
目の前のフォームには、その気配がありません。
記録と実物の、どちらかが間違っている。
このときは、まだそう考えていました。
つまり、そのフォームは、人であることを確かめてはいるけれど、人には何も求めていない。そういう仕組みが、あるのです。
判定ロジックの解像度不足が招いた「フォルスネガティブ」と、618社の機会損失
ここで、判定の中身を見に行きました。
こちらは、ページの中に「人であることを確かめる仕組みのパーツが入っているか」を見ていました。パーツがあれば、そういう確認が行われる。
そう考えるのは、自然です。
ところが、この仕組みには種類があります。
利用者に操作を求める種類と、求めない種類があります。
求めない種類のものは、訪問者の動きから、機械らしさを静かに判断します。利用者は、何も操作しません。
そこに確認があることにさえ、気づきません。
こちらの判定は、その2つを区別していませんでした。
パーツがある、だから送れない。
そう一括りにしていました。
この2つを見分けるのは、難しくありませんでした。
パーツの種類が違うからです。
ページの中を見れば、区別が付きます。
区別を付けていなかったのは、技術の問題ではなく、「どちらも同じだろう」と考えたからでした。
作ったときには、そこまで種類があることを知りませんでした。
知らないまま、まとめて1つの判定にした。
そして、その判定は、一度作ったあと、見直されていませんでした。
誤って除外していた会社は――約618社。
これらの会社のフォームは、開いていました。
送れば、届いていました。
こちらが、扉の前に自分で線を引いて、引き返していただけです。
しかも、この判定は最初の工程にあります。
除外された会社は、そこから先の工程へ進みません。
文面も作られず、送信も試されず、結果の記録にも「送信できない会社」として残ります。
一度そう記録されると、次回も同じ扱いになります。
判定が間違っていることに気づく機会が、どこにもありませんでした。
今回気づけたのは、一覧を理由ごとに数えた、それだけのことです。
数えていなければ、同じ判定が、いまも動いていたはずです。
618社という数字は、ある期間の一覧を数え直して出したものです。
この数字を見て、いちばん気になったのは、これが「気づいた分」でしかないことでした。同じ判定は、それ以前もずっと動いています。
以前分については、記録の残り方が違うため、同じようには数えられません。だから、書ける数字は618社です。
実際に見送っていた会社は、それより多いはずです。
数えられる範囲だけを書く、というのは、こういうとき、少し歯がゆいものです。
スクリーニング要件の再定義と、除外データの再処理（リカバリ）フロー構築
直したことは、2つあります。
ひとつ。判定を、種類ごとに分けました。
利用者に操作を求める種類のものは、これまでどおり送りません。
そこは、相手が意図して置いている線です。
求めない種類のものは、送信の対象に含めました。
通常の訪問者と同じように、普通に入力して、普通に送ります。
ここは、慎重に線を引きました。
こちらがしているのは、確認をくぐり抜けることではありません。
相手が用意した窓口に、用件を書いて、送信を押す。
それだけです。
その結果、相手の仕組みが機械だと判断すれば、届きません。それでいい。
判断は、相手がすることです。
こちらが先回りして、判断を代わりにする必要はありませんでした。
ふたつ。「送信できない」と判定した会社を、見直せるようにしました。
一度そう記録された会社も、判定の規則を変えたら、もう一度対象に戻せる。
第1話でも同じことをしています。
こちらの判断で外したものは、こちらの判断が変わったら、戻せなければ嘘になります。
「フェイルセーフ」の罠。サイレントエラーを防ぐための除外ログの定期監査
この件で、いちばん考えたのは、判定の向きです。
「できる」と判定して、実際にはできなかった場合、すぐ分かります。失敗するからです。
「できない」と判定した場合は、何も起きません。
試していないので、失敗もしません。
記録には、静かな行が1行増えるだけです。
つまり、「できない」の判定は、自分で自分を検算しません。
誤りが、そのまま残り続けます。
いま、私たちは「できない」の一覧を、定期的に見直すようにしました。
何がどれだけ除外されているのか。
その理由ごとの件数が、想定と合っているか。
数が多い理由ほど、疑ってかかります。
理由ごとの件数を並べると、判定の癖が見えます。
ある理由だけが極端に多いとき、それは、本当にその理由が多いのか、判定が雑なのか、どちらかです。
たいてい、後者でした。
「その他」や「対象外」といった、まとめて片付けている箱ほど、中身を見る価値があります。
きれいに分類されているものは、すでに考えられています。
考えられていないものだけが、大きな箱に入っています。
「できない」の判定こそ、いちばん疑うべきでした。
この件のあと、判定の一覧を1枚の表にまとめました。
どういう場合に、何と判定するのか。
その判定は、いつ作られたのか。
最後に見直したのは、いつか。
書き出してみると、数年前に作ったまま触っていない判定が、いくつもありました。
作ったときには正しかったものです。
世の中の作りは変わります。
こちらの前提だけが、その場に残ります。
判定は、作った日の世の中を写した写真に似ています。
写した側は、そのままです。
写っている側だけが、変わり続けています。
618社のフォームは、ずっと、開いたままでした。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第15話「7割の沈黙」
「送信はした。ただ、完了画面を確認できなかった」
この結果を、失敗として扱っていました。
返ってきた結果の、約7割。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは300以上のWebサイトから企業リス
