使い勝手が悪く、二度と使いたくないと思った地図を見たことはありませんか？例えば、調べたい地図上のポイントがなかなか読み込まれないとか、地図を少し動かすたびに「地図情報を更新する」ボタンをタップしないとポイントが更新されない、など。こうした直感的でないUXにより、コンバージョンや収益が失われていることは想像に難しくないと思います。Webサイトでは、ロード時間の遅さやユーザーとのインタラクションの悪さは、リピーターを減らし直帰率を高めます。アプリであれば、せっかく獲得したユーザーがアプリを削除してしまい二度と戻ってこないこともあり得ます。こうした難しい問題をすべて解決し、しかも時間とお金を大幅に削減できるのが、MapboxのMTSです。

まだMTSをご存知でない方のために、下に動画で非MTSとMTSを横に並べて比較してみました。左はクライアント側のアプリケーションがAPIからポイントを取得していて、右はMTSにアップロードされていることで、ポイントがMapboxサーバーから取得されています。どのように実装されているのか、ぜひこのコードをご覧ください。

面白いことに、左のアプリケーションを構築して維持するには、右のものよりもはるかに多くの労力と時間が必要になりそうだということがご理解いただけると思います。一度サーバーにアップロードするだけで配信はMapboxが行うという、UXのみならずデベロッパーの利便性をも重視したシンプルな仕組みになっているからです。ここでは、いくつかのトピックをご紹介します。

サーバーサイドの開発

左側では、クライアントサイドは特定の地域内のポイントのみを必要としているため、このロジックを処理し、特定のポイントのみを返すサーバーサイドのアプリケーションが必要となります。この作業は意外と困難です。「ウェブやモバイルの負荷を処理するために、どのようにAPIを設計するか」、「一度のリクエストで返せるポイントの最大数はどれくらいか」、「このデータをクライアントにどのくらいの速さで提供できるか」、「このサービスをマルチリージョンで提供するにはどうすればよいか」、「このシステムを維持するためには何人のエンジニアが必要か」などなど爆発的に課題が増えます。これらを解決するためにはたくさんの議論と時間が必要となりますが、MTSを使用した場合、これらのポイントはMapboxの最先端のグローバルインフラを使用してタイルと共にクライアントに配信されるため、それらを考える必要はなくなります。デベロッパー側は、ジョブなどを通じMTSにアップロードするだけです。（チュートリアル、このデータセットのクイックガイド）

クライアントサイドの開発

左側では、クライアントサイドはデータを素早く表示する必要がありますが、その際に解決すべき問題がたくさんあると思います。「良いUXを提供しつつ、負荷と帯域幅を削減するためには、どのくらいの頻度でAPIを呼び出すべきか」、「ユーザーが地図を少し動かした場合、どの条件で再度APIを呼ぶべきか」、「地図がズームアウトして地域が大きすぎる場合はどの様に表示すべきか」などです。右図では、当社のSDK（iOS、Android、Web）を使ってポイントの取得、キャッシュ、スタイリングが自動的に行われるため、開発者はこれらの問題を考える必要がありません。地図をズームアウトしたときにクラスターを表示することもできます。

複数のプラットフォーム開発‍

左側で全ての課題を解決できた場合でも、同じロジックをiOSやAndroidなどの他のプラットフォームにも導入する必要があります。これにはより多くの開発時間が必要となりますが、右の場合は、MTSにアップロードした後、Mapbox Studioでポイントの外観をデザインすれば、各クライアントのコードベースを更新することなく、すべてのプラットフォームに反映することが可能です。。もちろん、クリックやタップなどのユーザーインタラクションに応じてデザインを変更する必要がある場合は、そのようなロジックを各プラットフォームに実装する必要があります。

テクニカルサポートエンジニア

鈴木拓人