「12分で着きます」が25分かかった日

昨日の続き。キャスト候補の表に出る「約19分」が、どこから来るのかの話。

最初のバージョンは、白状すると直線距離だった。緯度経度の差から距離を出して、 時速で割る。博多の街中なら大きく外れないだろうと高を括っていたら、 テスト運用で早々にバレた。福岡は真ん中に川と湾がある。直線では2kmでも、 橋まで回ると倍になる場所がいくらでもある。海沿いの子を「12分で着きます」と 案内して、実際は25分。これを2回やったところで作り直しを決めた。

地図会社のAPIを使わなかった理由

普通に考えれば大手の経路APIを叩けば済む。ただこのデリヘル管理システムは、ホテルを選んだ瞬間に 出勤中のキャスト全員ぶんの経路を一度に計算する。電話1本につき十数件、 しかも候補を見比べているあいだに何度も打ち直す。従量課金のAPIでは 月末の請求が読めないし、外の会社のサーバーが詰まった日に電話が取れなくなるのも嫌だった。 なので経路エンジンは自前で持つことにして、地図データを手元のサーバーに積んでいる。 計算は1回あたり数十ミリ秒なので、何度打ち直しても誰も待たない。

生の所要時間は、そのまま使わない

経路エンジンが返す所要時間は、深夜の空いた道を制限速度で走った場合の数字に近い。 夜の繁華街でそのまま案内したら全部遅刻する。そこで画面に出す前に補正をかけている。 生の所要時間に係数を掛け、そこに固定で10分を足す。 係数は曜日・時間帯・天気・近くのイベントで上下するが、上限は決めてある。 10分のほうは駐車と、コンビニやトイレに寄る時間。これは距離に比例しないので 係数側には入れず、足し算で持つ。

この係数と10分は、だいぶ揉めた末の数字だ。最初はもっと大きな係数に5分を足していたのだが、 遠い行き先ほど膨らみすぎて、地図アプリなら20〜30分のところが44分と出た。 安全側に倒したつもりが「遅い店」として案内することになる。 代表的な5ルートを地図アプリの通常時と突き合わせて、 「通常時プラス駐車5分プラス休憩5分」がちょうど良いというところに落ち着いた。 将来また揉めるのが目に見えているので、根拠はメモに残してある。

地図の等時線も同じエンジンから引いている。目的地から10度刻みで全方位に点を打ち、 各点への所要時間を測って15分・30分の境目をつなぐ。 電話口で「30分以内で行ける子」を目で探せるようになったのは、このおまけのおかげだった。