目次


IoT 開発のベスト・プラクティス

モバイル開発から学んだ教訓を IoT プロジェクトに活かす

Comments

IoT 製品を開発することに決めたのなら、開発を始めるにあたって、モバイル開発で考え出された多くのプラクティスから学ぶことができます。具体的には、以下のプラクティスを行うことを検討してください。

  • API をサービスから切り離す
  • ソリューションのプロトタイプを繰り返し作成する
  • 接続の問題を想定する

アバター、サービス、切り離された API

何らかの Web アプリケーションを作成したことがあるとしたら、サービスの概念についてはよくご存知のことでしょう。サービスとはアプリケーションが提供する機能であり、従来はシステムのことをサービスと見なしていました (例えば、気象データ・サービスなど)。

こうしたサービスを利用するのは、インターネット接続された「モノ」である「アバター」です (ソフトウェアの場合もあれば、物理的な形を備えたスマートなモノの場合もあります)。これらのアバターが、サービスの一部または全体とやりとりします。アバターはそれぞれ独立してサービスとやりとりしながらも、そのすべてがまとまってサービスを強力なものにします。

例として、気象データ・サービスについて考えてみましょう。この場合のアバターとしては、コンシューマーとして現在の気象に関する測定値を表示する Web サイトまたはモバイル・アプリであることが考えられます。あるいは、データを気象サービスに毎分レポートして、現在の気温、湿度、風速に関する情報を共有できるように、ネットワーク接続された測候所がアバターになることもあります。

現世代のモバイル・サービスは極めて強力なので (例えば、数あるコンシューマー・アプリケーションの中でも Google (とりわけ Google Now)、Facebook、Twitter など)、これらのサービスにアクセスするには、デスクトップ・アプリケーション、モバイル Web サイト、特定のアプリケーション、サード・パーティー製アプリケーション、さらにはブラウザー・プラグインなど、さまざまな手段を使用することができます。これらのアバターは、それぞれが動作する特定分野のコンテキストに対応するために、必要とされるだけのサービスを利用することができます。したがって、あらゆる Web ページ (アバター) に「このリンクをツイート」ボタン (1 つのサービス) を埋め込むことも、Android (アバター) のホーム画面から検索結果のリスト (別のサービス) を表示することも可能なのです。

この手法を促進する決め手は、それぞれのアバターがコンテキストに応じて効果的な方法でやりとりできる、利用しやすい API を備えたサービスを設計することです。

ハードウェアの分野に関して言うと、この手法の最近の好例としては FitBit が挙げられます。FitBit の製品ラインアップはすべて、健康とフィットネスをこれまで以上に測定可能なものにする上で役に立ちます。製品ごとに違いはあるものの (例えば、歩数を記録する製品と、登った階段の段数を記録する製品との違いなど)、コアとなるサービスはすべての製品で共通しています。FitBit 製品は、アクティビティーに関連するセンサーからデータを集約します。その集約したデータをユーザーに提供し、ユーザーが情報に基づいて健康に関する意思決定を行えるようにします。

つまりサービスの観点で言うと、FitBit が提供するのは以下のサービスです。

  • アクティビティーに関するデータ (アクティビティーのタイプ、継続時間、カロリー消費量、アクティビティーが行われた時間、心拍数) を追跡するサービス
  • 睡眠に関するデータ (睡眠時間と、眠っていない時間の長さ) を追跡するサービス
  • カロリー摂取量と水分摂取量を追跡するサービス
  • 体重データを追跡するサービス
  • システムで収集したデータをレポートするサービス

アバターの観点で言うと、FitBit 端末に対してはさまざまなアバターがさまざまな形で動作します。

  • 体力トラッカーが情報を記録し、その情報をサービスに渡します。
  • 集約したデータの基本ビューをモバイル・アプリが表示します。
  • これまでの傾向をより詳細に示すビューを Web アプリケーションが表示します。
  • サード・パーティー・システムがプラットフォームにデータ (食糧消費量など) をプッシュする場合もあります。
  • サード・パーティー・システムが、集約データ (歩数など) を読み取って、そのシステムに固有のサービスに追加する場合もあります。

