こんにちは！デザミス株式会社の採用担当です。
本日は、エンジニアの石川さんと香田さんにインタビューをしてまいりました。

・プロジェクトが始まった背景
・方針決定のプロセス
・注力したポイント/苦労したポイント

についてお話しして参りますので、「IoT製品開発に興味のある方」や「これまで培ってきた技術を活かして社会貢献したい方」はぜひ最後までご覧ください。

登壇者プロフィール
＝＝＝＝＝＝＝＝＝

＜香田さんプロフィール＞
大学では社会科学専攻とITとは無縁の日々を送っていた。
スマホゲーム開発の現場に飛び込むところからITのキャリアが始まり、HRテック領域のプロダクト開発を経由して現職に至ります。主にRails & React でのWeb開発、品質保証、アジャイルな組織運営に携わってきました。今後はデータサイエンスやIoT開発に挑戦中...

＜石川さんプロフィール＞
大学では機械系を専攻。ロボットに興味を持ち、大学院では電動車椅子の研究をする。その後、大手電機メーカーで組み込みソフト開発に携わる。

現在はエンジニアとして、デザミスのプロダクト「U-motion」の開発などを担当。
＝＝＝＝＝＝＝＝＝

本記事をお読みいただく前に、こちらの記事をご覧ください！
↓

プロジェクトが始まった背景

ープロジェクトが始まった背景を教えてください。

石川：プロジェクトが始まった背景は大きく二つ。一つ目は、従来の首に巻いて使うセンサーには牛の成長に合わせてベルトを少しずつ緩めなければならないという弱点がありました。特に何千頭もの牛がいる牧場では、その作業の手間が非常に大きくなってしまいます。そのため、「ベルトを緩める必要のないセンサー」が長年求められてきたんです。

二つ目に、現在使用されている首のセンサーは6〜7年前に開発されたもので、この間にハードウェアの進化が進み、例えばセンサーの消費電力が低下したり、精度が向上するなどの技術的な進歩が見られました。これらの進化を製品に反映し、ユーザーにより大きなメリットを提供するために、新たな形のセンサーを開発するプロジェクトが立ち上がったという経緯です。

ーお二人はそれぞれどのような役割を担っていましたか？

石川：私が担当した一つ目の業務は、イヤタグ内の基板上で動作するプログラムの開発です。イヤタグに内蔵されたセンサーからデータを集め、それを無線で 送信する部分のプログラムを作成していました。二つ目の業務は、イヤタグから送信されたデータを受信し、クラウドにアップロードするための「ゲートウェイ」と呼ばれる機器のプログラム開発です。

香田：私は、主にソフトウェア開発で、大きく三つの業務を担っていました。まず一つ目は、活動量の判定モデルをAWSのLambdaに載せる仕組みを整えたことです。これは、石川さんが開発したゲートウェイからアップロードされるデータファイルなどを分析するための仕組みでもあります。

二つ目は、判定結果をS3に蓄積し、そのデータをU-motionのデータベースと連携させるためのバッチを作成したことです。

三つ目に、U-motoinの画面をイヤタグに対応させるための作業も行いました。

ーどのように連携して開発を進めてきましたか？

石川：二人で牧場に行って、牛にセンサーを取り付け、そのセンサーをつけた牛が何時に何をしていたかというデータを収集する作業を、開発の初期段階で一緒に行いました。

また、牛の活動量などのセンサーデータからその時点で牛が何をしていたかを判定する仕組みがあるのですが、この部分についてセンサーデータをどのようにアップロードするか、またそのデータをどのように分析するかを二人で話し合いながら決めていきましたね。

運用が始まってからも様々な作業を連携して行っており、大きなところでは、イヤタグセンサーが脱落してしまった際に、すぐにユーザーに通知できる機能の開発を一緒に進めました。実際にどのような脱落パターンがあるのかを考慮し、通知するだけでなく、今後脱落を減らすために、脱落原因を入力できるフォームを作成するなど、運用中に見えてきた課題の解決にも一緒に取り組んでいます。

方針を決めるプロセス（技術選定理由）

ー方針を決めるプロセスについて詳しく教えてください。

｜従来の首センサーの運用実績をもとに機能改善

石川：首に装着するセンサーの運用実績があったので、その運用の中で気づいた課題から「この機能があればより良い」といった改善案がいくつか出てきました。これらを実現できる技術を選定していったことが、今回の基本方針を決める上での大きなポイントだったと思います。

具体的には、まず一つ目の課題として、牧場で収集したデータをインターネット上に送信する必要があるのですが、牧場は山奥や通信環境があまり良くない場所にあることが多いです。そのため、通信が途切れたり、停電が発生した場合、データが送信できなくなるという問題がありました。こうした通信が不安定な状況でも、安定してデータ分析を回せるようにすることが、技術選定やシステム構成を決定する上で解決すべき課題でしたね。

二つ目の課題はコストです。イヤタグが装着されている牛の数が増えると、それに伴ってデータ分析や転送、保管にかかるコストも増えてしまいます。そこで、装着数が増えてもコストを抑えられる仕組みを作ることは、方針として持っていたものです。

三つ目の課題はセンサーデータの分析がしづらいというものです。IoTセンサーの運用の中では、ハードウェア自体の故障や、受信が安定しないセンサーの特定、原因の解析など様々なデータ分析タスクが発生するのですが、既存の仕組みだと新しい切り口の分析が難しい課題がありました。

｜安定稼働ができる

