「WoT」はごくごく簡単にいうと、既に普及しているHTMLやJavaScriptなどのWeb技術を使ってIoTの開発を標準化しよう、という考え方です。WebBluetooth APIやWebNFC APIなど、みなさんが慣れ親しんでいるWeb技術を使ってハードウェアを制御する方法も増えてきています。

今回は、WebページからPCに繋がれたUSBデバイスを制御することができる「WebUSB API」の概要とサンプルを紹介します。

HTMLと簡単なJavaScriptで試せる内容になっていますので、Webデザイナーやディレクターなどエンジニアではない方もぜひチャレンジしてみてください！

WebUSB APIとは

WebUSB APIはPCに接続された全てのUSBデバイスにウェブから直接アクセスすることができる技術です。USBデバイスの認識、読み出し、書き込みなどを行うことができます。

Googleの2人のエンジニアによって開発され、2017年9月にはChromeブラウザ（Google Chrome 61）で正式に採用されました。

WebUSB APIを利用するとただちにユーザのUSBデバイス全てにアクセスできる、というわけではなく、ユーザがWebページとUSBデバイスの相互通信を明示的に許可することで開始されます。

WebUSB APIのポリシーやセキュリティについては、Googleの開発者向けページで詳細に紹介されています。

⇒ Access USB Device on the Web（Google Developers）

WebUSB APIの活用シーン

WebUSB APIを活用することで、これまで事前にドライバやソフトウェアのインストールが必要だったUSBデバイスのセットアップが、サイトにアクセスして許可するだけで自動で行えるなどの連携が考えられそうです。

またデバイスの開発者サイドのメリットとしても、OSごとに異なっていたドライバ開発がJavaScript SDKを使ってクロスプラットフォームに構築できるそう。

webusb/arduinoなどの例を利用してArduinoなどのマイコンボードをWebから制御することも可能になりました。

詳細な仕様は開発者のドラフトを確認してみてください。

⇒ WebUSB API

本格利用はこれから

ただし、実際にWebUSB APIを導入するにはまだまだ課題がありそうです。

USBアクセスを求めるWebページを公開するために資格や証明が必要ということはなく、利用ユーザは「本当に信頼できるWebページか」ということを知る方法が今のところありません。

また開発者サイドも、USBデバイスの情報が新しくなったり変更されたりするたびにWebページを改修する必要がある可能性もあります。

利用には気をつけるべきポイントが多く、WebUSBはまだ開発中の段階と捉えたほうがよさそうです。安全面、実装面ともに改良され、より使いやすい機能となっていくことに期待ですね。

WebUSB APIを使ってログイン認証を実装してみよう

今回は「登録済みのUSBデバイスならログインする」というWebページを作ってみます。

用意するもの

• Chromeブラウザ
• 任意のUSBデバイス（筆者はiPhone7）

手順1：Chromeのバージョンを確認する

はじめに、ChromeブラウザがWebUSB APIに対応したバージョンになっているか確認します。

Chromeのツールバーから［Google Chromeについて］を選択します。

Chromeの情報ページが開くのでバージョンが62以上であることを確認します。

基本的には自動でアップデートされているはずですが、万が一されていない場合は下記を参考にアップデートしましょう。

⇒ Google Chromeを更新する（Google Chrome ヘルプ）

手順2：ログインページを作る

WebUSB APIを設置するWebページを作ります。今回はコード共有サービス「CodePen」からログインフォームのソースコードを利用しました。

Calm breeze login screen（CodePen）

［Export］からソースコードを取得しローカルに配置します。

今回は「Username」「Password」は不要なので、index.htmlのフォーム部分から消去しておきます。

<form class="form">
	<input type="text" placeholder="Username"> // この行を消去
	<input type="password" placeholder="Password"> // この行を消去
	<button type="submit" id="login-button">Login</button>
</form>

ログインのイベントを作成する

LoginボタンをクリックしたらWebUSB APIのイベントが発火するよう、Submitボタンを変更します。

auth()というfunctionを呼ぶようにし、記述用のJSファイルの呼び出しも追加しておきます。

<form class="form">
		<button type="button" onclick="auth()" id="login-button">Login</button>
	</form>
	<script src="js/webusb.js"></script>
</body>

ログイン成功時のイベント（デフォルトのJQuery）は名前つき関数にしておきます。

function login() {
  $('form').fadeOut(500);
  $('.wrapper').addClass('form-success');
}

USBデバイスにアクセスして識別情報を取得する

認証に使用するデバイスを識別するために、［Vendor ID］, ［Product ID］, [Serial Number]を調べてみます。

Macの方は［システム情報］->［USB］で確認できます。

Windowsの方はMicroSoftのusbviewなどを利用しましょう。 ※このシリアル番号は、iPhone自体のシリアル番号とは別です。

/jsフォルダの配下にwebusb.jsファイルを作成し、authfunctionを作成します。コード内には取得したVendor ID（製造元 ID）、Product ID（製品 ID）、Serial Number（シリアル番号）を追加します。

'use strict';

const auth = () => {
  const vendorId = XXXX; // ここにVendor ID
  const productId = XXXX; // ここにProduct ID
  const serialNumber = 'XXXXXXXX'; // ここにSerial Number
  navigator.usb.requestDevice({ 'filters': [
      { 'vendorId': vendorId, 'productId': productId }
    ]
  }).then(device => {
    if (device.serialNumber === serialNumber) {
      console.log('success!');
      login();
      return device.open;
    } else {
      console.log('false!');
      alert('認証に失敗しました');
    }
  }).catch(error => {
    console.log(error);
  });
}

今回は簡易的にJSファイルに直接認証情報を書いています。

ログイン機能を試してみよう

登録したUSBデバイス（今回はiPhone）で試してみます。
認証が成功しました。

登録していないiPhoneでも試してみます。
認証に失敗しました。

これでUSBデバイスを識別することができました！

まとめ

今回はUSB接続したスマートフォンを利用しましたが、マウス、キーボード、フラッシュメモリなどUSBデバイスならどんなものでも利用可能です。

またWeb USB以外にも、WebBluetooth APIやWebNFC APIなどWeb技術を使ってハードウェアにアクセスする方法は増えています。ぜひこれからの開発に利用してみてください！

HTML5Experts.jp名物、いろんな会社におじゃまして開発環境や開発体制とかを根掘り葉掘り聞く企画、今回はIoT通信プラットフォームとして大変な注目を集めるソラコムさんに伺ってきました。

インタビューに答えてくれたのは、執行役員プリンシパルソフトウェアエンジニアの片山暁雄さん、シニアソフトウェアエンジニアの清水雄太さん、同じくシニアソフトウェアエンジニアの小熊崇さんです。
今回は副編集長の仲さんがインタビュアーを務めます。

まずは自己紹介から！

仲 本企画は、イケてるサービスを作っている会社を訪問して、どう開発しているのかなどを根掘り葉掘り聞く企画です。まずは、自己紹介からお願いできますか？

片山 イケてるっていう前提がハードル高いですね(笑) 。

私は現職ではソフトウェアエンジニアで、課金の周りやSIMを管理する仕組みなどを開発しています。どちらかというとバックエンド寄りですね。もともとはJavaのプログラマーを10数年やっていて、以前は金融業界にいたので、ずっとBigDecimalとかを扱うプログラムを書いていました。結局今も同じようなことをやっていますけど(笑)。

前職はAWSでサービスの普及に務めていたのですが、だいぶ普及も進んだのでプログラマーに戻ろうかなと思い、転職して今ここにいるというかんじです。

▲株式会社ソラコム 執行役員 プリンシパルソフトウェアエンジニア 片山暁雄さん

小熊 私はソラコムに入社した当初は、Webの管理コンソールを開発していました。

今はAPIのゲートウェイになる部分を作っています。ソラコムのバックエンドは、実際にはいくつものマイクロサービスに分かれているのですが、それを外から見た時に単一のAPI群に見えるようなゲートウェイを作っています。

あとは、コマンドラインインターフェースやSDKなど、開発者の皆様に使っていただく部分を開発しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 小熊崇さん

清水 私はフロントエンドを中心に担当しています。例えば、先ほどの小熊が以前開発していたWebの管理コンソールは、現在私が開発を引き継いでいます。

前職でRuby on Railsを使ってフロントエンド・バックエンドの開発を行っていましたので、ここでもそういう役割が多いですね。

ほかにも、普段の開発作業で行うスタンドアップ・ミーティングやSlackなど、開発体制の整備も行っています。このオフィスを作るにあたってのディレクションなど、開発から少し外れた部分も担当しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 清水雄太さん

ソラコムって…なに？

仲 では、ソラコムさんのサービスの概要を教えていただけますか？

片山 はい、私たちのサービスを一言で言うならIoT向けの通信プラットフォームです。IoTのサービスを実際に展開しようとした際に発生する、技術的な課題やビジネス上の課題解決を支援するためのプラットフォームです。

具体的には、3GやLTEといったモバイル通信を使った通信サービス、そしてそれらをうまくクラウドにつなぐためのサービスです。 SIMカード「SORACOM Air」は、Amazon.co.jpで1枚から通販で購入可能です。また、世界の120の国と地域で通信を行えるようになります。

SIMカードを提供するとだけでは従来の通信事業者さんと変わらないのですが、私たちの特徴はIoTに特化しているというところです。

まず私たちの特徴の一つとしては、通信事業者であれば通常必要とされるようなパケット交換機や顧客管理といった通信用のハードウェアを一切持っていません。専用のハードウェアを用意する代わりに、それらを実現するソフトウェアコンポーネントを用意して、AWS上ですべてを実現しています。

通信に必要な基地局などは、MVNOとして通信キャリアから借りて、クラウド上ですべてを処理できる仕組みを持っています。

仲 なるほど、IoTに特化した、クラウドネイティブなMVNOというかんじですね。

片山 こうしたサービスをAPIの形で公開している、というのも大きな特徴と言えるでしょう。

IoTをやろうと考えるお客様は、数万から数十万の回線を扱うことも、特別なことではありません。例えばビーコンに通信機器を入れて全国にばらまく、といったことをする場合は相当な回線数になるので、人手では管理しにくい。

そこをAPIで管理できるようにしているので、通信量のモニタリングや、異常があったら通信を止めたりということを自動化していただくことができる。こうしたあたりが、私たちが「IoT向け」と謳っている強みになります。

また、3G網からAWSに専用線でつなぐこともできるので、Internet of Thingsといえども「インターネットを使わない」という環境を作ることもできます。

例えば自社システムがAWSの中だけにあったりする場合に、SIMカードを持っている人しか閉域に入れないような仕組みも簡単に作ることができる。そういった、セキュリティが重視されるIoTのシステムなんかも作ることが可能です。

また最近のアップデートとしては、「LoRaWAN」という通信量は限られているのですが、非常に省電力で広域まで届く通信プロトコルにも対応します。 そうなってくると、さらに多くのお客様に使っていただけるんじゃないかと思っています。

白石 私のようなWebエンジニアが、ソラコムさんのサービスを使って、何かしらIoTを試してみたい…ということもできるんでしょうか。

片山 はい、最近だとRasberry Piのような汎用的なデバイスもありますし、簡単に試せると思います。SIMのソケットを持つIoTデバイスを用意して、ほんとに簡単なロジックを書くだけで、クラウドまでデータが届きます。

例えばcurlコマンドでHTTP POSTするだけとかでもいい。JSON形式のデータでクラウドまで届きますので、後はご自由にどうぞというかんじです。

ソラコムの開発はどのような体制で行われている？

仲 ソラコムさんはWebのフロントエンドから通信キャリア的なバックエンドまで幅広く開発をされていますね。開発チームの体制などについて伺ってもよろしいでしょうか？

片山 あまり、チームに分かれて開発…というっかんじではないかもしれません。私たちは2週間のイテレーションをベースとして開発しており、2週間に1回インテグレートしてリリース、というのを繰り返しています。

なので、イテレーションを開始する際に次に実現する機能のプランニングや担当を割り振って、あとは個々人がそれぞれ進めていきます。

仲 なるほど。

片山 ただ、担当の割り振りについては、決まったものがあるわけではありません。エンジニアの平均年齢は30代中盤、ぼくらは各分野で経験を積んできたメンバーが集った、言ってみれば「おっさんベンチャー」なので(笑)、「これしかできません」っていう人はあんまりいない。

足りないところがあったら「代わりにやりますね」という雰囲気です。

仲 皆さん、一番得意なスキルはあれども、その他のこともこなせるというかんじなんですね。

清水 開発者としては実際に10名ちょっとなので、基本的に1チームで開発を進めている雰囲気です。

片山 弊社は、ベースが開発者っぽい人が多いんです。例えば、ビジネス開発をしているメンバーも、実はデバイスにものすごく詳しかったりして、コマンドラインで作業したり、ハードウェアの調査をしたりというのを普通にやったりするので…。だから、そういうところからも開発リソースを調達したりしています(笑)。

雨だから人が来ていない(笑)

仲 グローバル展開されているので、海外にも開発者がいるわけですよね。海外メンバーとのコミュニケーションはどのように取っていらっしゃいますか？

片山 基本的にはSlackとかGoogle Hangoutとかですね。ビデオ会議システムについては、いろいろ紆余曲折がある(笑)。

清水 例えばSlack Callsはまだリリースされたばかりで、機能も不足しています。スクリーン共有ができなかったり。なのでappear.inとかGoogle HangoutとかSkype for Businessとか、いろいろ試しましたね。まだここについては決定版がないという状態です。

白石 リモートワークが可能な体制になっているわけですね。そういえばこのオフィスも、他にほとんど人がいない状態ですが、皆さん別の場所で仕事してらっしゃるんでしょうか？

片山 はい、今日人が少ないのは雨だからだと思います(笑)。生産性を高く保てる環境で仕事をしているはずです。

清水 もちろんオフィスにいないと困る職種の人もいるので、そういう人は基本的に出社していますね。

マイクロサービス・アーキテクチャが実現する「開発者の自由」

仲 では実際の開発をどのように進めているかも教えてください。具体的にはどのようなプログラミング言語を使って開発していますか？

小熊 基本的には、先ほども申し上げたように、ソラコムの内側はマイクロサービスとして分かれているので、それぞれのサービスを開発者が選んだ言語で開発しています。

片山 例えば「使いたいライブラリがその言語にあるから」という理由で言語を採用することもありますね。ぼくらはスタートアップなので、一番早く実装できる方法を選択したいというのがその理由です。

今のところ、使っている言語としてはGo、Java、Node.js、C…。あと、AWS Lambdaの開発は、実はPythonが一番やりやすかったりもするので、Pythonを使ったりということもしていますね。

仲 その技術を採用する前に、誰かに相談したりはしないんですか？

片山 CTOに相談したり、といったことは多少ありますけど、基本的には開発者の自由ですね。

仲 なるほど、マイクロサービスに分けているからこそ、様々な言語を混在させることも可能なわけですね。興味本位で伺いますが、そこまで自由だと今後エンジニアが増えていったときとかに、「既存のコンポーネントを自分の好きな言語で書き直したい」なんて要望も出てきたりしないのかな…なんて。

小熊 書き直す正当な理由があるなら、それも許されるとは思います。REST APIの定義さえ変わらなければ、あるコンポーネントの中身がごっそり置き換わっても他の部分には影響ないですし。

片山 あとマイクロサービスのいいところは、オーナーシップがわかりやすいことですね。サービスごとに開発した人が大体分かれているので、担当者が自然と定まってくる。もし今後開発者が増えていって、100人とかになった時に、今と同じことができるかはわからないです。

