Mobility業界のDXを支えるSmartDriveの分析基盤

スマートドライブの事業紹介〜事業の領域と特徴

スマートドライブの石川です、よろしくお願いいたします。私は大学で数学系の学科に所属し、卒業後は人材系ベンチャー企業でCRMシステムやMA、DMPやBIなど、データに関わる最新のテクノロジーの導入利活用を推進してきました。その後、スマートドライブへ参加し、Mobility Data Sientistとして移動データの解析や移動データと関連性の高い周辺領域のデータを分析しています。

スマートドライブは「移動の進化を後押しする」というビジョンを掲げ、あらゆるIoTデバイスから移動のデータを収集し、それを弊社のプラットフォームに蓄積して事業化している企業です。ビジネスモデルはデータインプット領域、データプラットフォーム領域、データアウトプット領域と大きく三階層に分けて展開しています。

データインプット領域

スマートドライブが開発している、シガーソケットに装着するタイプのコネクテッドデバイス。このデバイスを車に装着すると、1秒に１回GPSを取得し10秒に１回通信して弊社のプラットフォームにデータが蓄積されます。その他にも、他社で開発したドライブレコーダーや温度センサ、タイヤの空気圧情報を通信で取得するセンサなどからデータを集めています。車が直接通信するコネクテッドモビリティサービスも増えておりますが、弊社では後付け可能な車載器で四輪車や二輪車が直接通信するモデルを構築しています。

データプラットフォーム領域

さまざまなデータタイプに応じた移動にまつわるデータを弊社のプラットフォームに収集して解析可能な状態で保持しています。

データアウトプット領域

スマートドライブはデータを活用した3つのサービスを展開しています。

法人向けには、車両管理サービスのSmartDrive Fleetを提供しています。これは社用車の事故削減や適切な配車、車両台数の最適化を支援するものです。また、BtoBtoCサービスとして、ドライバーが安全運転をすればするほどポイントや買い物で得するクーポンがもらえるドライバ―エンゲージメントサービスを、BtoC向けには高齢者が危険な運転をするとスマホに通知がくる運転見守りサービスのSmartDrive Familiesを展開しています。

また、スマートドライブは「MobilityData Sience、Mobility Data Platform、Mobility Ecosystem」という3つの特長と強みを持ち合わせた事業を展開しています。

Mobility Data Sience

スマートドライブの創業後、初めに請け負った仕事が柏の葉スマートシティの移動データ解析でした。データ分析からスタートした会社ですし、ここから多くの分析事例を積み重ねてきましたので、データ分析に関しては弊社のもっとも強みとするところです。

Mobility Data Platform

スマートドライブの事業の中核にあるのがプラットフォームです。このプラットフォームをベースに自社サービスを展開するだけでなく、他社さまにもご利用いただきながらサービス開発に協力させていただいています。

ユピテルさまとの連携事例では、同社が開発したドライブレコーダーのデータを弊社のプラットフォームに連携し、ドライバーが危険運転をした前後10秒ずつ合計20秒の動画を、検知した瞬間にサーバーへ通信し、管理者が管理画面で確認できるようにしました。次にホンダ社が提供している二輪EVテレマティクスサービスは、弊社のプラットフォーム上に直接構築したものです。データの収集からサービスにアウトプットできる仕組みを0から構築するとなるとかなりの工数を要しますが、弊社のプラットフォームを活用いただければスピーディに構築できます。その点をホンダさまに高く評価いただきました。

このように、さまざまなIoTセンサーのデータを弊社のプラットフォームに蓄積する仕組みを評価いただき、NEDOの助成金にも採択されました。現在は政府の支援を受けながら、コネクテッドモビリティやコネクテッドカーサービスの開発に注力しています。

Mobility Ecosystem

近年、モビリティ業界を変革するMaaSやCASEといったワードが注目され、すでに数々の実証実験が進められています。しかし、これらが描く未来図は壮大すぎるため、一社のみで成功させることは非常に難しい。私たちは業界業種の垣根を超えて企業同士がコラボレーションし、個々が持つ強みを生かしながら、新たなMaaS系のサービスを創出していくべきだと考え、さまざまな業界、企業が協業できる新たな場所を作るためにMobility Transformationというイベントやセミナーを開催しています。

2019年11月には虎ノ門ヒルズで開催し、業界業種を問わず多くの方にご参加いただきました。また、今年の4月末にもオンラインでカンファレンスを開催。どこにいても参加できるということで、都心部から地方にお住いの方まで、7,700名以上の方が参加してくださいました。

