日本交通株式会社のグループ会社であるJapanTaxi 株式会社は、100年以上の歴史ある老舗産業であるタクシー業界にITの力を持ち込み、日本初の配車アプリ「JapanTaxi」に代表される配車プラットフォームから、決済プラットフォーム、広告事業、IoT 事業、モビリティ研究開発事業まで、多岐に渡った事業を展開。日本一のみならず、「世界一の乗車体験」を実現するべく、ソフト面・ハード面での挑戦を続けています。
「『移動で人を幸せに。』というミッションの下、人々の移動をささえるために『タクシー』移動体験の改善、タクシー配車に関わるサービスを企画、開発、運営をしております。タクシーに乗車されるお客様のみならず、乗務員様、タクシー会社様を含めてサポートしていき、より良い交通インフラを築いていくことを目指しております。」( 江尻好治氏)
社員数は2016年時点の約30名から2019年2月時点で約150名にまで増え、現在も人員を拡張中。そのうち半数以上がエンジニアで、5,6カ国籍からなるインターナショナルかつダイバーシティの高いメンバーでチームが構成されています。
より良い移動サービスを提供するためには、配車アプリの提供だけでは難しく、JapanTaxiではタクシー車内のハードウェアまで内製化して企画、開発をしています。
JapanTaxi のお客様はタクシーの乗客だけではなく、タクシーの乗務員様、その乗務員様が所属するタクシー会社様も主要カスタマーになっています。広告事業も展開しているため、広告主様も大事なお客様となります。
JapanTaxiのビジネスにおいてテクノロジーが果たす役割
700万DL を越える日本最大級の配車アプリ「JapanTaxi」をはじめ、交通・モビリティにおける革新を起こすべく、タクシーを中心としたサービスの提供を行なっているJapanTaxi は、ソフトウェアからハードウェアまで一貫したシステムの開発を行っています。
「JapanTaxi」アプリは全国47都道府県のタクシー会社を網羅。すでに日本国内のタクシー車両のおよそ1/3にあたる全国約7万台をカバーし、圧倒的な供給量を誇ります。
また、2020年の東京オリンピックに向けて、海外の利用客向けに韓国の「カカオT」や台湾の「TaxiGo」と連携し、他国のサービスとAPI 連携。タクシー車載タブレットでのクレジットカード・交通系IC・電子マネーなど複数決済の対応など、配車という側面のみならず、日々スピーディに変化するビジネス環境対応しなければなりません。そのためには、機動的な開発環境を構築し、素早いシステム開発を行っていくことが求められています。
JapanTaxiのシステム環境
サービスはほぼ全てDockerで動作するようになっており、Microsoft Azure（以下 Azure）上のAKS、Amazon Web Service（以下 AWS）上のECSやEKSで動作するようにインフラを構築しています。
サーバーサイドはRuby、Go、Scalaをメインで使用しています。それぞれのビジネス特性やチームのスキルに応じて言語を使い分けています。クライアントサイドはSwift、Kotlin、JavaScript はReact を使い開発しています。アプリケーションの特性によりAWS LambdaやAzure App Service などで運用している部分もあります。
JapanTaxi が抱えてきた課題
グループの日本交通株式会社は東京最大手のタクシー・ハイヤー会社ですが、兄弟会社であるJapanTaxi は、まさにIT ベンチャー・スタートアップ的組織として独立した存在です。少人数で開発しているため、自前でのモニタリングサービス運用には限界があり、発足当初から外部のモニタリングサービスを利用する必要がありました。
配車、決済に関する様々な企画と開発は常に行われており、多くのプロジェクトに対し、少人数で開発し続けなければなりませんでした。それゆえに、サービスのモニタリングの設置は、導入・運用が容易なサービスが必要でした。また、プロジェクトの性質に合わせて適切なクラウドサービスを利用しているため、AWS、 Azure、他の開発を支援するツールなどとの連携ができるツールも必要でした。
その結果、当初APM はNew Relic、インフラは他社モニタリングツール、という運用体制を採用していましたが、モニタリングコストが割高になってしまう問題がありました。
さらに、ビジネス環境の急速な変化に伴い、日々新たなサービスのリリースとアプリケーションのデプロイが求められました。そんな中で、デプロイ直後にパフォーマンスの低下が発生する問題が時折起きていました。
New Relicへのモニタリングツール等の一元化により、監視コストの節減とカスタマーエクスペリエンスの向上を実現
New Relic からInfrastructure のサービスと、AWS とのインテグレーションがリリースされたことにより、Kubernetesとの連携などを含め、元々他社製品を利用し行っていたモニタリング機能がNew Relic Infrastructureでも十分カバー可能であるとわかり、コスト面でメリットがあるNew Relicに移行となりました。
「New RelicのAPM はサーバーサイドではほぼ採用しているので、New Relicの多言語対応は非常に重宝しています。また、Kubernetesのインストレーションも簡単にできて使えたので、こちらも重宝しました。」（Quentin Plessis 氏談）
New Relic APM によりデプロイ直後のパフォーマンスの低下に関しても、検知が容易になったのに加え、各種ドリルダウンの機能により、その修復が容易になりました。またカスタマーエクスペリエンスのレベルを可視化することにも繋がっています。
New Relic 側ではAPDEXスコアや、レスポンスタイムを基準にアラートを設定し、電話やSlackで通知を受ける仕組みを構築していますが、これにより問題発生と同時に検知をし、修復するというフローが出来上がりました。
「9月の台風の直後などは、アクセスの集中によるパフォーマンスの低下からかなりのアラートが上がり、繁忙期のシステムの状況が肌感覚として可視化された、といったベネフィットもありました。」( 水戸 祐介氏談)
上記に加え、JapanTaxiではInsights 上にダッシュボードを作成し、インフラのリソース状況からアプリケーションのパフォーマンス状況までを横断的に監視しています。それゆえに、Insightsのモバイルアプリは、スマホ上でも全く同じダッシュボードを見ることができ、いつでもどこでもリアルタイムで状況が確認できるので、これらの機能が非常に重要な役割を担っています。