そうなったら、ある程度統一しようという話も出てくるのかもしれませんが、とりあえず現在の段階では、マイクロサービスを開発者それぞれが開発するという体制でスケールアウトを目指したほうが素早くサービスを拡張できると考えています。

仲 マイクロサービスによる開発には、開発そのものをスケールアウトできるというメリットもあるわけですね。

白石 しかしそれだけ多様で自由に開発しているとなると、コードレビューなどが難しくなったりはしないのでしょうか？

片山 コードそのものよりも、仕組みやアーキテクチャ、APIのほうを重点的にレビューするようにしていますね。

小熊 開発をしていると、呼び出す相手のコンポーネントについて APIの挙動がよく分からなかったり、バグっぽかったりしても、相手に聞いたりする前にまずコンポーネントのコード読んじゃって、「あ、なるほど、こうやってこのAPI呼び出すのか」とかって自己解決しちゃったりすることもあります。

その際に、そのコードが難解すぎて読めないとか、何をするためのコードなのか理解できないとかいったようなことはこれまで経験していません。事前にアーキテクチャなどをレビューしているからということもありますし、各コンポーネントを担当しているエンジニアのスキルが一定以上の水準だからだと思います。

清水 私の担当しているユーザーコンソールなどは複数人で開発しているので、少しレビューを綿密にやっていたりはしますね。

（筆者補足: ソラコムさんは「理想的なリーダーシップ」について書かれた15の項目「リーダーシップ・ステートメント」をメンバー内で共有し、定期的に議論、各自が実践することで、自由なワークスタイル、自由な開発体制、そして各自が責任を持って仕事をすることを同時に実現しているのだそう。見習いたい！）

DevOpsではなくOpsDev

仲 サービスの運用などについても聞いてみたいです。DevOpsのあたりとかは、どのように運用を自動化しているのでしょうか？

小熊 そこは、弊社だとOpsDevと呼んでいるんです。Opsをメインでやっている人間が強いこだわりを持っていまして(笑)。開発したものを運用するんじゃなくて、運用のためにこそ開発がある、と。

仲 運用をメインで行うチームがあるというわけではないんですか。

小熊 まず、そもそも開発メンバー自体が、日々の運用やサポートにも直接参加しています。いわゆるDevOpsです。さらに弊社では、運用の自動化にメインで取り組むエンジニアが一人いて、彼を中心に様々な自動化や監視を行っています。

片山 メインはZabbixによる監視と、Ansibleによる自動化をしています。何か問題があったら、次はどうそれを自動化するかとか、次に問題をどうやって起こさなくするかとかを決めて、あとはそれを担当のOpsDevエンジニア中心にやる、という運用になっていますね。

白石 御社だと、運用そのものがビジネスかもしれませんよね。

片山 はい、そうなんです。通信コア部分を安定的に、そしてスケーラブルにAWS上で動かすというのが我々のビジネスの根源と言えば根源なので、そこは一番力を入れています。

なのでそれ以外の、例えば私が書いているバックエンドの部分などは、AWSのBeanstalkなどにを使えばそれなりにスケールアウトするし、それに頼って作っているという部分はありますね。

仲 先ほど「スケーラブル」という単語が出てきましたが、スケーラビリティを担保するためにどのようなアーキテクチャになっていますか？

片山 一言で言うのは難しいですが、例えば一番ネックになるデータベース部分はDynamo DBをメインで使っています。メインとなる通信サービスで、RDB使ってるところはほとんどないんじゃないかな。

ただDynamo DBだと、アプリケーション側で頑張らなきゃいけない部分が出てくるので、そこは頑張るといった感じですね(笑)。

白石 マイクロサービスだし、DBも分けてらっしゃるんですよね？

片山 はい、そうです。ただ、使っているDBはみなDynamo DBですね。

白石 決済の部分とかは、トランザクション処理が必要だと思いますが、そこはどうしてるんでしょう？

片山 そこもDynamo DBで頑張っています。Dynamo DBはトランザクションがあるにはあるのですが、2レコードをアトミックに更新できないので、極力1レコードに寄せるようにしたりとか。あと公式のトランザクションライブラリもありますし。

仲 ほかには、ログの管理などはどうしてらっしゃいますか？

片山 Logglyというサービスを使っていますね。ライブラリを使ってログを送ると、よしなにインデックスしてくれるようなサービスです。

仲 Elastic Searchを自前で運用したりはしていないのですね。

片山 はい。弊社のサービスは、ログの分析などがビジネスの源泉になるものではないので。ビジネスの源泉になる部分は自社開発にこだわっていますが、それ以外の部分は積極的に外部のサービスを使用するようにしています。

ソラコムの課題・改善点

仲 では、ソラコムの開発において、課題だと感じていることや今後改善していきたい点などはありますか？

片山 個人的に継続的に追求していきたい課題としては、いかにチームを小さく保っていられるかというところですね。

人が増えるといろんなロスが発生してくるじゃないですか。機動性を確保しておくために、人をなるべく増やさない。そのために必要なのは生産性を上げることなのか、一人が何役もできるようにすることなのか、ということですが、そこを追求していきたいと思っています。

清水 私も、今の片山の話ともリンクしていると思いますが、作るものをいかに小さく保っておけるかが大事だと考えています。大きなものを作ろうと思うと、沢山の人が必要になるし、メンテナンスも必要になってくる。

なので、同じ価値を少ない機能やコンポーネントで実現するということにはこだわっていきたいですね。今はまだぼくらは、機能やツールを追加していくフェーズではありますが、ある程度、一通り揃ったタイミングで、いかにそれらを減らしていけるか、シンプルにしていけるかは考えていきたいと思います。

小熊 ぼくは…課題とか不満とか、あんまりないですねえ(笑)。すごく自由だし、生産性も高いし、今のところ申し分ありません。

あらゆるものが「目」を獲得し進化する

白石 では最後になりますが、まだIoTに取り組んだことのないエンジニアに対して、IoTにどう取り組むべきかを教えてください。

清水 私はもともとWebエンジニアなんですけれども、IoTをやると、様々な業種の人々と接することになるのが楽しかったりします。

例えばWeb系の勉強会だったら、Webのトピックがやっぱり一番熱いので、Webの話が中心になる。それはそれで楽しいのですけど、ソラコムのユーザーグループだったり、メイカーズ・ムーブメントだったりに顔を出していくと、自分と同じくらいのスキルセットを持った人がぜんぜん違うことをやっていたりするわけです。

サーバーサイドもできるんだけど、Arduinoで何かやっていたりもする。そういう人たちに接すると、IoTに取り組むモチベーションも上がったりするんじゃないかなと思います。

小熊 私はもともと組み込み系の出身なんです。組み込みの業界のエンジニアは、「Webやクラウドについてはまだわからない」という人も多いですが、エンジニアリングの基礎がしっかりしているので、吸収も速いと感じています。

なので、組み込みの方々がIoTに取り組むのはすごく向いているので、ぜひトライしてみるといいと思います。

片山 個人的には、IoTでワクワクすることの一つは、あらゆるものに「手足」や「目」ができることだと思っています。どんなものにもセンサーが付き、デジタルデータ化できる可能性がある。

例えばぼくは、部屋のあらゆるものの最終アクセス日時が分かったら、片付けとかにすごく便利じゃないかと考えているんですよね。

白石 確かに(笑)。

片山 センサーだけじゃなくて、Amazon Goみたいに画像解析によるアプローチもあるし、そういうアイデアが実現可能な時代はもう来ている。これが進んで、身の回りのものがデジタルデータになることで、世界はもっと面白く、便利になるんじゃないかと思っています。

生物はカンブリア紀に目を獲得したことで、大幅に進化が進んだと言われているのですよね。それと同じことが、今まさに起ころうとしているんじゃないかなと。現在、そういう進化の途上なのだと考えると、IoTの波に乗っかってみるのも悪くはないと思えるんじゃないでしょうか。

私もフロントエンド・エンジニアではありますが、もともと関心があったことと、去年からデータ・ストリームのPaaS (platform as a service) 会社であるPubNubで働いていることもあって、IoTを避けずには通れなくなり、電子工作を始めるようになりました。

そこで、最近東京・渋谷で行われた、東京Node学園で登壇した際に話したテーマ、Hardware Hacking for JavaScript Developers から、ArduinoとNode.jsを使ってプロトタイプする、という内容についてチュートリアル形式で書いてみたいと思います。

Arduinoが変えたMakerムーブメント

みなさん、Arduinoの名前は聞いたことがあると思います。Arduino、もしくはGenuinoとして知られているこのオープンソースのAVRマイクロコントローラ電子工作キットは、既存のマイコンボードと違い、安価で、I/Oポートもあり、USB接続で今すぐ始められます。開発環境（IDE）とサンプルコードなども簡単にダウンロード、インストールできることから初心者でも簡単に電子工作ができるようになったという面では、今までハードウェアに縁がなかったソフトウェアエンジニアが、Makerムーブメントに積極的に参加するようになった火付け役ともいえると思います。

しかし、同じソフトウェアといえども、ウェブエンジニアはどうでしょう？Arduinoで使用される言語はC-ベースのSketchということで敷居が高く感じたり、興味がなかったりするのではないでしょうか？でも、もし馴染みのJavaScriptで好きなことができたら、遊んでみたくなりませんか？

Johnny-Five: JSロボティクス・フレームワーク

そこで紹介したいのが、JavaScript ロボティクス・フレームワークである、Johnny-Five。日本ではまださほど知られていない感じがしますが、オープンソースでディベロッパ・コミュニティの結束も固く、インターナショナル NodeBots Dayなどでユーザ・コミュニティも大きくなってきたこのフレームワークを使えば、JavaScriptをで簡単にプログラマブル電子工作ができるようになります。ここは説明よりも実践してみるほうが理解も深まると思いますので、さっそくチュートリアルを始めましょう！

1. Arduino のセットアップ

用意するハードウェアとインストールの必要なソフトウェア

• Arduino (Genuino) Uno
• Arduino IDE
• Node.js

始めにセットアップから始めます。ArduinoボードをUSBで、コンピュータにつなぎます。Arduino IDEをダウンロード、インストールして、起動させたら、ボードとシリアルポートの設定をします。

メニューのツール > マイコンボードの中のArduino Unoを選択し、 ツール > シリアルポートの中の/dev/tty.usbmodem、もしくはcu.usbmodemという名前が含まれる項目を選びます。

Johnny-FiveはFirmataプロトコルを使ってArduinoと通信をするので、今度はStandardFirmataをインストールします。

メニューからファイル > スケッチの例 > Firmata > StandardFirmataを選択すると新しいウィンドウが開きます。そこから左から２番目にあるアップロードボタンをクリックします。下のGIFアニメーションの通りです。

終わったら閉じ、このIDEはもうこれからは必要ありません。

2. Hello World

まずコンピュータに、Node.jsがすでにインストールされていることを、確認してください。そして適当なディレクトリ (e.g. /j5-hello/) を作ったら、そのディレクトリ内にパーケッジマネージャであるnpmを使って、Johnny-Fiveをインストールします。

$ npm install johnny-five

さっそくJohhny-Fiveを使ってはじめの一歩である、Hello Worldを書いてみましょう。新しい言語やフレームワークを学ぶ際に初めて書くプログラムは”Hello world”という2つの単語を出力する、というのが一般ですが、ここでは、ハードウェア界のHello Worldとも言える「Lチカ」（LEDを点滅させる）をしてみます。

必要なハードウェア

• セットアップ済みのArduino Uno
• LED
• ブレッドボード
• ジャンパー・ワイヤー（両側がピン状になっているオス〜オス）
• 抵抗　（200-330Ω 程度）

まずはハードウェア側のセッティングです。 部品などどこで買ったらわからない、という方はAmazonなどでキットを買うのをお勧めします。

LEDの基本

LED（発光ダイオード）には、極性があり、その＋極をアノード、ー極をカソードと呼びます。普通のLEDには通常、足が二本ついていますので長い方がアノードです。これは回路を作るときに重要になってきますので必ず覚えておいてください！

電気回路の作成

ArduinoからLEDを光らせるための回路はこんな感じになります。ここでは便宜上、電源からつながるプラス側を赤、Groundにつながるマイナス側を黒のワイヤーで示してあります。何色を使っても構いませんが、混乱を避けるために2つの異なる色にすることをお勧めします。

ブレッドボードや抵抗についての基本、そしてこの「Lチカ」の回路については初心者でもわかる・できる！Arduinoを使った初めての電子工作実践の「部品をつなぐ」セクションで豊田陽介さんが詳しく説明されているので、それを参考にしましょう。

Johnny-FiveでLチカ

では、適当なファイルネーム、例えばblink.jsを作成し下のコードをコピーペーストしてください。

var five = require('johnny-five');
var board = new five.Board();

board.on('ready', function() {
  var led = new five.Led(13);
  led.blink(500);
});

ターミナルからこのファイルを走らせましょう。

$ sudo node blink.js

正しく作動しましたか？回路が正しく、コードにエラーがない場合は、500ms間隔でLEDが点滅します。

これで、JavaScriptとハードウェアを使う基本を学びましたので、今度は実際にスマートデバイスのプロトタイプを作ってみましょう。

3. スマート照明システムをプロトタイプする

Philips HUEや、LIFXは、ムードや状況によってスマートフォンやタブレットから、明かりの色や照度をカスタマイズできるLED電球です。さっそく Arduinoを使ってこれらのように色を自在に変えられるLEDを作ってみましょう。色を変えるためのコントローラはHTML５を使ってブラウザから操作できるようにしましょう。

JavaScript で Internet of Things

さて、ここで重要なのは、デバイス（ハードウェア）とモバイルUI (HTML5)をインターネットでつなげて、IoT化するということです。Bluetoothなどと違い、インターネットにさえ繋がっていれば、あなたが世界のどこにいようともモバイルから自宅の照明の操作をすることができるのです。この2ウェイ・コミュニケーションを可能にするにはソケット・コネクションが必要になります。ここで、この双方向通信を簡単に行うことにできるPubNubのJavaScript APIを使って、IoTのプロトタイプをしてみましょう。

PubNub はグローバルなデータストリームネットワーク (DSN) で、 このAPIを使ってリアルタイムアプリケーション、IoTデバイスなどを接続、拡張、管理することができます。今から作成するスマートLEDは下の図のようにモバイルデバイス（このプロトタイプの場合はブラウザ）とハードウェアをインターネットでつなげることが可能です。

例えば、サンフランシスコにいるモバイルユーザが東京にあるArduinoを操作する場合：

1. ユーザがモバイルから「緑い照明にしたい」と送信（パブリッシュ）
2. メッセージがPubNubのサンスランシスコデータセンターに送信される
3. データは世界各地のデータセンターと同期
4. Arduinoが東京データセンターからデータを受信（サブスクライブ）して、LEDを緑に

この全てのオペレーションがわずか¼秒かそれ以下で行われるのが、PubNubの利点です。

このチュートリアルではJavaScriptを使ってプロトタイプを作りますが、PubNubの組み込みとモバイルのSDKを使えば、実際にHUEのようなスマートデバイスを製品化することも可能なのです。

必要なハードウェア

• Arduino Uno
• RGBフルカラーLED（カソードコモン）
• ブレッドボード
• ジャンパー・ワイヤー（オス〜オス）
• 抵抗　（220Ω x 2, 330Ω x 1）

RGBフルカラーLEDの基本