おわかりのように、サービスと優れた API の作成を切り離すことで、FitBit には以下のメリットがもたらされています。

  • さまざまなアバターを通してサービスを表現できるため、あらゆる箇所 (手首、ポケットの中、デスクトップ上) で価値を提供することができます。
  • サード・パーティー・システム独自のサービスで、FitBit に付加価値を与えることができます。
  • (多くの企業が Apple と競争したことで) モバイルの世界は分断されましたが、FitBit は、アバターを必要としていた任意の端末を対象とするアプリに、迅速かつ容易に対応することができます。

この、サービスと API を切り離すという手法は、次第に一般的になっています。それは、アプリケーションがモバイル・エクスペリエンスとデスクトップ Web エクスペリエンスの両方に対応しなければならないためです。したがって、同じような手法で IoT サービスをセットアップすれば、市場機会の出現に応じて新しい方向性に転じることが可能になるはずです。

IoT 製品に必要なソフトウェアとハードウェアのプロトタイプ

物理的な実体のある製品を作っている誰もが知っているとおり、製品作成のプロセスは、まず非常に単純なプロトタイプを作成するところから始まります。その後、フィードバックや実際のパフォーマンスに応じて、プロトタイプの改良を重ねていきます。IoT 製品の場合、ソフトウェアとネットワークの構成要素のプロトタイプも作成しなければならないという複雑さが加わります。

IoT 製品が使用される可能性のある数々のコンテキストを考えると、この複雑さはさらに深刻なものになります。センサー 1 つを取っても、そのセンサーとどのようにやりとりするのか、やりとりにはモバイル・アプリを使用するのか、それとも Web アプリケーションを使用するのか、構成はレポートされる内容に沿ったものになっているのか、インターフェースはどの程度使いやすいのかなど、質問は枚挙にいとまがありません。

モバイル製品は、この難題に対処してきた長い歴史があります。それは、モバイル環境の性質として、サービスのユーザビリティーに影響を及ぼすコンテキストの変化が生じる恐れがあることが、その背景にあります。したがって、モバイル開発は一般に基本的なプロトタイプを使用して進められます。プロトタイプを改良しながら、その忠実性を高めていくという方法です。通常、このプロセスを構成するのは以下の 4 つのフェーズです。

  1. 単純な対話型 Web アプリケーションを作成します。この対話型 Web アプリケーションでは、開発フレームワークを使用して、対話の中核部分のワイヤーフレームを迅速に作成します。そして、プレースホルダー・コンテンツに対するすべてのサービス呼び出しをスタブアウトします。このプレースホルダー・コンテンツは、情報をどのようにレンダリングしてやりとりする必要があるかをシミュレーションするのに十分な程度、実際のコンテンツに近いものにします。
  2. プロトタイプを改良した後、サービスの単純な側面を統合する作業を開始し、レスポンスが適切でコンテキストに従って関連性があるものになっているかどうかを判断できるようにします。
  3. 機能のプロトタイプに加え、インターフェースの設計を開始します。そして、対話のメソッドと要件を検討して、ガイダンスとフィードバックを求めます。
  4. 製品をリリースするまで、機能の改良と統合を続けます。

IoT 製品のプロトタイプ作成を繰り返し行うことで、その製品が有用であること、そしてサービスの適切な側面が組み込まれていることを確実にすることができます。ただし、サービスのあらゆる側面がすべてのコンテキストで必要なわけではないことに注意してください。最近のモバイル・バンキング・アプリケーションを例に取ると、口座の残高照会や一部の支払い/振込み操作以外では、バンキング・プラットフォームを完全に思い通りに操作することはできないのが通常です。モバイル・バンキングを使用するコンテキストでは、ユーザーは外食したり料金をすぐに支払ったりするのに十分な残高があるかどうかを確認するだけ、というのが一般的だからです。

