CASE時代の課題解決から生まれたIoTデータ収集プラットフォーム「D-tote」

デンソーが開発したデータ収集プラットフォームの「D-tote」は、PoC（Proof of Concept：概念実証）のデータ収集の効率化という社内の課題解決に寄与するものと伺いました。

近藤：確かにD-toteは社内課題を解決したのですが、それが本来の目的ではありません。D-toteの前に、我々クラウドサービス開発部の位置づけについて説明した方がわかりやすいと思いますので、こちらからお話しさせてください。

まず、現在のデンソーが全社的に推進している方針として、「ソフトウェア・ファースト」が挙げられます。従来はクルマという「モノ」をユーザーに提供することが価値の源泉だったわけですが、現在ではサービスやシステムといった「コト」を社会に提供することが求められるようになってきました。

コトの根幹とは、ソフトウェアです。そのソフトウェアを自分たちの武器として成長させていく。この役割を担う部署として2017年にデジタルイノベーション室が生まれました。その後、組織変更を経て、ソフトウェア開発を行うデジタルイノベーション室と、ビジネスモデル開発を行うビジネスイノベーション室で構成されるクラウドサービス開発部となりました。

クラウドサービス開発部は、単に社内の課題を解決するのではなく、社内外のニーズを探し出し、顧客とともに考えながらソフトウェアを内製し、そのプロダクトを社会に向けて提案していくという点に特徴があります。

D-toteに繋がっていくことになったニーズとは、例えばどのようなものだったのでしょうか？

髙木（祐）：データ収集用の環境を一度作ったら、あとはそれを使い回せるようにしたい。そういう相談が寄せられました。

近藤：例えば、サーマル事業部では、車室内の空気質をセンサーで感知して、センサーデータをクラウドに自動収集し、そのデータを活用するシステムを検討していました。仕様を決定するために、PoCを行いたいと考えていたのです。

当時、私たちが認知していた社内の課題として、似たようなデータ収集のシステムが複数乱立していたことが挙げられます。主にセンサーなどのハードウェアを開発するエンジニアは、ソフトウェアやクラウド技術になじみのない状況も多く、データ収集のシステム構築は外部に開発委託していることが一般的でした。

そのような背景から、データ収集のシステムは、個別プロジェクトに最適化された形で開発され、他プロジェクトで再利用できていませんでした。
D-toteは、社内の様々なプロジェクトで、汎用的に利用できるように設計し、共通システムを目指して開発することにしました。

D-toteの仕様は、どのように固めていったのでしょう？

髙木（祐）：社内PoCで利用できる「データ収集プラットフォーム」を創ればよいと考えましたが、社内の要望を満たすだけでなく、クラウドサービス開発部として、社外向けのビジネスにも繋げることを想定し、かなり試行錯誤しました。

要件として見えてきたのは
・利用者が簡単に計測を開始できる
・顧客ニーズに応じて任意のセンサーからのデータ収集を取捨選択・カスタマイズできる
・遠隔地から計測内容の設定変更を複数台同時に行える
ということでした。

こうしたシステムを実現するためには、実験車に搭載されたセンサーからのデータ収集と、クラウド上での処理の両方を行う必要があります。私と南は、クラウドサービスの開発経験はありましたがIoTについては経験がなく、手探りで検証を進めていきました。

南：あれこれ試すうちに、何とか車載器からクラウドへのデータアップロードができるようになり、プロトタイプを創ることができました。

髙木（祐）：プロトタイプができたことで、顧客の要望を満たせる目処が立ち、そこからようやくアジャイル開発を始められるようになりました。

利便性を考えると、スマートフォン用アプリの開発要望もあったのではないですか？

髙木（祐）：はい、「スマートフォン用アプリはいつできそうですか？」と相談を受けていたのですが、なかなか手が回りませんでした。しかし、チーム内で話し合っているうち、私たちは「求められているのはテストドライバーからアンケートをとる」ことだと気づきました。

それならば、アプリを新規に開発しなくても、Googleフォームでアンケートを作ればよいのではないか。早速、アンケートを試作してみたところ、「これはいいね」ということになりました。外部委託していたら、このスマートフォン用アプリ開発に多くの時間と費用がかかっていたと思います。

お金をかけた、すごいものを顧客が欲しがっているとは限らない。本質をついていれば、シンプルなものでも顧客に満足いただけることもある、という学びがありました。

従来のデータ収集システムとD-toteでは、システム構成はどのように違うのでしょうか？

髙木（祐）：まず、従来のデータ収集システムですが、車載器にはセンサーからのデータ取得とクラウドへのアップロード機能があります。クラウド上にあるデータ保存機能のメッセージブローカーは、車載器からのデータを受信。データ分析を行うアプリレイヤーは、データ保存機能からデータを取得して活用するというのが大まかな流れです。これまではPoCごとに、こうした一連のシステムを用意していました。

PoCに必要な機能のうち、共通化できる部分を切り離してD-toteとして開発し、プロジェクトごとに異なる部分は各PoCの担当者が用意するようにしています。プロジェクトごとに異なる部分というのは、各センサーからのデータ取得と各アプリレイヤーです。

車載器はLinuxが動作するコンピュータを使い、センサーから取得したデータの変換やクラウドへのアップロードといったD-toteの機能は、Dockerコンテナ*3にまとめられています。

*3 Dockerコンテナは、アプリケーションを実行するために必要なリソース（関連するライブラリやミドルウェアなど）を1つにまとめたもの。開発環境とは異なる環境であっても、複雑な設定を行うことなく、誰でもアプリケーションを動かせる利点がある。

