【社員インタビュー 後編】価値のあるデータとは何かを追求していく

今回のエントリーは社員インタビュー後編となりますので、まだ前編を読んでいないという方はぜひこちらからどうぞ。
後編は弊社取締役の元垣内が弊社に入社した時点からの話になります。

データ解析はどう始まったのか

入社後しばらくは、そもそも解析するべきデータの蓄積自体がほとんどありませんでした。はじめていわゆるデータ解析っぽいことをやり始めたのが、社内で「G-Force」と読んでいる重力マップを開発し始めたところからでした。これに関しても、ビッグデータが集まったからさあやりましょうと始めたわけではなく、ユーザー数が多いという意味でのビッグデータが整うのを待っていたらいつになるかわからなかったので、そういう種類のビッグデータがなくてもできる解析をまず始めていこうと考えました。

ビッグデータにもいろんな考え方があると思っていて、例えば、1万人が1時間運転した1万時間の運転データと、1人の人が1万時間運転した運転データは、どちらも1万時間の運転データですよね。前者は1万通りの運転手の特性が1時間分詰まっているデータで、後者のデータは1人の運転手を1万時間も深く見ていくことができるデータだと大別できるかもしれません。つまり、まず後者から始めていったということです。

ビッグデータというのは、当然ですがビッグであれば価値があるとは限らないですし、ビッグデータはあるけど活用はできてないという状態は昔も今もよく聞く話なので、単に規模が大きいデータだけあってもしょうがないとはずっと思いながらやってきました。

うちの端末も最初のOBD-II端末からシガーソケット型に変わったり、筐体の形やサイズの改良、内部部品や回路に手を加えたり、BLE接続モデルの他に端末のみで通信できるモデルも提供し始めたり、ここまで様々な変遷を遂げてきましたが、取得するデータという意味で大きな変化だったのは、OBD-IIでは車の車載コンピューターから取得していたデータが、シガーソケットタイプになってからはGPSや加速度・ジャイロセンサーで取得するデータに置き換わったというところです。そこから、G-Forceの開発が始まっていきました。

単なる数字の羅列をいかにして価値ある情報に変える

最初はいろんな論文を読みながら、センサーデータの解析の仕方を先行文献を参考にしながら調べていきました。当時のうちの端末だとOSも積んでないですし、チップマイコンが入っているだけで高度な処理はできなかったので、端末としての制約がかなりある中で解析できるようにするためのロジックを考えないといけないのがチャレンジでした。

便利なライブラリを使うようなこともできないので、すべての演算を自前で書いていくような形になるわけですが、かといって計算量が膨大にならないようなものを作らなければいけなかったので、まさにR&Dというか、それこそ線形代数やベクトル解析的な演算レベルで処理を考えて、途中、数学的に美しくかつシンプルな計算処理に気がつくと快感を覚えたりしながら（笑）、開発というよりは研究に近いレベルのことをやっていました。

もちろん端末のスペックを上げれば高度な処理ができるようになるのですが、そうすると今度は製造コストがグッと上がります。あくまでも製造後の拡販を想定した上でビジネス的に成り立つのかという視点は必要なので、単に性能が良いものを作ればOKというわけではありません。

これがなかなか難しくて、いろんな方々の知恵や経験もお借りしていくつものヒントを得ながらやってきたわけですが、最終的には自分達で苦しみながら様々な難所や制約を乗り越えて、弊社の運転診断の元となるG-Forceが完成するに至りました。これは今でも継続的に進化させていっているものなので、開発して終わりというプロジェクトではなく、その先には更なる進化もあるわけですが、とはいえ自分が入社して以来で考えても、「大変だったことランキングTOP5」に入るプロジェクトでしたね（笑）

結果としてこれはうちの強みやオリジナリティの１つになっているので、まずは一旦そこまで昇華させられたのはよかったなとは思っています。一見ただの時系列の数字の羅列でしかないものが、人の運転の特性を表すものになるという意味づけをしていくものに初めてなったわけです。その上でようやく分析をしていくことができるという、その土台になるものができた瞬間でもありました。

限られたデータという制約がある中で価値を創出する

