Mobility Technologies（MoT）として初のリリースとなったタクシーアプリ「GO」。合併前は競合であった「JapanTaxi」アプリと「MOV」のそれぞれの強みを活かし統合を行うことで、新たなタクシーアプリが誕生しました。

タクシー車両のリアルタイムな位置情報連携と高度な配車ロジックによって、アプリユーザーと近くのタクシー車両とのマッチング精度を大幅に向上させ、「より早く乗れる」体験を追求しています。

両社の合併前から構想され、コロナ禍において開発が始まった「GO」。この大規模プロジェクトの裏側には、MoTならではの強みを感じられるストーリーがありました。MoTの開発本部本部長であり、「GO」の開発責任者である恵良和隆に聞きました。

コロナ禍でタクシー業界が苦境に…前例のない大規模プロジェクトでリリース前倒しを決断

――約5ヶ月という短期間で大規模なアプリ統合を実現させる。そのプロジェクトの指揮を依頼された時の、率直なご感想を教えてください。

事業統合により、両社がそれぞれで運営していたタクシーアプリ「JapanTaxi」「MOV」を統合していくことは念頭にあったのですが、のちに決定する「9月リリース」というスケジュールには正直驚きました……（笑）。

――やはり、本来では考えられないほど短い開発期間だったのですか？

そうです。2月初めに事業統合が決まり、まず、4月1日からスタートするMoTの組織体制を決めていく中で主要プロダクトであるタクシーアプリをどうするか、という議題があがりました。基本的には「統合」ありきで、「JapanTaxi」アプリと「MOV」、どちらのシステムをベースにするのかという議論をその時点で始めていたんです。

3月には双方のエンジニアが顔を突き合わせてお互いのシステムを紹介した上で、アプリを統合するにあたっての本格的な議論を開始。大枠の方針は事業統合前に決定し、4月1日に「GO」の開発作業がスタートしました。

――その時点で、9月にリリースできると判断できたのでしょうか？

当初は「11月頃にリリースできるのではないか」と話していましたね。

「MOV」と「JapanTaxi」アプリにはそれぞれ異なる歩みがあります。「JapanTaxi」アプリは長期間運営されてきたため、初期のサービス「全国タクシー」からのレガシーシステムを引き継いでいました。一方「MOV」は歴史がそう長くないため「JapanTaxi」アプリと比べると機能面がシンプルですが、その分、レガシーシステムがない。「GO」のベースにするには「MOV」が適していたんです。

――ベースではない「JapanTaxi」アプリユーザーへの配慮も必要になりそうですね。

まさにそうなんです。これまで「JapanTaxi」アプリで利用できた機能がなくなるというのは、ユーザーにとっての利便性を欠くことに繋がります。そのため「なくなった機能の代替となる新機能を搭載するか、もしくはそれを上回るユーザーメリットが出せる状態で『GO』をリリースしなければならない」という意見もありました。

実際、新機能を搭載することを考えると11月頃のリリースが現実的でした。ただ、コロナ禍において全国のタクシー事業者が大きな影響を受ける中、我々がのんびり開発しているわけにはいきません。少しでもタクシー業界全体の回復に貢献するため、経営メンバーを含めて議論した結果、機能よりもスピードを重視するという意思決定をしました。統合する両アプリのタクシー車両を呼べることが利用者にとっての圧倒的な利便性であり、タクシー利用者の増加につなげられる。その判断から、ミニマムな統合をした状態で、「GO」を9月にリリースすることにしたんです。

事業統合で「昨日の敵は今日の友」、MaaSのドリームチーム結成

――アプリ統合には何名のエンジニアが携わったのでしょうか？

最終的に「GO」に携わっているのは約70名――「JapanTaxi」アプリと「MOV」を担当しているエンジニアの約半数にのぼります。一般的なアプリ開発プロジェクトでこれほど多くのエンジニアが稼働することはまず考えられませんし、私も初めての経験でした……。

――エンジニアの大半が統合アプリの開発に取り組む必要があったと。

そうですね。一時期は全体の8割が「GO」専属で開発に取り組み、残りのエンジニアが既存のプロダクト開発や運用タスクを担当するような状態でした。旧JapanTaxi社にのみ存在していた領域のプロダクトも多くあって、それらは将来的に「GO」と連携してひとつのプロダクトになるものなので、その対応にも並行して取り組んでいます。

今後、タクシー配車管理だけではなく、相乗りなどのより複雑なシステムを含めたモビリティプラットフォームを作り上げるためには、もっと多くのエンジニアが必要です。特に、モビリティサービスに造詣が深いエンジニアが必要なので、旧DeNAオートモーティブと旧JapanTaxi社のエンジニアが集結していることには、非常に大きな意味があると思っています。経験豊富なエンジニアの数、そして組織力。その点が他社との大きな違い、アドバンテージになると確信しています。

――「GO」になり提携車両数が増加します。それに伴いトラフィックも増えますが、サーバーサイドでの苦労などはありますか？

実は、トラフィックの増加はそこまで手のかかる問題ではないんです。統合により確かにトラフィックは増加するのですが、計画的にスケーリングができるので。利用者側でいうと、例えば前日と比較してアクセス数が20倍になることもあり得るため、かなり神経は使いますが、DeNAでゲーム運用を経験してきたメンバーもいるため、極度のアクセス集中への対応も慣れています。車両側に関しても、「明日突然タクシーの台数が増える！」といったことがないため、キャパシティプランニングがしやすいんです。

