「Mobility業界のDXを支えるSmartDriveの分析基盤」セミナーレポート

「Mobility業界のDXを支えるSmartDriveの分析基盤」セミナーレポート

石川 信太朗のアイコン
石川 信太朗
Mobility Data Scientist
株式会社スマートドライブ

新型コロナの影響もあり、企業はビジネスモデルを変革するためにデジタルトランスフォーメーション(DX)に取り組むことを余儀なくされています。そのDXを加速させるために重要なポイントがデータの利活用。スマートドライブでは移動データを取得・分析し、業務の改善から新たなサービスの創出まで、あらゆる角度から企業の成長を支援していますが、事業の根幹であり土台となっているのが独自で開発したデータプラットフォームです。

このセッションでは、スマートドライブの分析基盤がどのように構築されてきたのか、どのような分析事例があるのかについて詳しくお話しさせていただきました。

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

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

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

データインプット領域

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

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

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

データアウトプット領域

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

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

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

データアウトプット領域

スマートドライブはデータを活用した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を導入し、データガバナンスとセルフサービス分析を正しいデータで多くのダッシュボードをスケールしていく環境を構築しました。

DWH構築とデータ統合をサポートする、スマートドライブのMobility DWH

BigQueryでDWHを作るのは容易ではありませんし、開発を外部へ委託するお客様も少なくはありません。そこで私たちは、BigQueryでDWH構築を支援するためのサービスとしてMobility DWHをリリースしました。

これは、一般的な移動データ・測量データ・顧客データ・売上データなどをBigQuery≒Mobility DWHに統合し、さまざまな分析を共に行い、事業を共創開発していくというスマートドライブの思想を落とし込んだものです。一般的に、ゼロベースでデータを収集し、インサイトを取得するまで2〜3年はかかりますが、データの収集・加工のフェーズを弊社が支援させていただき、垂直に立上げを行って数カ月でインサイト取得まで到達できるアーキテクチャになっているのがMobility DWHの特徴です。Mobility DWHと分析コンサルティングを同時にご利用いただければ、短期間でインサイトを得て、サービスに落とし込むことも可能です。

実例として、移動に関わる広範囲なセンサーデータを活用する、一般的な顧客情報や人事情報を取得して労務管理に移動データを使用する、交通関連の情報を取得して危険地帯マップを作成するなど、分析からサービスのご提案まで対応させていただいております。データを掛け合わせるときに一番の課題となるのがデータの統合です。それをシームレスかつスムーズに行えるのがMobility DWHの一番の強みです。

まとめ

DX=データの利活用におけるデータの収集・統合・分析の3ステップで、統合分析基盤とデータの意味解釈を行う専門家の不在がボトルネックになっていましたが、BigQueryやLookerを導入することで、解決へと導きました。ただし、金額面だけ見るとLookerは他のBIツールと比較してやや高額です。そのため、初めてBIの導入を検討する方であれば、TableauとLookerを比較してLookerを選択するのは、なかなか難しい意思決定かもしれません。

とはいえ、複雑な元データでセルフサービス分析を作りこめば作りこむほど、混乱する原因を作り、短期間での結果が出しづらくなります。また、このようなアーキテクチャの維持にはそれなりにコストもかかってきますので、スマートドライブとしては各企業の得意領域を活かし、連携しながらサービスを構築していくべきだと考えています。弊社にはデータ分析やサービス企画、新しい事業を創造するプロフェッショナルが多く在籍していますので、企画段階からご一緒して、必要なデータを拾い、システムを構築し解析結果をレポーティングするなど、ゴールとスケジュールを切りながら共に事業を創造することができます。最後に、もう少し具体的な分析事例を紹介させてください。

連携している企業の事例

小田急沿線にお住まいの方のマイカーに、SmartDrive Familiesというコネクテッドデバイスを装着いただき、そこから取得した利用者の移動履歴をもとに、小田急沿線のバスの経路をこのように変えてはどうでしょうとか、地域の商業施設を変えていきませんかと提案しています。

EVの場合は電欠防止の通知、オンデマンドバスなら相乗り率が最大化する配車を分析。出光さんの事例ではカーシェアリング一回利用あたりの走行時間を増やす施策や、予約を増やすためにはどの場所でどのような観光地を開発すべきかをLookerで分析しています。

