💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
完了画面のレスポンスに依存した成果判定。正常系シナリオのバイアス
フォームへ文面を届けたあと、その結果を判定します。
届いたのか、届かなかったのか。
判定の材料は、送信したあとに返ってくる画面です。
「送信が完了しました」
「お問い合わせありがとうございました」
そういう画面が返ってきたら、成功。
エラーが出たり、入力画面に戻されたりしたら、失敗。
分かりやすい判定です。
分かりやすさは、たいてい、どこかを切り捨てた残りです。
このときの私たちは、何を切り捨てているのかを、まだ知りませんでした。
ただ、世の中のフォームは、そこまで親切ではありません。
送信したあと、そのまま会社のトップページへ戻るもの。
真っ白な画面になるもの。
何も変わらないように見えるもの。
こちらから見ると、こうなります。
送信の操作は、確かに行った。
拒否もされていない。
けれど、完了したという確認が取れない。
なぜ完了画面が返ってこないのか、理由はさまざまです。
- 送信後に別のページへ移す設定になっている。
- 完了の文言が、こちらの想定していない書き方をしている。
- 画面の一部だけが書き換わる作りになっている。
- 完了画面の代わりに、メールで返す仕組みになっている。
どれも、フォームとしては、まったく正常です。
完了画面を返さなければならない決まりは、ありません。
こちらが「完了画面が返る」という前提を持っていただけです。
この結果に、私たちは名前を付けていました。
「送信したが、完了を確認できなかった」
そして、この結果を、失敗として扱っていました。
フォールスネガティブ（誤判定）の顕在化。7割の「結果不明」と重複送信のインシデント
名前を付けたところまでは、正しかったと思います。
問題は、そのあとでした。
名前は付けたのに、扱いだけが、2つのうちのどちらかに寄せられていた。
失敗として扱う、というのは、次にこう動くという意味です。
その会社には、まだ届いていない。
だから、もう一度送る。
この動きは、判定が正しければ、正しい動きです。
名前を付けた時点では、これは少数派のはずでした。
大半のフォームは完了画面を返す。
返さないものが、少しある。
そういう想定です。
想定が正しいかどうかは、数えるまで分かりません。
ある日、返ってきた結果の内訳を数えました。
はっきり成功したもの。
はっきり失敗したもの。
そして、完了を確認できなかったもの。
確かめるだけの作業の、つもりでした。
数え終わって、手が止まりました。
3つ目が、いちばん多かった。
返ってきた結果の――約7割。
7割が、失敗として扱われていました。
そして、7割分、もう一度送っていました。
7割という数字を見たとき、まず疑ったのは、判定の作りのほうではありませんでした。
「送信できていない会社が、そんなに多いのか」
そう考えて、送信の仕組みを調べ始めました。
つまり、送信が失敗しているという前提で、その原因を探そうとしたのです。
前提を疑うまでに、少し時間がかかりました。
数字がおかしいとき、疑う場所は2つあります。
数えられた側か。数え方か。
先に疑ったのは、数えられた側でした。
自分の作った物差しは、いちばん疑いにくい場所にあります。
ここで、確認をしました。
本当に届いていないのか。
いくつかの会社について、実際に確認できる手段がありました。
届いていました。
完了画面が返ってこなかっただけで、問い合わせは、相手に届いていたのです。
オペレーションコストの増大と機会損失。見えない重複が生む「最も高い代償」
ここから先は、こちらの都合の話ではありません。
同じ会社へ、同じ内容の問い合わせが、二度届きます。
受け取った側から見れば、同じ相手から、間を置かずに同じ文面が来た、ということです。
丁寧に扱っていただけることもあるでしょう。
そうでないこともあるでしょう。
どちらにしても、こちらが望んだ形ではありません。
送信の数だけを見ていれば、「たくさん送れている」と見えます。
実際に増えていたのは、重複でした。
送信の件数は、画面に出る数字です。
重複の件数は、どこにも出ない数字でした。
見える数字だけを見ているあいだ、見えない数字が、その裏で増えていました。そして、この重複には費用もかかっています。
文面は1社ごとに作ります。
二度送れば、二度作ることになります。
判定を間違えると、その先の工程が全部やり直しになります。
いちばん軽い工程での判断の誤りが、いちばん重い工程の費用に変わる。
判定は、工程の中で最も安い部分です。
そして、最も影響が大きい部分でもありました。
3値ステータスの導入によるデータモデリングの最適化と運用フローの再構築
原因は、判定の作りにありました。
結果を、成功か失敗かの2つに分けていた。
現実には、3つ目があります。
そして3つ目が、いちばん多い。
いちばん多いものに置き場所を用意していなかったので、それは自動的に、隣の箱へ落ちていました。
確認できたのは、ごく一部の会社についてです。
全部を確かめる方法は、ありません。
それでも、「届いていないはず」の会社に届いていた事実が出た時点で、判定の前提は崩れました。数件で十分でした。
直したことは、こうです。
3つ目の結果を、そのまま3つ目として残すようにしました。
失敗にも、成功にも寄せません。
「完了は確認できていないが、送信は行われた」という状態のまま持ちます。
そのうえで、次の動きを分けました。
はっきり失敗したものは、原因を見て、必要なら送り直す。
3つ目のものは、送り直しません。
代わりに、その会社の記録に印を付けます。
反応があれば、届いていたことが分かります。
一定の期間、何もなければ、そのときに改めて判断します。
画面にも、3つ目をそのまま表示するようにしました。
以前は、失敗の件数に混ざっていました。
見ている人は、実際より多くの失敗を見せられていたことになります。
これは、使う方の判断にも影響します。
失敗が多い一覧を見ると、「このリストは質が悪い」と考えます。
実際には、届いていた。
届いた証拠が取れなかっただけです。
数字の分類が変わると、その数字を見た人の次の行動が変わります。
集計の設計は、表示の話ではなく、判断の話でした。
バイナリ判定（2値分類）が生むデータの隠蔽。業務の「ペンディング（保留）」を許容するシステム要件定義
この件は、判定の話ではなく、分類の話でした。
白か黒かで分けると、作りは簡単になります。
分岐が2つで済みます。
画面も作りやすい。
けれど、現実のほうは、たいてい3つあります。
はっきりしているもの。
はっきり違うもの。
そして、いちばん多い「たぶん、こう」。
2つの箱しか用意しないと、いちばん多いものが、どちらかに押し込まれます。
押し込まれた先が失敗なら、無駄が増えます。
押し込まれた先が成功なら、見落としが増えます。
そして、押し込んだことは、記録に残りません。
記録に残るのは、押し込んだあとの姿だけです。
あとから見た人には、最初から2つだったようにしか見えません。
分類は、決めた瞬間に、決めたという事実ごと見えなくなります。
どちらにしても、いちばん多いものの扱いを、こちらが決めていないことに変わりはありません。
3つ目を作ってから、運用も変わりました。
「たぶん届いた」の会社には、数日おいてから、別の手段で様子を見ます。
すぐ送り直さない。
けれど、忘れもしない。
この中間の扱いは、人がやっていたことです。
営業の方は、はじめからそうしていました。
返事がなくても、すぐには追いかけない。
しばらく置いて、別の角度から触れる。
システムのほうだけが、白か黒かで動いていました。
人は、宙ぶらりんのまま覚えていられます。
仕組みは、置き場所を作らない限り、覚えられません。
人がやっていた待ち方に、仕組みのほうを合わせた形です。
白か黒かで分けると、いちばん多い「たぶん届いた」が、行き場を失います。
行き場を失ったものは、黙って隣の箱に落ちます。
7割が、そうなっていました。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第16話「送れない394社」
文面を作る費用が、本来の2.7倍になっていました。
増えたぶんは、どこにも届いていませんでした。
作られては、消えていました。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 営業リスト探しに、もう時間をかけない。
業種別に企業情報をまとめて収集できるリストルを、まずは3,000件まで無料でお試しください。👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは300以上のWebサイトから企業リストを自動収集。今すぐ無料で体験！
