このページの本文へ

Web開発者も無関係じゃいられない!? IoT案件に取り組む前に知る「Webとの違い」

2016年07月27日 00時17分更新

文●Charles Costa

  • この記事をはてなブックマークに追加
本文印刷

IoTが身近になっていくにつれ、Web開発者やデザイナーにもIoT関連サービスの案件に携わる機会が増えていきそうです。そんなときに気をつけたいWebとの違い、課題とは?

Internet of Things(IoT:モノのインターネット)は社会にいまだかつてない大きな可能性をもたらすものです。インターネットと人が互いに関わり、人の暮らしを改善していくものです。

企業は、重要な情報を集めることで業務を合理化し、大きな変化を予測し、リアルタイムで顧客の期待に応えていることを確認できます。消費者のメリットは、日常のタスクに追われることなくスマートな生活を送れることです。

IoTにはプラスの点が数多くあるものの、開発者にとってはIoTのシステムを構築する際に取り組まないといけない固有の課題もあります。

課題1:限られたバッテリー寿命

IoT Batteries

スマートフォンを考えてみると、画面サイズは毎年大きくなっていくように見えます。たとえば、「ファブレット」というタブレットサイズのスマホ。もちろん役に立つものですが、大きい画面は必ずしも便利ではなく、むしろその大きな画面のためにバッテリーをとても食うようになっています。コンピューターが薄型に進化しても、バッテリーの消費量は変わりません。

バッテリー寿命の問題はハードウェアエンジニアの領域と感じますが、UXやソフトウェア開発のプロがデバイスのバッテリー寿命を改善できる方法もあります。

  • ダークカラーの使用:アクティブマトリクス式有機EL(薄型化のためバックライトは控えめ)では、ブラックピクセルを頻繁にオフにするとバッテリー寿命が伸びます。一般に、アクティブマトリクス式有機ELでは、明るい色合いは暗い色合いよりも多くの電力を消費します
  • できるだけJPEGを使用:PNGはサイズ調整のしやすさやサポートが明確なことで広く普及してきていますが、圧縮ではいままで通りJPEGがナンバーワンのフォーマットです。スタンフォード大学の研究によると、バッテリー寿命はPNGよりもJPEGを標準にした方が効果的です
  • ネットワークリクエストの排除:リアルタイムのポーリングやデータ接続が必要なときもありますが、データプランの制限を考慮するなら控えめにしましょう
  • JavaScriptの削減:アプリ内に帯域幅や電力消費の余裕があっても、JavaScriptが大きな落とし穴になることがあります。ブラウザーが<script>タグを見つけると、追加アセットはスクリプトコードが実行されるまで、ダウンロードをストップします。

課題2:データ管理:「すべてをキャッチすること」が正解ではない

Catching fish

IoTシステムを最大限利用するには、セキュリティを維持しながらインサイトを提供し続けないといけません。ビッグデータの話になると、Forbesの「測定できないものは管理できない」というモットーが正しいようです。

多くのソフトウェア開発者が共通して犯している間違いは、どんな目的においてもデータはできるだけ収集すべきだという考え方です。バッテリー寿命の話に戻りますが、データ処理を続けながらも、データ収集を最低限に限定することで、バッテリーはできるだけ節約したいはずです。

データセキュリティの観点では、オープンエコシステムにうまく対処することが現在進行形の新領域です。業界トレンドに遅れをとらずに彼らが向かっている方向を見据える必要があります。しかしほかのモバイル開発プロジェクトと同様に、必要に応じてユーザーに権利をゆだねることは、デバイスを守るために必要不可欠な土台だと考えています。

もちろん、デジタルの脅威に怯えるだけではありません。ユーザーを代表して個人データを管理すれば、ソーシャルエンジニアリング・アタックから守られていると保証できます。

課題3:新しい基準

Gears

IoTがエコシステムとつながりデバイスとうまく作動しても、現実は少し違います。まだテストされていない新領域があるため、主要プレーヤーになるべく企業間競争が激しく繰り広げられているのです。

いくつかの製品では製品間が完全に遮断され、信用できるプロバイダーに限定して作動するように設計されているものもあれば、すべてオープンなシステムもあります。開発者にとって最大の課題は、異なるシステム間で使えるようなインターフェイスを設計することです。

この挑戦を成功させようと、Open Connectivity Foundation(OCF)は最近オープンな基準を策定し、先に言及した個別デバイス開発の問題を解決しようとしています。

ドラフト仕様から大きく変わったのは、開発スタックのすべてのレイヤーで完全なオペレーション——ユーザー体験を成功させるために、特定の分野に特化したサービス、プラットホーム、接続性など——を設計する必要があることです。動的でレイヤーにとらわないデータプロトコルを確保しながら、OCF標準の大部分で開発ワークフローを合理化するために、抽象化を活用しています。OCF標準の5つの方法は以下のとおりです。

  • 作成
  • 回復
  • 更新
  • 削除
  • 通知

また、標準化のさまざまなラインを持つIEEEの、IoT向けの拡張もあります。

課題4:すべての人のためのデザイン

Young girl entertaining Mickey Mouse and other friends at a make-believe tea party, 1930s

IoT開発の最大の課題は、おそらく、すべてのユーザーのニーズに応えることです。

本当に成功するためには、デバイスとつながるだけでは、テクノロジーに精通したユーザーを満足させられません。たとえばスマートホームはすべてのデバイスのエコシステムを活用します。施錠、気温、電気、アラーム向けの機器などは家で暮らすのに必要なものです。

さらにM2M(Machine to Machine)プロジェクトとして、スマートパワーグリッドや一般ビルのオートメーション、乗り物間の通信、ウェアラブル通信デバイスがあります。これを聞いて圧倒されてしまいますか? その必要はありません。

iPhoneやAmazon Echoを考えてください。どちらもUXデザインがよくできている例で、どんなユーザーにも対応できます。子どもからおばあちゃん、そしてテクノロジー音痴まで普通に使いこなせています。

昔は、ビジュアルがユーザー体験のプラットホームを適切に整備するための土台でした。しかし現在、すべては会話型のUIに未来はかかっています。会話型のUIは同時に新しい厄介なことを引き起こします。いまやユーザー体験のプロは、言語とビジュアルデザインの両方を取り扱えなければいけません。

途方に暮れることはない

今日の世界は開発に関する課題がたくさんあっても、あとに続く開発ワークフローのリーンやアジャイルの原則があれば、いくら複雑でも管理できるレベルに落ち着きます。

プロダクトの小さな部分であっても集中して構築し、手順に沿ってテストをすれば、激戦マーケットにおいてでも高品質なコードを届けられます。

(原文:The 4 Unique Design Challenges of IoT

[編集:Livit

follow us in feedlyfacebook_button

Web Professionalトップへ

WebProfessional 新着記事