💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
目次
- 「前提」が壊れた日に初めて気づく自動更新の仕組み
- エラーを出さずに静かに終わる「見えない故障」
- 足りているかは確認しても「多すぎないか」は見ていない
- 直したのではなく、届いた。「届ける道」こそが土台である
「前提」が壊れた日に初めて気づく自動更新の仕組み
お客様の手元で動くツールがあります。
ホームページのフォームへ文面を届けるためのものです。
サーバーの上ではなく、それぞれのパソコンの中で動きます。
手元で動くものには、利点があります。
速い。落ちにくい。回線の事情に左右されにくい。
そして、決定的な弱点があります。
配ったあと、こちらから触れません。
だから、自動更新の仕組みを付けています。
新しい版を用意したら、「いま最新はこれです」という案内を1か所に置く。
ツールは起動のたびにそこを見にいき、自分より新しい版があれば、取ってきて入れ替える。
お客様は何もしなくていい。
気づいたら新しくなっている。
そういう作りです。
うまく動いているあいだ、この仕組みは誰の目にも入りません。
目に入らないことが、うまく動いている証拠でもあります。
この仕組みがあるので、私たちは安心して直せます。
不具合が見つかっても、直して、置けばいい。
数日のうちに、全員の手元が新しくなります。
その安心が、前提になっていました。
前提は、壊れたときに初めて、前提だったと分かります。
エラーを出さずに静かに終わる「見えない故障」
ある日、その仕組みが動かなくなりました。
新しい版を用意して、案内を書き換えて、置きました。
手元の道具を起動します。
何も起きません。
もう一度起動します。
何も起きません。
エラーも出ません。
「更新があります」とも言いません。
ただ、いつもどおり起動して、古い版のまま動きます。
こういうときは、何も起きないほうが、原因を探しにくいものです。
エラーが出れば、その文言から調べられます。
何も起きなければ、どこまで進んだのかも分かりません。
止まってくれる故障は、止まった場所から調べられます。
黙って通り過ぎる故障は、どこを通ったのかを探すところから始まります。
最初に疑ったのは、置き場所でした。
案内の置き場所が変わっていないか。
道具が見にいく先と、こちらが置いた先が、食い違っていないか。
確認しました。合っています。
手元から案内を読みにいくと、ちゃんと返ってきます。
中身も、新しい版のことが書いてあります。
読める。中身も正しい。それなのに、更新が始まらない。
次に、道具の側の記録を見ました。
起動したとき、案内を見に行ったかどうか。
見に行った結果、どう判断したのか。
記録には、見に行ったことまでは残っていました。
そのあと、何も書かれていません。
失敗した、とも書いていない。
更新の必要なし、とも書いていない。
途中で、静かに終わっている。
この「何も書かれていない」が、手がかりでした。
足りているかは確認しても「多すぎないか」は見ていない
処理は、案内を読み込む段階で終わっています。
つまり、読み込みの結果を、ツールが受け入れなかったということです。
次に見たのは、案内そのものの形でした。
この案内は、決まった形式で書かれた短いファイルです。
新しい版の番号。
取ってくる場所。
中身が壊れていないかを確かめるための照合値。
必要なことだけが並んでいます。
目で見るだけでは、正しそうに見えます。
正しそう、を確かめる方法は、1つでした。
正しく動いていたころのものと、並べることです。
並べて、前の版の案内と見比べました。
項目が、1つ多い。
前の版には無かった項目が、1つ増えていました。
1項目の違いに気づくまでに、少し時間がかかりました。
案内ファイルは、目で見て確認していました。
必要な項目が、正しく入っているかどうか。
必要なものが揃っているかは、見ています。
余計なものが入っていないかは、見ていませんでした。
確認は、たいてい「足りているか」を見ます。
「多すぎないか」を見る習慣は、ありませんでした。
その1項目を書き加えたのは、こちらです。
案内ファイルを組み立てる作業を、用意されたツールにまかせていました。
そのツールは、こちらの想定より少しだけ親切で、必要のない項目を1つ、足してくれていました。
足された項目そのものに、害はありません。
中身も、間違ってはいません。
ただ、受け取る側が、それを知りませんでした。
ツールは、案内を読み込むときに、「知らない項目が入っている」と判断しました。
判断したうえで、こう考えます。
この案内は、自分の理解できる形ではない。
無理に読み進めるのは危ない。
今回は、何もしないでおこう。
つまり、安全側に倒れたのです。
その判断は、正しい。
壊れた案内を信じて、変なものを取ってくるより、何もしないほうがずっとましです。
結果として、何も起きませんでした。
そして、いつもいうように、何も起きないことは、外からいちばん見えにくい状態でした。
直したのではなく、届いた。「届ける道」こそが土台である
直したことは、3つあります。
① 案内ファイルの中身を、正しい形に戻しました。
② 案内を組み立てる手順を、自前のものに切り替えました。
親切に何かを足してくれるツールは、この用途には向きません。
そして、いちばん困ったのは、この時点でした。
更新できないツールは、お客様の手元にあります。
こちらから直せるのは、案内のほうだけです。
ツールそのものは、触れません。
幸い、今回は案内の側の問題だったので、案内を直したら、次の起動から更新が始まりました。
もしツールの側に問題があったら、更新の道が使えない状態で、更新が必要なツールを直すことになります。
配り直すしかありません。
お客様に、手作業をお願いすることになります。
その一歩手前でした。
③ 配る前の確認手順に、1項目を加えました。
新しい版を置いたら、実際に古い版を起動して、更新が始まるところまで見る。
案内が読めることの確認では足りません。
更新が終わって、版の番号が変わるところまでを見ます。
この件のあと、言い方を1つ変えました。
「直しました」ではなく、「直したものが、届きました」と言うようにしました。
サーバーの上で動くものは、直せば、その瞬間から新しくなります。
そこには距離がありません。
手元で動くものは違います。直したものは、こちらの手元にあるだけです。
お客様のパソコンで動いているのは、まだ古い版です。
その距離を埋めるのが、更新の道です。
だから、更新の仕組みは、ツールのいち機能ではありません。
そのツールを、これから直し続けられるかどうかを決める、土台のほうです。
土台が壊れているときは、新しい機能を作っている場合ではありません。
いまは、更新の仕組みに関わる部分を変えるときだけ、確認の手順を倍にしています。
他の機能なら、不具合が出ても直せます。
ここだけは、壊れると、直す手段そのものが無くなります。
ツールそのものは、いくら磨いても構いません。
けれど、届ける道が壊れていたら、磨いた成果は、こちらの机の上にあり続けます。
そして、その状態は、こちらからは見えません。
こちらの手元では、新しい版が動いています。不具合も直っています。
お客様の手元では、古い版が動いています。不具合も、そのままです。
同じツールの話をしているつもりで、違うものの話をしていることになります。
この件のあと、配る作業の記録を残すようにしました。
いつ、どの版を、どこに置いたか。
そのとき、案内をどう書き換えたか。
更新が実際に始まったことを、どう確認したか。
配る作業は、月に何度もあるわけではありません。
だから、手順を覚えていられません。
覚えていられない作業ほど、書いておく価値がありました。
配ってしまったものは、直しても、届きません。
届ける道が壊れていたら。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第13話「英語のエラー画面」
起動した瞬間、見慣れない英語の文字列が並びました。
お客様には、できることが何もありません。
その画面を、私たちは一度も見たことがありませんでした。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
