見出し画像

タクシーアプリ『GO』の配車機能を支える「配車ロジック」リニューアルの裏側

タクシーアプリ『GO』配車機能の根幹ともいえる配車ロジック。

タクシーに乗りたいユーザーとユーザーを乗せたいタクシーをマッチングさせるアルゴリズムだ。Mobility Technologies(以下、MoT)では2022年10月に新たな配車ロジック、プロジェクトネームnarutoの試験運用を開始。そして、2023年2月より本格運用がスタートした。

このリニューアルにはどのような意味があったのだろうか。

リニューアルプロジェクトを手がけたAI技術開発部・アルゴリズムグループの老木智章(おいき・ともあき)、 AI技術開発部・プロダクトグループの森下篤(もりもと・あつし)、 GO事業本部・事業企画1部・ビジネス開発グループの脇田謙一(わきだ・けんいち)に、リニューアルの目的、そして成果を聞いてみたい。


配車リクエストを個人最適から全体最適へ

AI技術開発部・アルゴリズムグループ 老木智章

ーまず『GO』における配車ロジックの役割から教えてください。

老木:『GO』において、タクシーに乗りたいユーザーとユーザーを乗せたいタクシーをマッチングさせる機能です。

ユーザーからの配車リクエストがあると、基本的にはなるべく近くを走っている車両に向かってもらうことが多いのですが、ユーザーのなかには「この会社の車両に来てほしい」「空気清浄機を搭載した車両に乗りたい」といった希望をお持ちの方もいます。

今までの配車ロジックは単純なルールベースで処理していました。「予約のときは確実に時間通りに到着してください」というように「◯◯なケースでは、△△してください」という記述がたくさんあったのですが、それぞれがバラバラに実装されていたため複数の条件があるとうまく作動しないようなこともあって。そのあたりの矛盾を解消するために、ルールを統一することになりました。
ユーザーはもちろん、タクシー側のニーズもすり合わせて一番ベストなマッチングを実現するためのプロジェクトがnarutoです。

脇田:もう少し具体的に説明しますね。

今までの配車ロジックは、一つひとつリクエスト順に対応していくイメージなので、個別最適化が起きやすかった。たとえば、僕が配車リクエストをした0.1秒後に別の人がしたら、まず僕のリクエストに対応してから、次の人に対応して……と。

でも、僕の配車リクエストに対応する際に少し待って、その直後のリクエストも含めて検討したら、マッチングの答えは変わり、全体最適化ができたかもしれないわけです。「予約」や「乗務員指定」、「車両指定」といったリクエストごとの“重みづけ”を考慮して、ユーザーが5〜10人ほど並んでいるような状況で最適なマッチングを図っています。

老木:それぞれのリクエストをパラメーター化することで重要度の間で“綱引き”をして、バランスよく最適解を導き出すようにリニューアルしました。

ーそれによってどのような変化があるのでしょうか。

老木:単純なお迎えまでの時間の合計値が、9分から7分に短縮されています。もしかしたら「少し待つようになった」と感じる人もいるかもしれませんが、俯瞰してマッチングの合計時間が短くなっていることはユーザー体験の向上に寄与できていると言えるのではないでしょうか。


想像を超えたリニューアルまでの道のり

AI技術開発部・プロダクトグループ 森下篤

ーリニューアルの過程は平坦ではなかったように見受けられます。

老木:結構面白かったですよ(笑)。最大マッチングという最適化のグラフアルゴリズムを、実務で活用する機会なんて滅多にありませんから。

ー他にもいくつか選択肢はあったのでしょうか。

老木:そうですね。ただ、議論の中で「これくらいシンプルなものでいいんじゃない?」という話になり、最大マッチングを採用しました。

とはいえ、実装までの過程にはかなり苦労しました。先ほど脇田が“重みづけ”と表現していましたが、最大マッチングを使うと「どの組み合わせがどのくらい嬉しいのか」のパラメーターを付与しなければいけないので。

