失敗談：自動出品が1週間止まっていた原因｜エイジク

毎朝動くはずの自動出品が、1週間止まっていました。原因は、自動ログインの仕組みが「もうログインは有効」と誤って判定し、有効だったログイン状態を空のファイルで上書きしていたこと。直し自体は小さなものです。痛かったのは直す手間ではなく、「止まっていることに1週間気づかなかった」ことです。

何が起きたか

自分の会社では、海外ECモールへの出品を毎朝自動で動かしています。前の日までに人が選んで確認した商品を、朝の決まった時間に、仕入れ先の管理画面へログインして出す仕組みです。出す商品を選ぶのも、売値を決めるのも人。機械は、人が決めたものを決まった時間に出すだけです。

ある朝、記録を見ると「セッション無効」（ログインが切れている）で止まっていました。さかのぼると、1週間前から毎朝、同じところで止まっていました。その間の出品は止まったままです。

仕組みはこうでした。

問題は2でした。自動ログインの仕組みが、ログイン情報が空なのに「既に有効」と判定してしまう。そして、その空の状態を、保存先のファイルに書き込んでいました。結果、前日まで有効だったログイン情報が空のファイルに置き換わり、3で「セッション無効」になる。翌朝も同じことを繰り返す。

つまり、「直す役」が毎朝「壊す役」をしていた、という話です。

直したのは2か所です。

直したあと、ログインし直し → 確認、まで通して動くことを見てから元に戻しました。

私が反省したのは、仕組みの作りより、監視のほうです。

無人で動くものは、動いている時は静かで、止まっている時も静かです。人がやっていれば「今日出品してないな」と誰かが気づきます。機械に任せると、誰も見ていなければ1週間でも止まり続けます。

そこで、毎朝の報告に「ログインが有効か・今朝は何件出す予定か」が出るようにしています。予定なしの日が続けば、朝のうちに目に入ります。

自動化を作る時、動く部分には時間をかけます。でも「止まった時にどう知るか」は後回しになりがちです。順番は逆で、止まったことを知る手段を先に決めてから、動く部分を作るほうがいい。これは次に何かを作る時の、自分へのルールにしました。

上書きする処理は、その前に今の状態を確かめる。 今回の原因は「確かめずに書き込む」でした。ログインし直す、ファイルを置き換える、設定を更新する。状態を変える処理の前に「今どうなっているか」を見る一手を入れるだけで、同じ種類の事故はかなり減ります。

御社の「無人で動いている仕事」の止まり方、一緒に見ます。60分・無料。