イベントの詳細についてはMobility Transformation公式サイトからご確認いただけます。このサイトからセッションの資料もダウンロードできますので、ご興味がありましたらぜひダウンロードください。

データインプット領域

スマートドライブが開発している、シガーソケットに装着するタイプのコネクテッドデバイス。このデバイスを車に装着すると、1秒に１回GPSを取得し10秒に１回通信して弊社のプラットフォームにデータが蓄積されます。その他にも、他社で開発したドライブレコーダーや温度センサ、タイヤの空気圧情報を通信で取得するセンサなどからデータを集めています。車が直接通信するコネクテッドモビリティサービスも増えておりますが、弊社では後付け可能な車載器で四輪車や二輪車が直接通信するモデルを構築しています。

データプラットフォーム領域

さまざまなデータタイプに応じた移動にまつわるデータを弊社のプラットフォームに収集して解析可能な状態で保持しています。

データアウトプット領域

スマートドライブはデータを活用した3つのサービスを展開しています。

法人向けには、車両管理サービスのSmartDrive Fleetを提供しています。これは社用車の事故削減や適切な配車、車両台数の最適化を支援するものです。また、BtoBtoCサービスとして、ドライバーが安全運転をすればするほどポイントや買い物で得するクーポンがもらえるドライバ―エンゲージメントサービスを、BtoC向けには高齢者が危険な運転をするとスマホに通知がくる運転見守りサービスのSmartDrive Familiesを展開しています。

また、スマートドライブは「MobilityData Sience、Mobility Data Platform、Mobility Ecosystem」という3つの特長と強みを持ち合わせた事業を展開しています。

Mobility Data Sience

スマートドライブの創業後、初めに請け負った仕事が柏の葉スマートシティの移動データ解析でした。データ分析からスタートした会社ですし、ここから多くの分析事例を積み重ねてきましたので、データ分析に関しては弊社のもっとも強みとするところです。

Mobility Data Platform

スマートドライブの事業の中核にあるのがプラットフォームです。このプラットフォームをベースに自社サービスを展開するだけでなく、他社さまにもご利用いただきながらサービス開発に協力させていただいています。

ユピテルさまとの連携事例では、同社が開発したドライブレコーダーのデータを弊社のプラットフォームに連携し、ドライバーが危険運転をした前後10秒ずつ合計20秒の動画を、検知した瞬間にサーバーへ通信し、管理者が管理画面で確認できるようにしました。次にホンダ社が提供している二輪EVテレマティクスサービスは、弊社のプラットフォーム上に直接構築したものです。データの収集からサービスにアウトプットできる仕組みを0から構築するとなるとかなりの工数を要しますが、弊社のプラットフォームを活用いただければスピーディに構築できます。その点をホンダさまに高く評価いただきました。

このように、さまざまなIoTセンサーのデータを弊社のプラットフォームに蓄積する仕組みを評価いただき、NEDOの助成金にも採択されました。現在は政府の支援を受けながら、コネクテッドモビリティやコネクテッドカーサービスの開発に注力しています。

Mobility Ecosystem

近年、モビリティ業界を変革するMaaSやCASEといったワードが注目され、すでに数々の実証実験が進められています。しかし、これらが描く未来図は壮大すぎるため、一社のみで成功させることは非常に難しい。私たちは業界業種の垣根を超えて企業同士がコラボレーションし、個々が持つ強みを生かしながら、新たなMaaS系のサービスを創出していくべきだと考え、さまざまな業界、企業が協業できる新たな場所を作るためにMobility Transformationというイベントやセミナーを開催しています。

2019年11月には虎ノ門ヒルズで開催し、業界業種を問わず多くの方にご参加いただきました。また、今年の4月末にもオンラインでカンファレンスを開催。どこにいても参加できるということで、都心部から地方にお住いの方まで、7,700名以上の方が参加してくださいました。

イベントの詳細についてはMobility Transformation公式サイトからご確認いただけます。このサイトからセッションの資料もダウンロードできますので、ご興味がありましたらぜひダウンロードください。

Mobility Data Platformの活用事例

ここからは、Mobility Data Platformを用いた共創事業についてご紹介します。

小田急電鉄×スマートドライブ

SmartDrive Familiesを小田急沿線にお住いの方々に配布し、小田急電鉄へのエンゲージメントを高めるためのデータの分析をしています。

ロイヤリティマーケティング×スマートドライブ

ロイヤリティマーケティング社は、Pontaカードをマネージしている企業です。Pontaカードを利用しているユーザーの移動データを掛け合わせて新たなサービスを作ろうと、ディスカッションから参加させていただきました。実際に5月から実証実験を開始し、今もデータを蓄積している最中です。この実験では、Pontaの利用履歴と移動データを掛け合わせて分析します。

