IoTアプリ開発に立ちふさがる壁
IoTアプリをざっくりととらえると「デバイスからデータを取得して処理するもの」と言える。ここには「デバイス」「データを取得」「処理」という3つの側面がある。「デバイス」は組み込み開発であり、「データ取得」はArduinoのような入出力ポートを備えた基板とプログラミング、「処理」にはクラウドが絡む。つまり、複数のテクノロジーを統合的に扱う必要があるということだ。
IoTアプリと、そうでないアプリの開発で大きく異なる点として、山崎氏は「データを取得するセンサーはネット上ではなく、リアルワールドにあります」と指摘。リアルワールドにあるということは多くの選択肢と不確定要素が存在するということであり、試行錯誤が必要となる。
例えば、センサーからデータを取得する際にも、まずセンサーを設置する位置はどこが最適か、あるいは距離を測る場合でもセンサー自体、赤外線がいいのか超音波がいいのか、さらに、データ取得の間隔はどの程度が適当なのか、何度も試してみないとわからない。現場の状況によって最適解が異なるのが実情だ。
一方、開発サイクルの観点では、データの収集から始まり、処理、蓄積、可視化、分析、検討のサイクルを回していくことになる。近年はDevOpsが主流のため、開発（計画、創出、検証、パッケージ化）と運用（リリース、構成管理、監視）の間を行き交うことになる。
こうした現状を踏まえ、山崎氏は「IoTアプリ開発では複数のテクノロジーを簡単に扱えて、開発と運用を行ったり来たりできてPDCAサイクルを素早く回せることが重要です」とポイントを語る。
そして、「SHARE MY FUN（私の楽しさを共有します）」ということで「Node-RED」を紹介した。Node-REDはフローベースのビジュアルプログラミングツールで、Webブラウザからフローを編集できる。ハードウェアデバイスやAPI、クラウドサービスなどを線で結んでいくため、IoTアプリ開発に使える。もともとはIBMが開発したものだが、JS Foundationに寄贈されたため、今はOSSとなっている。
Node-REDを使用するには、ローカルにインストールする方法と、アカウントを登録してクラウドサービスで使用する方法の2通りがある。前者はNode.js上に構築する。後者だと、現時点では「IBM Cloud」「アマゾン ウェブ サービス（AWS）」「Microsoft Azure」それから「enebular」が選べる。山崎氏のオススメはもちろんウフルが提供するenebular。Node-REDを拡張して、IoTの製品やサービス作りを包括的に支援するオーケストレーションサービスだ。
山崎氏はenebularが一番簡単にアカウント登録できるとし、その流れを披露した。まずは「enebular.com」にアクセスして「新規登録」をクリック。続いて入力フォームに氏名、メールアドレス、パスワードを入力し、プライバシーポリシーなどを確認して「sign up」ボタンをクリック。あとは届いたメールで確認を済ませれば登録完了となる。確認が済んだら「Go to Dashboard」で利用開始だ。
作ってみた！ 遠隔地の親を見守るIoTアプリ
IoTアプリを簡単に開発する例として、山崎氏は実家にて独りで暮らす母親のためのIoTアプリ開発を紹介。高齢となり、寒さで風邪をひかないか、夏は熱中症にならないか、息子としては心配になる。そこで「IoTな感じの見守りアプリ」を開発することにした。
システム的な要件を抜き出すと、「規定値以下または以上の気温になる」と、「遠隔地に通知する」となる。
手軽に作るため、山崎氏はAmazonで入手できるデバイスで試作することにした。選んだIoTデバイスは「NETATMO ウェザーステーション」。天候センサー（温度、湿度、気圧、二酸化炭素、騒音など）が一通りそろっていて、スタイリッシュなデザインが特徴だ。ネットワークに接続し、設定値になるとスマホにアラートを送ることかできる。
この要件をNode-REDのフローエディタで開発してみる。5分間隔のトリガーを繰り返して気温を取得し、測定温度により処理を分岐する。寒すぎる、または暑すぎるとメールとSlackに通知し、それ以外であれば確認のためのデバッグメッセージを出力する。
注目は分岐処理。温度により処理が分岐するところを「switchノード」にて、分岐条件を記入する。「<=」や「is between」を選んで気温を記入することで、コーディングせずに条件分岐できる。ループ処理もコーディング不要だ。
今回の処理はクラウドサービス間だけでデータをやりとりする。IoTデバイスから開発環境となるenebularへデータが受け渡され、実行環境のHerokuにデプロイされた。もちろん、Raspberry Piのようなデバイスを使うフローも可能だ。
またデータの蓄積にFirebase、データ可視化に「enebular INFOMOTION」を用いることで発展させることもできる。これらはenebular標準機能として提供されている。
山崎氏はオススメ記事も紹介した。Node-REDで効率がいい設計パターンをまとめた「目からウロコ！Node-REDのデザインパターン10選」がある。これは2015年にQiitaに投稿された記事で、多くの人に読まれている。山崎氏によると、この記事の投稿者は後日上司に「この記事には良いことが書いてあるから、君も読むといい」と勧められてしまったという。
最近では続編となる「目からウロコ！Node-REDのアンチパターン10選」が、同じ投稿者から発表された。前回とは逆に、アンチパターンをまとめたものとなる。
チームで開発するときのポイント――役割分担や初期設定の管理
企業などチームで開発する場合には、役割に応じた権限付与が必要になる。enebularではプロジェクト管理者「Project Owner」、プロジェクトメンバー「Project Collaborator」、1つのアセットにひも付いたメンバー「Outside Collaborator」といった役割を使うことができる。また「owner」「superdev」「developer」「operator」「user」で権限を分けることができる。
またチームでフローを共有すると、マジックナンバーやマジックストリングが分散してしまう問題が起きてくる。1つの有効な対策となるのが各種設定をまとめた初期化フローを作成し、設定するノードを1つにまとめることだ。
開発コミュニティも、ある意味、協力し合える、より大きなチームと言えるだろう。enebularのフローなどの開発用資産（Asset）の公開・共有機能を使ってAssetをインポートして開発を効率化したり、自分の開発したAssetをコミュニティに還元したりするもまた楽しい（Fun）。
ところで、こうしたコーディング不要のツールに対して「（慣れたプログラマなら）コーディングしたほうが早いのでは」という疑問が投げられる。それに対して山崎氏は、IoTLT主催者である菅原のびすけ氏のコメントを紹介した。
「確かにデバイスだけなど、1つのテクノロジーのプログラミングならそうですね。でも、デバイスや複数のクラウドテクノロジーが重なってくると、コードも複雑になって訳がわからなくなるので、そんなときはenebularなどのノンコーティング開発がいいですね」（菅原のびすけ氏のコメント）
将来を見据えた保守性を考えると、ノンコーディングで複雑性を減らしたほうがメリットがあるということだ。
最後に山崎氏は「コーディングを減らして楽しくやりましょう。試行錯誤が低コストで素早くできる開発環境を選びましょう。そして先人の知恵をうまく借りましょう。ただし借りたら返すことも大事です。得た知見をコミュニティに発表することや、フィードバックを送ることで恩返しができます。ぜひまずは第一歩を踏み出しましょう」と述べてセッションを締めた。
お問い合わせ
株式会社ウフル