「予約時間に確実に間に合う」や「玄関先まで迎えにいく」、「キャンセルが多い傾向の乗務員とマッチングして待ち時間が長くなるのを防ぐ」などにそれぞれ“重みづけ”していくのはなかなか骨が折れるプロセスでした。

また、当然ですが、現行の機能も達成させながらのリニューアルですからね。エンジニアリング寄りの話ではないかもしれませんが、いくつものルールを引き継ぎながらプロジェクトを進めていくことは大変でした。ソースコードを読んで、書き出して、一覧表をつくって……みたいなことを延々とやりましたからね。

少し技術的なところだと以前のロジックと新しいロジックが同じ動作をしていることを検証するテストツールを新たにつくりましたし……。

ーリニューアルで特に印象に残っていることは。

脇田:「マッチングまでの時間を2秒縮めよう!」という取り組みじゃないですか?

老木:あぁ、そうかもしれない。ユーザーのアプリ上に「車両が決まりました」というメッセージが出るまでの時間は、実はすごく重要な指標です。少しでも遅れるとキャンセル率が上がってしまうので。運用直後に少し遅くなって、会社の上層部から「遅くなって、ユーザーキャンセル率が上がったんだけど」と言われたときは焦りました(笑)。

森下:ユーザーからリクエストがあってからのバックエンドの処理とタクシーのマッチングまでの時間を早くすることに、エンジニアリングコストをかけていた感じもします。

それでも我々だけでは全く解決の目処が立たなかったですね。『GO』自体がマイクロサービス化していて、プレミアムプランがあったり、車両の位置だけを求めてくるためのシステムがあったりと、複数のものに分かれている中で最終的に集めてきてアルゴリズムにかけなければいけなかったので。そのときにひとつでも処理に時間がかかると最終的にユーザーのリクエストが遅くなってしまうので、narutoと関係するさまざまなシステムを横断しながら解決していきました。

narutoの誕生がもたらしたもの

GO事業本部・事業企画1部・ビジネス開発グループ 脇田謙一

ーリニューアルによる成果は感じられていますか?

老木:正直、まだ試験運用ではあるのですが、ドラスティックに変えた割には特にクレームなどがなく胸をなでおろしているところです(笑)。

脇田:少なくとも予約の失敗率は下がっていると思いますよ。たとえば雨天の朝帯など車両が枯渇しがちな状況下で『GO』は空車車両が出現するタイミングを予測して予約を受け付けています。下手をすると失敗する可能性もあるのですが、narutoの誕生によってアルゴリズムがうまく機能することで、うまく予約とマッチングができています。

先日も早朝から雨が降っていましたが、配車できなかった報告は全くなかったので、少しずつ成果は出ていると感じます。

ーみなさんのモチベーションという点ではどうでしょうか?

老木:組織的には大きくモチベーションは変わりました。もともとは配車のシステムは我々ではなく全く別のバックエンドチームが担当していたのですが、機能を切り出して専任を置きました。『GO』にとっても「もっと効率化を目指す」という意思表示でもあるので、これまでとはスタンスが全く異なってきていると思います。

森下先を見据えてチャレンジできた点は大きいと思います。結果ありきだったらどうしても後手後手になってしまうので……そういう意味では取締役や部長クラスが「ここにコストをかけていかないと、いずれ『GO』が立ち行かなくなる」ことを認識していることの証とも言えるかもしれませんね。

脇田:ビジネスサイドからの話をすると、実は『GO』のユーザーが増えたことで2022年の後半ぐらいから車両の供給不足になり始めていました。車両の供給に関しては別のプロジェクトで解消に向けて動いているのですが、限られた供給の中で効率よくマッチングすることは重要なポイントで。

だから、2022年春ぐらいの段階では「ゆるやかに配車ロジックをリニューアルしていこう」という温度感だったのですが、夏ぐらいには「「何が何でも今年の冬までには!」という雰囲気に変わってきてしまった経緯があります。
プレッシャーのある状況下ではあったもののエンジニアがプロジェクトを主導してくれて、専門性の高いメンバーが「こうしたら社会にとって価値になるんじゃないか」と議論しながら、形にしてくれた。エンジニアドリブンで進めたことが、成功の秘訣だと感じています。大変な状況下でも歯を食いしばって頑張ってくれたことに感謝です。