IoT サービスとアバターのプロトタイプを作成することに加えて、以下のように、製品で使用するハードウェアのプロトタイプを繰り返し作成することもできます。

  1. まずは、単純な市販のハードウェアから始めます。Arduino は趣味で使用するプラットフォームだと誰もが思っていますが、これは安価な上に、よく作られており、何かを迅速に作成して自分で操作できるようにする上では、十分信頼に足るものです。カスタム・システム・ボードの設計に投資しなくても、わずか数ドルを出すだけで、自分のアイデアにメリットがあるかどうかを判断することができるのです。
  2. できるだけ市販のコンポーネントを使って、プロトタイプを改良します。プロトタイプは、迅速に解体して組み立て直せる規模に維持する必要があります。それには、システム・ボード (ホール・コンポーネントを使用) とプラガブル・モジュールを使用してプロトタイプを作成するのが最善です。実装の詳細に没頭することなくプロトタイプを作成できるよう、とてもよく知られているコンポーネントを使用します。
  3. 極めて重要なコンポーネントは、接続先のシステム・ボードとは切り離します。I2C や SPI などの標準プロトコルを採用しているコンポーネントを使用すれば、Arduino を BeagleBone または Raspberry Pi と迅速に交換することができます。
  4. ハードウェアを交換することに決めるまでは、できるだけ長いこと市販のハードウェアを利用し、ハードウェアを交換することに決めたら、今度はその新しいハードウェアについて再び検討を行います。

注目すべき点として、IoT 製品のコアには、Raspberry Pi、Arduino、ESP8266、またはこれらと同様のコンポーネントを使用することができます。もちろん、特定のチップやシステム・ボードを使用しなければならない、それ相応の理由がある場合もありますが、インターネット接続されたガーデン・センサーを作成しているとしたら、ATMEGA328 (Arduino のコア) または ESP8266 を使用すれば、頭上に十分なスペースができます。市販のコンポーネントを使用すれば、すでに存在しているスケール・メリットや、基本的な問題が解決済みであるというメリットが得られます。

最近のハードウェアは簡単にリバース・エンジニアリングすることができます。IoT 製品の価値は、個々のアバターではなく、そのサービスにあります。したがって、カスタム設計された高価なハードウェア・コンポーネントを使用しても、アバターのコストが高くなるだけで、サービスの価値を有意義な形で引き上げることにはなりません (製品の価格が下がる場合もあります)。コンポーネントとコントローラー・ボードは、モジュール式のままにしてください。そうすれば、より強力なシステム・ボードや、より価格の低いシステム・ボードへと移行する必要が生じた場合、すべてを始めから作り直す必要がなくなります。

プロトタイプの作成について最後に指摘する点として、必ず使用状況とエラーの詳細をログに記録してください。これらの詳細をログに記録しておくと、システム内で何がうまく行っていて何がうまく行っていないのかを理解できるだけでなく、より迅速にデバッグすることができます。迅速にデバッグできるということは、プロトタイプ作成のフェーズでは非常に重要な要件です。ロギングしたものは、本番へ移行するまでずっと保持することもできますが、その場合、エンド・ユーザーは当然このロギングに関してプライバシーの懸念を抱くこと、そしてその懸念に適切に対処する必要があることを頭に入れておいてください。

接続の問題を解決できる「オフライン・ファースト」デザイン

欧米の都市では特にそうですが、大都市で暮らす多くのエンジニアたちは、モバイル・ネットワークと Wi-Fi ネットワークはどこででも使えるのが当然のこととして考えています。この誤った前提によって、製品がまったく使いものにならなくなる可能性があります。最近のモバイル開発と Web 開発では、「オフライン・ファースト」と呼ばれるプラクティスが採られています。その目的は、ネットワークのバックアップがなくても、できるだけ適切に機能するアプリケーションを作成することにあります。すべての機能が利用可能な状態を維持するとまでは行かなくても、接続が失われてから回復するまでのプロセスは、エンド・ユーザーに影響しないシームレスなものでなければなりません。

