💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
止めたはずのファイルが増え続ける
ソフトウェアには、作っている最中だけ必要になる記録があります。
- いま何をしているのか。
- どんな値を受け取ったのか。
- どこで分かれ道を選んだのか。
画面には出さず、裏でファイルに書き出しておく。
うまく動かないとき、それを読めば、どこで話がおかしくなったのかが分かります。
開発中は、この記録が命綱です。
そして、公開したら、止めるものです。
止めた、つもりでいました。
ある日、サーバーの空き容量を確認していて、手が止まりました。
減っていました。
データが増えたから、ではありません。
企業データの増え方は把握しています。そんな増え方ではない。
何が容量を使っているのか、大きい順に並べてみました。
いちばん上に、見慣れた名前のファイルが1つありました。
開発中に使っていた、記録ファイルです。
その隣に書かれていた数字が――47ギガバイト。
見間違いかと思って、単位から読み直しました。
1ファイルで、47ギガバイト。
映画なら何十本分という大きさです。
それが、たった1つのテキストファイルに入っていました。
しかも、中身はすべて、「いま、この処理を通りました」という報告です。
一行はごく短い。
ただ、書かれた回数が違いました。
「正しい設定」が説明できない容量
最初に確認したのは、設定のほうでした。
記録を出すかどうかを切り替えるスイッチは、最初から用意してあります。
見に行きました。
切ってありました。
ちゃんと「出さない」になっている。
書いた本人の記憶とも一致しています。
つまり、設定は正しい。
なのに、書き出されている。
正しい設定と、増え続けるファイル。
この2つは、どこかで両立しています。
その「どこか」が、見つけられずにいました。
次に疑ったのは、設定の読み込みでした。
切ってあるつもりで、実は読めていないのではないか。
別の場所の設定を見ているのではないか。
確認のために、記録を出す処理を1つ選んで、そこで設定の中身を表示させてみました。
「出さない」と表示されました。
設定は正しく読めています。
その処理も、正しく黙っています。
正しく黙っている処理があるのに、ファイルは増え続けている。
確認するたびに、正しいものだけが増えていきます。
正しいものをいくつ集めても、47ギガバイトの説明にはなりませんでした。
門を素通りする「17か所」の通り道
ここで、ようやく考え方を変えました。
問題は、スイッチの側ではない。
スイッチを見ていない誰かが、どこかにいる。
そこで、記録を書き出している処理そのものを探しました。
ファイルに文字を書き足している行を、片っ端から。
書き出しに使う命令の名前で全体を検索して、出てきた行を、1つずつ開いていきます。
スイッチを見てから書いているか。見ずに書いているか。
確かめることは、それだけです。
見つかったのは、17か所でした。
そのうちのいくつかは、きちんとスイッチを見ていました。
切ってあれば、何も書かない。
残りは、見ていませんでした。
スイッチの前を通らずに、直接、ファイルに書きにいっていた。
手元の「1行」が本番で「容量」に変わる
スイッチは、確かに付いていました。
配線されていない場所が、あっただけです。
門は、閉まっていました。
閉まった門の脇を、いくつもの通り道が素通りしていました。
なぜそうなったのかは、想像がつきます。
調べ物をしている最中に、もう1行だけ記録を足したくなる。
その1行は、いま追いかけている問題を解くためだけのものです。
明日には消すつもりで書く。
明日になると、別の問題が来ています。
そうやって書かれた行が、17か所分残っていました。
責める気にはなりませんでした。
その1行があったから、解けた問題があります。
書いた時点では、正しい判断です。
問題は、書いたことではなく、書いた場所に、戻ってくる仕組みが無かったことでした。
一時的に足したものは、一時的だと分かる形にしておく。
そうでなければ、すべては恒久的になります。
もうひとつ、事情がありました。
この記録は、企業データを1件処理するたびに書かれます。
手元で数十件を試している間は、増え方が見えません。
本番では、桁が違います。
夜間の処理で数万件、数十万件が流れていく。
1件につき数行でも、掛け算をすればそうなります。
手元で問題にならなかったことが、本番では容量になる。
第7話でも似た話が出てきますが、規模が変われば、同じ作りが違うものに変わります。
恒久的な肥大化を防ぐ、3つの改善と再設計
直したことは、3つあります。
ひとつ。
17か所すべてを、スイッチを通るように直しました。
書き出し口を1つにまとめ、そこだけがファイルに触れるようにしました。
ふたつ。
記録ファイルそのものに上限を設けました。
一定の大きさを超えたら、古いほうから捨てる。
定期処理の中で、毎日それを確認するようにしました。
みっつ。
容量を、毎日見るものに加えました。
気づいたのが空き容量の確認だった、というのが今回のすべてです。
偶然に頼らないようにしました。
なお、47ギガバイトのファイルそのものは、慎重に消しました。
一息に消すと、その瞬間に負荷がかかります。
何かの処理が同時に触っていれば、巻き込む可能性もあります。
動いている処理が少ない時間を選び、先に書き込みを止めてから、消しました。
大きくなったものは、片付けるときにも大きさぶんの手間がかかります。
もうひとつ、記録の設計そのものも見直しました。
何を残すのかを、2つに分けました。
ひとつは、いつも残すもの。
処理の開始と終了、件数、失敗した件数。量が増えないもの、後から必ず見るものだけです。
もうひとつは、調べるときだけ残すもの。
これは、対象を絞って、期間を決めて出します。出したら、終わったときに止めます。
以前は、この2つが混ざっていました。
混ざっていると、止めるべきものが分かりません。
全部を止めれば、必要な記録まで消えます。
全部を残せば、今回のようになります。
分けていなかったことが、どちらも選べない理由になっていました。
仕組みが「ある」ことと「効いている」ことは違う
この件で、ひとつ言い方を変えました。
「スイッチは付いています」とは、もう言いません。
「スイッチが効いていることを確認しました」と言うようにしました。
長さは倍になりますが、意味はまるで違います。
付いていることは、設計の話です。
効いていることは、事実の話です。
私たちが確認していたのは、ずっと前者のほうでした。
机の上で済む確認と、動いているものを見に行く確認。
手が伸びるのは、いつも前のほうです。
似た形は、他にもありました。
上限を設けてあります、という機能。
通知を出すようにしてあります、という仕組み。
自動で消えるようにしてあります、という記録。
どれも、設計としては存在しています。
存在していることと、いま現に働いていることは、別の話です。
そこで、確認のやり方を変えました。
「そういう仕組みがあるか」ではなく、「最後に働いたのはいつか」を聞くようにしました。
通知なら、最後に飛んだのはいつか。
自動削除なら、最後に消したのはいつか。
日付が出てこない仕組みは、たいてい、どこかで止まっています。
そして、止まっていることは、何も起きないという形でしか表れません。
この違いは、言葉にすると当たり前です。
当たり前ですが、仕組みを作った直後は、必ず動いています。
動いているのを見て、確認は終わります。
そのあと、誰も見ません。
止まるのは、たいてい半年後です。
別の変更のついでに、通り道が変わったときです。
容量が減っていくのを見て、何かが増えているのだと考えました。
増えていたのは、データではありませんでした。
「あとで消すつもりだったもの」でした。
スイッチがあることと、効いていることは、違います。
47ギガバイト。
そのほとんどが、「ここを通りました」という報告でした。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第4話「2秒の礼儀」
相手先に迷惑をかけないよう、
1社ごとに2秒待つようにしていました。
100社で、約8分。
礼儀の、つもりでした。
━━━━━━━━━━━━━━━━━━━━━━━━
⚙️リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは270以上のWebサイトから企業リストを自動収集。今すぐ無料で体験！www.listoru.com
