MaaSアプリ
「my route（マイルート）」
開発の歩みと、これから描く未来　
[前編]

画期的なサービス発案からデモ開発への歩みと、予想外の反響

― 「my route（マイルート）」の構想は、どのように生まれたのでしょう？

間嶋氏「my routeの前身にあたるプロジェクトの構想は、2014年頃からトヨタ自動車の未来プロジェクト室（当時。以下、未来室）という部署で検討が始まっていました。私が加入したのは2018年からですが、「“もっと移動したくなる環境づくり”を通じて、”すべての人の移動の自由”と”ずっと賑わう街づくり”に貢献したい」というプロジェクトのビジョンは、前任の方たちから大切に受け継がれています。自動車の移動だけに着目するのではなく、さまざまな移動手段の中の一つとして自動車を位置づけ、最適な移動手段を提供したいという考えが、根本にありました。」

― その時点で両社は、どういうお付き合いだったのですか？

― デモ開発はどのくらいの期間で、順調に進んだのでしょうか？

蔡氏「開発期間は約半年。その間はシーイーシーとほぼ毎週打ち合わせをして、あれこれ議論しながらアイデアを形にしていきました。」

辻「シーイーシーは『お客様に言われたものを作る』とか『言われたことだけやる』のではなく、常に『こうした方がよいのではないか？』と提案して、議論し合い、お客様と一緒にアイデアをシステムとして具現化していく基本姿勢を心がけています。」

蔡氏「それはすごく感じました。我々が気づかない、見落としている点を自ら考えて動いていただけるので、本当に助かりました。」

辻「蔡さんをはじめ、トヨタの皆様もそれを受け入れてくださる雰囲気でしたので、早期に良い関係性が築けたと感謝しています。」

― デモをお披露目された反響はいかがでしたか？

蔡氏「その時点では、PC上のみで動作するスタンドアローンシステムでのコンセプト・デモをお披露目しました。その発表会に未来室の方々が来られていて、『ちょうど私たちもビジネス目線で人々の移動総量を増やし、街を活性化させるアイデアがある。』とおっしゃっていただいて、意気投合したのです。」

東京でのテスト実施に向け、約3カ月でマルチOSアプリを開発

次なるステップとして、2018年3月から東京でクローズドなテストが行われることとなりました。

― 東京でのテストは、どういったものだったのでしょうか？

蔡氏「東京でのテストは、約200名の利用者を対象に行いました。どういう属性のユーザーをどのくらい人数集めれば全体像が見えるのか、性別や年齢層を満遍なく把握するにはそのくらいの規模が最適だろうと。ルートを絞り実際に利用していただいて、ユーザーインタビューで声を集め、機能を充実させることが目的です。若干ですがモニターの一般公募も行い、その方々はWebアンケートでデータを集計しました。」

辻「デモ時点ではPC上で動くスタンドアローンシステムで、それをWi-Fiで飛ばしてスマホでWeb画面として見る仕組みでした。それをわずか3カ月間でアプリ化することになったので、大変でした。」

蔡氏「しかも、AndroidとiOSのマルチOSですからね。まだテスト段階だからどちらか片方で、との声もありましたが、作るからにはきちんとしたものを作りましょうという、未来室の強い意向でした。」

辻「Androidに比べ、iOSはどうしても開発に時間がかかります。でもなんとか乗り切ろうと。急遽、スマホ開発チームを増強して、機能制限を付けながら開発しました。」

― テストにあたり、本格的な開発をそのままシーイーシーに依頼された経緯は？

辻「当社は未来室とのお付き合いは初めてでした。蔡さんが推薦してくださったと伺っています。」

蔡氏「シーイーシーにお手伝いいただいたデモがある程度完成しており、技術部分をまた新規でやるともったいないですし、時間もかかります。これまでの関係性も財産と捉えて、ぜひシーイーシーを使い続けたい、とお伝えして了承いただきました。そしてここから、UI/UXを専門とするデザイン会社にもプロジェクトに加わっていただきました。」

― UI/UXとシステム開発の兼ね合いはいかがでしたか？

