体組成計の自動取得が、初回に来なかった話 — 失敗の通知は「動いて失敗したとき」にしか鳴らない

体組成計の測定データを、月に一度、自動で取ってきて保存する。そういう仕組みを自分で組んだ話の続きだ。前回は、組むまでに8日間ハマった話を書いた。あの記事の最後で、自分はこう書いている。

月に一度の自動実行は、まだ一度も動いていない。初回は来月だ。うまくいく見込みは立っているが、見込みと実績は別物だ。

その初回が来た。そして、動かなかった。

正確に言うと「動かなかった」ですらない。その日の実行が、何の痕跡も残さずに消えていた。

何が起きたか

仕組みはこうだった。毎月1日の朝、決めた時刻にパソコンが自動で処理を起動し、タニタの「ヘルスプラネット」から前月分の測定データを取ってきてファイルに保存する。取れなかったときはエラーを記録して、画面に通知を出す。ここまでは前回の記事で組み終えていた。

9月1日の朝。その時刻、パソコンの電源は入っていなかった。スリープではなく、切ってあった。

ここまでなら想定内だった。予定はWindowsに最初から入っている予定実行の機能で登録してあり、そこに「開始時刻を逃した場合は、次に起動したときにすぐ実行する」という設定を入れてあったからだ。予定した時刻に処理が実行されない、電源を切っていた間の分が走らない、という状況のための設定だ。以下、この後追いの実行を「追い掛け」と呼ぶ。実際、別の毎日の処理では、この追い掛けが動いた実績もあった。パソコンを数日落としていた後に起動したら、溜まっていた分がちゃんと走った。

その日の夕方、パソコンを起動した。ほかに登録してあった予定は、起動直後にまとめて追い掛けで実行された。これは夜になってから実行の記録で確かめたことで、その場で見ていたわけではない。

この月次の取得だけが、そこに含まれていなかった。

どうやって気づいたか

気づいたのは夜になってからで、しかもこの処理を見に行ったからではない。同じ日に初めて動く予定が他にもいくつかあり、「今日が初回のものは動いたか」をまとめて確認していたら、そのうちの一つとして「動いていない」が浮かんだ。

もし確認する予定が他になければ、たぶん気づいていない。ログを見に行っても、そこには8月上旬に手で動かしたときの記録が最後で、9月1日の行は1行もない。エラーの記録もない。通知も出ていない。何も無いので、何も無いことに気づけない。

留守中に荷物が届けば、不在票が残る。不在票があれば「来たのに受け取れなかった」と分かる。この予定は、不在票を残さなかった。来なかったのか、来たのに受け取れなかったのかすら、ログの上では区別がつかない。

通知が鳴らなかった理由

ここで自分が一番引っかかったのは、前回の記事で「失敗したら通知が出る」仕組みをわざわざ作っていたことだ。実際に意図的に失敗させて、通知が画面に出ることも確認していた。それなのに、今回は鳴らなかった。

理由は単純で、通知を出すのは処理自身だった。処理が起動して、ログインに失敗したとか、データが取れなかったとか、そういう「動いた上での失敗」なら、処理が自分でエラーを書いて通知を出す。だが処理が起動しなければ、通知を出す主体がそもそも存在しない。

つまり自分が作った失敗検知は、「動いて失敗する」ことしか想定していなかった。「動かない」は、その設計の外側にあった。

皮肉なことに、この処理の外側に失敗を見張るために付けた仕組みには、自分で説明文をこう書いてある。「静かに失敗し続ける状態を防ぐのが、この仕組みの主目的である」。静かに失敗し続けていた8日間の反省から作ったものだ。それが、別の経路で静かに実行されなかった。

分かっていないこと

なぜ追い掛けが効かなかったのかは、この記事を書いている時点で分かっていない。

追い掛けの設定そのものは、走った処理と同じものが入っている。違うのは周期(毎日と毎月)と、実行のときに使う権限や打ち切りの条件を、この処理だけ別の組み合わせにしてあったことだ。その組み合わせのどれかが効いていそうだ、という候補はいくつか挙がっているが、「これが原因だ」と一つに絞れてはいない。原因を一つに絞るには、わざと同じ条件を作って再現させる必要があり、それはまだやっていない。

前回の記事で、「原因が外にあると分かった気になった瞬間に、内側を調べる手が止まる」と書いた。今回はその逆をやらないように気をつけている。候補が挙がった段階で「たぶんこれだろう」と決めてしまうのも、調べる手を止める方法の一つだからだ。

だから今回は、分かっていないものを分かっていないまま書く。

持ち帰れること

自分が今回持ち帰ったのは2つ。

「失敗したら通知」は、動いた場合しか守ってくれない。「そもそも動いたか」は別に見張る必要がある。

処理の外側から「予定の時刻を過ぎたのに記録が増えていない」を見るものが要る。

「何も起きていない」と「確認できていない」は、見た目が同じ。

記録に何も無いのは、何も起きていないからかもしれないし、起きたことを書く主体がいなかったからかもしれない。何も無いときこそ、「無い」ことを誰が保証しているのかを一度考える。

自動で動いているつもりのものが手元にあるなら、今日ひとつだけやってほしい。その記録が最後に増えた日付を見る。それだけで、この記事に書いたことの半分は確かめられる。

正直に書いておくこと

8月分のデータは、結局手で取り直した。処理を動かしたのではなく、ページを開いて1か月分を写した。だからこの取得は、自動取得の記録には一切残っていない。ファイルだけが増えている。割に合っているかどうかは、前回と同じで、まだ言えない。

そして再発防止の変更は、この記事を書いている時点ではまだ入れていない。案が無いわけではない。自分で使っているAIに原因を調べさせて、対策の候補はいくつか出ている。処理の外側に「予定の日を過ぎたのに記録が増えていない」を見張るものを置く。予定の時刻に起動していたかどうかを、処理とは別に記録する。そういう類の案だ。

ただ、原因を1つに絞れていない段階で対策のどれかを入れると、それ自体が「たぶんこれだろう」で手を止める形になる。だからまだ入れていない。外から見張る仕組みだけは原因と関係なく置けるので、それは次の初回の前に置く。次の初回は10月1日で、そのときパソコンが起動しているかどうかも、追い掛けが効くかどうかも、まだ分からない。

前回の記事は「見込みと実績は別物だ」で終えた。その言葉を書いた自分は、見込みが外れる方向として「動いて失敗する」ことしか想像していなかった。実績はもう一段外側から来た。

次にこの話を書くときは、10月1日に何が起きたかを書く。動いたなら動いたと、動かなかったならなぜかを。