これまで歴史的にも、社内で一番ロウデータ（生データ）を見てきましたが、そのデータが時に不正確だったり、取れるはずのデータが、取れていなかったりすることで、お客様やパートナー企業様に迷惑をかけてしまうようなことも発生したりしました。

そういう経験からのチャレンジとして、「データの抜け漏れが絶対ないように改良しないといけない」「データ精度を完璧に近づけよう」というような話になりがちなのですが、それを突き詰めようとすると、大抵はもっとマシンスペックを上げなければならないというところに帰結してしまいます。そして、これをやってしまうと、仮にテクニカルな問題は解決できたとしても、ビジネスに与える影響が大きくなって結果的に実現不可能となってしまいがちです。

最終的に目指す世界観のユーザー体験を実現するのに必要な、許容できるコストを定義し、その制約の中で何ができるかを考え、マシンスペックを上げずにデータの異常値や抜け漏れを完全に失くすというのは現実的に難しいので、逆にそれを前提条件とした上で、それでも運転診断やスコアリングができるように担保するにはどうすればいいか、と考えていきました。

つまり、ある意味「データは不完全に飛んでくるもの」だとして、欠損があっても、また精度が悪いところがあっても、それらをうまくハンドリングして、運転特性を評価できるような計算方法を生み出すということですが、実はこのやり方には様々な恩恵があります。というのは、特定のデータやセンサのスペックを求めなくても済むことにも繋がるので、幅広いセンサ端末のデータを受け取って解析できるベースをつくっていけることにもなります。

自社端末から飛んできたデータはもちろん、他社が開発提供している端末で取得したデータであっても同じように運転診断や分析ができれば、極論どこの端末でも良いという話にできます。うちと違うメーカーのGPSを使っていても、加速度センサやジャイロセンサでも、それがスマホに内蔵されているものであっても、とにかく最低要件を満たせばすべて受け取って活用できますよということです。

データを活用した事業をする上で重要なこと

実際にあったケースですが、うちと他社でコンペになった際に、うちのデータ解析の汎用性・柔軟性が、最終的にうちを選んでいただいた決め手になったことがありました。コンペの企業のソリューションでは、ある特定の端末において取得できる非常に多くの細かいデータを活用していくという話だったのですが、逆にうちではタイムスタンプと速度情報のみでもかなり深い解析ができますという提案でした。

もちろん、高価であっても、特別な専用端末で精密なデータを取得しないとできないこともあるので、ここで話しているケースというのは、あくまでも一般法人企業に対して提供するSaaSという条件下においては、端末にかけられるコストは限られていると思うのと、事業のスケーラビリティを考慮した時に、できるだけ汎用的なデータの受け方ができるプラットフォームの方が有利であるという考え方を前提とした話ではあります。

できるだけシンプルなデータセットで深い解析ができるモデル、それが僕がこれまで取り組んできた開発です。お客様の中には「本当に速度データだけで大丈夫なの？」とびっくりされる方も結構いらっしゃるわけですが、実際は速度情報だけでも様々なシーン分けができるので、細かくはここでは話せませんが（笑）、うちの強みのひとつはそこにあったりもします。

前述のビッグデータの話に戻ると、データが大量にあるというだけでは価値がなくて、お客様にとって価値があるデータにするためにはどういう視点・切り口で見ていくのか、それらをどう組み合わせて解釈・意味づけするのかという「料理」の部分がより重要になってくると考えています。

結局のところ、データだけ見せて「なるほどね」で終わりではなくて、そのデータをもとに何らかの意思決定に寄与して、施策を打てるのかというところが大切です。まさに今は「データをいかに活用するか」というところに各社必死になって取り組んでいる時代かと思いますし、どう活用するかの具体的なイメージがあるからこそ、「そのためにはどうデータを集めるべきか」という視点も生まれて、かつてよくあったような「どう使うかはわからないけど、とにかく集めてはみた」みたいなことが起こりにくくなるのかなと思っています。

今後はますます弊社のデータ活用事例が世の中に出ていくことになると思うので、ようやくここまできたかという思いと、まさにここがスタートラインだという思いもあって、ますますエキサイティングなフェーズになってきたなとワクワクしています。