辻「デザイナーサイドはデザイン視点でユーザーの使いやすさ、見映えにも非常にこだわられます。画面の動作もヌルっとしてくれとか。普通に開発したら標準部品では対応できず、カスタマイズ工数がかさんでしまいます。また、AndroidとiOSでもなるべく挙動や見た目を揃えたい。協議しながら、落としどころを見つけていきました。」

― 「my route（マイルート）」というネーミングも、この時期に決まったのでしょうか？

蔡氏「はい。私は『モビリティプランナー』という名称を考えていたのですが、やはり技術者なので、どうしても機能推しになってしまいます（笑）。新しいサービスだし正解がある訳ではないのですが、とにかく利用者目線でわかりやすいもの、親しみやすいものを、という想いが込められています。」

間嶋氏「当時の資料を見返すと30個程度の案が並んでいましたが、その中でもユーザーフレンドリーで分かりやすいことを最優先とされていました。ネーミングだけでなく、UIデザイン面でもユーザーフレンドリーでありたいと思っています。」

「空想」のデモと「現実」のギャップを、いかにして埋めるか？

― アプリ開発にあたり、特に苦労された点は何だったのでしょうか？

間嶋氏「私はちょうどこの時期にプロジェクトに参画したのですが、このシステムの特徴として連携先が多いことと、加えて決済まで踏み込むため、開発の複雑度や信頼性のハードルが非常に高いということですね。相手方のシステムが、我々の意図通りに動くとは限りませんし、加えて業務フローやオペレーションの制約でできないこともあります。会社も変われば仕組みも変わるのが難しさですね。」

蔡氏「言ってみればデモシステムは空想の世界。それを現実世界で動かすと、想定通りに行かないこと、足りないパラメーターが山ほどあります。連携候補のシステムがきっとこのような振る舞いをするだろうなどと予想して作ってはいましたが、現実は違う。ですので先方に訪問して、システム仕様や業務フローのヒアリングから始めました。」

― 現在ならともかく、当時はまだAPI連携も一般的ではなかったですよね？

蔡氏「幸い、テストに協力いただいた大手タクシー会社が先進的で、当時から他のシステムからタクシーを呼ぶことを想定して、ある程度APIの構想を持たれていました。連携にあたっては互いの要求を出し合い、仕様変更を重ねました。」

― 特に決済機能との連携が大変だった？

蔡氏「当時、タクシーの決済は、土日を挟むと最長3日かかることもあると。アプリを利用して金額がすぐにわからないのは困るのですが、どうしてもタイムラグが発生します。『その間にクレジットカードの限度額を超える』といったケースも発生し得ますので、そういったリスクも考慮しないといけません。こうしたチューニングが、開発段階で山ほどありました。」

辻「各社でAPIがあったりなかったり、仕様も異なります。同じ予約画面で操作したいが、受け手が違うとそれらをすべてシステム側で吸収することになります。例えばこのタクシー会社なら決済まで可能、この会社は車内で現金払いのみとか、そういう判断が入るとシステムが肥大化します。そこをいかに標準化しながら、かつスピーディーに開発するかには、苦労しました。」

― 地図やルート検索は、どのように実現しているのですか？

蔡氏「複数社の検索エンジンを利用しています。さらに当時は電車、バス、車など単独のルート検索のみで、マルチモーダル検索は存在しませんでしたので、その部分はアプリ側で組み合わせる必要がありました。」

辻「当社は先行研究の支援もしており、研究も一緒に行いますが、その道のプロがやった方が速い場合、開発は棲み分けして対応します。実証実験では、ルート検索エンジン各社の検索結果を組み合わせて、マルチモーダル検索の結果となるようにシステム側でさまざまなチューンナップを施し、実現しました。しかし、アプリ側でさまざまな組み合わせを実行すると時間がかかってしまいます。そのため、最終的にはアプリ側で対応したマルチモーダルの検索結果をルート検索エンジン各社へフィードバックし、ルート検索エンジン各社がマルチモーダル検索結果を出せるようにすることで、スピーディーな表示を実現しました。」

my routeプロジェクトで提供したスマートモビリティサービス

事例一覧へ