久々のエントリは近況というかここ3年間ぐらいの活動のご報告から。
2018年に株式会社ウフルを退職してから 畜産アグリテック の世界に身を置き、ものすごく忙しくも充実した日々を過ごしています。この業界の面白さとやりがいを少しでも多くの人に伝えたく、まずはどんなモチベーションでこの業界に飛び込み、そしてどんな仕事をしてきたのかを紹介したいと思います。
私が畜産アグリテックに魅力を感じてチャレンジしたモチベーションは2つありました。
- たくさんのセンサーが接続された大規模な IoT システムの実践経験が積める
- 日本の農業が抱える社会課題 (後継者不足、コスト対策、生産性等) の解決にテクノロジーで貢献できる
まず1つ目に関しては、そもそも IoT というのはデータを集めてなんぼの世界なわけですが、ウフル時代は PoC (概念実証) で終わってしまう、つまり本来の目的である沢山の集めたデータから知見を得て改善を回す活動にまで到達せず、IoT という手段の検証だけで終わってしまうことがほとんどでした。その点畜産アグリテックは、現実世界に観測対象が多数存在していて、なおかつ課題を抱えている現場なので、本気で IoT に取り組めるフィールドでした。しかも相手は生き物です。観察すればするほど面白い、奥が深い世界です。膨大な量のデータを集めて分析することで初めてわかることもたくさんあります。
2つ目に関しては、皆さんもご存知のことかとは思いますが、日本の農業は本当にたくさんの課題に直面しています。後継者は不足し、作業を手伝ってくれる人手も不足し、飼料コストは急騰し、さらに事業の存続に関わるような疾病リスクとも常に戦っています。生産性の向上も道半ばです。しかしその分、テクノロジーによってよりよくできる余地がたくさんあります。しかも自らの手で直接テクノロジーを現場に届ける機会を得ることができます。いままで社会に役に立っている実感が得づらい仕事が多かった私にとっては、これは大変なやりがいを感じるフィールドでした。
そんなわけで、2018年の10月から畜産アグリテックのスタートアップにジョインし、今日まで IoT エンジニアとしてさまざまな仕事に携わっています。 さらに、今年の10月までは牛を対象としたスタートアップに属していましたが、11月からは豚を対象としたスタートアップに CTO として参画し、より現場と技術を繋ぐ最前線で仕事をすることになりました。 これからさらにこの畜産アグリテック業界を盛り上げていけるように頑張ろうと思います。
それでは、これまでおおよそ3年間ちょっとのうちに私が畜産アグリテックの世界でどんな仕事をしてきたか紹介したいと思います。
IoT エンジニアとしてのお仕事
IoT 機器管理・監視プラットフォームの開発
私が牛のスタートアップに入社した時点で、センサーとそのデータ収集基盤などは既にありました (自社開発ではなく、外部の会社が開発・納入したものです)。 ところが管理が行き届いているとはいえず、このまま顧客が増えていくとトラブル対応などで忙殺されてしまうと気づきました。そこで、現地の人がセンサーや設備の状態を確認できるセルフサービスのシステムが必要と考え、企画書を書いて提案し3ヶ月で基本機能を実装して社内に提供しはじめました。
システム名は “UMForce”、企画時に掲げた達成目標は以下のようなものでした。
ちなみに以下のような技術で開発しています:
- インフラ: AWS ECS (Fargate), AWS Lambda
- データベース: DynamoDB, ElastiCache (Redis), OpenSearch Service (Elasticsearch)
- 言語: Go, Python
- 画面構築: Go (
html/template標準ライブラリ) - CSS フレームワーク: SLDS (Salesforce Lightning Design System)
- グラフ描画: Chart.js
このシステムは各顧客にどの機器がどのように配置され今どんな状態なのかを社員だれでもすぐに見つけることができるようになっているほか、牛1頭1頭につけているセンサーの最新状態や過去の履歴なども確認することができます。 電池が切れそうなセンサーや、センサー値のおかしなセンサー個体を監視してレポートする機能もついています。 最終的には、現場作業や営業活動を助けるさまざまなおまけ機能なども次々と付け加えていき、フィールドエンジニア向けサービスマニュアルや業務フローなどのドキュメントの配信まで担うごった煮アプリケーションに発展しました。
画面例をチラ見せするとこんな感じです (登壇スライドより抜粋)。
当初は一部のフィールドエンジニアが便利だねって言ってくれるぐらいのものでしたが、必要な機能をひたすら追加していった結果、今やフィールドエンジニア、営業、そしてカスタマーサクセスチームが業務の起点として活用するプラットフォームになり、このシステムが当初掲げていた「顧客が気づくより先に問題を発見して対処するための基盤」は気づいたら出来上がっていました。スケーラビリティについても、開発に着手してから牧場数も7倍・8倍に膨れ上がっていますが、DynamoDB のキャパシティを引き上げるぐらいの対応で済んでいます。
もっとも、私の画面の設計にセンスがなかったり使い勝手がいまいちなところも多々あり、特にスマートフォン表示の作り込みの甘さがあるなどの課題もありますが、そのあたりは今後後進がいい感じにしてくれることを願っています。笑
IoT ゲートウェイの開発
牛舎には環境センサーを置いているのですが、機材の切り替えに伴い新しい環境センサー機器向けの IoT ゲートウェイを新規開発する機会がありました。 またそれ以外にも実験用センサーの受信などでそれ用のゲートウェイを書く機会が度々ありました。
ゲートウェイって右から左にデータを流すだけで簡単じゃん？と思われる方も多いのですが、製品として利用するゲートウェイプログラムにはさまざまな機能実装が必要になります。基本機能としては、以下のようなものが挙げられます。
- 受信処理
- デコード
- バリデーション
- 送信処理
- リトライ
- キューイング
- 設定ファイル機構
- 自動バージョンアップ機構
- ロギング
- 自己回復機構
- 自己診断機能
多くの機能は並行処理で動かさないといけません。たとえば、もし送信処理と受信処理が同じスレッドで動いていたら、送信処理中に届いたデータは取りこぼしてしまうかもしれません。要件によりますが、アラートなど人のアクションにつながるような重要なデータの場合だったり、状態変化の転換点となるようなデータの場合は、取りこぼしは機能障害にもなり得ます。
リトライは、とても気をつけないといけない処理の一つです。通信はさまざまな要因で失敗することがありますが、かといって安易なリトライは障害発生時に火に油を注ぐ事態を引き起こします。そのためエクスポネンシャルバックオフ機構を導入したり、エラー要因によってはリトライをしないようにしたりすることがあります。キューイングはリトライと似ていますが、通信が不安定な場面でも最終的に欠損がない状態に持っていきたい場合にリトライと組み合わせて作りこみます。ただし通信回線が細い場合は後でまとめて送信することも困難なため、手動操作で取り出せるようにすることもあります。
自己回復機構については、プロセスがクラッシュしても自動で起き上がる仕組みが重要になりますが、これは systemd に任せることが多いです。どんなにエラーハンドリングやリソースリーク等の対策をしっかりしていても、落ちるときは落ちるものです。systemd が下に敷かれていると、このあたりの自己回復はある程度任せることができます。
自己診断機能は、現場にいる営業やフィールドエンジニアが問題を切り分ける際の助けとなるとても重要な機能です。簡単な Web インタフェースを用意するだけでも状況把握がだいぶ楽になります。表示内容は要件によって異なりますが、概ね設定状況、動作状況、構成要素の認識状況、各種ログなどを画面に盛り込みます。これらは問い合わせの削減にも大きく貢献します。
実装においては、Go 言語を積極的に採用しました。なんといっても並行処理を簡便に書けるメリットはとても大きく、IoT ゲートウェイに求められる要件にとてもマッチしています。CPU やメモリ等のリソース効率が良いことや、1バイナリにまとめられること、標準ライブラリが充実していることも大きなメリットです。 いっぽうでバイナリサイズが比較的大きいという欠点もあります。このせいで、細い回線ではバージョンアップ処理が何度も失敗してしまうといった事態に直面したことがありました。ビルド時のフラグを工夫したりバイナリを圧縮して配布したりと策は打っていますが、根本的な解決にはランタイムの動的リンク化ぐらいしかないかもしれませんね。
リモートアクセス・ネットワーク監視システムの開発
IoT をやっていて、なおかつ現場に TCP/IP をしゃべる機器を置いている場合は、誰しもファイアウォールや NAT にとらわれずに SSH でサクッと入れる仕組みを用意しておきたいと考えるはずです。そのためのツールはすでに沢山あり、有名どころだと Remote.it が挙げられるほか、SIM ベンダーの SORACOM は Napter というサービスを提供しています。しかし Remote.it は数千台の機器で運用するにはコスト効率が悪く、SORACOM のサービスは SIM にロックインされる時点でミスマッチ・・・。
そんな場合によく取られるのが IoT のゲートウェイ側から SSH トンネリングセッションを張って待ち受ける方式です。ただしこの方法を大規模に展開するには以下のような課題があります。
- TCP ポート番号がぶつからないように何らかの管理やルールが必要になる
- 接続しにいくまでの手順が煩雑 (ポート番号調べたり、踏み台サーバーを経由したり)
- 繋がらなかったときのトラブルシューティング・原因の推測が容易ではない
- 認証鍵を物理的に各地にばら撒くことへの抵抗感、耐タンパー性の問題
この課題には昔から気づいていて、趣味でオープンソースで作っていたものがありました。名前は “kaginawa”、こんなシステムです。
ゲートウェイ上にエージェント (小さなプログラム) を置いて systemd などで起動させておくだけで、インターネット上のどこからでもその ID でさくっと SSH 接続を確立できるというものです。どの SSH サーバーにつなぎに行くのか、ポート番号は何なのかは、管理サーバーが対応関係を保持しておきます。ゲートウェイ1台1台には個別の ID をあらかじめ設定しておくことができ、設定してあればその名前でアクセスできます。ID は重複してもよく、その場合はどちらに繋ぐかの選択肢をツールが提示します。
これを実現するために、以下のような仕組みを用います。
エージェント “Kaginawa” は管理サーバーの “Kaginawa Server” から SSH サーバーの接続情報を受け取り、それを使って OpenSSH Server にトンネリングセッションを確立します。この際、ポート番号は空いているものを自動で割り当てます。接続が確立したら、ポート番号などの情報を管理サーバーに通知します。これで、インターネット上のどこからでも個別に設定した ID だけで SSH ログインできるようになるという仕組みです。
ログインには通常の SSH コマンドを使うこともできますが、それだとせっかくこのシステムを導入したメリットが半減してしまいます。”kssh” という独自ツールを用いると、管理サーバーに問い合わせて ID を探したり、ID が重複していたら選択肢を出したりする機能を利用することができます。中では結局 SSH コマンドがやることと同じことをするのですが、この ID だけでターゲットにつなぎに行けるのは本当に便利です。
ポート番号や接続状態を管理サーバーに送るついでに、さまざまな簡易メトリクスや任意のデータも送ることができます。使い方次第ではこれを IoT プラットフォームにすることもできますね。
集めたデータは管理サーバー “Kaginawa Server” で閲覧したり API で取得したりできます。注目は履歴グラフで、これを見ると通信不能だった時間帯の原因が通信障害なのか電源障害なのか一目で切り分けることができます。
Kaginawa ツールチェインは BSD 3-clause License のオープンソースソフトウェアとして開発を続けており、GitHub でソースコードや各環境向けバイナリ、Docker イメージ等を入手することができます。ただ、環境構築手順などのドキュメントが不足しているので、今後整備をしていこうと思っています。開発言語は Go です。
kaginawa
牛スタートアップではこのツールを 2,000 台ほどの Raspberry Pi に導入して運用しており、運用・保守の手間の削減や問題解決の高速化に役立てています。 Kaginawa Server のホスティングは AWS ECS / Farage, OpenSSH Server のホスティングは Lightsail, データベースは DynamoDB を使っています。
個人でももちろん (?) 運用しており、こちらは実家に置いたサーバーのメンテやネットワークのトラブルシューティングなどに活用しています。 Kaginawa Server のホスティングは Heroku, OpenSSH Server のホスティングは Oracle Cloud, データベースは MongoDB Atlas を使っています。
新規 IoT プロダクト開発
新しい価値を提供するために、いくつかの IoT プロダクトの開発を行う機会もたくさんありました。 市場投入まで見届けられなかったものも多いですが、牛舎にお邪魔して実験させてもらったりして沢山の経験を積むことができました。
公開されている実績としては、畜舎用噴霧機の IoT 化のお手伝いがあります。 畜舎用噴霧機は霧を吹いて牛を冷やしたり、薬剤を散布してサシバエ対策をしたりできる装置です。これを IoT 化することで、稼働データや高精度の温湿度計のデータの継続的な収集を可能にし、効果測定がしやすくなったり、トラブルを見つけたり、メンテナンスを効率化したりできるようになりました。しかも、牛の台帳データ・センサーデータと組み合わせて分析すれば、体調不良の分析・改善にも役立てられるというわけです。 私は制御盤から電波を拾ってクラウドに蓄積・提供するための一連のプラットフォーム (ゲートウェイのプログラム、クラウド側の API、管理画面、およびアラート) を開発しました (顧客用フロントエンドは専門のエンジニアにお任せしました)。
素敵なランディングページもあります。
“共創” や “オープンイノベーション” といったキーワードがたびたび喧伝される IoT 業界ですが、畜産アグリテックには農家のために異なる業界のプレーヤーが自分たちの技術を持ち寄って新たな価値を創造する、文字通りの共創の機会がたくさんあります。
ネットワーク構築・部材選定
IoT を実現するためには多くのネットワーク機器が必要です。LPWA などでは比較的シンプルですが、TCP/IP で通信する機器が何台もあってインターネット回線でデータを上げていく場合は、ゲートウェイのほかルーターやハブやアクセスポイントなどのネットワーク機器を配備して運用していくことになります。 そのネットワーク機器も、値段に釣られてコンシューマー向け商品を選んでしまうと調達が不安定だったり保証期間が短かったりして苦労することになります。そこで法人向けの機器を積極的に採用することにしているのですが、それでも新しいモデルに変わったりディスコンしたりは結構起きます。そんなときは別の機器をもとめて部材を検証・評価したり、サービスマニュアルを書いたりする活動を行います。
難しいのが無線機器の検証です。とくに Wi-Fi は外的要因でかんたんに不安定化してしまいます。飼料を搬入するトラックに電波が遮られたり、近くにノイズを発する設備があって影響を受けたりなんてことも。現場の数だけ課題があるといっても過言ではありません。問題の解決には TCP/IP をはじめとしたコンピューターネットワークの知識、解析ツールを使いこなせる Linux の知識に加え、牧場というフィールドの想像力も必要になります。 しかし、難しい問題を解決できるとエンジニアとしても成長を実感できて楽しくなります。また、ほとんどの問題は現場にいるフィールドエンジニアと連携して対処するのですが、新しい機器を初めて導入する際などは IoT エンジニアが直接現地に出向くこともあります。そこで大きな改善効果が得られたりすると喜びもひとしおです。
監視カメラの展開
IoT エンジニアの仕事の範疇になるかは微妙なところですが、IP 通信できる監視カメラも立派な IoT 機器ではあります。そして農家から設置してもらえないかとよく相談を頂く機器でもありました。そこで試験的に導入をお手伝いする活動も本業の傍らやっていました。
IP カメラの難しいところはなんといってもセキュリティ対策です。ほとんどの農家が牧場の外 (自宅等) から映像を確認したいというニーズを持っているのですが、そのためにはインターネットからカメラにアクセスできるようにする必要があります。しかし安全に映像を中継するためのクラウドサービスを備えた業務グレードのカメラはまだ少なく、それ以外のカメラの場合はいわゆるポート解放によってアクセスするのが一般的になっているようです。もちろん私はインターネットに攻撃対象面を安易に晒すようなことはしたくないので、クラウドサービスを備えたカメラの導入を推し進めてきました。ただ、選択肢が限られてしまうので「なんでこっち (要ポート解放) のカメラじゃダメなのか」と営業から噛みつかれることもありました・・・。
簡単にカメラをポン付けしてお試しできるユニットも開発しました。コストを削減するため Raspberry Pi にルーター OS である OpenWrt を導入し USB スティック型の LTE ドングルを使って通信する PoE 給電可能なゲートウェイを作ったりしました。この中には前述の “Kaginawa” も入っており、ノウハウが詰まっています。
IoT エンジニアとして以外のお仕事
エンジニア採用活動
エンジニアはどこも人材不足、ということで途中から採用活動にも積極的に携わるようになりました。書類選考や面接などをするだけでなく、会社の露出度アップ作戦もいくつか実行しました。たとえば、セミナーに登壇したりです。
“UMForce” の説明で紹介した絵は、以下のスライドから抜き出してきたものです。エンジニア向けに会社の概要を説明した資料になります。
こうした活動を通じて、畜産アグリテックに興味を持ってくれるエンジニアはとてもたくさんいることに気がつきました。ただし一歩を踏み出そうとする人となるとやはり少ないのが現状です。 私の訴求力ももっともっと高めていかねばと感じています。
プログラミング教育
ウフル時代は Kotlin の教育などをやったりしましたが、IoT との親和性を示すことができた Go 言語をもっと広く使ってもらおうと社内 Go 研修を企画して実施するなどしました。その様子は技術ブログ (Note) に記してあります。
資料公開！約半年間かけて「社内 Go 言語研修」を実施しました
アンケート結果を見ると全体的にやや難易度が高め＆詰め込みすぎだったようで、もう少し時間をとった上で分かりやすく教えることが必要であることを学びました。
なお資料は古くなったり間違った情報が書かれていることもありうるので、ご利用の際は自己責任でお願いします。
プログラミング以外にも、社内勉強会で技術書の紹介やツールの紹介などをすることがあったほか、新人向けに AWS の DynamoDB について簡単な講習を開いたりもしました。ただし、一度や二度の勉強会や講習で伝えられることは多くはありません。やはり後進の育成には時間をかけて継続して取り組む必要があることも痛感しています。これからも高い優先度で取り組んでいこうと思っています。
牛から豚へ
冒頭の写真は展示会でブースに置いていた豚の模型です。 この通り現在は豚ビジネスにおける価値創造に取り組んでいます。
牛と豚には共通点もありますが、異なっていることのほうが多く、牛相手を3年間やっていた私にとってはまだ知らない世界が広がっています。 違いを楽しみつつ、ノウハウも発揮しつつ、畜産農家や食肉業界の社会課題に貢献できるような仕事ができればと思っています。
この記事では IoT エンジニアの立場から得られる経験の一部を紹介しましたが、Web、機械学習、インフラ、ネットワーク、DevOps、SRE、セキュリティ、組み込み、ロボット、回路設計、機械設計、フィールドなどさまざまな種類のエンジニアが畜産アグリテックで活躍の可能性があります。 テクノロジーの社会実装に興味がある方、食の未来にテクノロジーで貢献したい方は、ぜひこの業界に飛び込んで欲しいと思います！一緒に畜産アグリテックを盛り上げていきましょう！