Contents
まず結論
その夜、スマホに映った数字は最初「バグだ」と思ったのに、調べたら本物でした。同時に、本物の混乱の中に本当のバグも1つ紛れていました。この「どれが現実で、どれが自分のミスか」を切り分ける作業こそが、一番の勉強になりました。
「本物の遅延が来た日が、本当のテスト」と書いていた
少し前の記事で、私はこう書いていました。「次に本物の遅延が起きた日には、ここまで積んだ機能が一気に試される」と。アプリはそれまで、平常運転や小さな遅れでしか動かしていませんでした。大きく乱れた瞬間にどうなるかは、誰にも分からなかったのです。
その日が、一昨日の夜に来ました。帰りの時間帯、浅草線が大きく乱れ、手元のアプリの画面が、見慣れない数字を映し始めました。
第一印象は「壊れた」
画面に出たのは、常識ではありえない待ち時間と到着予測でした。普段なら数分で来るはずの区間が、桁違いの数字になっている。「バグだ」——それが最初の反応でした。
ここで、以前の自分ならそのまま「壊れてる」と決めつけて、原因を自分のコードの中だけで探し始めたと思います。でも、この数週間で何度も書いてきた教訓が、頭の中でブレーキをかけました。
驚くようなデータを、反射的に「バグ」と決めつけない。まず本物かどうかを疑う。
検証フェーズで、あり得ない数字を「保留」にした経験。欠測をゼロと読み違えかけた経験。あの積み重ねが、ここで効きました。
調べたら、数字は”本物”だった
落ち着いて確かめると、その異常な数字は、バグではなく現実そのものでした。実際に大きな乱れが起きていて、アプリはそれを正直に映していたのです。「壊れている」と思ったものが、実は「ちゃんと現実を見ている」証拠だった。これはちょっとした感動でした。ターミナルの中で作ってきた仕組みが、生きた混乱の断面を、初めて自分の目の前に描いて見せた瞬間だったからです。
ただし、本物の中に”本当のバグ”も紛れていた
ここからが難しいところでした。数字の大半は本物だったのですが、その中に1つだけ、どう考えても成立しない値が混ざっていました。現実ではあり得ない到着予測が出ていたのです。
つまりその夜の画面は、「アプリが正しく捉えた混乱」と「アプリのミス」が、同じ画面に同居していたわけです。全部が正しいわけでも、全部が壊れているわけでもない。この状態がいちばん厄介でした。「どこまでが現実で、どこからが自分のミスか」を1つずつ切り分けないと、正しい部分まで疑ってやり直す羽目になります。
初学者向けに一番の学びを言葉にすると、こうです。本物の信号とバグは、しばしば絡み合って現れる。だから「おかしい画面」を見たとき、全部を白か黒かで判断してはいけない。混乱の中から「これは現実」「これは自分のミス」を仕分ける——それがデバッグの本体でした。
もうひとつの発見：アプリは”向けた先”しか見ていなかった
さらに考えさせられたことがあります。浅草線は京急・京成・東武と直通運転をしていて、電車が各社の線へ乗り入れています。今回の混乱の本当の原因は、その直通先という、アプリがまだ十分に目を向けていない場所で起きていました。だからアプリ自身は「浅草線の中は正常です」と表示しながら、乗り入れ先から流れ込む乱れで現実は大きく荒れている、というちぐはぐが起きていたのです。
これは大事な気づきでした。システムは、こちらが観測するよう向けた範囲のことしか教えてくれない。見ていない場所で起きたことは、どれだけ現実に影響していても、画面には出てこない。「アプリが平常と言っているから平常だ」と鵜呑みにするのは危険で、アプリの”視野の外”を意識するのは、使う人間の側の仕事なのだと痛感しました。病院SEの仕事で、監視していない機器の異常は監視画面に出てこない、というのと同じ話です。
おわりに ── 混乱の夜が、一番の教材だった
正直に言うと、その夜のアプリは満点ではありませんでした。バグも出たし、出していた助言も、後から考えると鵜呑みにできないものでした。でも、平常運転を100日眺めるより、本物が乱れた1日のほうが、はるかに多くを教えてくれました。
驚く数字をまず疑う。現実とバグを切り分ける。アプリの視野の外を意識する。どれも、混乱が起きなければ気づけなかったことです。次に同じ規模の乱れが来た日が、修正の本当のテストになります。そのときアプリがどう振る舞うか——今から、少しだけ楽しみにしています。
個人開発 / デバッグ / 実測主義 / 都営浅草線
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