ホンダ×スマートドライブ

先述しましたが、EVの二輪バイクの分析です。ドライバーの運転挙動と消費電力を紐づけ、燃費効率が悪いユーザーの特長を分析したり、適切な充電タイミングをお知らせできるようにしたり、ユーザーエンゲージメントを高めるためのサービス開発を行っています。

住友商事×スマートドライブ

住友商事さんは、昨年から社員を対象としたオンデマンドバス実験を実施していますが、スマートドライブはその裏側にある基盤を構築しました。データ収集の一部を弊社のデバイスで行い、パートナー様が開発したオンデマンドバスアプリと予約管理システムデータを掛け合わせて分析しています。

出光×スマートドライブ

出光さんが最近発表した超小型EVの実証実験をする際に、Mobilty Data Platformを採用いただきました。EVのカーシェアの利用を促進するにはどのような態度変容が必要か、どんなタイミングでどのような通知を出すのかを共に検証しています。

スマートドライブが主とするのはMobility Data Platformです。移動のデータをより大きな価値に変えるために、自社に限らず、さまざまな企業さまと連携して事業開発を行っています。スマートドライブではMobility Data Platformをベースにさまざまなサービスを提供していますが、この分析基盤の一部として採用しているのがLookerです。後半では、分析を強みとする弊社がLookerを選んだ背景、現在の基盤になった経緯について詳しく解説していきましょう。

ここまでに数多くの質問をいただいていますので、いくつかお答えさせていただきますね。

質問Mobility Data Platformに入るデータはお客様保有のデータが直接投入されるのでしょうか。

弊社のデバイスをご利用いただいた場合はそのデバイスを利用した分のデータが、お客様自身がデータを保有している場合は分析の部分のみを私たちが対応することもあります。

質問プラットフォームは日本リージョンでしょうか。

スマートドライブは海外展開も積極的に行っており、直近ではマレーシアに拠点を構え、同地域でもサービスを構築しています。国を跨ぐと規格などが変わってしまうため、現在は日本とマレーシアのリージョンの2つです。

質問シガーソケット以外の開発予定はないのでしょうか。

検討はしていますが、直近では開発の予定はありません。ただ、他社による3rdPartyデバイスを弊社のプラットフォームにつなげるお話は多く頂戴しているため、自社に限らず、さまざまなタイプのデバイスが今後シームレスにつながっていくかもしれません。

デジタルトランスフォーメーションを進めるうえでぶつかる4つの課題

繰り返しになりますが、スマートドライブはMobility Data Platform、つまり移動にまつわるセンサーデータを収集・解析し、価値に変えることを事業の柱とする企業です。

現在、売上の多くをBtoBのSaaSモデルが占めますが、この車両管理市場の外側に「モビリティDX市場」があります。ホンダさんとの事例をはじめ、自動車メーカーとコネクテッドサービスを開発したり、保険会社と安全運転になるほど月額保険料が安くなるテレマティクス保険を提供したり、電気自動車のバッテリー充電の最適化やスマートシティにまつわるサービスもモビリティDX市場に位置するものです。

デジタルトランスフォーメーション（以下、DX）は、ざっくりまとめると①データを集める、②基礎解析をかける、③サービス化や自動化など、新たな価値を生み出すという3つのステップがあります。DXを実現するには、この3つのステップにおける課題を解決しなくてはなりません。

課題は大きく4つです。中でも一番大きいのが「データの所在が分散している」こと。たとえば、移動データは弊社のサーバー内にあるのに、アプリの管理ログは別の会社が持っているとしましょう。さまざまなレイヤーのサーバー内にデータが分散して保存されていることで、同時にアクセスができないとなると、データを価値に変えることはほぼ不可能です。データを収集する時には、データ統合が一番の課題になります。

2つ目は、大量のデータを高速で捌く必要があることです。スマートドライブのプラットフォームにはすでに200億レコード以上のデータが格納されていますが、ここへEVの消費電力データを掛け合わせる場合、一回のSQLで何百億レコードも処理することになる−―つまり、テラバイト、ペタバイト級の膨大なデータ量を高速かつ一気に処理できなくてはなりません。つまり、貧弱なサーバーでは分析さえできないということです。

3つ目が、「正しいデータに正しい権限で誰もがアクセス可能である」こと。これは運用やオペレーションに強く紐づくところでもあり、この問題を見落としてしまうと、せっかく分析をしても、データの正否を問われた時に答えられないという場面が出てしまいます。データ分析の品質を保つには、必要な人に正しいデータを提供するということは重要ですし、データを価値に変えるための重要なポイントです。

