電車の経路が1件も返ってこない — 「終電後だから」ではなく、日本が除外されていた — 制作日誌 #17

複数の目的地を回る経路アプリで、移動手段に「電車・バス」を選べるようにした。ところが実装した直後から、**所要時間が全部「取得できず」**になる。

このとき、私は最初にこう考えた。

• 深夜に試しているから、終電が無いのでは
• 目的地どうしが近すぎて、電車を使う経路にならないのでは
• 実装のどこかで、移動手段の指定を間違えているのでは

もっともらしいが、全部推測だった。推測のまま直しにいくと、直らないものを直そうとして無限に時間が溶ける。なので、先に実験することにした。

対照実験

同じ鍵・同じ座標で、条件だけを変えて叩いた。結果を全部並べる。

この表を見た時点で、私の3つの推測はすべて否定された。

• 時間帯が原因なら、朝10時では返るはず → 返らない
• 距離が原因なら、車や徒歩でも同じ座標で失敗するはず → 車も徒歩も成功する
• 実装が原因なら、ニューヨークでも失敗するはず → ニューヨークは成功する

**「同じ実装・同じ鍵で、地域だけを変えると成功する」**という一行が、原因を地域に確定させた。

公式に書いてあった

そこで公式のFAQを読みに行った。「どの国で乗換案内が使えますか」という項目に、対応範囲の説明があり、そこから除外される対象が挙げられている。日本の交通事業者が名指しで除外されていた。

これは技術的な制約ではなく、交通事業者との契約の線引きだ。したがって、

• 実装を直しても返らない
• 時間が経っても返らない
• 鍵の権限を増やしても返らない

つまり**「待てば直る」ではなく「別の手段を用意する」以外に道が無い**種類の問題だった。バスも同じ扱いで、バス限定で聞いても0件だった。

代わりに使ったもの

日本の電車・バスの所要時間が要るなら、国内の乗換案内サービスを使うしかない。実装して分かったことも書いておく。

• 路線バスもちゃんと返る。 山間部のバス（35分・路線バス）まで返ってきた。ただし街中では電車のほうが速いので、電車の経路が優先される
• 駅名・バス停名の文字列で受け取る。 座標から直接は引けないので、座標→最寄り駅を引く窓口を挟む必要がある
• 🔴 1リクエストごとに実費がかかる。 ここが設計に直結した

最後の点が重い。目的地が5つあると、総当たりの所要時間表を作るには20回の問い合わせが要る。1回の操作で月の予算を使い切る計算になるので、総当たりの表を作る機能では使えない。結果として、電車・バスは有料プラン限定・かつ総当たりでは使わない、という設計にした。

「できない」と分かったあとの設計

代替サービスが有料で、しかも1リクエストごとに課金される、と分かった時点で、機能の形そのものを決め直した。

BとDを組み合わせて、「有料プランの人が、必要な区間だけ調べる」という形に落ち着いた。

ここで大事だったのは、制約を先に確定させてから機能の形を決めたことだ。順番が逆だと、作った後に「これは原価的に出せない」と気づいて捨てることになる。外部サービスの単価は、仕様を書く前に調べるという順番に変えた。

学んだこと

• 推測で直しに行かない。 私の3つの推測はもっともらしかったが、全部外れていた。実験は30分で済んだ
• 対照実験を1つ入れる。 「同じ実装で、条件を1つだけ変えたら成功する」という結果が、原因を確定させてくれる。今回は「地域を変える」が決め手だった
• 失敗の一覧より、成功の一覧を作る。 どこまでが動くかを並べると、動かない範囲の輪郭が出る
• 公式ドキュメントは、機能の説明より先に「対応範囲」を読む。 私は使い方の説明ばかり読んでいて、対応範囲の記述を最後まで開いていなかった
• 地域による制限は、時間で解決しない。 「そのうち対応するだろう」と待つ判断が、一番損をする

「サービスの仕様上できない」と分かるのは、悔しいようで実は良い結果だった。直せないと確定した時点で、代替案を探す作業に切り替えられるからだ。原因が分からないまま試行錯誤を続ける状態が、一番高くつく。