D-toteのクラウド部分はAWS上に置いています。D-toteは、データ収集機能に注力しており、分析などのアプリレイヤーの機能は有していません。データの分析はユーザー部門が保有するアプリレイヤー機能で行う構成になっています。

D-toteの構成図を見ると、センサーから取得したデータが変換されていますね。どのようなデータ形式に変換しているのでしょうか？

髙木（祐）：センサーデータは、JSON形式※4のテキストデータとして保存しています。JSONファイル内のフィールドは、データ取得時のタイムスタンプと値が1つというシンプルな構成です。データファイルのファイル名は、センサーのシグナルコードとタイムスタンプで命名されているため、ファイル名から一意の信号を特定することができます。どのセンサーでも同一フォーマットのJSON形式ファイルにして圧縮・保存していますからストレージの容量を削減できていますし、さらにはアップロード時の通信コスト削減にも繋がっています。

*4 「JavaScript Object Notation」の略で、元々はプログラミング言語のJavaScriptで利用されていたデータの表記法。キーと値をコンマで区切って記述するシンプルなテキスト形式になっており、現在ではさまざまなプログラミング言語で利用されている。

データの観点からすると、D-toteは土管のような仕組みと言えるでしょう。センサーからデータを取得できさえすれば、どんなデータでもクラウドにアップロードして、そのままアプリレイヤーで扱うことができるようになっています。CAN（Controller Area Network）、温湿度、GPS等のセンサーには対応済みですし、その他のセンサーについても要望に応じて追加可能です。

JSONデータの管理には、HIVE形式※5というフォーマットを採用しました。こうすることで、AWS Athenaというサービスを利用して求めるデータを、容易に抽出できるようになっています。

*5 データファイルをフォルダごとに整理する方式の1つ。HIVE形式では、JSONファイルに含まれているキーと値の情報を元にしてフォルダを作り、データファイルを管理する。

それにしても、クラウドサービスが専門だったエンジニアが、IoTのハードウェア周りも手がけるのは大変だったでしょう。

近藤：私は後からクラウドサービス開発部に合流したのですが、当時のドキュメントを読むと、D-tote開発の試行錯誤が伝わってきます。「××という機器を購入して、××と配線。信号がうまく流れて、データを取ることができた」という風に、一つひとつ課題に取り組んでいたことがわかります。

髙木（祐）：センサーなどの組み込み開発とクラウドサービスの開発では、一口にソフトウェアエンジニアといっても随分文化が違うので、戸惑うことは多かったです。開発中のセンサーに特定の信号を送るとデータを取得できるはずですが、どうやってもできない。調べてみると、センサーのバージョンが違っていたということもありました。

ユーザーがD-toteを使う際の流れは、どのようになっていますか？

近藤：ユーザー側で車載器とデータ計測用センサーを用意すれば、クラウド上のサービスは最短1日で使い始めることができます。

D-toteの開発には、多様なバックグラウンドを持ったエンジニアが参加しているのが印象的です。

髙木（祐）：私の前職は、インターネットサービス企業でのクラウドサービス開発でした。

南：私はガソリンエンジンのシステム開発を担当していました。コードもたまに書きますが、エンジンにはどういう部品を配置するかなどを決める、言ってみれば音頭取りのような役割です。

髙木（進）：私は1年前までカーエアコンのメカ設計を担当していましたが、キャリア転身プログラムでソフトウェアエンジニアとしてのキャリアをスタートさせました。

クラウドサービス開発部ではアジャイル開発の手法をいろいろと取り入れているのですが、特にエクストリームプログラミングは効果的だと思いました。何人かがチームになって1つの画面を見ながらペアプログラミングをしたりするのですが、そうした取り組みのおかげで、先輩の指南をいただきながらスムーズにチームへ合流することができました。

今開発を担当しているD-toteは、ハードウェアとの通信もあれば、クラウドでの処理もあります。ハード、ソフト両方の知識をいろいろと蓄えていくことで、顧客に提案する手札も増やしたいと考えています。

近藤：デンソーとしては現在、ソフトウェアエンジニアを積極的に育成しているところです。キャリア転身プログラムでハードウェアエンジニアからソフトウェアエンジニアにリカレント教育する研修も行っていますし、社内公募で想いのある社員を募り、誰でも新規ソフトウェアプロジェクトに異動することができる機会も創出しています。もちろん、社内にはないスキルを持つ人材を社外からキャリア採用することも積極的に行っています。

そうしたさまざまなスキルを持つ人材が豊富な部署が、私たちのクラウドサービス開発部だと思っています。

D-toteの今後の展開について教えていただけますか？

近藤：D-toteが利用できるのは、モビリティ関連のプロダクトやサービス開発に限りません。工場等の施設で使うシステム開発にも利用することが可能です。

D-toteは、デンソーのグループ会社の製品・サービス開発に利活用されることも見込んでおり、社外のニーズにも対応していきたいと考えています。

また、デンソー社内では現在D-toteCarという取り組みも進めています。これは社有車を使って、さまざまなプロジェクトにおけるデータ収集作業を容易にしようというものです。モビリティ向けプロジェクトでは走行実験が必要になりますが、大規模にデータ収集をしようとすると、人手不足に悩まされることがよくあります。そこで、社有車を使って出張をする人にはセンサー・車載器搭載済のD-toteCarを使ってもらい、代理でデータ収集してもらおうというわけです。

IT企業では「ドッグフードを食べる」という言い回しがよく使われます。これは、自分たちが作ったサービスを自分たち自身で使いながら改良を重ねていくことを指します。

ユーザーのニーズに寄り添って、アジャイルに改善をしていく。D-toteは、そうしたソフトウェア・ファーストのあり方を体現するプロダクトだと言えるでしょう。