森下:正直「本当にリリース間に合うのか」みたいなこともあったんですけどね(笑)。

老木:個人的にはAI技術開発部としてはこれまで『GO』のクリティカルな部分に携わる機会は少なかったので……一瞬でも止まったら連絡がくるような部分に携われたことはやり甲斐を感じましたね。オーナーシップもあったのでモチベーションは高かったです。

インフラと呼ばれるサービスに携わる責任

ーnarutoのリニューアルを経て、改めてMoTのエンジニアとして働く魅力を教えてください。

老木いろいろありますが、やはりユーザー数の多さは魅力です。そのままやり甲斐にもなりますし、扱うデータが多いことはAIを扱うエンジニアとしては嬉しいことなので。しかも、意思決定がデータドリブンで、すぐに反映される。提案から実現までのリードタイムがすごく短いんですよね。そのあたりはワクワクできるポイントです。

森下:narutoの開発は簡単ではありませんでした。要求水準は高いし、つなぐシステムの数は多いし……でも、単に機能をつくってサービスをリリースするだけではなく、難易度が高いエンジニアリングにチャレンジできたことはエンジニアとしてはやっぱり嬉しいし、これからのキャリアにとってもいい経験になったように思います。

ーチームとしてはいかがでしたか?

脇田:基本的にプロジェクトはそれぞれのスペシャリティを持っている人たちを集めて仮想チームが組まれることが多いので、馴れ合いがなく建設的な議論ができたと思います。かなり忌憚のない議論がありましたよね(笑)。

老木:ビジネスサイドともたくさん議論しましたね。「この機能をやめませんか」と言う僕に「必要なんです」と言ってくれて(笑)。

脇田:そういう本音の議論ができないと機能が偏ってしまうので(笑)。

ーこれからのnarutoについても教えてください。

森下:今後機能を追加して、保守・運用していくわけですが、マッチングが遅くならないようにこれからも戦い続けていく所存です。

老木:これからが本番ですからね。一応最低限のラインはクリアできましたが、もっと効率化していきたいし、データドリブンな試作決定や仕組みの導入も進めていきたい。せっかく専念できるチームができたので、着手できなかった部分に本腰を入れていきたいです。

そしていずれは、データなどを活用してユーザビリティを客観的に良くしていく意識を社内にインストールしていきたい。効果を見て良くしていくステップを配車ロジックから広めていきたいと思います。

脇田:アーリーフェーズだったら「まだ未完成だけど面白そうだから使ってみる」みたいなユーザーもいたかもしれませんが、もはやインフラと呼べる規模感なので温かい目を期待してはいけません。要求水準はどんどん上がっていきますが、それだけ社会とつながっているわけですから。これからも道は険しいかもしれませんが、テクノロジーの力で世の中の課題を解決していきたいですね。

老木 智章(おいき ともあき)AI技術開発部・アルゴリズムグループ 
日鉄ソリューションズにて金融システムや画像認識システムの開発に携わる、5年ほどの勤務を経て、三菱電機へ。強化学習論文の作成などを経験したのち、DeNAへ。その後、MoTへ出向。

森下 篤(もりもと あつし)AI技術開発部・プロダクトグループ
SIにて、システムアーキテクトとして医療機器メーカー向けiPadアプリなどの開発を担当。その後、大学ベンチャーでビッグデータDBの研究開発を経験する。2018年よりDeNAオートモーティブ事業部へ。以来、主にお客様探索ナビ開発を担当する。『Visual Studio Code実践ガイド』(技術評論社・2020年)執筆。

脇田 謙一(わきだ けんいち)GO事業本部・事業企画1部・ビジネス開発グループ グループマネージャー
beBit、コンサルティング会社でのコンサルタントとしての経験を経て、DeNAオートモーティブへ。現在は、MoTで事業企画を担当する。

※掲載内容は2023年2月時点の情報です。

採用情報
MoTでは、共には働く仲間を積極的に募集中です。
興味がある方は、お気軽にご連絡ください!