💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
アナログ情報の陳腐化とOCRによるデジタル化。データ統合を支えるバックエンドの重要性
名刺は、いまだに紙です。
商談から帰ってきた鞄の中に、数枚入っています。
机の上に、輪ゴムでまとめた束があります。
引き出しの奥に、去年の展示会のぶんがあります。
その中には、会社名も、担当者名も、役職も、電話番号も、メールアドレスも書いてあります。企業データに、いちばん欲しい情報です。
そして、ほとんどが、入力されないまま眠っています。
理由は明快です。
入力が、面倒だからです。
そして、眠っているあいだに、情報は古くなります。
異動する。役職が変わる。会社が変わる。
名刺は、いただいた瞬間がいちばん新しい。そこから先は、価値が下がっていくだけです。
入力の手間は、時間が経つほど、見返りが小さくなります。
見返りが小さくなると、ますます後回しになります。
後回しになるほど、また古くなる。
机の上の束は、そうやってできあがります。
だから、その場で片付くことが大事でした。
だから、撮るだけで登録できるようにしました。
名刺を写真に撮る。
画像から文字を読み取る。
会社名、氏名、役職、連絡先を、それぞれの欄に振り分ける。
画面で確認して、登録する。
複数枚を一度に撮ってもいい。
1枚の写真に何枚か写り込んでいても、分けて読み取ります。
登録されると、会社と、その会社の担当者として記録されます。
すでに登録されている会社なら、担当者だけが足されます。
この「すでに登録されている会社なら」の部分は、名寄せの仕組みがそのまま使われています。
名刺に書かれた会社名は、たいてい正式名称です。
こちらのデータには、略した名前で入っていることがあります。同じ会社と判定できなければ、同じ会社が2つ並ぶことになります。
第20話で作ったものが、ここで効いています。
機能は、単体では動きません。下に何があるかで、使い勝手が決まります。
PII（個人を特定できる情報）のガバナンス。「画像を保存しない」というゼロトラストな要件定義
ここまでは、よくある機能です。
ただ、作る前に決めていたことが、ひとつありました。
機能の一覧には、出てこない決めごとです。
何を作るかではなく、何を作らないか、の側の決定でした。
画像を、保存しない。
先に決めたのには、理由があります。
作ったあとで削るのは、難しいからです。一度保存する作りにすると、それを前提にした機能が、あとから足されます。
画像を一覧で見る画面。
画像から再読み取りする機能。
そうなってから消すのは、もう別の話になります。
保存したほうが、便利ではあります。
読み取りを間違えたとき、元の画像を見れば確認できます。
あとから見返して、名刺のデザインを思い出せます。
検索に使うこともできるかもしれません。
技術的にも、難しくありません。置いておくだけです。
それでも、保存しないことにしました。
名刺は、こちらのものではありません。
その方の名前、勤務先、役職、連絡先。
全部、その方の情報です。
いただいた目的も、はっきりしています。連絡を取るためです。
画像そのものを、こちらが持ち続ける理由は、実は、どこにもありません。
必要なのは、文字にした結果だけです。
もうひとつ、現実的な理由があります。
預かったものは、守らなければなりません。
置き場所を安全にする。
誰が見られるかを決める。
消したいときに、確実に消す。
何かあったときに、何が入っていたかを説明する。
どれも、やるべきことです。やるとなれば、ずっと続きます。
預かる量が増えるほど、守る仕事も増えます。
そして、いちばん確実な守り方は、最初から持たないことでした。
利便性とコンプライアンスのトレードオフ。原則を貫くシステム設計とフィールドセールス向けのUX
この判断のおかげで、説明が簡単になった、という副産物もありました。
画像はどこに保存されますか、と聞かれたときに、保存していません、と答えれば終わります。
保存している場合は、どこに、どれくらい、誰が見られるのか、すべて説明しなければなりません。
読み取りが終わった時点で、画像は捨てます。
確認画面に出ているあいだだけ、一時的に扱い、登録が終われば、残しません。
読み取りを間違えていたら、その場で直していただきます。
あとから直す場合は、もう一度撮っていただきます。
不便です。
その不便は、こちらが選びました。
この判断には、社内で異論もありました。
読み取りは、完璧ではありません。崩した書体、薄い印字、複雑な配置。
間違えることは、あります。
画像が残っていれば、あとから直せる。
その主張は、正しい。
正しいので、簡単には片付きませんでした。
便利さの側には、いつも具体的な場面があります。
間違えたまま登録して、あとから気づいたら、という場面です。
預からない側にあるのは、場面ではなく、原則だけです。
原則は、目の前の場面より、弱く見えます。
最終的に、こう考えました。
間違いを直すために画像を持ち続けるのは、「こちらの都合で、その方の情報を預かる」ことです。
間違いは、その場で直せます。
確認画面は、そのために出しています。
利便のために預かるのか、不便を引き受けて預からないのか。
後者を選びました。
複数枚をまとめて撮れるようにしたのは、実際の使われ方を見たからです。
1枚ずつ撮る形にすると、その場で使う人はいても、後日は続きません。
展示会から戻ってきた鞄には、何十枚も入っています。
1枚ずつ撮る作業を何十回も繰り返すなら、結局、後回しになります。
機能があるかどうかではなく、最後までやり切れる形かどうかでした。
データ保持ポリシーの策定とヒューマンインザループ。「人が仕上げる」業務プロセスの構築
この考え方は、他のところにも広げています。
集められる情報のうち、使い道が説明できないものは、集めません。
残せる記録のうち、誰がいつ見るのか答えられないものは、残しません。
第5話でも、似た判断をしました。
あのときは容量の話でしたが、根っこは同じです。
持たないものは、失いません。
持たないものは、漏れません。
持たないものは、説明の必要もありません。
機能を作っていると、情報は多いほど良いという方向に、自然と傾きます。
あとで使えるかもしれない。
持っていて損はない。
損はない、というのは、正しくありません。預かった時点で、責任が発生しています。その責任は、使っていなくても発生し続けます。
便利さは、使った日にだけ感じます。責任は、使わない日も、静かに続いています。比べる土俵が、そもそも違っていました。そして、その責任には終わりがありません。
システムを作り直すときも、引き継ぎます。
会社の体制が変わっても、引き継ぎます。
何年経っても、預かっている限り続きます。
いま便利かどうかで決めたことが、何年ぶんの責任になるのかを、決める瞬間には、なかなか考えられません。
だから、決めごとにしました。
新しく何かを預かるときは、それを消す条件を、同時に決める。
消す条件が決められないものは、預かりません。
預かる前なら、断るだけで済みます。
預かったあとでは、そうはいきません。
読み取りの精度についても、割り切りました。完璧を目指すと、際限がありません。崩した書体も、縦書きも、英語表記も、すべてに対応しようとすると、いつまでも終わらない。
そこで、こう考えました。手で入力するより速ければ、それでいい。
7割の欄が正しく埋まっていれば、残りを直すほうが、全部を打つより早い。
確認画面は、そのために作りました。
完璧な自動化ではなく、人が仕上げる前提の下ごしらえです。
そう決めたら、作るものがはっきりしました。
名刺を撮ると、その方の情報が企業データに入ります。名刺そのものは、どこにも残りません。
いちばん確実な守り方は、たいてい、いちばん地味な方法でした。
預からないことも、守り方のひとつです。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第24話「クリックが教えてくれる」
送った文面は、読まれたのか。
こちらからは、何も見えませんでした。
ひとつだけ、見える瞬間がありました。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
あなたの営業活動を応援します！
営業リスト作成にお困りではありませんか？
→ 営業リスト探しに、もう時間をかけない。
業種別に企業情報をまとめて収集できるリストルを、まずは3,000件まで無料でお試しください。👇
📊営業リスト収集ツール「リストル」