移動データ活用のこれから

「移動・交通データ」という文脈で言うなら、運転特性や事故リスクというデータにとどまらず、位置情報データは、下の資料（2020年4月28日開催「Mobility Transformatation 2020」より）にあるように、今後はますますこの「移動データ × 他のデータ」という、データの掛け合わせでビジネスオポチュニティが拡大していくことになると思っています。

例えば、「移動データ × 営業データ」という組み合わせいくと、売上実績の高いエリアとそうでないエリアのスタッフの日々移動にどういった違いがあるのかを丁寧に見ていくと、何がその売上実績の差に影響しているのか、もし実績を高めるノウハウがあるのであれば、それを標準化して全体の底上げを図るといったようなことも可能となります。

もし、そのノウハウの体現度合を定量化するとしたらどういった指標になるかから考えれば、モニタリングすべきKPIも見えてくるので、次はそのKPIを追いながら、閾値を設けることによって自動でリアルタイムに報告が上がってくるようにもなります。そうなると、その報告に対して必要なアクションを即座に取ることができるようになるので、たまたま発見したようなタイミングで対処するのではなく、事実に基づいて素早く行動を取り、改善サイクルを早めることができるようになります。

上の図も Mobility Transformation 2020 で使った資料なのですが、今話した内容は、「見える化」と「自動化」の領域の例です。

さらに、「AI・機械学習」を使った予測分析などの活用形態があるわけですが、シンプルな過去の情報をトリガーに自動化するような世界から、「AI・機械学習」によって、様々な過去の情報に基づく将来予測の結果や直接計測ができない何かの状態を推定した結果をトリガーに自動化する世界への進化があります。

これは基本的には「自動化」の延長ですが、より予見的で未然の対応ができたり、シンプルなルールベースでは判定できなかったり、人間が苦手とするような複雑な状況を機械が読み解き処理するといったことができるようになるテーマは、この領域の代表格といえる自動運転の制御だけにとどまらず、「移動データ × 他のデータ」の文脈でも、ほぼ無限の可能性があります。

最近のトレンドでは、拡張知能や行動変容といった領域で、移動データをうまく活用し、ヒトができる幅を広げる支援をしたり、ヒトの移動を始めとする行動を意識せずとも変えていたりする観点で、特に、スマートシティやスーパーシティといった人が暮らしやすい社会インフラの中に実装されていくような活用の進化も考えられます。

一方で、とりわけモビリティ業界においては、ようやくコネクテッドの社会実装が始まった段階で、まだまだ「見える化」「自動化」の領域にも様々な可能性がある極めてチャンスのある黎明期真っ只中という状況です。

インターネットの歴史の中で、サイトの閲覧状況がよくわかっていない時代において、Google Analyticsがサイトにどれくらいの人が来ていてどれくらい滞在してどこに関心が高く、またどういった経路で流入・流出しているのかといった見える化を実現し、今やそれはマーケティングやサービス改善のデファクトスタンダードとなっています。

ある意味では、モビリティ業界における移動データの活用は、まだGoogle Analyticsがなかった時代のインターネット業界と似たような環境にあり、「見える化」「自動化」の領域にも大きなチャンスが眠っているフェーズだと思います。

まだ、移動やモビリティとい長い歴史のある巨大な業界/テーマにおいては、その中で本質的なイノベーションを起こしていくことを考えると、どこか一社が単独でそれを成し遂げようと考えるのではなく、様々なプレーヤーとの共創・協力によって実現していくことが不可欠だと考えています。

CASE時代での大きな変革期の到来に加えて、コロナ時代の中で移動に対する考え方も大きく変わってきています。
移動自体もそうですが、そのデータの活用がより一層大きな変化と価値の創出を求められています。そういった新しい時代を切り開いていく中で、移動のデータ活用を通じ、様々な企業・自治体等の既存事業における課題解決や、新規事業におけるサービス開発を支援し、弊社のコーポレートビジョン「移動の進化を後押しする」をとおして、人類の未来に貢献していきたいと考えています。