RGB (Red-Green-Blue) フルカラーLEDは、赤、緑、青の3色のLEDが一本になったもので、この三原色の組み合わせで無数の色を作り出すことができます。ほとんどのこのタイプのLEDは、各色のピンが一本づつと共通のカソード（もしくはアノード）の合計4本のピンがあります。このチュートリアルでは、カソードコモンのものを使用しています。

電気回路の作成

Hello World を成功させたからには、この下の図の回路も問題なく作れるのではないでしょうか。がんばってみてください。

ワイヤーを差し込むピンは、単純な「Lチカ」とは違い、PWM (Pulse Width Modulation：パルス幅変調) ピンを使っています。Arduinoボードにラベルされているピン番号の前に「〜」が付いているものがPWMピンになります。

これらと他のピンの違いは、簡単にいえばアナログかデジタルかの違いになります。例えばLEDの場合、一般のデジタルピンにつなぐとオフかオンの2つのステートしか表現できません。Lチカ（点滅）はこのデジタル信号をオンとオフと交互に発しています。しかしRGBフルカラーLEDで無数の色を表現するには、各色の値の組み合わせで色を作り出すので中間の値が必要になりますので、アナログであるPWMピンを使います。

ここで抵抗を220Ωと330Ωにわけてあるのは、同じ抵抗だと赤が強くなるので、抵抗を増やして赤を控えめな明かるさになるように調整してあります。抵抗の計算方法やカラーコードの読み方については、ここで割愛しますが、自分でいろいろ調整してみてください。

IoT リモートコントローラーUIの作成

ブラウザでLEDの色をコントロールするUIを作ってみましょう。

HTML5の“、”R”、”G”、”B”の各色調整をするスライダーバーを描写します。各色は0から255まで(min="0" max="255")の整数の値(step="1")を、つまみで調節できるようなUIにしてみましょう。

<input id="red" type="range" min="0" max="255" step="1" value="0">

これで赤色を調節するスライダーができました。このチュートリアルではCSS部分は省略しますが、スクリーンショットのようなスタイルにするには、GitHubのソースコードのgh-pages ブランチを参照してください。

次はJavaScriptでこの値がユーザによって変更された時に、その値をArduino側に反映させるようにします。これを実現させるためにPubNub JavaScript APIで両デバイスを接続させてみましょう。

PubNub JavaScript API を使うには、まず自分のAPIキーを取得を取得したら、CDNライブラリ（もしくはローカルファイル）を読み込みます。

<script src="//cdn.pubnub.com/pubnub-3.7.15.min.js"></script>

そして自分のキーを使ってインスタンスを初期化します。

var pubnub = PUBNUB({
　subscribe_key : '自分の subscribe key',                          
　publish_key   : '自分の publish key'
});

UIイベント発生時に自動的にLEDの色を変える仕様にしてみましょう。 スライダーDOMにchangeイベントが発生した時に、変更値をPubNubに publish メソッドを使って送信（パブリッシュ）します。

var red = document.getElementById('red');

red.addEventListener('change', function(){
  pubnub.publish({
    channel: 'smart-led', 
    message: {color: 'red', brightness: +this.value}
  });
}, false);

この時の channel 名は何でも構いませんが、のちにこのデータを受信する際にはこれと同じチャンネル名にします。

では次はNode.jsを使ってハードウェア側でこの値を反映させてみましょう。

Johnny-Five と PubNub で Arduino を IoTデバイスに

Johnny-FiveでRGBフルカラーLEDを動かすコードは、いたって簡単。npmでjohnny-fiveをインストールしたら、次のコードを動かしてみてください。

var five = require('johnny-five');
var led;

five.Board().on('ready', function() {
  console.log('ready');

  // RGB LED を初期化
  led = new five.Led.RGB({
    pins: { // pin 番号
      red: 6,
      green: 5,
      blue: 3
    }
  });

  // テスト
  led.color({red: 255, blue: 0, green: 0});
  
  led.on();
});

LEDが赤色に光ましたか？ 何も起こらない場合はコードと配線などを確かめてください。それでも作動しない場合は、使っているRGB LED がカソードコモンではなくアノードコモンの可能性があります。その場合は、GND（図上の黒のワイヤー）を、Arduinoの5Vのピンに変えてみてください。

「テスト」とコメントされた行をみてください。color メソッドでLEDの色を指定しているのがわかると思います。この場合、赤の値が255で他が0となっているので、LEDを赤で光らせることができます。Johnny-Fiveでは、CSSのcolorプロパティと同じようにRGBの値を0～255で指定することができるのです。RGBの各値を変えながらどんな色になるか実験してみてください。

さて今度は、このRGBの値をブラウザUIからリモートコントロールして、動的にLEDの色を変えてみましょう。

さきほどのUI側からパブリッシュされたデータを受け取って、ハードウェアに反映させるには、PubNub subscribe メソッドで受信（サブスクライブ）しましょう。

まず、npm で pubnub をインストールします。

$ npm install pubnub

フロントエンドと同様に、pubnubインスタンスの初期化します。

var pubnub = require('pubnub').init({
  subscribe_key: '自分の subscribe key',
  publish_key:   '自分の publish key'
});

UI側から送信されたデータは、同じ channel にアクセスすることによって自動的に送信することができます。データが送信された際には、subscribe メソッドの callback が返されます。このコールバック内で送信された色データをLEDに反映させます。

pubnub.subscribe({
  channel: 'smart-led',
  callback: function(m) {
    if(led) {
      r = (m.color === 'red') ? m.brightness : r;
      g = (m.color === 'green') ? m.brightness : g;
      b = (m.color === 'blue') ? m.brightness : b;

      led.color({red: r, blue: b, green: g});

      console.log( 'color change to...' );
      console.log( led.color() );
    }
  }
  error: function(err) {console.log(err);}
});

送信されたメッセージ、m は、UIから送られたオブジェクト、例えば青の値が150の場合、{color: 'blue', brightness: 150}、となります。次に送信された値が、{color: 'red', brightness: 150} ならば、前の値の青＝150はそのままで、ここに赤＝150が加わることによって、LEDは紫に近い色になります。さらに赤緑青の3つの値が変われば、LEDはさまざまな色に変わります。

全コードは、GitHubのソースコードのmaster ブランチ内の /node/index.jsを参照してください。

さて、これでIoTスマート照明のプロトタイプができあがりました！

Johnny-FiveもPubNubもArduinoだけではなく、他のいろいろなマイクロコンピュータに使うことができます。いろいろなセンサーやカメラなどを組み合わせて、IoTプロトタイプに挑戦してみてください。

では、Happy hacking!

References

• Johnyy-Five: The original JavaScript Robotics programming framework
• PubNub: The global realtime Data Stream Network for IoT, mobile, and web applications

こんにちは、編集長の白石です。

昨日（2015年8月27日）、「IoT / WoT」をテーマにした「第59回 HTML5とか勉強会」に参加してきました。 この記事では、イベントの模様や参加した感想をレポートしたいと思います。

ちなみに、「IoT」（Internet of Things）はバズワードなのでご存じの方も多いと思いますが、「WoT」というのは「Web of Things」の略です。「IoTのWeb版」と言えばわかりやすいでしょう。個人的には「WoT」という言葉にはどうも「IoTブームに乗ってやれ」という（何者かの）意図があるような気がしていて、ちょっと懐疑的でした。リソース食いだし、デバイスの機能を自由に使うこともできないWeb技術は、IoTとは相性悪いんじゃないか…と。

しかし、今回のイベントに参加して、そうした疑いは晴れました。「Web×デバイス」の勢い、まがい物ではなさそうです。そしてその勢いをさらに推し進める一員になりたいな…と思ったのも正直な気持ちです。それくらい、最先端では楽しいことが起きている。

では、前置きが長くなりましたが、イベントの内容を簡潔にご紹介していきたいと思います。 イベント自体の内容が盛りだくさんでしたので、今回のレポートでは前半の2セッションのみのご紹介となりますがご容赦ください。

また、講演資料はアップされたのを確認次第、追記していきます（現在のところ、2つ目のセッションに関する資料しか見当たりませんでした）。

「myThings開発者のMaker Faire Tokyo体験記」

1つ目のセッションは、ヤフー株式会社の河合将臣氏と畑元氏による 「myThings開発者のMaker Faire Tokyo体験記」でした。

「myThings」とは、2015年7月にヤフージャパンがリリースしたプロダクトです。 複数のWebサービスやデバイスを自由自在に繋いで、いろんなことをオートメーションさせられるサービス／モバイルアプリです。

と、この説明を聞くと「それってIFTTTと何が違うの？」と思ってしまうのが自然な流れ（？）。

このセッションでは、その疑問にもしっかり答えていました。いわく、

• 日本語対応
• Yahoo! Japanのサービスが使える。特に、通常API経由では利用できないサービスやデータを使えるのは強み
• 国内で展開されているサービスも利用できる。代表的なのははてなブックマーク。

だそうです。

また、IDCF Cloudというプラットフォームも用意されており、自作のガジェットとmyThingsをつなぐことも可能。MQTTやWebSocket、REST APIに対応しているそうで、Web技術者でも簡単に扱えそうなのが魅力。

セッションの後半では、Maker Faireにヤフーさんが出展された時の（もちろんmyThingsとIDCF Cloudを使った）デモアプリを、内部設計や作業工程も含めて情報共有していただきました。

Web技術者がハードウェアの設計・製造まで行ったということで、その過程で気づいたことを以下のようにわかりやすくまとめています。

「WebController for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」

２つ目のセッションは、株式会社アトモスデザインの児玉 哲彦さんによる「WebController for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」でした。

第59回 HTML5とか勉強会 ーIoT/WoT発表資料「Web Controller for V-Sido CONNECT：WebRTCとWebGLで作る人型ロボット遠隔操縦システム」

このセッションのウリは、とにかく「ホンモノのロボットをWebブラウザで動かせる！」という点。Google Chrome上で動作するWebアプリから、ロボットの手を動かしたり足を動かしたり、果ては怒らせたり。

「JavaScriptでロボットを動かす」なんて、数年前では考えられなかった事態に感動です。

そもそもV-Sido CONNECTというのは、人型ロボットを作るためのOS（そんなのがあったのか…）である「V-Sido OS」用のマイコンで、公式HPによると「シリアルサーボモーターをつなぐだけでロボットを作ることが可能です。」「V-Sidoの一部機能がマイコンに搭載されているので初心者でも簡単にロボットを動かすことができます」とのこと。

今回の児玉さんの発表は、この「V-Sido CONNECT」をWebブラウザ上から制御できるというプロダクトの紹介というわけです。 このWeb Controllerはどう動作しているかというと、Webアプリとスマホアプリを連動させ、スマホからBluetoothでロボットの制御信号を送っているとのこと。先ほどのmyThingsといい、スマホがIoTデバイスのハブになるという流れなのは間違いなさそうです。

また、Webアプリとスマホアプリの通信はWebRTC（及び、NTTコミュニケーションズのSkyway）を使用しているそう。WebRTCを使う決め手となったのは、映像や音声を扱うことができるから（ロボットのカメラから映像を受信したりできる）。

以下の比較表は中々興味深いです（写真ボケててすいません）。

WebRTCのおかげで、なんとドイツから日本のロボットを動かすといったような接続性を確保できたとのこと。地球狭い。

そして、Webエンジニアであれば気になるコーディング方法ですが、以下の表に示すように、非常に簡潔なAPIです。たったこれだけでロボットに複雑な制御を行わせることができるというのは、Web技術者にとってはありがたい限りです。

2000年代の「ユビキタスコンピューティング」に足りなかったものは今は揃っており、WoT時代の幕開けを感じさせてくれるセッションでした。

まとめ

今回紹介しなかった後半の内容（MozillaのFirefox OSベースのマイコン「CHIRIMEN」や、NTTコミュニケーションズ小松さんによるRaspberry PiとWebRTCを連動させた話）も非常に興味深かったので、気になる方はTwitterでイベントの様子を確認してみてください。

イベント全体の模様をを動画でご覧になりたい方はこちらからどうぞ。

このIoTブームの中、「Web技術者にできることを広げようとしている人たちが多く存在する」「Web技術者にできることはたくさんある」ということを実感させてくれる、非常にバリエーション豊かな内容でした。

Microsoft Azureの話題が中心だった前半（レポート記事）とは対照的に、後半はWindows 10やHoloLensなど、コンシューマ向けプロダクトの紹介が主でした。 よって、内容が派手！見栄えのするデモや、ぼくらが大好きなコードの話も出てきて、見どころ満載でした。

ジョ〜〜！！！

「前後半の合間に、ちょっとした息抜きをしましょうか。Power BIの勉強でもしましょう」って言われた時は「えっ」という気持ちでいっぱいでしたが、フタを開けてみると本当に息抜きのコンテンツでした。

次の登壇者である「Giorgio Sardo」（ジョー）さんの名前を観客が全力で叫び、その音量を視覚化するというもの。 何やらせんだ。

最後はメーター振り切ることができて、マイクロソフトの方々もご満悦

で、ジョーが出てきました。

デベロッパーエクスペリエンス & エヴァンジェリストグループ シニアディレクターのGiorgio Sardo氏

Windows 10で、目指せ10億台！

話題はもちろんWindows 10です。 Windows 10は、「巨大なターゲット市場」「スマートエンゲージメント」「One Store & Dev Center」「統合された開発プラットフォーム」という特徴を備え、大きなチャンスを生み出すと言います。

巨大なターゲット市場

この画像で言いたいことは、「Windows 10はスゲエよ！10億台のデバイスを繋げるんだ！儲かるぜ！」ということ（超意訳）。

「儲かるぜ！」は、さすがに言ってなかったっけな。

スマート エンゲージメント

あらゆるデバイスを統合した通知機能や、Cortanaによるインテリジェントな検索により、アプリケーションとユーザの接点をより緊密なものにします。

（Windows 10がどこでも動くから）Windows 10アプリは一度書けばどこでも動く！HoloLensでも！

Windows 10の目指す所は、あらゆるデバイスに対して一つのOSという「One Windows」というビジョンです。 それにより当然ながら、アプリストアも一つに統合されます。

そうなると、「一つのアプリがあらゆるデバイスで動作する」必要も出てきます。つまり、あらゆるスクリーンサイズで動作する…レスポンシブであることが望まれる ということです。 レスポンシブなWindows 10アプリの例を、楽天のポータルアプリ「楽天Gateway」で実演。

あらゆるデバイスを統合するプラットフォームとしての、Windows 10のデモはまだまだ終わりません。 この画像が、マイクロソフトさんの言いたいことをよく表しているように思います。

こんなすごい3Dマップも…

一行書くだけで実現できます。

こういう、3Dモデルを作れるアプリも…

HoloLensがあればホログラム化！これはすごい！

Edgeの話も忘れずに

Webエンジニアとしては、最近一番ワクワクする話題だった「Microsoft Edge」の発表。 もちろんこの基調講演でも大きく扱われていました。

EdgeHTMLという新しい描画エンジンにより、4,200以上の相互運用性を改善したそうです。

もちろん、JavaScriptの実行速度を向上させるのも忘れません。

Edgeの大きなウリをMicrosoftさん自身でまとめるとこうなります。 「定期的な更新」っていうのが個人的には一番ツボです（IEは後方互換性の問題があって、これができなかったからなあ…）。 あと、ChromeやFirefoxの拡張機能が（ちょっとした修正で）動くと噂の、「新しいエクステンションモデル」も気になります。

新機能「Hosted Web Apps」は、WebサイトをそのままWindowsアプリにしてしまえる機能。

