この記事について
この記事の対象読者
- これからIOTの仕事に取り組まれる方。
- 既にエッジまたはクラウドの仕事をしているが相手側の文化を知らない方。
この記事から得られること
- 相互理解が深まり、あなたのプロジェクトにプラスの影響を与える。
あらまし
IOTはエッジの世界とクラウドの世界の２つの異文化が交わる領域である。２つの世界は文化が大きく異なるために、しばしば合意形成が難航することがあります。それぞれの文化の特徴対比を以下にまとめます。
クライアント側（機器側）の文化
ウォーターフォール
開発は工程ごとにきっちり区切られて責任範囲を明確にして進められる。すなわち、V字工程の物づくりが徹底され、要件定義 ⇨ 仕様書作成 ⇨ アーキテクチャ設計 ⇨ ソフト仕様書 ⇨ 単体テスト ⇨ 結合テスト ⇨ … と進められる。電子部品はISO26262に従った開発をするところも多く、ドキュメント作成のボリュームも多い。
垂直統合型
情報格差を作ってリーダがコントロール。情報共有は共有範囲を限定してコントロールされる。よって、ナレッジマネジメントツールを使われることは少なく、exelファイルでQ&Aを２社間でやり取りする。効率よりも規律が重視されるので、サーバー側（IT業界側）から見ると、凄く効率の悪いやり方をしてるように見えるときもある。
品質未然防止
OTA(Over the Air)が実装されていない機器の場合は、不具合があった場合には、市場品を回収してソフト書き換えを実施することになり、場合によっては開発費以上の不具合対応費が発生することすらある。このことから、市場投入前に徹底的に品質の未然防止をするという考え方がベースにあり、曖昧さを含む仕様書や、抜け漏れの多いテスト計画書などは、忌み嫌われる。
仕様変更は罪（＝追加費用）
OTAが無かった時代の名残で、開発費を合意した段階から仕様を変更すると、追加費用を請求される文化がある。ベンダは仕様FIXを急かし、要求元は仕様FIXをぎりぎりまで後ろに引っ張る。IT業界のノリが通じないのはこの部分で、POCフェーズを設けずに量産開発をGOしてしまうと、開発日程で不都合が生じやすい。
成熟産業の人が多い（井の中の蛙かも？）
電子機器（通信機）を開発するベンダの担当者は、IT業界と比べて、同じ専門分野を継続されたキャリアの人が多い。ハード設計者（電子回路設計者）とソフト設計者（プログラマ）できっちり担当が分かれていて、両方できる人は少ない印象がある。
サーバー側（クラウド側）の文化
アジャイル開発
ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称。ウォーターフォールの人にわかりやすく説明するなら、いくつかの工程をオーバーラップさせながら同時並行的に進める開発スタイル。上流工程の仕様FIXをまたずに分かっている範囲のことは開発を進めてしまい、下流工程から上流工程への問題提起（仕様提案）のようなことをする。下流（プログラマ）のほうがIT技術をよく理解してるケースが多いといった背景もある。
水平分業型
Redmineや、Backlogといったナレッジ共有ツールを使って全関係者が必要な情報を共有して、水平分業体制で進める。効率はいいが、実務推進においてはリーダーの影響力は弱まる。一方、メンバがオーバーフロー気味のときには課題形成が他責になりがちなので、プロジェクトのQCDに責任を追うプロマネがしっかり課題形成することが重要。
DevOps
開発 (Development) と運用 (Operations) を組み合わせた造語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。 スケール性能など非機能要件の細かいパラメータなどは、運用しながら決めていく。
DRYの法則
Don’t Repeat Yourselfの略で「同じことを繰り返すな」というIT業界の教訓。もともとはソフトウェア開発における重複を避ける意味の言葉で、ソフトウェア、DBスキーマ、テスト、ビルドシステム、ドキュメントなどを対象に、「ソフトウェア開発全体において情報を重複させない」という意味。転じて、進歩が早いIT技術分野で同じ仕事ばかりしてると時代遅れになるといった意味でも使われる。
エッジ側とサーバー側の両者が知っておくべき共通知識（2WAY認証）
たくさんのクライアントとセキュアに通信するクラウドセンターを構築しようとする場合、スケール性能とセキュアの確保が重要になります。そういうIOT分野共通のニーズに応える形で登場したフルマネージド型サービスがAWSのクラウドサービスがAWS_IOT_COREです。
（AWSサイトより引用）
AWS_IOT_CORE
AWS IoT Core は、インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージド型クラウドサービスです。AWS IoT Core では数十億個のデバイスと数兆件のメッセージをサポートしており、それらのメッセージを AWS エンドポイントや他のデバイスに確実かつセキュアに処理してルーティングします。AWS IoT Core を使用すれば、アプリケーションがインターネットに接続されていない場合でも、すべてのデバイスを常に追跡して通信できます
AWSより
MQTT
スケール性能を確保するためには、通信電文サイズを小さくしたい。このためhttpsよりも、通常はMQTTが選択される。MQTTは通信品質をQOSで指定することが可能。QOS=0なら送りっぱなし、QOS=1なら確実に１回送信完了するまではリトライする。
２WAY認証
サーバーとクライアントで相互認証する機能がIOT_COREには実装されている。サーバーがクライアントにサーバー証明書を渡し、クライアント側でその著名が自分が知っているルートが著名しているかをチェックする。クライアントはクライアント証明書をサーバーにわたし、サーバー側でクライアント証明書をチェックする。この2WAY認証なお、AWS_IOT_COREでは、カスタム認証をサポートしているが、非推奨。理由は、カスタム認証用の処理をlambdaなどAWS_IOT_CORE外部に処理させる必要があるが、この方法ではせっかくのAWS_IOT_COREのスケール性能の恩恵を受けれないためである。
GreenGrass
AWS技術になれた人が、エッジ（デバイス）側まで迎えにいくことをやりやすくするためのモジュールで、エッジ側のMQTT通信などを可能にする。LinuxベースのOS上で動作する。組み込みの世界でいう割り込み関数が、Lamnbda関数として表現される。COREとGreenGrassの通信ラインを使って、エッジ側のLambda関数をOTAできるのもメリット。エッジ側の会社に、これを実装依頼するとしばしば拒絶反応を示されます。組み込み系の世界とは、テクニカルギャップがあるようだ。
開発をスムーズに進めるために
以上のように、両者のベースとなる文化が異なるために、真逆の価値観をもってたりすることがしばしばある。相手は相手の文化があり、自分たちとは異なるという相互理解の精神が肝要で、お互いに相手の文化へのスキルシフトの精神が必要。一番、鍵になるのは、機器とサーバーとの通信仕様書を作成する実務担当者である。この人は、２つの異なる文化・知識を柔らかく吸収し、QCDを考慮して最適機能配置（機器側とクラウド側のどちらにソフト実装するのか？）を決める重要な役回りです。両方の分野の人が理解できる解説的な補足説明を記載できるとよりベターです。この仕様書の完成度が高ければ、IOT開発は峠を超えることができたと考えていいでしょう。