4つ目が、データアナリストの人材不足です。高度な専門性が必要ですし、現在の業務時間を割いてゼロから勉強し始めても、スムーズに分析できるまでには1年から2年はかかります。弊社も全く同じ課題を抱えており、立上げ当初はすべての解析を私一人が担当していました。しかし直近ではデータアナリストも増え、数人で分析しています。分析は労働集約型になりがちのため、アナリストの人数が増えなければアウトプットの量が増えませんので、利益率の高いビジネスモデルとは言えなくなります。Lookerを導入した背景は3つ目と4つ目の課題が大きく関連しています。

分析の進化を後押しする「3つのフェーズ」と課題

今思えばかなりアナログかもしれませんが、創業当初はAWSからCSVで出力し、Excelで分析していました。それがPhase1の立ち上げ期です。Phase2の変化期ではBigQueryを導入。Tableauを導入し、セルフサービス分析を行っていました。Phase3の成熟期ではBigQueryを弊社のサービスへカスタマイズし、Mobility DWHという名の分析基盤構築支援サービスを構築しながらLookerに大きくリプレイスしました。このように、分析基盤を3つのフェーズで変遷してきました。

Phase2〜BigQueryの採用〜

当時、社内では数え切れないほどのサーバーにさまざまなデータが分散した状態で保存されていました。まずはそれらをBigQueryに集め、複数サーバーに分散保存されていたデータをクラウドに統合しました。BigQueryは他のDWHと比べて圧倒的なパフォーマンスを誇り、大量のデータに対するクエリ処理を投げても高スピードで結果を返してくれる、ビックデータ解析に強いデータウェアハウスです。

スマートドライブは、緯度経度を含む地理に関するデータを大量に集めていますが、BigQueryにはGIS関数と呼ばれる地理的データの解釈に長けた関数が多量にあるため、重宝しています。一般的なDWHにはSQLのアーキテクチャがセットになっていますが、Googleが開発したSQLのアーキテクチャは大量のデータが一括で処理できますし、GIS関数といったデータにも柔軟に対応できる、非常に優れたものです。Google自体もGoogleマップで地理的データを扱っていますので、この領域に関する分析に強いのでしょう。

私たちはPhase1から2にかけてTableauを導入しましたが、そこで3つの課題にぶつかりました。BigQueryからTableauサーバーにデータを移し、Tableauが処理を実行することになりましたが、Tableauサーバーに200億レコードを抽出するのは物理的に難しく、移行した時点でパフォーマンスが一気に落ちてしまったのです。これが1つ目の課題でした。

次に、センサーデータとセルフサービス分析は相性が悪いということ。セルフサービス分析とは、非エンジニアユーザーやビジネスロールの方が、自分でローデータの分析をしてアウトプットすることです。これについては後ほど、補足させていただきます。3つ目は、Excel時代と同様に集計ロジックが属人化したことです。集計ロジックがアナリスト毎に断絶し、お互いが何をしているのか、ダッシュボードがどのように作られているのかがわからない状態を作ってしまったのです。

2つ目については、Lookerを導入した一番の背景でもありますので、ここで少し補足をさせていただきます。

一般的に、セルフサービス分析とデータガバナンスは両立が難しい概念です。ここで、2つの記事を紹介させてください。左がDeNAで、右がメルカリの記事です。象徴的な言葉がメルカリの記事にある「俺の考える最強の中間テーブル」というもので、それぞれのアナリストが、「この中間テーブルがあると分析しやすい」と考えるものを人数分作成しています。しかしこの場合、Aさんが作成した中間テーブルでBさんが集計すると、誤った集計をしてしまったり、意味が解釈できなくて使いこなせなくなったりする可能性があるんです。要は、ローカル定義と呼ばれる「俺の考える最強のダッシュボード」が大量に作られ、俺が人数分いる状態になってしまうのです。そうなると、セルフサービスで分析“っぽい”ものが出せても、それが本当に正しいのか、どのようなロジックなのかを問われた時に明確に答えることが難しくなってしまう。それは、セルフサービス分析をすればするほど、ガバナンス、ができなくなってしまうということです。

とくにIoTセンサーデータはセルフサービス分析との相性が良くありません。わかりやすく解説するために、発注に関する一般的なトランザクションデータを持ってきました。「営業担当No5の人が対象顧客NO100に、何月何日に1万円の発注をもらった」といったことがわかるように、ここには営業担当のIDと顧客のID、発注日と金額が並んでいます。