こんな感じのフライトシミュレーターアプリ（Webアプリ）も…

っと、デモを本格的にやる前に、プレイヤーとしての心の準備。 （最近のMicrosoftさん、エンジニアが好むゆるい雰囲気をよくよくわかってらっしゃる）

Windowsアプリにしてしまえば、よりネイティブな機能を利用できるので、Microsoft Bandと連携して飛行機を操縦…なんてこともできちゃう。

IoTも！機械学習も！

見どころ多すぎて、書くの疲れてきたんですが、まだまだ行きます。

Windows 10をIoTに対応させる動きも活発ですが、Minnowboard MaxとRasberry Pi 2ですでに利用可能です。

なんか偉い人らしいんですが、コスプレして出てきました。

これは何のデモかというと、富士通と共同で開発した「牛管理アプリ」だそうで（コスプレしてた偉い人は「Connected Cow」という札を下げてました）、牛にセンサーを付けて集めたデータを、Azure Machine Learningを使って機械学習＆統計出力していました。なんでもありだな、マイクロソフト。

スクエニ来た！なんかすごいデモや！

そろそろ最後の山場。

Windows 10のゲームとグラフィックの機能をプレゼンする段になり、スクウェア・エニックスの第2ビジネス・ディビジョンから田畑 端氏がいらっしゃいました。

中央がスクウェア・エニックス 第2ビジネス・ディビジョン ディレクター・プロデューサー 田畑 端氏

発表はふたつありました。

ひとつは「FINAL FANTASY AGITO on Windows 10」。

年内ローンチって言った？言ったよね？え？予定？

もうひとつは、Windows 10に搭載されるDirectX 12、そしてNVIDIAも巻き込んで開発された、アートとテクノロジーを融合させたデモンストレーション。

このクオリティの3D CG（髪の毛の本数も、実際の人間と同じだそうです）を、リアルタイムに視点移動させることができます。思わず会場からはため息が漏れました。 これは、動画見ないと伝わらないかも…。

WITCH CHAPTER 0 [cry]

ってことで動画貼っておきますね！

すべてのエンジニアとアプリのために

基調講演の最後は、MacやLinuxでも動作することで話題になった「Visual Studio Code」や、Dockerを一例としてオープンソースコミュニティへの貢献を拡大させていることなど、Microsoftの開発者に向けた取り組みが、Windowsに囲い込もうとしていた以前とは全く異なることへの言及でした。

「Empower every engineer」（すべてのエンジニアに力を与える）というフレーズは、このキーノートで一貫して取り上げられていましたが、聞いていたぼくとしてはその本気度が十分に伝わる内容でした。この記事を読んでいらっしゃる皆様にも、その雰囲気が少しでも伝われば幸いです。

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。

HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。

アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライズ開発出身の白石俊平編集長がさまざまなトピックスをぶつけていきます。

XML Webサービスは今どうなったのか

白石：とりあえず、昔話から軽く聞いてみたいですね。まずは、エンタープライズ内のシステム間連携でよく話題に上がる、SOAPとRESTについての現状について、どうお考えでしょうか？

鈴木：SOAPは下火だと思われがちですが、私の知る限り、今でもよく利用されています。RESTとJSONの組み合わせも当然よく使われているんですが、（SOAPは）WSDLで型定義ができるので、それなりにかたいシステム間連携だったりすると、WSDLがあるほうがコードの自動生成もできるし、非常に楽なのでよく使われています。

　　 ▲グロースエクスパートナーズ株式会社 執行役員 鈴木雄介さん

細川：とはいえ、SOAPの上位レイヤで規定されているWS-ReliabilityだとかWS-Securityなどの様々なプロトコルは、あまり使われていない印象です。

白石：では、システム間連携などではプレーンなSOAPがよく使われているということですね。

鈴木：まあSOAPもRESTも用意する、というパターンが多いんじゃないでしょうか。オブジェクトモデルは同じで、それをSOAPでもJSONでも表現できるように設計しておくというパターンは、比較的多いような気がします。

細川：あと僕が気になるのは、スケーラビリティなんですよね。SOAPだとちょっと気になるのはやっぱりシリアライズ・デシリアライズの処理が重いし、トラフィックも増大するじゃないですか。そういった意味だとやっぱりREST + JSONのほうにもメリットがありますね。本来だったら使い分けみたいなところが重要なんですけど、いまだにSOAP一択という開発現場も多い。

　　　▲株式会社アーキテクタス 代表取締役 細川努さん

白石：どっちかに寄せちゃったほうが考えることが少なくて、楽ってこともあるかもしれないですね。

鈴木：一長一短…というとつまらない話になってしまいますが（笑）、実際のところそういう結論になっちゃいますね。HTML5が盛り上がっている現在、JavaScriptと相性が良いJSONにはすごく価値がある。一方で例えば、日付型をどう扱うんだとか、型定義やコードの自動生成がしづらいというJSONには苦手な分野もあるのですが、SOAPはそういう部分に強い。「SOAPはXMLだからダメ・ダサい」ということは、実際のシステム開発には全く当てはまらないと思いますよ。

エンタープライズアーキテクチャパターンは今も有効か

白石：アーキテクチャという点では、マーティン・ファウラーのエンタープライズ アプリケーションアーキテクチャパターンが昔は王道だったかとと思うんですが、それは今も有効なんでしょうか？

鈴木：あれは普遍的なものなので、時代が変わったからといって使えなくなってしまうようなものではありません。ただ、昔と比べると今はWeb API主導型のアプリケーションが主流になりつつありますね。クライアントのマルチデバイス化は当然エンタープライズでも相当重要なので、「サーバー側はAPIを提供するだけ」というスタイルに移行しつつあるのは、Webでもエンタープライズでもまったく変わらないと思います。

白石：具体的には、JAX-RSを利用するとか？

鈴木：JAX-RSもありますし、JSON用のバインディングAPIもJava EE 7で標準化されたので、何の違和感もなく使えますね。

細川：エンタープライズ アプリケーションアーキテクチャパターンは非常に洗練されていたのですが、実際のエンタープライズ・アプリケーションはもっと泥臭いです（笑）。 例えばマーティン・ファウラーの提唱するモデルだと、プレゼンテーションレイヤからデータレイヤまでが3、4層ぐらいなんですが、実際はビジネスロジックだけで3層以上に分けたりとか、ビジネスロジックとプレゼンテーションの間にいろいろ挟んだりとか、端から端まで数えると下手したら10層ぐらいあるものも実際のプロジェクトでは山ほどありました。

白石：僕もそういうプロジェクトをやったことがあります。なんか別のメソッドを呼び出してるだけのメソッドが大量にあったり（笑）。

細川：そうそう。なので、どちらかというとほんとに綺麗なレイヤリングはできてなかったというのが現実ですね。最近、６〜７年以前につくられた数十万ステップくらいのシステムをいくつか実際に解析してみたんですけど、結構面白い結果が出たんですよ。サーバーサイドJava（JavaEE）としては最新ではなく、まだJ2EEと呼ばれていた頃のシステムです。どのシステムも、一番複雑度が高いのはビューとデータアクセス（永続化）、アーキテクチャ共通系のモジュールです。ビジネスロジックの部分は量は膨大なんですけど、複雑度自体は比較的シンプルなんです。

何が言いたいかというと、古い世代のサーバーサイドJavaは、ビューとアーキテクチャ制御に作り込みが必要で、そこのところが本当に大変だった。例えば、ビューのところのバリデーションなんかは、かなり作り込みが必要で、簡単な画面作るのも相当手間がかかってたんですよね。結局は、かつてのJava EE（J2EE）って、エンタープライズ系プログラマーが本来集中すべき業務上のロジックにあんまり集中できていなくて、もっと簡単にできるはずのところに手間がかかっていたのが現実だったんじゃなかったかなと。

白石：ほんとにそうですよね。オブジェクトの変換とか、別のメソッド呼び出すだけとか、ファサード作ってそこに一生懸命集めるだけとかやっていて、なにやってるんだろうこれは…とか思っていました。

細川：以前はそうでしたね。そのレガシーなところが今はみんなの足を引っ張ってる（笑）。現在は、それがどれだけ良くなってるか、というところですよね。

白石：今の流れをまとめると、ビューの複雑なところっていうのが、だんだんクライアント側に寄ってきていて、ようはHTML5でリッチクライアント化されてきて、サーバー側はAPIを提供しているだけになっていると。

鈴木：大きくはそうです。ただ、エンタープライズシステムの場合、とにかくシステム間連携が多くて、1つの企業の中でいろんなシステムがあって、ほとんどのシステムが関連付いているのが当然になっています。そうするとクライアント側からするといろんなシステムにいちいちログインして使うのは面倒くさいので、どうやってシンプルに使うのかというのが今の大きなテーマになっていると思います。サーバー間で連携したり、クライアント側でアグリゲーションしたりというのが今の課題としてあって、エンタープライズの場合は、そこがシンプルにならないので、それがひとつの前提になっています。

白石：なるほど。そのシステム間連携がさきほどおっしゃっていたようにXMLベースだったり、RESTだったりという感じですね。

鈴木：はい。企業って、いろんなユーザーといろんなシステムがあるので、いわゆる一般コンシューマー向けのECサイトのようなシステムもあれば、例えば人事システムみたいなものもありますよね。人事システムだと、人事部だけが使うのでユーザーが10人しかいなかったり、でも社員数10万人を支える人事システムっていうと相当でかいっていうものだとか。じゃあその2つが同じアーキテクチャで、同じ作り方でいいんですかっていうと全然そうじゃないですよね。

企業の中のさまざまなシステムの中で、HTML5に合うものもすごく増えてますし、HTMLの可能性が広がったことでやれることもすごく増えましたが、一方でそれが銀の弾丸ではないです。ここはRESTでつくったらいいよねとか、ここはWSDLがちゃんとあってSOAPでやったほうがいいよねっていうのがある。そこは全体の中での選択してやっていけばよいことです。エンタープライズの人って古めかしい人印象があるかもしれないですけど、新しいことも古いこともやらきゃいけないので、そういう意味ではちゃんとまともにやっている人は、それを両方うまくバランスよくやっていますね。

エンタープライズとモバイル

白石：最近のエンタープライズ業界に疎くて、初心者的な質問で申し訳無いのですが、モバイルをエンタープライズで使うというのはもうかなり普通に行われていることなんでしょうか。

鈴木：そうですね。モバイル、タブレット、PC、専用の機器とか、何を何に使うといいよねっていうユースケースはちゃんと考えなきゃいけないですが、モバイルはものすごく重要なツールとして使われています。

白石：エンタープライズでモバイルといえば結構HTML5が使われているという話を聞くのですが、実際そうなんですか？コンシューマ向けだと、ネイティブアプリが全盛です。

鈴木：そもそもモバイルという文脈で求められる操作性とか機能が、エンタープライズの場合はそんなにネイティブでやらなくてもいいようなものが多いので、HTML5がフィットしてるんじゃないかと思います。例えば、ゲームはネイティブアプリがいいといわれますが、別にあそこまでビジュアル的なものとか、細やかな操作性はあんまり求められることはないと。

なので、HTML5でやるっていうのは多いんじゃないでしょうか。Webアプリであれば、リリースも楽ですしね。去年ぐらいまでは写真とか音声とかでいろいろやろうとすると、まだまだHTML5では制約が多いということでネイティブアプリという選択もありましたが、そうした制約もブラウザが進化してきてだんだん問題にならなくなってきています。

白石：なるほど。ちなみに、そうしたHTML5で書かれた業務アプリは、ハイブリッドアプリとしてインストールする形が多いのか、それともWebサイトとしてURLでアクセスする形で作るんでしょうか。

鈴木：それは両方あります。どちらにも利点があるので。

クラウドがアーキテクチャに与えた影響は？

白石：これも初心者的な質問で恐縮です。クラウドがエンタープライズのアーキテクチャに与えた影響はありますか。

鈴木：もちろんあります。クラウドができたことで一番大きかったのは、PaaSという概念ができたことですね。あるニーズに特化したものっていうのは共有化されたものが使われるべきだっていう概念がはっきりしたのはPaaSのおかげです。例えばAWSのラインナップを見て貰うとわかるんですが、CDNありますねだとか、ロードバランサありますねだとか、ストレージ、サーバーノード、認証認可とか、メールの配信サービスとか、ああいうものはPaaSとしてみんなが共有して使うべきだという概念ができた。

なので、そういうプラットフォームを用意してその上にアプリケーションを作って、アプリケーションはUIを含めてそれだけに特化して、なるべくプラットフォームの機能をうまくつかってやっていくていうアイデアは、今のエンタープライズでも浸透している考え方だと思います。

細川：開発者視点でいうと、開発者ができる領域が増えてきましたね。従来だと、サーバ構築とソフトウェア開発は別々のものでしたが、プログラマーがだんだんとクラウドを前提にして、環境を構築するようになってきた。そうすると、同時にパフォーマンスだとかセキュリティだとかをエンジニアが自分で考えなきゃいけない時代になってきていて、Webエンジニアだとかエンタープライズエンジニアとかの区別はなくなってきている。そういう意味では、フルスタックで両方できなきゃまずいんじゃないでしょうか。

鈴木：もうそれはエンタープライズでも間違いなくそうですね。

細川：もうひとつの特徴としては、昔は大規模＝エンタープライズということが多かったんですが、今ではコンシューマー向けとかゲームだとか、そっちのほうがより大規模なんですよね。それを実現しているのがやっぱりクラウドなのかと思っています。そういった意味でも、これからはWebエンジニアこそ大規模を得意にならなきゃいけないんじゃないかと。サーバーとクライアントのメッセージの単位なんかもパフォーマンスに大きく影響するので、そういったところも、かなりノウハウを積まないといけなくなってきています。

エンタープライズ・アーキテクチャの未来像

白石：IoTとかウェアラブルとかを見据えて、今後どういうふうにエンタープライズ・アーキテクチャが変わっていくべきか、ご意見はありますか？

鈴木：IoTを真剣にやろうとすると、先ほど細川さんが言っていた大規模っていうのがエンタープライズに戻ってくるんですよね。対応するデバイスの数が、今まではユーザーが数万人ですんだのが、億になるかもしれない。例えば、すべてのダンボール箱にチップがついたらどうなるんだろうっていう世界を考える。そうすると日本で流通しているダンボール箱は何箱あるんだとか、ものすごいクライアントの数になってしまう。そうなってくると、エンタープライズがまた大規模な性能を頑張らないといけなりますね。

例えば、わかりやすい例でB2Bのケースを考えると、トラックをトレースする仕組みを作ることになったとします。じゃあ全国にあるトラックを全台管理しますとなったときに、全部で何台あるのか。1台のトラックにセンサーがいくつついているのかということになると、センサーが車輪それぞれにあって、それぞれのタイヤのすり減り方を計測して、運転手が寝てるんじゃないかというのを監視するセンサーがあって、速度・加速度をとるセンサーがあって…というようにトラックにすごい数のセンサーがある。

そして、トラックを1万台管理します、データを500msごとに取るとすなると、ものすごい数になる。つまり、B2BでIoT、ウェアラブルというのはB2Cのスケーラビリティをエンタープライズでもう1回頑張らないといけないということになる。今、Webの人が大規模で頑張っているテクノロジーセット、例えば大量のストリームを処理しながらイベントドリブンでやるっていうのは昔からエンタープライズにあって、それがWeb側ですごく実用化されて使われていたのが、またエンタープライズに戻ってくる。そういう流れが未来にはやってくるんじゃないかなと考えています。