香田：安定稼働に関しては、非常に力を入れて取り組みましたね。センサーからデータが送られてきて、それを活動量判定モデルにかけるためにLambdaを用意しましたが、その処理が滞ることなく、リアルタイムに近い形で進行できるように配慮しました。

また、問題が発生した際の復旧も重視していました。例えば、「活動量データが欠損してしまうケースをどのように扱うか」などについて考慮しながら進めていました。

｜コスト削減

香田：コスト面については私の担当領域でも注力した部分の一つになります。当初はAWSのAthenaを利用して分析対象のデータをクエリする方向で進めていたのですが、検討を重ねて最終的にはアップロードされたデータを直接Lambdaで処理する方法に落ち着きました。この選択は今考えてもすごく良かったと思います。

注力したポイント、苦労したポイント

ー注力したポイント、苦労したポイントを教えてください。

｜センサーデータを活用しやすいような分析基盤の構築

石川：従来の首のセンサーでは、アップロードされたデータが主に活動量の算出やアラートのお知らせに使われており、それ以外の用途にはあまり活用されていないという背景がありました。しかし、本来センサーデータは、様々な角度から分析することで多様な機能を提供できるはずです。また、ハードウェアにトラブルが発生した際、その原因を迅速に究明できるようにするためにも、センサーデータを活用しやすい形で保管することに注力しました。

具体的には、AWSのAthenaというサービスを活用し、データを分析しやすくする仕組みを導入しました。Athenaを使うことで、例えば加速度センサーからデータが取れていないセンサーの一覧を簡単に取得したり、イヤタグセンサーから送信されたデータを複数あるゲートウェイ機器の中のどの機器が受信したかを判定し、牧場内で牛の位置を把握したり、1分間に何回受信したか、受信強度はどの程度か を簡単に確認できるようになりました。また、加速度センサーの情報を集計して、イヤタグセンサーが脱落してしまった場合に、リアルタイムでお知らせできる仕組みを整えることができたのも、Athenaによって汎用的なデータ分析が行えるようになったことによるものです。

｜通信環境が悪い場所でも安定したアップロードができるようにすること

石川：通信が原因でゲートウェイ機器からデータがアップロードできなかった際は、ゲートウェイ機器内部に一時的にデータを保存し、ネットワークが復旧した際にインターネットへ送信する仕様に変更しました。この仕様変更自体は難しいものではありませんが、遅れてアップロードされてきたデータに対しても、通常の処理のフローで分析が回るようにするためには、バックエンド側での工夫が必要になる点です。この点も、香田さんと協力して進めたところです。

｜ゲートウェイ機器を汎用的に使えるように作った
石川：ゲートウェイ機器を汎用的に使えるように、様々な種類のセンサーに対応できるような形でプログラムを作成しました。具体的には、ゲートウェイ機器側ではセンサーから送信されてくるデータのフォーマットに依らず、データを受信できるようにしておいて、可能な限り生の受信データに近い形でクラウドにアップロードし、クラウド上でその生データを変換して、データ分析基盤に振り分ける構成にしました。

これにより、イヤタグ以外にも、温湿度センサーやCO2センサーなど他の機器からの情報も同じゲートウェイ機器で受信ができるようになり、将来的に新しい機器や通信フォーマットが増えても柔軟に対応できるというメリットが生まれました。

｜システム全体として安定稼働させること
香田：U-motionは、起立困難アラートや活動量のグラフなど、ユーザーの業務に直接影響を与える部分が多いため、障害を起こさないようにすることは言うまでもなく大切です。その上で、万が一障害が発生した場合には、早期に検知できる仕組みや迅速に対処できる準備を整えることも意識しました。

具体例になりますが、大規模な牧場の分析でLambdaがタイムアウトしかけて冷や汗をかく局面があり、この際は石川さんと協力してマルチプロセスで処理する対応で収束を図りました。これを機に、緊急事態に備えてデータを分割して処理するオプションなどを用意しました。

｜顧客に価値を素早く届けること
香田：必要最小限の機能を最速でリリースすることや以下の点を重視しています。

・リリースした機能をブラッシュアップして継続的に改善すること
・そのために、顧客や現場の要望に真摯に受け止めることや、利用状況などのデータを分析すること

これらはHRテックの会社に在籍していた時のアジャイル開発の経験が大きく生きているかなと思っています。

｜利便性の向上による社内のメンバーの業務効率化
社内には、私よりもお客様に近い現場で働いている人たちが多く、その方々の作業を効率化することが、お客様にとって大きな価値に繋がるということをこれまでの経験の中で強く認識していました。
具体的な例としては、開発チームが運用で利用するツールの拡充に取り組みました。活動量のグラフに異常が出た場合に、活動量の再分析〜U-motionへの連携までを誰でも実行できる仕組みを整えたことなどが挙げられます。また、各牧場で使われているセンサーが、従来の首センサーなのか、新しいイヤタグセンサーなのか、またはその併用しているのかといった基本的な情報をUI上で確認できない状態を解消しました。こうした小さなUIの改善は継続的に取り組みたいと考えています。

最後に

ー今後「U-motion」をどのようなプロダクトにしていきたいですか？

石川：まだまだハードウェア、ソフトウェアともに完成度をさらに高めていく必要があると感じています。そのため、分析基盤を整えたり、さらに多くのデータを集めて、より高精度な仕組みを構築することに継続して取り組んでいきたいですね。

香田：蓄積されているデータの活用はまだまだ進められると感じています。それをもとに新たなアラートやセンサーの故障、電池切れなど様々なケースに対応できる機能を強化して、さらにお客様に価値を提供できるプロダクトにしていきたいです。

ー石川さん、香田さん、ありがとうございました！