このデータを見れば「発注日ごとに金額をまとめれば、日ごとの売上が算出できるだろう」とか「営業担当ごとに金額の項目を合計すれば売上が算出できるだろう」と直感的にわかるでしょう。このような、ビジネスユーザーが良く見るトランザクションデータはセルフサービス分析と相性が良いのですが、弊社が所有するIoTセンサーデータは少し異なります。

「どのデバイスから、何月・何日・何時・何秒何ミリsecのタイミングで、速度●kmで▲▲にいた」という情報が200億レコード並んでいます。これらのデータを「アイドリング時間を算出するだけでSQLを100行書く」とか「緯度経度を住所に置換するには、ポリゴン境界マスタをジョインしてGSI関数で境界と点の関係を算出して…」とか「距離を算出したいだけなのにパラメータで別で定義して…」と、それぞれのアナリストが解析するわけですが、データが複雑なためセルフサービス分析では混乱を招きやすいのです。そのため、IoTセンサデータとセルフサービス分析は相性が悪いという結果に。

このような背景を踏まえて、そもそもセルフサービス分析はスケールしない仕組みであるということに私たちは気づき、Lookerの導入に至りました。

Phase3〜Lookerの導入〜

Lookerを導入して初めに行ったのが、集計ロジックをブラックボックス化させない運用を構築することです。SQLとはデータにアクセスするためのプログラミング言語ですが、そのSQLを原文で保持するのではなく、LookMLという少し特殊な言語で意味だけ定義しました。集計ロジックとして特定の概念のみを定義できるのがLookMLです。シンプルに、読みやすいと思っていただければよいでしょう。LookMLベースでロジックを定義し、バージョン管理システムのGithubで、誰がどのタイミングでどういう理由で変更を加えたのか、それを誰がレビューし、どのタイミングで本番環境にマージし、どのダッシュボードに影響があったか、すべてログを残します。この仕組みを使って、集計ロジックをブラックボックス化させないように運用を作りました。

次が、「DataAnalystの業務を労働集約から知識集約に」すること。いままでのセルフサービス分析だと、それぞれの分析内容が各人単位で断絶してしまいますが、LookMLによってGithubでバージョン管理してお互いのコードをレビューする体制になると、誰がどんな理由でどのような分析をしたのかがすべてのアナリストに共有されます。つまり、正しいLookMLコードが作られるほど、アナリスト一人あたりのアウトプットが増えていくモデルへと変わっていくのです。そのため、労働集約ではなくて知識集約で、人を増やさずともビジネスはスケールしていく。その基盤をLookerで構築することができました。

また、弊社はBIをサービスレイヤーに埋め込むことを前提として考えていましたので、カラムレベル・レコードレベル・ロールレベルでさまざまな権限を自由にマネージし、iframeで自由に埋め込みができるといった組み込み分析に向けて、現在も開発を進めている最中です。

もう少しセルフサービス分析とLookerの違いをわかりやすくするため、図に落としてきました。

Phase3のアーキテクチャはこの図のようになっています。一番上にはユーザーレイヤーがあり、中央にはデータモデリング層、最下部はデータ統合層と大きく3つのレイヤーで構成されています。

Phase3では、データアナリストたちがGithubを経由して互いの分析ロジックをマネージし、データモデリング層のLookerにプルリクエストを投げます。LookerはLookMLをベースに大量のSQLを発行し、ユーザー側にダッシュボードを提供します。そしてデータ統合層であるBigQueryはLookerのみ、SQLを発行しているのです。

Phase2に遡ってみましょう。アナリストたちはBigQueryに直接アクセスしてSQLを大量に発行しますし、データモデリング層にもアクセスしてさまざまなロジックを作るため、データモデリング層とデータ統合層の間には双方向の行き来が存在します。Phase3だとSQL発行はLookerがBigQueryに発行するのみですが、Phase2ではデータ統合層に直接、データアナリストがSQLを発行し、Tableauに一回戻しますが、この中にもロジックがある。数々のレイヤーにロジックが分散し、アナリストごとに分断していたものを統合できたのがPhase3であり、先ほどお伝えした3つの価値を実現可能にできました。

Phase1ではAWSからCSVを出力しExcelに手を加え、Phase2ではBigQueryでDWHを構築し、Tableauでセルフサービス分析。Phase3で新しいアーキテクチャーのLookerを導入し、データガバナンスとセルフサービス分析を正しいデータで多くのダッシュボードをスケールしていく環境を構築しました。