白石：なるほど。ちなみに、もう実際にIoTの案件とか発生しているんでしょうか。

鈴木：相談はかなり増えてきてますね。まだ実証実験ぐらいが多いという感覚ですが。今は車がうまくいっていて、ホンダの事例がわかりやすいです。日本中の車のブレーキの発生情報を集めてるんですけど、それを解析すると事故が発生しやすい曲がり角がわかるんですよね。みんながたくさんブレーキを踏んでいる曲がり角がどこかっていうのを提供しているんですよ。そしたらそれを元に道路の信号とか標識とかを改善するってことをやっています。

まとめ

白石：本日は、エンタープライズ・アーキテクチャについて様々なご意見をいただき、誠にありがとうございました。最後に、読者に向けて一言お願いします。

鈴木：自分たちの生活を考えると、やっぱりエンタープライズ業界の会社が自分達の生活を支えてるわけじゃないですか。それがより便利になったり、役立つようになったり、世の中が進化するっていうのはとても大事なことだと思うんですよ。なので、それが実現されるためにはどうしたらいいのかっていうときに、エンタープライズとかWebとかそういう区切りはどうでもよくて、どうやれば本当に価値がでるのか、そういうのを考えるのが面白い。

ただ、社会基盤として変えてはいけないところもエンタープライズにはどうしてもあるので、それをどのように変えずに、より新しいことにトライしながら今あるものの価値をより高めるのかというところが大事ですね。なので「エンタープライズwww」という風潮はよろしくないと思います（笑）。

細川：2点あって、ひとつは、今までのエンタープライズ開発は、ユーザーの言われたものを作るという風潮が多かったんですが、今後はユーザーと一緒につくるっていうのは大事になってくるんじゃないかと考えています。そういう意味ではエンタープライズ業界もWeb業界と同じようにUXとか、よりユーザーが求めるものは何かというところを柔軟に対応してかなきゃいけない。エンタープライズもWebに学ばなきゃいけないということ。

もうひとつは、今後、変化がたくさんあって、それに対応するためにエンタープライズ側、Web側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。

IoT/WoTという言葉があちこちから聞かれるようになって久しいですが、最近は言葉だけではなくなってきた気がします。新しいマイコンボードや、XXセンサーのデータをクラウドに溜めて○○する商品などが続々と発売され、IoT/WoTのバックエンド専用のサービスまで登場してきています。

これから出てくるサービスやツールは、画面の中からの情報だけでなく、画面の外からの情報を使うことができそうです。逆に画面の外に影響を及ぼすようなことも可能になるかもしれません。解決できる課題の幅がグンと広がってきそうな予感がします。

加えて、先日の村岡さんの記事でも紹介されていたように、JavaScript等のWeb技術で開発できるマイコンボードも続々と登場し、IoT/WoTはWeb開発者にとっても身近なものになりつつあります。

今回はその中でもシンプルで扱いやすい、Espruino Boardを使い、JavaScriptでIoT/WoTに挑戦したいと思います。

ボードを購入するところから、温度センサの値を読み取る方法、Wifiに接続する方法について、ステップバイステップで解説していきます。「IoT/WoT、やってみたいけど敷居が高くてできない！」というWeb開発者の皆様に、一歩を踏み出すお手伝いができれば幸いです。

Espruino Boardとは

冒頭で紹介したとおり、Espruino Boardは、JavaScriptを利用してハードウェア制御ができるマイコンボードです。ざっくり言ってしまえば、ArduinoのJavaScript版のようなもので、まずはこの理解でいきましょう。

「とりあえずJSでハード制御してみる」を実現するには最も簡単で、かつ財布にも優しい選択肢とも言えるマイコンボードです。筆者もこれでIoT/WoTの第一歩を踏み出しました。

他の多くのマイコンボードと違い、自前でJavaScriptの実行環境を実装しているところも熱いポイントです。

また、Espruinoの今後の展開として注目されている、Espruino Picoについても触れておきます。Espruino Picoは、今回紹介するEspruino Boardよりもさらに小さい基盤(USBメモリサイズ)で、Espruino Board同様にJavaScriptでの制御が可能です。2015年春にプレオーダー分が出荷予定となっています。

どうしてJavaScript?

ただWeb開発者が知っている言語だから、というわけではなく、筆者はマイコン上でセンサー等のハードウェアを制御する言語として、JavaScriptは適した言語だと考えています。主な理由としては、イベントドリブンな記述がしやすいことと、setTimeoutやsetIntervalを使って、ループ処理を非同期に逃がすことができることが、挙げられます。

実際にマイコンボードを使ったサービスを運用してみると、マイコンボードにはやらなければならないことが意外とたくさんあることに気づきます。センサーの値を読みとってPOSTするだけでなく、センサー自体の死活監視のためのリクエストを投げるといった、運用のための処理や、Too Muchなリクエストの発生を避けるためにデータを間引いたりする処理がどうしても必要になります。

一例として、多くの言語がサポートする、無限ループを回しつつ、sleepで時間調整をする方法で、以下のような処理を実装することを考えてみましょう。

• 5秒に１回センサーの値を読み込む
• 1分に１回はマイコン自体の死活監視用にPingリクエストを投げる

普通に実装すると、5秒のスリープ処理の入った無限ループを作り、その中でセンサー値の読み取りを毎回実行します。Pingリクエストについてはカウンタ等を用意してIF分を切って実行有無を判定する、という実装になりそうです。やることが増えてくると、困りそうですね。

一方、JavaScriptでは2つのsetIntervalにそれぞれの処理を実装してしまえば事足ります。マイコンボードのようなpoorな環境でこれができるのは、Espruinoを始めとするJavaScriptで開発できるマイコンボードの強みであると筆者は考えています。

メインのテーマではないのでこの辺りで…

Espruinoを使い始める

では早速、Espruinoを使ってみましょう。 ボードを購入するところから、JavaScriptでLEDを光らせるところまでを、以下の流れで解説していきます。

• 必要物品を調達する
• Web IDEをインストールする
• ファームウェアをアップデートする
• JavaScriptコードを実行する

必要物品を調達する

IoT/WoTの”T”はThings、つまりモノです。何をするにもまずは物理的にモノを購入する必要があります。お金もかかる上に届くまでに時間もかかります。新しいツールをタダでダウンロードして、すぐに試せる環境に慣れ親しんだソフトウェア開発者にとっては、最初のハードルかもしれません。

でも大丈夫です。すぐに慣れて、いろいろ買いあさるようになると思います。

最低限必要になるのはコチラです。

• Espruinoボード
• マイクロUSBケーブル(Aタイプ オス/ マイクロBタイプ オス)

そしてWeb開発者であれば必ずWifiに繋ぎたくなるはずなので、以下も用意しておきます。

• CC3000 Wifi モジュール

Espruinoボードは国内販売されていないので、公式サイトにある販売サイトへのリンク一覧の中から何れかを選んで購入します。

オススメはEspruinoとCC3000の両方を取り扱っているAdfruitです。ここで一緒に買うことで、送料を節約することができます。

• Espruino
• CC3000 Wifi Module

