そして最終的に私が下した判断は、「直さない」。今回は、その顛末の話です。
まず結論
ズレの正体は、私が使っていた”物差し”そのものの目盛りの粗さでした。電車の動きの性質ではなく、観測する側の癖。それを見抜けたので、補正を入れずに済みました。
今週の学びを一行にすると、こうです。
測って出てきたズレが、対象のものなのか、物差しのものなのか——
それを確かめる前に補正すると、測定の癖を本番に焼き付けることになる。
疑いは3つあった
調査は「原因の候補を先に3つ立てて、データで消していく」形で進めました。ざっくり言うと、こんな候補です。
- A：どこか一箇所で、一度だけ余計な時間がかかっている（到着直前の停車など）
- B：距離が伸びるほど、少しずつ誤差が積み上がっている
- C：AでもBでもない、別の何か
ここで大事なのは、調べる前に「どういうデータが出たらどれを採用するか」を決めておいたことです。後から都合よく解釈しないための予防線で、これは以前「採点基準を測る前に凍結した」のと同じ考え方でした。
結果、AもBもデータと合いませんでした。Aなら残り区間が短いときにも同じズレが出るはずなのに出ない。Bなら距離に比例して増え続けるはずなのに、ある値で頭打ちになって、それ以上増えない。両方とも棄却です。
決定打：「観測が欠けているときほど、誤差が消える」
ここからが今回の白眉でした。データを掘っていて、奇妙な事実が出てきたのです。観測の回数が少ないときほど、誤差が小さくなる。
これは、よく考えるとあり得ない話です。電車の走り方は、私がどれだけ観測したかとは無関係だからです。こちらが見ていようが見ていまいが、電車は同じように走る。それなのに観測回数で誤差が変わるということは——
その誤差は、電車の性質ではなく、観測する仕組みの性質である。
初学者向けに、私が一番腑に落ちた説明を書きます。私が使っているデータは、一定の間隔でしか更新されません。つまり物差しの目盛りが、その間隔ぶんの粗さで刻まれている。目盛りより細かい出来事は、原理的に正しく測れないのです。そして決定的だったのが、誤差の頭打ちの値がデータの更新間隔とほぼ一致していたこと。物理現象が、たまたま観測の周期とぴったり一致する理由はありません。
定規の目盛りが1cm刻みなら、5mmのものを何度測っても正確には出ない。今回のズレは、電車の遅れではなく、その”目盛り”を見ていただけでした。
学び①：「補正しない」も、立派な成果物
ここで、非常に強い誘惑がありました。「じゃあ、その分だけ予測を早めれば当たるようになるのでは？」
でも、それは絶対にやってはいけませんでした。理由はこうです。その”ズレ幅”は、電車の性質ではなく私の観測環境の癖から出た数字です。それをそのまま補正値にしてしまうと、測定の癖を、アプリ本体に焼き付けてしまうことになります。観測環境が変われば、その補正は途端に間違いに変わる。
だから今回の作業は、コードの変更ゼロで終わりました。数字を出しただけ。それでも私は、これを今週いちばん価値のある仕事だと思っています。調べた結果「直さない」と決めるのは、何もしなかったのではなく、間違った修正を1件未然に防いだことだからです。以前たくさん駆除した「静かな嘘つき」を、生まれる前に止めた形です。
学び②：やらなかった調査こそ、記録する
ただし、ここに落とし穴があります。「直さない」判断は、コードに痕跡が残りません。
ということは、記録しなければ——3ヶ月後の私は、同じズレを見つけて、同じ調査を最初からやり直します。だから今回、調査の経緯と棄却の理由を、台帳に文書として残しました。やったことより、やらなかったことのほうが、記録しないと消える。これは今回いちばん実用的な教訓かもしれません。
学び③：自分の物差しで測った答えを、自分の採点に使わない
もうひとつ、大事な但し書きも記録しました。今回の分析に使った「実際の到着時刻」も、同じ粗い物差しで測ったものです。つまりこのデータには、最初から測定の癖が混ざっています。
今回は「癖そのものを暴く」目的だったので問題ありません。でも、このデータを将来ほかの指標の較正（基準合わせ）に流用してはいけない。癖のある物差しで測った答えを”正解”として自分を採点すると、癖を癖と気づけないまま合格が出てしまいます。この但し書きを、データと一緒に書き残しました。
おまけ：数字の「直書き」は、いつか歩き出す
この件に関連して、小さな訂正作業もしました。ある文書に、別のプロジェクト側の事実（データの更新間隔）を数字でそのまま書き写していた箇所があり、後の実測でその値が古いと判明したのです。
対応は、正しい数字に書き換える——ではなく、数字の直書きをやめて「向こうの記録を参照」の形に変えることでした。直書きは、原本が更新されたときに古いまま取り残され、いつか誰か（未来の自分）がそれを読んで再び歩き出します。おなじみの「真実は1箇所」を、プロジェクトをまたいで適用した形です。
そしてもう一つ感心したのが、修正を任せたAIの判断でした。その文書は「ある時点での偵察結果」という題だったため、古い値を消さずに「当時の記録」として残し、現在の正しい値は参照で示すという形にしてきたのです。値を消してしまうと「その時点で正しい値を知っていた」ことになり、記録の時系列が歪む。事実は正しく直しつつ、記録の正直さは壊さない——この線引きは私が指示していなかった部分で、素直に学びになりました。
おわりに ── 測る前に、物差しを疑う
思えばこの数ヶ月、ずっと同じことをやっています。驚く数字はバグか本物かを疑い、「分からない」を2種類に割り、高得点の内訳を見て、中途半端な7割を10割と0割に分けた。そして今回は、誤差そのものが、物差しの影だった。
共通しているのは、目の前の数字を鵜呑みにせず、それが何を測っているのかを問うという、たったひとつの動作です。新しい技術は何も覚えていませんが、この動作だけは確実に速くなってきました。
残った宿題もあります。今回の調査では説明しきれなかった、別の小さなズレ。これは今の記録の取り方では切り分けられないと分かったので、先に計測の仕掛けを増やすことにしました。測定器は、本体より先——この順番も、もう体に入っています。
個人開発 / 測定設計 / 実測主義 / デバッグ
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