――「タクシー乗車」というリアルな行動が伴うサービスである分、トラフィックが読みやすいということですか？

はい、その通りです。どちらかというと、利用者のトラフィックよりも車両1台がアップロードする車両動態情報といったデータ総数が増加し、それに伴う処理コストが課題なんですよ。費用が上がるのは仕方のないことですが、それをどこまで低コストに抑えられるのか、そのためにシステムをどのように最適化していくのかが、モビリティの専門家集団としての技術力の見せ所ですね。

――コスト改善は、アプリの機能面にも影響を与えるのでしょうか？

MoTは「ユーザーのより良い移動体験の実現」を目指していますが、乗務員と利用者のスムーズなマッチングを実現するために、実はかなり複数の工程があります。詳しい説明は割愛しますが、既存の様々なサービスの組み合わせでシステムをつくっても、1件の配車注文にかかるコストが大きいのが実情です。これは日本だけの話ではなく、世界的に見ても同じなんですね。

つまり、世界に通用するような「移動を進化させる新機能」を開発しても、同時にコストが上がっていく構造になっています。結果、いくら便利なサービスを開発しても、ユーザーは高額で利用することになるんです。それでは、たぶん誰も使わないですよね（笑）。

――ちなみに、今までどの程度のコストを削減してきましたか？　お答えできる範囲で……（笑）。

回答が難しいですが……わたし自身、コスト改善はこれまでにも取り組んだことがあって、その時はサーバーコストの7割程度を削減できましたね。

――サーバーコスト7割削減は、かなり大きいのでは？

いや全然。今後はもっと削減していく必要があるでしょうね。事業統合前から仕込んでいるコスト改善策もたくさんありますが、その一部は「GO」の開発においても、車両を呼ぶための礎として機能しているんです。

――その「仕込み」や「礎」とは、どのようなものですか？

もともと、「MOV」の車両動態情報は「AWS IoT」でデータ処理をしていたのですが、コストが大きくなってきたため代替しようと考えていました。その際、収集されたデータを束ねて必要なところにディスパッチしていく処理を自分たちで作る必要があり、基礎設計はすでに行っていて、裏側を徐々に切り替えていく準備を進めていたんです。

また、車両のリアルタイムな情報を、様々なサブシステムに連携できる仕組みづくりも併せて進めていました。いきなりAWS IoTから切り替えるのは難しいため、AWS IoTを動かしながら、そこに入ってくる車両動態情報を新システムに流す形です。

「JapanTaxi」アプリに入ってくる動態情報をこの新システムに横流しすることで、双方の車両を同じ動態情報として束ねてディスパッチできるようになりました。これにより、データの処理コストを抑えることができています。

――別の目的で開発していたものが「GO」のコスト改善に活かされたのですね。

そうですね。もともとは「MOV」のコスト削減と今後の展開を見据えた仕込みとして開発していたのですが、思いがけず「GO」で有効活用できたんです。

コスト削減はモビリティ領域に関わるエンジニアの永遠の命題です。なぜなら、いくら便利な機能があっても適正なコストでなければ利用者は増えず、我々が目指す「ユーザーのより良い移動体験」は実現できないからなんですね。現在はコストを削減しながら新機能を開発できているので、未来に向かって確実に前進している――そんな強い手応えを感じています。

他社の追随を許さない、唯一無二のタクシーアプリを創るために

――今後もプロダクト統合やコスト削減、新機能を並行して開発することは重要になりそうですね。

両プロダクトの良さをブラッシュアップして、ひとつのアプリにうまく統合していきたいと考えています。今はプロダクトそれぞれで異なる実装方法を採用していますが、最終的にひとつの実装方法に整理していこうと。とりあえず繋げただけでは、動いたとしても効率が悪く、システムとしても無駄に複雑化してしまうので、リファクタリングして積極的に最適化していく、という考え方ですね。

本当の意味で、“ひとつのプロダクト”をつくっていくフェーズがこれから始まります。大規模なリファクタリングをしつつ、配車注文や決済など各機能のマイクロサービス化を効率的に進め、並行して新機能も開発していく、とてもチャレンジングな仕事になると思っています。

――こうした難易度の高いプロジェクトに携わるエンジニアには、どのような能力・心構えが必要でしょうか？

MoTは技術を強みとしていますが、技術そのものを目的とした会社ではありません。技術は課題解決の手段であるため、プロダクトに向き合えることが重要です。言われたものをそのまま作るのではなく、ユーザーの課題やニーズを理解した上で、より良い体験を追求するための議論をしながら開発を進める必要があるんです。

タクシーアプリは、物理的な“モノ”を前提としたサービスであり、デジタルで完結するサービスと比べて「知らなければならないこと」がリアルの場にたくさんあります。乗客としてのUXはもちろん、比較的年齢層の高いタクシー乗務員にとって使いやすいシステムを考えなければなりません。つまり、ターゲットの条件に合わせたプロダクトデザインが求められるんです。

MoTには、事業統合前に両社が磨いてきた既存システム・資産もあります。それらを活用しながら、より良いUXを追求し、MoTのミッション実現に向けてコミットできる方と共にサービスを作っていきたいですね。
　　　　　　　　　　　　　　　　
 
※掲載内容は2020年10月時点の情報です。

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