ちなみに筆者はseed studioより購入しました(当時、AdfruitはEspruinoを取り扱っていませんでした）。送料に積む金額によって配送期間が変わるようです。無料だと2週間程度、30ドル払ったら4日で届きました。

補足 : 公式で推奨されているモジュールとは異なりますが、CC3000については国内販売されているコチラのモデルでも動作することを確認しています。筆者の手元での確認なので保証することはできませんが、国内で調達できるので、コチラを利用するのもアリです。

Web IDEのインストール

Espruinoの上で自分の書いたJavaScriptコードを実行するには、本家から提供されているWeb IDEを使用します。Espruinoとの接続や、ファームウェアのアップデート等もサポートしているので、まずはコレを導入します。Chrome Extensionとして提供されているので、Chrome Webストアからインストールしましょう。

EspruinoとPCを接続

EspruinoのマイクロUSB端子とPCのUSB端子を繋ぎ、WebIDEを立ち上げます。立ち上がったら、画面左上の接続ボタンをクリックします。

ダイアログが表示されるので、接続するシリアルポートを選択します。OSやマシンによって選択すべき項目が異なるため、下記を参考に選択します。

• Windowsの場合 : COM# のうち、数字が一番大きいもの
• Mac OSXの場合 : /dev/tty.usbmodem1234 (1234はマシン依存)
• Linuxの場合 : ttyACM0/ttyUSB0

Web IDEの左側のコンソールにConnectedと表示され、Espruinoのアスキーアートが表示されれば成功です。

ファームウェアのアップデート

JavaScriptのコードを書く前に、まずはEspruinoのファームウェアをアップデートしておきます。出荷時期によってこの作業の要否は分かれますが、自前でJavaScriptの実行環境を実装している関係上、ファームウェアが古いと思わぬエラーが発生したりもするので、アップデートしておくことをおすすめします。

• WebIDEの右上の歯車アイコンをクリックして、設定画面を開きます。
• 設定メニューのFLUSHERを選択し、Flush Firmwareボタンをクリックします。ダイアログが表示されます。

• ダイアログの指示通り、EspruinoのBTN1(USBコネクタから遠い方のボタン)を押しながら、RSTボタン(USBコネクタ寄りのボタン）を押します。
• ボード上の青色のLEDがゆっくり点滅するはずです。
• ダイアログのNEXTをクリックし、デバイスを選択します。
• ファームウェアの更新が始まり、ボード上のLEDが激しく点滅を繰り返します。
• 完了後、ダイアログのNEXTボタンをクリックした後、ボードのRSTボタンを押します。
• 再びWebIDE左上の接続ボタンをクリックして、Espruinoと接続します。

以上でファームウェアのアップデートは終了です。

JavaScriptコードを実行する

いよいよEspruino上でJavaScriptコードを実行します。 Espruinoボード上のLEDを光らせてみましょう。 WebIDEの左側のコンソールに、下記コードを打ち込んでEnterを押してみます。

LED1.write(true);

Espruinoボード上の赤いLEDが点灯しました。 続いて下記を入力してEnterを押します。

LED1.write(false);

予想通り、LEDを消灯することができます。簡単ですね。

こんな風に対話的にプログラムを実行することができるのは、Espruinoの一つの特徴と言えると思います。Webインスペクタのコンソールのような感覚でコードを動かして試すことができるので、デバックや開発途中のお試し実行に重宝しています。

さて、ここでプログラムについても少し解説をしておきます。

LED1.write(true);

Espruinoに備え付けられているLEDやGPIOのピンは、ビルトインのグローバルオブジェクトとして、あらかじめ登録されています。上記のコードで言うとLED1がそれにあたります。このオブジェクトに対して、書き込み(‘write’)や読み込み(`read’)の命令を投げることで、LEDやピンの入出力をコントロールすることができる、という仕組みです。

Espruinoで温度を計る

前項までで、Espruinoの上でJavaScriptを実行する準備が整いました。ここからはセンサ等と組み合わせてEspruinoを使う方法について解説します。まずは温度センサ「DS18B20」を使い、Espruinoで温度を計ってみましょう。

なお、この段階からはハンダ付け等の電子工作的な作業が必要になります。筆者が以前に書いた記事になりますが、以下を参考に、Espruinoをセンサー等のモジュールに繋げる準備を行います。（ピンヘッダを取り付ける、と聞いてピンとくる方は読み飛ばしてもらって問題ありません）

• Espruinoにセンサーとかをつなげるために必要な準備

また、ブレッドボードやワイヤー等、電子工作の基礎的な事柄については、以下の記事にて非常に丁寧にまとめられています。

• 初心者でもわかる・できる！Arduinoを使った初めての電子工作実践

調達

• 温度センサ「DS18B20」: おなじみ秋月電子さんより通販、店頭にて購入することができます
• 4.7kΩ抵抗 : 通販であればこちらも秋月電子さんより購入することができます。ただし、100本単位の購入になってしまうので、そこが気になるという方は千石電商秋葉原本店B1F等のバラ売りをしているお店で購入しましょう。

結線

温度センサ「DS18B20」には3つの端子がついています。それぞれの役割は、平らな面をこちらに向けて左から、GND、DATA、Vddとなります。GNDはグランドと結線するための端子、Vddは電源をとる端子です。温度のデータはDATA端子から読み取ることができます。

次のように結線してみましょう。

1. 温度センサのDATAとVddを4.7kΩの抵抗で繋ぐ。
2. 下記表の通り、Espruinoと温度センサを繋ぐ。

【写真だとこんな感じです】

プログラム

結線ができたら、次はプログラムです。先ほどはWeb IDEの左側のコンソールを使いましたが、今回は複数行のプログラムを実行する必要があるので、Web IDE右側のエディタを利用します。

以下のプログラムをWeb IEDの右側のエディタに記述してみましょう。温度センサから読み取った値を、1秒毎にコンソールに出力するプログラムです。

// センサーモジュールをセットアップ
var ow = new OneWire(A1);
var sensor = require("DS18B20").connect(ow);
// 1秒ごとに温度を表示
setInterval(function() {
  // getTemp メソッドで温度を取得
  console.log(sensor.getTemp());
}, 1000);

記述したプログラムを実行するには、書き込みボタンをクリックします。

温度センサの値がコンソールに出力されました。センサー部分を指で摘んだり、コタツの中にセンサを入れたりすることで、温度の変化を確認することができます。

ここでプログラムについて解説します。

ポイントは3行目のrequire("DS18B20")と7行目のsensor.getTemp()です。 7行目のsensor.getTemp()の命令一つで温度センサの値[℃]が取得できていることに注目してください。 本来、温度センサを始めとする電子部品から読み取れるのは、電圧の値です。ここから意味のある値、つまり温度を取得するには、センサの仕様を元に、電圧値に対して何らかの計算をしてやらなければなりません。 上記プログラムでは、最初にrequireしたDS18B20モジュールがこの辺りの計算を全て隠蔽してくれているので、末端のプログラムではgetTemp()の命令一つで温度値を取り出すことができるようになっています。下図のようなイメージです。

Espruinoでは各種ハードウェアに対応するモジュールが多数提供されており、電圧値等の生データを意識せずに、センサーの値を取得することができるようになっています(モジュール一覧)。

そしてこれらのモジュールはオープンソースとしてEspruinoDocsというリポジトリで管理されています。ここにプルリクエストを送ることで、誰でもモジュールを開発/公開することができます。筆者も最近、IoT向けプロトコルといわれているMQTTのクライアントモジュールに機能追加を行い、取り込んでもらいました。自分で自分の好きなプロダクトに手を加えられるのは、オープンソースの醍醐味ですね。

Web IDEについてもう少し

とりあえず温度センサの値を取得することに成功したので、ここでWeb IDEの使い方について、もう少し触れておきます。

コンソールとエディタの併用

例えば先ほどの温度センサのプログラム実行中に、コンソールにて下記プログラムを実行してみます。

clearInterval();

1秒毎に行われていた温度センサの値のコンソール出力が止まります。 続いて、温度を取得する命令を実行してみましょう。

sensor.getTemp();

温度が表示されました。

エディタで書き込んだコードに対して、自分の好きなタイミングで任意のコードを実行することができます。まさに、Webインスペクタのコンソール的な使い方ですね。

resetメソッド

画面左側のコンソールにてreset();を実行することにより、書き込んだプログラムの内容をリセットすることができます。コンソールにていろいろやりすぎてわけが分からなくなってしまったときや、単純にEspruino上で実行中のプログラムの動作を止めたい場合に使用します。

Wifiに接続する

いよいよEspruinoをインターネットに繋げます。 冒頭の「Espruinoを使い始める>必要物品を調達する」で紹介した、CC3000 Wifi Moduleを用意しましょう。こちらにもピンヘッダを付ける必要があります。

結線

ピンが多いですが、慌てずに落ち着いて結線しましょう。少なくとも、GNDとVBatだけは絶対に逆にしてはいけません（多分壊れます）。

プログラム

下記プログラムをWeb IDEのエディタに貼付け、wifiConfigのssidとkeyを、接続可能なWifiのSSIDとパスワードに編集します。

// wifi接続情報 ssidとパスワード
var wifiConfig = {
  ssid: "",
  key: ""
};

// コネクション確立時のコールバック
function onWifiConnect(s) {
  if (s=="dhcp") {
    // GETリクエストを投げる : 公式の Hello World! と返してくれるURL
    require("http").get("http://www.pur3.co.uk/hello.txt", function(res) {
      var data = "";
      res.on('data', function(chunk) {
        // 細切れのデータを変数に足し込む
        data += chunk;
      });
      res.on('close', function(){
        // レスポンスが全部返ってきたら溜め込んだデータをコンソールに出力
        console.log(data);
      });
    });
  }
}

// CC3000Wifiモジュールに繋ぐ
var wlan = require("CC3000").connect();
// wifiネットワークに繋いで、GetRequestを実行
wlan.connect( wifiConfig.ssid, wifiConfig.key, onWifiConnect);

書き込みボタンを押して、プログラムを実行します。Wifiに接続しに行くので、少し実行に時間がかかります。

コンソールに”Hello World!”と表示されました。この文字列は、Espruino本家がGetリクエスト用に用意しているURLから取得したものです。

しばらくWifiに接続していると、多少熱くなりますが大丈夫です。ただ、配線を悪い感じで間違った場合は、触った瞬間に尋常ではない熱さを感じることができます。すぐに電源を抜きましょう。当然ですが誤配線は故障やケガの原因になりますので、慎重に、落ち着いて結線することが大事です。

では、プログラムについて解説します。

26行目と28行目にて、Wifi接続処理を行っています。connectメソッドが2つ出てきているのが少しややこしいですが、26行目のrequire("CC3000").connect()のconnectメソッドはCC3000Wifiモジュールとの接続を意味し、28行目のwlan.connect()のconnectメソッドはWifiネットワークへの接続を意味しています。

後者28行目のWifiネットワークへのconnectメソッドは、SSIDとパスワード、そして接続完了後に実行されるコールバックを引数に取ります。今回のプログラムでは、onWifiConnectが呼び出され、このコールバックの中でGETリクエストが実行されます。

10行目でGetリクエストを実行しています。インターフェイスは、node.jsのhttpモジュールのgetメソッドと同様です。http://www.pur3.co.uk/hello.txtに対してGetリクエストを実行し、レスポンスをコンソールに表示しています。

今回のサンプルはGETリクエストでしたが、もちろんPOSTリクエストを投げたり、EspruinoをWebサーバとして動かすことも可能です。

参考

• POSTリクエストを投げる
• WEBサーバとして動かす

まとめ

駆け足でしたが、Espruinoを購入し、温度センサで温度を測り、Wifiに繋ぐところまでたどり着きました。 センサーとインターネットに繋がれば、とりあえずセンサー情報をクラウドに上げて、それをブラウザで面白おかしく表示するようなサービスは作れます。これを機に、とりあえず何でもよいから作ってみるのはいかがでしょうか。

筆者も会社のトイレの空き状況をブラウザで見れるサービスを作ったり、すだちの木に水を上げるとマスコットが喜ぶ玩具等々をEspruinoで作って運用しています。実際に作って運用してみると、本当にいろいろなことに気づきます。この手のサービスやシステムを設計するにあたっての勘所や注意すべきこと、開発当初は思いもよらなかったサービスの”効果”等、とにかくいろいろなことに気づかされます。もちろんハードウェアの専門家になることが目的ではないのですが、とても勉強になりますよ。

ちなみに、Espruinoは日本語ドキュメントが少ないことがネックです。なんとかできないものかと、去年ひっそりとEspruino Advent Calendar 2014なるものを作りました。（ところどころ挫折していますが）これらを参考に、一緒に面白いものを作っていけたらと思います。

最後に、Web開発者がIoT/WoTに挑戦してみる理由について、筆者の思うところを少しだけ。

これからはIoTだ！WoTだ！大きなビジネスチャンスだ！乗り遅れるな！……と、そういった現実的なものもよいとは思いますが、筆者個人としては、Web開発者がIoT/WoTに挑戦してみる理由は、「その方が面白いものが作れそうだから」で十分なのではと思っています（記事の冒頭ではえらそうなこと言っていますが）。

これまでのWebサービスは、人間にインプットしてもらった情報を収集して、それを便利で面白い形にしてアウトプットするものが多かったように思えます。紙でやっていたことをシステムに落としたようなものです。でも、たくさんのインプットがなければ面白くも便利にもならないし、面白くも便利でもなければ誰も情報をインプットをしてくれません。様々なサービス、システムがこんな鶏と卵のような悩みと戦ってきたのだと思います。

でも、インプットをするのが人だけでなく、モノが自ら語ってくれたら、少なくとも有益なインプットを作り出すことはできますよね。情報さえそろえば後はそれをどう見せるか、それは我々Web開発者の土俵です。面白いものが作りやすくなるのではないかと思っています。

で、面白いことをやっていたら、結果儲かっていた。となったら、ラッキーだなと。 エンジニアが勉強する理由なんてそんなものでよいのでは、と最近考えています。 (あ、でもこの辺の市場が拡大することは間違いないと思いますよw。実際、この手のサービスのお仕事のお話をいただく機会が増えてきています^^）

というわけでIoT/WoT。言葉自体は流行っていますが、取り組んでいる人はまだまだそう多くはありません。 これを機に、まずはEspruinoで、面白いモノを作っていきましょう。

JavaScriptではじめる組み込み系プログラミング

さまざまなデバイスがWebを介してつながるWeb of Things（WoT）。WoTの普及によってさまざまな分野からWeb上に新しいサービスがローンチされ、Webを利用するユーザーに新しい体験が提供されるタイミングが、すぐそこまできている感じがします。

一方で、WoTの普及はWebクリエイターにとっても、新しいビジネスチャンスかもしれません。ひと昔前まで、Web技術は、PCのWebブラウザ上でしか使われないものでした。しかし現在では、Firefox OSのようにモバイル・ネイティブで動作するようになりました。さらに最近では、マイコンなどの組み込み機器でも、直接JavaScriptなどのWeb技術が動作するものが出てきました。

ここ最近、海外でリリースされているデバイスの中には、JavaScriptなどのWeb技術を強くキャッチアップしている製品が増えてきています。今回はそれらJS Boardの中から、筆者がよく使っているのものを3つ紹介したいと思います。

Espruino

espruino.com

2013年にKickstarterで資金調達が開始され、目標額を大きく超える調達額を獲得し開発されたデバイスです。リファレンスボードであるEspruino Boardは、72MhzのCortex-M3でJavaScriptプログラムがコンパイルされ、動作する小さなマイコンです。

JavaScriptコードは、専用のEspruino IDEで編集し、EspruinoをPCとUSB接続すれば、IDEからEspruinoへ直接プログラムが転送できるようになっています。ArduinoのようにIDEが用意されているので、気軽に開発できるのがよいですね。

例えば、Espruinoに人感センサーをつないで人の動きを検知するサンプルコードは、このようになります。

setWatch(function() {
        LED2.write(1);
        setTimeout(function() {
        LED2.write(0);
    }, 3000);
}, A1, {repeat:true, edge:"rising"});

EspruinoのJavaScriptには、ハードウェアを制御するための専用APIが、搭載されています。上記のコードでは setWatch というsetIntervalに似た関数で、センサーの状態を取得するループ処理を行っています。

筆者はこのプログラムをもうちょっと作りこんで、ウチの猫のトイレに設置しています。猫ちゃんがトイレに入ったり出たりするのを検知して、クラウドにデータを送信し、スマートフォンにプッシュ通知するような仕組みをつくりました。猫のトイレがすぐに掃除できるようになったので、猫ちゃんのストレスが減りました（減ったにちがいないｗ）。この事例は日経テクノロジーオンラインで取り上げていただきました。

Espruinoに関する日本語の情報はあまり多くないですが、いまのところEspruino Advent Calendar 2014がよくまとまっていると思います。個人的にはJS Boardの中で一番気に入っているデバイスなので日本でももっとユーザーが増えてほしいところですね。

これからEspruinoを買おうと思っている方には、上記のEspruino Boardもいいんですが、現在開発中のEspruino Picoもオススメです。Espruino PicoはEspruino Boardよりもさらに小さいUSBメモリサイズの基盤です。とても小さな基盤なのでいろいろなケースに活用できるのではないでしょうか。Espruino Picoのプレオーダー分は、2015年春ごろに発送される予定のようです。

Tessel

tessle.io

DragonInnovationで資金調達されたプロジェクトで、Espruinoよりも少し大きなマイコンです。Wifiチップを搭載しているので、単独でWebにアクセスする機能を持っています。

Tesselの特長は、多くの専用モジュールが販売されていることです。加速度センサ、GPS、BLE、サーボコントローラー、NFCなど多くのモジュールが別売りで販売されていて、Tesselのポートに差し込むだけで利用できます。Espruinoに市販のセンサーを接続する場合は電子回路の知識が必要ですが、Tesselの場合は専用ポートに差し込むだけなので回路の知識は不要です。

TesselのJavaScript APIはnode.js互換な仕様になっています。例えば、加速度センサーモジュールを接続してデータを取得するサンプルコードは以下です。

var tessel = require('tessel');
var accel = require('accel-mma84').use(tessel.port['A']);

accel.on('ready', function () {
    accel.on('data', function (xyz) {
        console.log('x:', xyz[0].toFixed(2), 'y:', xyz[1].toFixed(2), 'z:', xyz[2].toFixed(2));
    });
});

accel.on('error', function(err){ console.log('Error:', err); });

JavaScriptらしいイベントドリブンな記述で、加速度センサーのデータがリアルタイムに受信できます。このコードでrequireしているtessel, accel-mma84といったnode.jsのモジュールライブラリはnpmでインストールできます。

Tesselは基本的に、4つのモジュール専用ポートに専用モジュールを接続して利用するスタイルですが、専用モジュール以外が利用できないかというと、そうではありません。Tesselには汎用的なGPIOポートも搭載されているので、秋月電子あたりで買ってきたセンサーをつなげることもできます。下図はTesselのGPIOポートでLEDを点滅させてみたところです。

　▲TesselのGPIOポートにLEDを接続してLEDを点滅させている

/*
* TesselのGPIOでLチカ
* LEDのアノードをTesselの TX/G1
* LEDのカソードをTesselの GND
* に接続する
*/
 
var tessel = require('tessel');
var gpio = tessel.port['GPIO'];
 
gpio.digital[0].write(0); // TX/G1
 
flag = true;

setInterval(function() {
  if(flag == true) {
    flag = false;
  } else {
    flag = true;
  }
  console.log(flag);
  if(flag) gpio.digital[0].write(1);
  if(!flag) gpio.digital[0].write(0);
}, 1000);

Tesselは今回紹介するデバイスで唯一国内販売されているデバイスです。スイッチサイエンスで購入できます。国内で買える、電子回路の知識が不要、node.js互換など、ハードウェアのない方でも入門しやすいデバイス、といえるのではないでしょうか。

Spark

spark.io

Sparkはマイコンというよりは、サーバーサイドを含めたオープンなIoTプラットフォームとして開発されています。昨年、Lion Wells Capital、O’Reilly AlphaTech Venturesなどから出資を受けて話題となりました。

Sparkから発売されている小型マイコンボード Spark Coreは、72 Mhz Cortex M3とCC3000 Wifi moduleを組み合わせた「マイコン付きWifiモジュール」と呼べるようなもので、Arduino互換な言語でプログラムを記述します。

EspruinoやTesselと違って、JavaScript使わへんやんけと思われるかもしれませんが、Spark Coreから取得したデータはすべてWeb APIで取得できるようになっており、Web APIをラップしたJavaScript SDKがnode.js、Webブラウザで利用できるよう提供されています。

Spark Coreへプログラムを転送する場合は、Espruino、Tesselと違って、PCとUSB接続をする必要がありません。クラウド上のIDE Spark Buildで編集したコードをFlashすると、ネットワークに接続されているSpark Coreにリモート転送され、実行される仕組みになっています。

下のコード例では、Spark Coreと人感センサーをつないでセンサーの値を detected 変数にバインドしています。（一部抜粋）

Spark.variable("detected", &detected, INT);
...
detected = motionDetect();

上記のようにバインドされた値は以下のようにアクセスすることで、クラウドからセンサーの値を同期的に取得することができます。

curl -G https://api.spark.io/v1/devices/[Device ID]/detected \
  -d access_token=[Access Token]

これをSparkのJavaScript SDKを利用して記述すると以下のようになります。

var spark = require('spark');
var ret = spark.login({"accessToken": "[Device Token]"});
device.getVariable('detected', function(err, data) {
  if (err) {
    console.log('An error occurred while getting attrs:', err);
  } else {
    console.log('Core attr retrieved successfully:', data);
  }
});

SparkはSDKの他にサーバー、デバイス間の通信プロトコルが、node.jsモジュールで実装されています。それを利用するモックアップサーバーもnode.jsコードで公開されているので、結構JS成分が多いです。SparkのプロトコルはCoAP+SSLで設計されていて、このあたりはWoTというよりはIoTなんですが、かなり興味深い実装です。

筆者がSpark Coreを使ってみた感覚では、長時間にわたる動作についてはTessel、Espruinoに比べて安定していると感じました。Tessel、Espruinoは実験や製品の試作レベルでカジュアルに利用できるデバイスですが、Sparkは、それらよりも一歩製品レベルに踏み込んでいるような印象があります。

現在販売されているデバイス Spark Core は39ドルで販売されていますが、次世代のSparkデバイスである PhotonとそのコアモジュールP0が2015年5月に発売予定となっており、現在プレオーダーが受け付けられています。価格はPhotonが19ドル、P0が10個で100ドル（1個あたり10ドル）となっており、IoT製品の量産に利用できるような価格帯となっています。

まとめ

個人的な話ですが、最近ハルロックの影響で電子工作にはまってます。仕事が終わってからハンダ付けをしたり、ブレッドボードで配線したりしてる今日この頃なんですが、マイコンのプログラミングはC++とかJavaとかでやるのはなんか負けた気がするので、JavaScriptでプログラミングできるものにこだわっています。

そういったWeb技術、特にJavaScriptを中心的に利用している組み込み機器を個人的に”JS Board”と呼んでいて、勉強会を開催したりしています。先日のHTML5 Conference 2015でも出展させていただきました。今後も勉強会などをやって、情報共有などをしていこうと思っています。

　▲HTML5 Conference 2015にJS Board勉強会が出展。さまざまなJS Boardデバイスが展示されている。

これからまだまだJavaScriptを活用するデバイスが続々と登場してきそうです。 JS Boardに興味を持った方々、ぜひ一緒に勉強していきましょう！

ArduinoやRaspberry piをはじめとした低価格のマイコンが登場し、ハードウェアの知識がなくても、手軽に電子工作が楽しめるようになってきました。HTML5 Experts.jp読者の皆さんも、こうしたIoTやWoTに関心を持ち始めた方も多いのではないでしょうか。

WebクリエイターがMakeするにあたって、Webで培った技術は役に立つのか・立たないのか、これから活躍の場はあるのか。白石俊平編集長を聞き手に、すでにモノづくりの世界に足を踏み入れ始めたエキスパート村岡正和さん、高岡大介さん、もうバリバリのハードウェアの人として活躍している岡島康憲さんにぶっちゃけトークを展開してもらいました。

　▲左から、白石俊平編集長、岡島康憲さん、高岡大介さん、村岡正和さん

IoTやハードウェアの世界に踏み込んだきっかけは？

白石：まずは、皆さんのIoTに対する取り組みを、教えてください。

村岡：僕はJavaScriptが得意なバリバリのWeb系エンジニアなんですが、最近IoTやWoTがIT業界で重要視されてきたので、ハードウェアの勉強を始めたところです。

でも、いまさら組込みの世界でJavaとかC++を始めてもかなわないし、そもそも自分はWebのエンジニアなんで、そっちに行ったら負けかなとも思ってるんです。僕のIoTへのこだわりは、ハードのアプリケーションやデバイスが動くWeb技術を取り入れていきたいってことなんですよね。

　▲村岡 正和さん（※今回はリモートで参戦）
神戸でシステム開発を行っているフリーランスのエンジニア。コミュニティ活動では、html5jのスタッフやマークアップ部部長、HTML5-WEST.jpの代表として関西でHTML5を中心としたWeb技術の普及に努めている。JS board勉強会や、「日本ウェアラブルデバイスユーザー会」を運営している。

JavaScriptで組込み機器を動かすというソリューションに注目していて、その技術を追っかけるために、「JS board勉強会」を立ち上げました。自分の家にも、JavaScriptを使った組込みボードで、猫の監視センサーを作ったりしています。

　▲猫の監視センサー　※詳しくはこちらの資料参照

Espruinoというマイコンボードをネコのトイレに設置して、猫が出たり入ったりすると検知して、僕のスマホに送ってくれるんですよ。焦電センサーを使って、マイコンとWifiのモジュールとつないでいるんです。僕が外出していても猫がトイレに行ったことがわかるし、家にいると、すぐトイレが掃除できるのは便利なんです。なんかスマートハウスぽいでしょ？(笑)。これはJavaScriptで操作します。Arduinoのようにセンサーをつけて、JavaScriptで動かせるので、僕みたいなWebエンジニアでも普通に使えます。

あと1つ、TesselもJavaScriptで操作できるものもあります。Espruinoよりももっと簡単に操作できる端末。Wifiが内蔵されているので、Intel Edisonに近いかんじです。Tesselの場合は、センサー類が別売りされている。簡単に装着することができるので、電子工作の知識がなくても使えます。スーパー簡単です。Espruinoはいろんな機能が使えるけど、電子工作の知識が必要ですね。

高岡：私は「先端IT活用推進コンソーシアム」で活動しているのですが、IT企業がIoTに対してどう取り組んでいくかを考えるために、2014年11月から月1回、一から勉強するIoT勉強会やハッカソンなどを主催しています。

　▲高岡 大介さん
外資系SIerでエンタープライズシステムの開発を経験した後、独法研究所にて形式手法やセマンティックWeb関連の研究に従事。ベンチャー企業などを経て現在はフリーランスとして、技術支援、開発、執筆、講演など様々な仕事に携わる。Build Insiderでオピニオンコラムを執筆中。Senchaユーザーグループや先端IT活用推進コンソーシアムで活動している。

例えばこのlittleBits（リトルビッツ）を使って、勉強会でデモをやったりしてます。Arduinoも試してみたんですが、Wifiシールドを付けないとインターネットにつながらないので、Intel Edisonを買ってつないだりします。

GROVE Systemとか、さっきのTesselとか組み合わせれば簡単にできるというのは、最近の流行ですね。littleBitsは磁石でつながるし、ショートしないようになっているから子供でも使える。間にセンサーにはさんだり、シンプルなボタンにラッチというモジュールを挟むだけでトグルスイッチにもなります。あとはcloudBit（クラウドビッツ）はインターネットにつながる秘密兵器なので、注目しています。IFTTTに対応したBitモジュールが便利なんですが、まだ日本では正式発売されていないんです。

こんなかんじでデバイスやセンサーのことは勉強してますが、自分はあくまでもアプリケーションレイヤーの部分で頑張りたいと思っています。だからデバイスはお手軽に組み合わせて、使えるものを選んで試しているかんじです。

岡島：私は、もともとはWebサービスの企画屋だったんです。2009年くらいから友人たちとハードウェアをいじり始めて、2011年に岩淵技術商事を起業。東京デバイセズ研究開発用製品を製造販売するメーカーを展開しています。それ以外にもABBALabでいうハードウェアスタートアップアクセラレータへのサポートを通じて、ハードウェアのスタートアップ支援や、アクセラレーションのプログラム提供などを行っているので、IoTに関わる機会は多いですね。

　▲岡島 康憲さん
岩淵技術商事株式会社 執行役員。インターネット関連企業・NECビッグローブにて、Webサービスの企画立案・運用やインターネット接続型ハードウェアの企画立案に6年間従事する。2011年7月、エネルギー関連ハードウェアや、Webサービスの企画開発を主業務とする岩淵技術商事株式会社を創業。研究開発用電子製品を開発・販売する「東京デバイセズ」を運営している。

友人たちと作った代表的なもの1つは、2009年にTwitterと脈拍のセンサーをつないで「死んだらツイートするデバイス」こと「秋月パルス」。毛細血管の赤外線吸収量から、血流の変化を検出し、Twitterに生命活動を投稿する自作デバイスです。Twitter APIを活用したハードウェアなんですが、同じように個人が開発したWebサービスと絡めたハードウェアで、PCなしで装置単体でネットもつながるのは当時はほとんどなかったと思います。海外のTechCrunchやEngadgetで取り上げられて、日本で話題になりましたね。

白石：へえ、すごいですね。ところで、ハードをいじり始めたきっかけは何だったんですか？

岡島：起業する前は、NECビッグローブで動画配信サービスなどWebサービスの企画運営をやってたんです。多くのWeb系企業が展開していたサービスの大半がPCや携帯電話向け中心だった状況に限界を感じて、上司と研究開発部を作って、今で言うChromecastのようなハードウェアプロトタイプをはじめ、いくつかのハードウェアの企画や試作をしました。また、Kickstarterのようなクラウドファンディングが普及し始めた時期に、個人間送金のようなかたちで投げ銭ができるサービスをリリースしたりしていました。

白石：東京デバイスセズは、販売代理店をやってるんですか？

岡島：いえ、全体の半分以上は自社製品です。複数人で製品開発を行う場合もありますが、大半のものは弊社の代表自身が開発しています。利用シーンやユーザーニーズををうまくとらえることで、少人数であっても魅力ある製品を作れるのではないかと考えています。

WebクリエイターがMakeする必要って、あるの？

白石：ではそろそろ本題に。そもそもWebクリエイターがMakeする必要性って、あると思いますか？

村岡：絶対やらないといけないということはない。jQueryと同じで使いたい人だけやればいいんじゃないかと。ただし、やったら絶対面白いと思いますね。これまでなかった新しいビジネスのチャンスにもなるし、勉強すればハードウェア業界に打って出れるチャンスでもある。

別にフリーランスだから新しい仕事を取りにいこうとか、自分で製品を作って売ろうとかも、今のところ考えてない。じゃあ、なんでかと言えば、答えはハードウェアの人と組んで仕事をするためには、最低限の知識が必要だと思っているから。これからはWebクリエイターもある程度のハードの知識は必要だと思うし、ハードウェア側の人も勉強しているはず。

お互いに共通言語で話せるくらいにならないと、いいものは作れないと思うんです。これからは絶対Makersみたいな仕事が増えていくし、ハードウェア屋さんの発想や知識だけではできないことを作りたいんですよね。Webクリエイターにしかできない新しいソリューションを生み出していきたい。ハード屋と仲良くなりたいから勉強しているし、自分のスキルアップや新たな分野にシフトチェンジするチャンスだと思ってます。

白石：なるほど。今の村岡さんの話には「IoTの仕事が増えていく」、「その中にWebクリエイターの仕事がある」という2つの仮説がありましたね。岡島さんは、どう思われますか？

岡島：IoTの仕事は実際、今も増えています。ここ2～3年は、「ネットとセンサーをつなげてこんなことができませんか？」といった問い合わせも多いですね。CES（Consumer Electronics Sh.ow）でもIoT系のデバイスやプロダクトも増えて、盛り上がっていた。大手メーカーやハードウェアベンチャーからこれまでインターネットと関係なかったデバイス屋さんからの相談も増えてます。

Webクリエイターの仕事チャンスはあると思います。僕自身もハードとソフトの中間の立場なので、バリバリのハードウェア業界の方々にはWebサービス界隈の人の顔をする。 「IFTTT（イフト）っていうのはなあ…」なんて話を偉そうにするし、逆にWebサービス業界の方々にはハードウェア界隈の人の顔をして「お前は知らないかも知らないけど、ハードウェアって超大変なんだぞ」って！

ハードウェア業界の方々の中には、Webサービスの可能性や実装に必要な技術を把握しきれていない人もいる。例えば、福島で放射能のセンサーを作ろうとしたときに、GPSとネットをデバイスにつなぐにはどうしたらいいの？って相談されたとします。通信は3Gならいけるな、Webサーバーを立てて、管理画面作らなきゃとか、Googleアカウント立ててみようかとか…。Web系のエンジニアが必要とされるところはたくさんあります。特にセンサー、デバイス周りの認証回りは、相性がいいと思いますね。

Web的な発想で企画提案する人や、管理画面が必要なのであれば、UIデザイナーも必要とされてくるはず。だから、その仮説は正しいんじゃないかと。

ハードウェアエンジニアとWebクリエイターの違い

村岡：さっきの話すごくわかりますね。最近、ハードウェア屋さんと話をすることが多くなって気づいたんですけど、彼らはソフトウェアやインターネットの知識が意外と少ない。ハードウェアは業務が高度に専門化しているから、設計者だけでは製造できないし、設計も業種が細かく細分化されている。何でもふんわり全部やるWeb業界の文化とは全然違うんですよね。でも、文化の違いを理解するだけでもずいぶん歩み寄れる。まずは業界・風土や仕事の理解ができてから、彼らと話がスムーズにできるというのがスタート地点。

そうなるとWebクリエイターはここからどういうソフトを作ったらいいか、サービスまで広げて考える。ソフトからサービスまで考えることがハード屋さんにはないから、新鮮に映るみたいです。デバイスを作る理由をサービスを作ることまでつなげてあげると驚かれるんです。これはやってみてわかったこと。ハード屋さんには刺激を与えられているし、面白いと言ってもらえる。本質的な新しいジャンルとのマッシュアップだと思っている。まだまだ可能性があるし、新しくて楽しい仕事が増えていくので、みんなも早くやったほうがいいと言いたい。

白石：僕は自分がハードを知らなさすぎるせいか、ハード屋さんがソフト屋さんになるほうが簡単じゃないのって思ったりします。ソフトウェア作りって、そんなに難しい気がしないっていうか…。

村岡：むこうも同じこと思ってますよ(笑)。電気回路を覚えるほうが、ソフトウェアやWebサービス考えるより簡単じゃないかって。

岡島：どういうレイヤーで作るかにもよりますけど、例えば銀行のシステムを作るのって個人レベルじゃ厳しいじゃないですか。PHPでちょいちょいとWebサイト作るのとは全然違う。

それと同じで、東京デバイセズは何千万の製品を完全なものを安定的に供給するのは無理だけど、ハッカブルな製品を毎月数台出すくらいなら問題ない。十分売り上げが立つんです。やること次第だし、比べることはあまり意味がない。

IoTの意味って、サービスのモノ化だと思っています。IoTはソフトのハード化なんだと。サービスを作るためにスマートフォンだけじゃ足りないからモノに手を出しているんだと。それが本質なんですね。僕がハードをいじりはじめた理由なんです。興味があったわけじゃないし、PCとガラケーでできることに限界を感じていたから。

大手メーカーが扱っていないモノを作ろうと思ったときに、画面の外に出たくてハードに手を出した。やりたいことに限界を感じたからハードを作り出したんです。ハード屋さんハードがあるからこそ、いわゆる従来型のハードウェアの企画開発フォーカスしてしまって、Webサービスによってハードウェア製品の価値を伸ばすことに検討の余地を残してしまっていると思います。

今後のIoTビジネスはどうなる？

村岡：サービスというのは「モノを売ってなんぼ」だけじゃない。ハード屋さんはモノを作って売る対価のやりかたに慣れすぎて、それに気づかないんです。クラウドを使うとか、ソフトばらまいて広告を売るとか、Webのマネタイズの話をすると、ハード屋さんに「思いもつきませんでした」と驚かれます。

高岡：今後のIoTビジネスの話は興味深いですね。IoT勉強会をやっていると大きく二つの流れがあるような気がします。Makersやデジタルファブリケーションの文脈のIoTと、IBMやインテル、シスコなどの大きいビジネスやスマートグリッドなどの文脈。これが両方が融合していない気がするんですよね。分断されてるというか。Webエンジニアがどっちの文脈でいくのがいいか悩みますね。

先日ガートナーは、ハードウェアスタートアップベンチャーはあと2～3年後で限界がくると指摘していましたね。スタートアップが大企業にとって食われて、やれることがなくなってくるというものでした。

白石：メイカームーブメントが終わるということ？

岡島：今の話で2つ面白いと思ったことがあります。1つはシスコやインテルのIoTと、スタートアップのIoTに乖離があるという点。シスコやインテルは、ネットに繋がるハードウェアをどういうプロトコルでつなぐといいかという点にフォーカスしている。そもそも考えている土俵が違うから、ずれがあるんですよね。理由はレイヤーが違うから。

ハードウェアスタートアップ限界説については、ハードウェアスタートアップがハードウェアを作るのはものすごく大変なので、実際今も起きている問題です。イニシャルコストが大きい、設計や試作も大変、サポートも大変と、ハードウェアはお金がかかるビジネスだから。

村岡：Kickstarterはバブルみたいなものだって、言われてますもんね。

岡島：僕は、ハードウェアを作るコストが下がってくれば、その構造が変わっていくと思っています。ガートナーの発表は製品を設計・製造・販売する環境が今と変わらない前提でのものだけど、製造コスト、サポートのハードルが下がれば、それぞれの枠組みが変わって、さらに多くハードウェアスタートアップが入ってくる。そうなると必然的に、ブレイクスルーが起きてくる。

それは、インターネット業界のスタートアップと仕組みは同じなんですよね。サーバーにはお金がかかるし、新しい技術の伝搬コストや情報共有するコミュニケーションコストもかかるから、大手しかできないと思われてたことが、今はサーバーも安くなったし、GitHubが出てきてベンチャーでも遜色なく作ることができる。

高岡：そこでまさに、私たちWebクリエイターの力が役立つ可能性が高いわけですよね。

岡島：インターネット業界では、例えばUberのように、物理的な不動産や動産に対してブレイクスルーを起こしてきた。それと同じことが起こればいいだけ。

白石：ハードウェアの製造コストが今は高いと思われているけど、ブレイクして、コストが下がれば、スタートアップは引き続き盛り上がるということですね。

岡島：もしハードウェアスタートアップのこの盛り上がりが落ち着くとしたら、潜在的な燃料がありそうなバイオ領域に関心が移ることじゃないかって思っています。大手の伸びに押されて尻つぼみになるシナリオはあんまりピンとこないですね。

村岡：ああ、確かにそれはありますね。

IoTの時代、Webクリエイターの仕事はどう変わる？

白石：IoTの時代が来るとして、僕らの仕事ってどう変わっていくのか意見を聞かせてください。

岡島：まず、Webのビジネスにどう関わっているかが、1つ大事な判断材料ですね。Webサービスの企画立案している人にとっては、企画の幅を広げるのにいいブーム。アタマのかたすみに考えておいたほうがいいと思います。サーバーサイドをやっている人は、IoTはセキュリティやプライバシーの問題とかで、ツッコミどころが多いから需要が増えると思います。

白石：TechCrunchでも、IoTのセキュリティとプライバシー問題は取り上げられてましたね。　

高岡：求められる人材としては、ハードウェアの知識もWebの知識もある人だけど、今はまだそうそういないですよね。私たちがハードウェアを理解したり、ハードウェアエンジニアがソフトを理解する必要がある。

白石：今は売り手市場だけど、ハードウェアエンジニアのニーズってどうなんですか？

岡島：ハード系のエンジニアも、めちゃくちゃ足りないって言われてますね。ハード系はフリーエンジニアはほとんどいないんです。大手メーカーがつぶれたら、数万人のエンジニアがが野に放たれる。エンジニアを解放してほしいって思ってます(笑)。

「DMM.make AKIBA」の施設運営やハードスタートアップ支援プログラムを小笠原という人間と一緒にやっているんですけど、いろいろなビジネスを通じた売上も重要である一方で、職業の枠をどれだけ増やすか、ハードウェアエンジニアの仕事をどれだけ楽しくできるかをよく話したりします。

ハードウェアビジネスに関わるためには大手メーカーに入るしか道がない、その状況を変えたい。これからは、想像もしないような職業が、新たなハードウェアニーズの隙間から出てくるはずなんです。そのためにもハードウェアのフリーエンジニアをどうやって増やすかを考えています。

白石：IT業界はゼネコン構造が多いですが、ハードウェア業界はどうなんですか？

岡島：見方によっては、今のハードウェア業界は20年前のインターネット業界に似ていると言われています。だが、大手しかできなかったことがより低コストでできるようになって、つまり「ハードウェアビジネスの民主化」が進むことで、個人でもビジネスでできるようになった。これからはもっと盛り上がっていくんじゃないでしょうか。

高岡：我々Webエンジニアがハードウェアビジネスに飛び込んで、成功する確率はあるのでしょうか？ IoTを勉強すれば、仕事の幅は広がるけど、ガチに参入したらどのくらい成功できるものなのか気になります。

岡島：インターネットのサービスの成功確率とほぼ変わらないと思います。0.00001％とか(笑)。Webのサービスも、生き残る確率は限りなくゼロに近いですよね。

白石：大半がつぶれるってことですか？

岡島：生まれてつぶれていくのが認識できないくらいですね(笑)。今はまだ母集団が少ないから、目立っているけど。ただ認識しないといけないのは、きちんとバリューが提供できるサービスなのかどうか、お客さんに価値を与えることができるのかどうか、自分達でないとできないサービスなのかということ。ハードもソフトも、そこを設計してサービスを考えられる人は生存確率が高い。

生粋のハードウェア屋よりも、そういう意味ではWebクリエイターの方が成功できるはず。みんな、はてブの「成功するための○○の法則」とか大好きじゃないですか。そいう思想に慣れているのが、Web系エンジニアの強みですよね。

だから、WebクリエイターもMakeしよう！

白石：では、最後にWebクリエイターとしてのメッセージを一言！

村岡：Webクリエイターもハードウェア知識も身に付けるべき、ということですね。ソフトとハードエンジニアの垣根がなくなってきたし、フルスタックエンジニアもハードの設計ができることが求められるようになると思います。

5年くらい前にHTML5の時代がくるって言われたけど、実際にHTML5が勧告されてから勉強し始めてたんでは、すでに遅い。たぶんそれと同じことが起こるんじゃないかと。「Arduinoとかできますよね？」って聞かれて、普通に「はい、やれます」と答えるような人が給料もらえるようになるんじゃないでしょうか。

高岡：なんだかんだ言っても、現実のものが動くのは楽しい。スクリーンを出て「現実をハックしよう！」ってことです。

岡島：画面の中だけに満足できなければ、ハードをやればいい。ただし、自分が興味があるものをやればいいし、世間にまどわされなくていい。受け身じゃなくて、好奇心をもってやるべき。時代の先端にいた人たちは、今に満足できなくて、踏み出した人たちなだけなんですから。

Arduinoなどのマイコンのおかげで、ハードウェア開発、特にプロトタイプづくりに関するハードルはだいぶ下がりました。自分（白石）のような人間でも、LEDをチカチカさせるくらいのことはやってみたことがあり、「こんなに簡単にハードを制御できるなんて！」と感動したのを覚えています。ただ、プロトタイプを一度作ってみると、更なる大きな疑問がわいてきます…身の回りにあるハードと、自分の作ったプロトタイプの落差に驚愕するのです。

自作したプロトタイプを、カッコいい量産ハードウェアに持っていくためには、どんな作業が必要なの？ 今回はそんな素朴な疑問に答えてもらうべく、Cerevoさんにお邪魔してプロダクトマネージャーの國舛さんにお話を聞いてきました。

Cerevoといえば「LiveShell」などのハードウェア制作で有名なハードウェアスタートアップ。先日のCESでは「Top Tech of CES」を受賞されたりと、その快進撃は止まりません。今回インタビューに答えていただいた國舛さんは、現在はCerevoのプロダクトマネージャーを務めていらっしゃいます。が、「SmartTrigger」という製品を手がける前までは、ハードウェア開発の経験を持たないWebエンジニアでした（僕らと一緒ですね！）。

　▲株式会社Cerevo プロダクトマネージャー　國舛等志さん

そんな國舛さんに、「量産ハードウェアの作り方」をわかりやすく語っていただきました。では、お楽しみください！

SmartTriggerの説明

白石: 今回は、國舛さんがはじめて中心となって手がけられた量産型ハードウェア、「SmartTrigger」を題材に、ハードウェア開発の実際についていろいろ伺いたいと思っています。どうぞ、よろしくお願いします。

國舛: よろしくお願いします。ではまず、SmartTriggerとはどんな製品かを簡単に説明したあと、開発のお話をしましょうか。

こちらがSmartTriggerです。簡単に言うと、カメラとこのデバイスをつないでおくことで、スマホからリモートでカメラを操作できる、という製品ですね。 シャッターを押すのはもちろん、連写やタイマー撮影もできます。

　▲聞き手：HTML5 Experts.jp編集長　白石俊平

白石: おもしろいですねー。SmartTriggerが、スマホから送られてくる命令に従って、カメラを操作するという感じなんですね。

國舛: そのとおりです。タイムラプス動画（時間をかけて連続撮影した写真を動画のように高速再生するテクニック。時間を圧縮したような感覚の動画を得られる）も、間隔や秒数などのパラメータをセットしたら、あとはSmartTriggerが勝手にやってくれます。その間、スマホでは別の操作をしていても全然構いません。

白石: カメラとSmartTrigger、スマホはどういう風に通信するんですか？

國舛: SmartTriggerとスマホの間はBluetoothで無線通信します。SmartTriggerとカメラはケーブルで有線接続。メーカーの違いはケーブルで吸収していますので、国内メーカーのカメラはほとんどサポートできています。

白石: なるほど、手持ちのカメラに合うケーブルも同時に購入する、というかんじなんですね。
では本日は、この「SmartTrigger」を制作するにあたってのいろいろなお話を伺いつつ、「Webエンジニアが量産品のハードウェアを作るまで」をお聞きしたいと思います。

元々はWebエンジニアが趣味で始めたプロジェクト

白石: 國舛さんは以前はWebエンジニアだったとお聞きしていますが、そんな國舛さんがSmartTriggerを作るようになった経緯と製作過程を教えて下さい。

國舛: はい、元々私はJavaで業務系のアプリを作っているエンジニアだったのですが、数年前にCerevoに転職しました。この会社では、最初はPythonでサーバサイドのプログラミングを担当していて、そこからiOSのアプリエンジニアにシフトしていきました。

SmartTriggerについては、最初は趣味でやっていたんです。テレビを見ていたら「タイムラプス」という表現方法があることを知り、それをキレイに撮れるようなデバイスはないかと探していました。

でもその当時の製品は割と高くてかっこよくなかったんです。買おうかどうか迷って、ネットで情報を収集しているうちに、「どうやら自分でもプロトタイプなら作れるんじゃないか」と思うようになりまして。同じようなものを作っている方の情報を参考にしながら、同じようにやったらとりあえずできた。

でもそこで自己満足してしまって、その後はしばらくほっといてたんですよ。その後会社でアイデアを出す場があったので、そこでこのアイデアを提案したことが、仕事になったきっかけですね。

白石: なるほど、会社の仕事とも関係なく、純粋に個人的なプロジェクトとして始められたんですね。

國舛: そうなんです。全然仕事にするつもりはなかった。

白石: ちなみに結論を先取りしてしまうと、結局これが量産ハードウェアづくりにつながるわけですが、その時点で量産ハードウェア開発の知識とかはあったんですか？

國舛: いえいえ、それが全然…。周りに助けられながら、なんとかやり遂げた感じです。

白石: それはソフトウェアしか触ったことのないぼくのようなエンジニアからすると、朗報です。いい仲間さえいれば、なんとかなるもんなんですね！

まずはプロトタイピング

白石: では、SmartTrigger開発がどのように進んだのかをお聞かせください。最初のプロトタイプってどんな感じだったんですか？

國舛: 最初はAndroidとArduino、あとカメラを全部有線でつないだようなものでしたね。ネットの情報を見ながら、「Androidで操作したらカメラのシャッターが切れる」というところまで作りました。 プロトタイプは3つくらい作りましたね。

まず最初のプロトタイプは、そもそものコンセプトが実現できるかどうかを、形や大きさを気にせず試してみました。

SmartTrigger最初のプロトタイプ

SmartTrigger2番目のプロトタイプ

SmartTrigger3番目のプロトタイプ

量産に至る過程

白石: ちょっとそこ、詳しくお聞きしてもいいですか？Arduinoとかを使ったプロトタイピングまではまだイメージできるんですが、そこから最終製品を量産するというところまでのイメージがさっぱりわかなくて…

國舛: ぼくの場合はまず、リリース時期を決めてしまいます。例えばクリスマス商戦に間に合わせるぞ、とかですね。そこから逆算して、各工程にかけられる時間を見積もります。

そうして今度は、量産を前提とした試作を行っていきます。試作は毎回、明確な目標を定めて行うようにします。

まず必要なのは基板の設計と製品のデザインですね。それぞれ専門の方に担当していただき、まずは荒くてもいいから動くものを作ります。で、ここでトラブルがたくさん起きる。

それを受けて次の試作では、1度目の試作で出たトラブルに対処しつつ、信頼性の検証を行いました。 例えば静電気が発生しても壊れないとか、ボタンを何回押しても壊れないとか。

こんな感じで、次に何をやるかをイメージしながら、どんどん試作を改良していくイメージです。

白石: デザインはどんどん変化していくんですか？

國舛: いえ、デザインは最初のほうでしっかり固めなくてはなりません。ハードウェアは、デザイン修正のコストが大きいので。そこがWebとは大きく違うところですね。 でも最近は3Dプリンタで簡単に出力できるのがありがたいです。基板が入るかどうかとか、ボタンが押せるかどうかとか、そういったことを確認するためには3Dプリンタで作った試作品がとても役に立ちます。

白石: なるほど。そして、何度か試作を行って完成度を高めたら、いよいよ量産に向けて動き始めるんですよね。

國舛: はい、そうですね。量産するにあたっては、部品を購入したり、工場を決めたりということが必要になってきます。
部品も、物によっては中々入手できなかったりするので、どこからどうやって調達するかを考えなくてはなりません。ぼくらは中国の工場を使ったのですが、部品を現地で調達したほうがいいのか、こちら（日本）で入手したり作ったりしてから送ったほうがいいのかとか、いろいろとトレードオフがあります。

また工場を決定するにあたっては、実際に現地の工場に足を運んで、設備や品質管理のレベルを確認します。スタッフの熟練度は非常に重要で、実際にサンプルを作ってもらって、クオリティを確認する必要があります。 そうして選んだ基板工場や金型工場、組み立て工場に3Dデータや回路図を渡し、量産を依頼するわけです。

白石: 工場に量産をお願いしたら、あとはスムーズに製品ができ上がるんですか？

國舛: それが理想なんですが、実際にはよくトラブルが起きてしまうんですよね。 あらかじめテスト項目を用意しておくんですが、テストにパスしないものが多く出てくると「不良率が高い」ということになって、なかなか出荷したい台数に届かないということになります。

量産するにあたっては、「量産試作」という工程があって、実際の工員さんを使って量産ラインを流してみます。 例えばそこで100台とか、多めの数を流して検証してみて、組立方法を変更して時間を短縮したり、製品に不具合がないかどうかを検証して調整します。 そうして問題が出なくなったら、あとはどばっと流すかんじですね。

ハードウェア開発の体制と工程

白石: 量産に至るまでの流れが、少しイメージできるようになりました。これも聞きたいんですが、ハードウェアを作るとなると、実際にはどういうスキルを持った人が必要になるんでしょうか？

國舛: 大きく分けると4つくらいの職種が共同で作業に当たる感じですね。

まずは電気設計。基板づくりを担当します。

デザイナー。製品の見た目はもちろん、ボタンの押し心地などの機構も考えます。他にはパッケージや製品アクセサリのデザインもするし、場合によってはWebサイトのデザインも行ったりします。

組み込みエンジニア。ハードウェアに搭載する組み込みのソフトウェアを担当します。

そして一般的なアプリエンジニアです。

他にもサーバインフラのエンジニアやプロジェクトマネージャーなどもいたりしますが、基本的には先程申し上げた4つの職種がメインになります。

白石: あと、工程や期間についても、少し具体的に教えていただけますか？

國舛: 原理試作、EVT、DVT、そして量産と言った流れですね。

量産型ハードウェア開発プロセス（一例）

「とにかく作ってみる！」それが大事！

白石: ではそろそろインタビューを終えたいと思いますが、これまでソフトウェア開発しかしたことがないエンジニアに向けて、一言いただけますでしょうか？

國舛: 「とにかく作ってみる」それが重要ですね。最近は3Dプリンタもあるし、マイコンも流行っているので、ハードウェアを触るのもずいぶん敷居が下がりました。エンジニアは、どうしても「小さく」「カッコよく」を目指してしまいがちなんですが、最初はそんなのどうでもいい。とにかくやってみることが重要です。あとは、最近はイベントとかもよくやっているので、そういうのにも参加してみてはいかがでしょうか。

白石: 本日は、実際にハードウェア製品をリリースするまでの過程を詳しくお話いただき、ありがとうございました！とてもためになりました。

ちなみに、國舛さんが「ハードウェアスタートアップでアプリエンジニアは何をしているか」というテーマでブログを書かれています。こちらも合わせてお読みいただくと、より理解が深まると思います！

• ハードウェアスタートアップでアプリエンジニアは何をしているか | Cerevo TechBlog