配車計画は保存しない。毎分、ゼロから作り直す

この画面の裏で動いている配車計画は、どこにも保存していない。毎分、その時点の予約と ドライバーの状態からゼロで作り直して、店ごとにキャッシュへ置くだけだ。 昨日書いた「担当配車を開く」の飛び先がこの配車監視で、開いた瞬間に目に入るのは 「稼働ドライバー 4 名・送迎 26 停車・全便 間に合う見込み」の一行と、ドライバーごとに色を分けた地図。 一行目が緑なら何もしなくていい。赤に変わって「遅延見込み」「未割当」「タクシー推奨」「座標なし」の 件数が並んだときだけ下へ読み進める、という順番で組んである。

計画の中身は、予約1件をキャストごとの「送り」と「お迎え」の2本に分解して、 勤務中のドライバーのルートへ安いところから差し込んでいく方式だ。 1台に乗せられる人数は車ごとの定員（未設定なら3名）、勤務時間の外には入れない、というのが破れない制約で、 予約時刻への到着だけは遅れてもいいが遅れた秒数ぶん重く罰するやわらかい制約にした。 全部を固い制約にすると、数分遅れる便が片っ端から「未割当」へ落ちる。遅れは遅れとして赤く残すほうが、現場の判断材料になる。 送りは予約の10分前に着くよう出発を逆算し、それより早くは迎えに行かない。 接客が終わって次の予約まで45分以内なら現場から次の現場へ直送、それより空くなら一度事務所へ戻す。 お客様のところにキャストを置いて帰る計画は、このデリヘル管理システムでは作らない。

毎分作り直すことの副作用

毎分ゼロから最適化すると、ドライバーの現在地が少し動いただけで「いま運んでいる人」が別の車に付け替わることがある。 7月14日にこれで困った。ドライバーの画面には次の行き先を音声で読み上げる仕組みがあって、毎分違う指示が飛んだ。 直したのは、ドライバーが「向かう」「乗せた」を押した送迎はそのドライバーのルート先頭にピン留めして、 再計算でも動かさないこと。乗車中なら車内人数も乗せた状態から数え始める。 それまでは、乗車中なのに事務所でもう一度乗せ直す計画になっていた。 計画は毎分作り直すが、始まってしまった送迎は現実のほうが正しい。

同じ計画を三つの見え方で

地図はドライバーの色でルートを描き、番号が停車順、塗りつぶしが乗車、枠線が降車。 ドライバー名のチップを押せばその1台だけになり、着信履歴の「担当配車を開く」から来たときは最初からその1台に絞られる （本日の停車が無いドライバーなら全車のまま）。 線は道なりで引くが、計画の探索で使う移動時間は直線距離に迂回係数を掛けた概算だ。 同じ区間を何度も評価する探索のたびに経路サーバーへ聞きに行くのは重すぎるので、本物の道は描くときだけ使う。

その下のタイムラインは縦が時刻で、停車が到着予定の位置に並び、赤い破線が現在時刻。 何も無い2時間以上の空白は省略バー1本に畳む。夕方まで予約が無い日の午前に、画面の大半が空白になるのを避けるためだ。 いちばん下がドライバー別の停車カードで、乗車事務所→お届け→お迎え→降車事務所の順に到着目安・車内人数・ナビのリンクが付き、 間に合わない降車は「到着目標 21:00 +8分 遅延」と赤字になる。 地図で近さを、時間軸で詰まり具合を、カードで手順を見る。どれか一つに寄せてみたこともあるが、誰かの用が済まなくなった。

251秒

6月9日、予約の多い日の計画生成に251秒かかっていることが分かった。 挿入位置の探索が三重ループで、時刻を比べるたびに日時オブジェクトを作っていて、その数が4千万個。 時刻を整数の秒に置き換え、配列のコピーを最良位置が決まった後の1回にし、ルートが20停車を超えたら末尾8か所だけ試す、で0.9秒になった。 速くなったこと自体より、「毎分作り直す」という前提を捨てずに済んだことのほうが大きい。 その少し前の6月3日には、兼任ドライバーの設定を外したのに配車監視から消えない、という報告もあった。 計画のキャッシュを予約の変更でしか捨てていなかったせいで、ドライバーの増減では古い計画が生き続けた。 毎分作り直しているつもりで、ドライバーの変更だけ取りこぼしていた。

宿題も残っている。探索に使う移動時間は平均22km/hに迂回係数1.3を掛けた固定値で、 受付画面の到着予定に入れている時間帯の補正はここには入っていない。入れるなら計画の速さと相談になる。 明日は、この計画がドライバーのスマホにどう届くか、ドライバーアプリの側を書く。