車両管理サービスSmartDirve Fleet

新型コロナの影響もあり、コスト削減に注力する企業が増えていますので、適切な配車を割り出し、車両削減を通じて何千万円単位のコスト削減ができるかといった支援をさせていただいております。

クラフティさまの事例では、安全運転の推進に向けて安全運転診断レポートを提供し、事故の削減ポイントを分析しています。同社は普段からSmartDrive Fleetの管理画面を見ながら振り返りをしているそうですが、安全運転診断を数値化したレポートでは、今までのスコアの推移や危険イベントの増減、安全運転指導の対象者などがわかり、より適切な安全運転教育が行えるようになったと言います。

また、モビリティデータを活用して、相楽東部広域連合さんのゴミ処理における課題を解決するお手伝いをしています。こちらの事例では、どの地域にどのようなゴミがどれくらい発生し、回収時間がどれくらいかかっているのか、委託業者ごとにどのような違いがあるのかを分析し、地方公共団体の担当者と委託業者間のコミュニケーションを円滑にすることができました。

このように、スマートドライブでは分析基盤を活用し、SmartDrive Fleetのオプション機能を提供したり、共創事業の土台となるデータを解析したりするために、Lookerでガバナンスを強化し、データアナリストが互いの知見を共有しながら日々、分析をしているのです。セッションは以上です。最後に、いただいた質問にいくつかお答えしましょう。

質問現在LTE対応だと思いますが5Gの計画はありますでしょうか?

具体的にいつとは言えませんが、5Gには大きな将来性を感じていますので前向きに検討しています。

質問海外に興味があります。マレーシアの話がありましたがASEAN周辺諸国に展開する予定はありますでしょうか。プラットフォーム部分で他国への提供は可能でしょうか。

スマートドライブも海外には注力していますし、マレーシア周辺のASEAN諸国はターゲットとして考えています。他国でのプラットフォーム展開ももちろん視野に入れていますので、ぜひ、お気軽にご相談ください。

質問交通データという匿名性に配慮しながら他ユーザーさんへ別の目的で活用するようなことは可能でしょうか。スマートドライブの各ユーザー様の情報を掛け合わせることで新たな価値が生まれるような気がしています。

車両管理サービスSmartDirve Fleetでは、個人が特定できないことを前提として利用を同意いただいております。ただ、弊社としても規約に沿ったデータの扱い方にはとくに注意すべきだと考えていますし、場合によっては、データが利用できないこともあります。ユースケース次第では、新しく事業を構築する前提で同意いただく内容を決め、その範囲内のみで分析することも可能です。

質問データ活用によりトップラインを伸ばす事は可能でしょうか。データ活用は運転の最適化などコストカットできるエリアへ方法抽出することに向いているような気がします。コストカットではなくトップラインを高めるユースケースや方法はないのでしょうか。近年データ活用を拝見して感じた素朴な疑問です。

これはデータを価値に変えるためにも、スマートドライブが注力している領域です。データを価値に変えるということは、企業や利用者がメリットを享受できるということ。トップラインを伸ばすために営業の生産性を改善する分析も行っています。訪問回数がトップラインに直結するようなビジネスモデルであれば、効率よく訪問先を回れた方がいいでしょう。また、走行履歴をもとに、ビジネスで成果を上げている人はどのような行動をとっているのかを分析するケースもあります。とくに物流、配送業のお客様の場合、配送料がトップラインに直結することも多いですしね。

質問データ活用となった場合にホンダ様とどういう役割分担をされているのでしょうか。バイクからのデータも含めシステムも内部で構築されているなら、ホンダ様が他のサービスを他の会社さまとやりたいとなった場合も、基本はプラットフォームが使われるという形になるのでしょうか。

それぞれが取り組みたいことを中心に、互いが持つアセットを最大限に出しあってサービスを開発しています。この事例でいうと、大きく分けて弊社がプラットフォームの上にサービスを構築する部分、ホンダさんはサービスの販促部分を考えていただく部分がメイン担当です。プリミティブな仕様のところをディスカッションしたり、デバイスを所有する企業とディスカッションしたりして決めていますね。弊社は自社のサービスにロックインさせる思想は持っていませんので、他社のプラットフォームとも連携し、互いがメリットを得られるようなスキームをディスカッションしながら詰めていくイメージです。