モバイルの観点では、オフライン・ファーストの設計を容易にするために従うべき一般原則には以下のものがあります。

  • どの瞬間でも ― (とりわけ) 転送の最中であっても ― ネットワーク接続が失われる可能性があることを前提とします。
  • メッセージとして 1 つの大きなサイズのリクエストとレスポンスを使用するのではなく、サイズを小さくしたメッセージを頻繁に送受信するようにします。
  • ネットワークで送信しなければならないメッセージは、ローカル・ストレージを使用してバッファリングします。ローカルで保管されたメッセージは、オフラインになった時点でキューに入れることも、障害が発生した場合に再送信することもできます。
  • 必ず、アプリケーションに接続を評価させます。ユーザーが接続状態を認識しているとは期待しないでください。
  • 裏でデータを同期するメカニズムを用意します。例えば、ユーザーが作業を続行できるように、最初にシステム状態を更新して、後でバージョン管理されたデータを同期させるなどのメカニズムです。

IoT の観点では、以上の一般原則の多くが当てはまるものの、永続的な Wi-Fi 接続を前提とするセンサー・デバイスは数多くあります。当然のことながら、非常に混み合った空間にいるとしたら (例えば、香港のような大都市の中心にある住居用のビルにいるとしたら)、50 から 100 の W-Fi ネットワークのすべてが同じ信号空間で競合している可能性 (そして、互いに干渉している可能性) があります。開発者を対象としたカンファレンスに出席したことがあればご存知だと思いますが、200 人程度でも、ノート PC、タブレット、そして携帯電話を携えた開発者全員がホットスポットに接続すると、Wi-Fi は劣悪な状態になってしまいます。私の経験では、完璧に良好なワイヤレス・モジュールが、ノイズと競合が原因でカンファレンスでの接続を拒否したこともあります。

IoT の観点では、以上のプラクティスから参考にできることは何でしょう?以下に挙げる設計上の要点について検討してください。

  • 随時、ネットワーク障害を想定します。
  • 最初にローカルで作成してから、データを送信します。
  • サーバー・サイドでは、RabbitMQ などのメッセージ・キューイング・システムを使用してメッセージを処理します。
  • メッセージング・プロトコルとしては、比較的重い HTTP ではなく、CoAP や MQTT などの軽量でレジリエンシーのあるプロトコルを使用します。

ノードが長時間ネットワークから切断されている場合に診断できるよう、アラート・システムをサービスに組み込みます。このアラートで情報を提供する必要がありますが、(デバイスのバッテリーに故障が発生した場合などのように) ユーザーを圧倒するような量の情報であってはなりません。

自宅のネットワーク環境でさえも、ネットワーク空間に入ってくる端末が増えてくると、ネットワークの信頼性を保証できなくなります。したがって、IoT 開発の極めて重要な要素として、オフライン機能とネットワークのレジリエンシーを確実にする必要があります。

まとめ

この記事では、API をサービスから切り離すことが、強力な IoT アプリケーションを作成する上でいかに役立つかを詳しく見てきました。また、Arduino ボードなどのモジュール式の単純なハードウェアを使用すると、IoT ソリューションを開発しやすくなります。さらに、「オフライン・ファースト」というモバイルの概念を適用することにより、IoT (モノのインターネット) デバイスのネットワーキングをより確実に成功に導けるようになります。この記事から、IoT の「モノ」の成功をより確実にするために、モバイル開発のベスト・プラクティスを IoT 開発に適用する方法を十分に理解できたはずです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development
ArticleID=1018557
ArticleTitle=IoT 開発のベスト・プラクティス
publish-date=10292015