コネクテッド製品は、その周辺エンジニアリングが完了するずっと前から、完成品のように見えることがあります。プロトタイプは安定し、データはクラウドに送信され、アプリは正しい値を表示し、最初のデバイス群はすでにユーザーの手に渡っています。その時点では、バックエンドはまだ十分にシンプルなので、チームはほぼすべてのデバイスを個別に把握できます。プロビジョニングはスクリプトで処理でき、構成変更は手動で行うことができ、何らかの障害が発生した場合でも、エンジニアは通常、問題を直接追跡できます。
そして、製品は現実世界での運用を開始しなければなりません。第2世代のハードウェアが登場します。一部の顧客は依然として第1世代の製品を使用しています。ファームウェアのバージョンが分岐し始めます。異なる顧客や市場向けに新しい構成が必要になる一方で、古いデバイスにはアップデートとサポートが引き続き必要となります。
必ずしも何かが壊れているわけではありません。単に、デバイスの背後にあるソフトウェアが独自のライフサイクルを獲得しただけです。
プロトタイプは問題なく動作し続けるため、この移行は見過ごされがちです。しかし、同じ物理製品の複数のバージョンが現場で共存する必要が生じると、バックエンドはもはやハードウェアの背後にある単なるインフラストラクチャではなくなります。それは製品アーキテクチャそのものの一部となるのです。
動作する接続プロトタイプはまだ拡張可能な製品ではない
プロトタイプには重要な役割があります。それは、システムがエンドツーエンドで正しく動作することを証明することです。デバイスはコア機能を実行し、ファームウェアはバックエンドと通信し、テレメトリデータは適切な場所に到達し、コマンドは正しく送信され、モバイルまたはウェブインターフェースを通じてユーザーに機能が提供されます。
しかし、同じシステムが多様性にどれだけうまく対応できるかは、これまで証明されてこなかった。
最初の20台のデバイスはすべて同じファームウェアで動作し、同じハードウェアリビジョンで製造され、同じエンジニアによって構成される可能性があります。この段階では、手動登録、直接的な構成変更、または簡単なオンボーディングスクリプトで十分対応できます。製品の性能が実証される前に、本番環境向けのツールを構築するのは時期尚早かもしれません。
規模が大きくなると、問題も変わってきます。デバイスはオフライン状態になったり、交換されたり、異なるファームウェアが動作したり、顧客ごとに異なる設定が必要になったりします。サポート担当者は、正しくプロビジョニングされなかったユニットと、設定ミスや単にアクセス不能なユニットを区別しなければなりません。
プロトタイプの負債は、多くの場合、悪い決定から始まるのではなく、製品が次の段階に進んだ後も残ってしまう一時的な決定から始まる。そして、その移行を意識させる最初の要因の一つが、ハードウェアそのものである。新しいバージョンは単に古いバージョンを置き換えるのではなく、古いバージョンと共存しなければならないのだ。
ハードウェアの改訂ごとに、ソフトウェアライフサイクルの問題が発生する
新しいハードウェア改訂版が、古いバージョンを完全に置き換える形で登場することは稀です。実際には、両方のバージョンが現場で使用され続け、場合によっては何年も使われ続けることもあります。移行バッチ、いくつかのファームウェアブランチ、そして顧客固有の構成が加わると、製品群は当初の製品モデルが示唆するよりもはるかに多様化していきます。
ソフトウェア層は、もはやすべてのユニットを抽象的な「デバイス」として扱うことはできない。個々のユニットがどのような機能を備えているかを把握する必要がある。
改訂版基板では、異なるセンサー、通信モジュール、またはコントローラーが使用される場合があります。最新バージョンで有効なコマンドが、以前のバージョンではサポートされていない場合があります。キャリブレーション値が変更される場合があります。構成制限が変更される場合があります。ある世代に適したファームウェアパッケージが、別の世代では安全でない場合があります。
物理製品のエンジニアは既にこのような方法で作業しています。見た目がほとんど同じ2つの部品でも、改訂版、公差、仕様が異なれば互換性はありません。コネクテッド製品もソフトウェア側で同様の問題を抱えています。プラットフォームは、どのバージョンの物理製品と通信しているのか、そしてその製品にどのようなルールが適用されるのかを確実に把握する方法を必要とします。
最初の改訂版ではある校正手順が用いられ、2番目の改訂版では新しいセンサーと異なるパラメータセットが導入された製品を考えてみましょう。顧客にとっては、どちらの製品も同じ製品に見えるかもしれません。しかし、プラットフォームにとっては、それらは同じ製品とはみなされません。
これらの違いが明示的に表現されていない場合、特殊ケースとしてアプリケーションロジックに漏れ出す傾向があります。あるワークフローではシリアル番号の範囲をチェックし、別のワークフローではファームウェアバージョンをハードウェア世代の代理として使用します。また別のワークフローでは、サポート担当者が古いバッチが現場で異なる動作をすることを発見した後に例外を追加しました。これらの修正はどれも単独では特に危険に見えませんが、これらが組み合わさると、今後のあらゆる変更の理解が難しくなります。
古いハードウェアが予定通りに姿を消すことは稀です。製品開発チームは当然ながら最新のリビジョンに注力しますが、顧客は以前のバージョンを予想以上に長く使い続けることがよくあります。そのため、プラットフォームは、既存の製品群が単一の最新バージョンに収束することを前提とするのではなく、複数の世代を同時にサポートする必要があります。
そうなると、ハードウェアの進化とソフトウェアのライフサイクル管理は切り離せないものとなる。プラットフォームは、デバイスがどこにあるのか、オンラインなのかどうかだけでなく、デバイスの種類、実行可能なソフトウェア、適切な設定方法、そして適用しても安全な変更点を把握する必要がある。
そして、これらの疑問に確実に答えるためには、各デバイスが一貫した方法でシステムに登録される必要がある。
プロビジョニングは、手動エンジニアリングがスケーリングを停止する地点です。
機器の台数が少ない場合、プロビジョニングは簡単そうに見えます。機器レコードを作成し、シリアル番号を入力し、認証情報を生成し、機器を顧客に割り当て、構成を適用して、次に進むだけです。数十台の機器であれば、これらの作業の一部を手動で行うのが依然として適切な選択肢となるでしょう。
しかし、生産規模においては、プロビジョニングはデバイスの識別情報、認証情報、所有権、構成、ライフサイクル状態が交錯する領域に位置します。導入時にミスが発生すると、製品が工場出荷後も長期間にわたって運用やサポートに影響を及ぼします。
スプレッドシートの内容が、実際にインストールされているものと一致しない場合があります。交換用デバイスには、誤ったIDを引き継ぐことなく、正しい顧客関連付けが必要です。工場出荷時設定へのリセットは、プロセスにおける別の経路を作り出します。インストーラーがユニットを誤ったアカウントに割り当ててしまうと、サポート担当者が、そのユニットがオフラインなのか、プロビジョニングが間違っているのか、あるいは単に構成が間違っているのかを判断する必要が生じます。
これらの質問に答えるために、開発者がデータベースを検査したり、内部スクリプトを実行したりする必要が日常的に発生するようになった時点で、そのプロセスは製品の成長に合わせて拡張できなくなっている。
重複もまた、警戒すべき兆候の一つです。各製品バリエーションごとに、独自のオンボーディングスクリプト、構成ツール、またはインストーラーワークフローが採用され始めます。これらの違いは些細なものに見えるかもしれませんが、根本的な責任は同じです。プロビジョニングは、特定のデバイスに付随するセットアップタスクではなく、再利用可能なプラットフォームインフラストラクチャへと変化しています。
そして、再利用可能にする必要がある機能は、それだけではないことがほとんどだ。
プラットフォーム層は再利用可能なインフラストラクチャになるべきである
複数の製品やハードウェアのリビジョンで基本的なニーズが共通化すると、一部のソフトウェア機能は製品固有のものではなくなります。デバイス識別、プロビジョニング、接続性、テレメトリ、ファームウェア配信、ライフサイクル状態、フリート可視化、診断などが良い例です。これらの機能を新しいバリアントごとに再構築すると、保守すべきコードと運用パスが増えるだけで、製品自体の独自性は向上しません。
チームが意図的にこのような重複を生み出すことは稀である。各製品に関して小さな違いが積み重なり、最終的には同じエンジニアリング責任を担う複数の実装を維持することになる。
より明確な境界線は、製品層とプラットフォーム層を分離することです。製品層には、特定のデバイスの価値を高める動作、ワークフロー、インターフェース、統合、およびドメインロジックが含まれます。プラットフォーム層は、ハードウェアが変更されても一貫性を保つべきメカニズムを処理します。
コネクテッド製品が最初のリリースを過ぎると、デバイスのプロビジョニング、デバイスのライフサイクル管理、フリート管理、およびサポートツールは、個別のプロジェクトの詳細ではなく、共有インフラストラクチャになります。企業向けのIoT PaaSは、複数の製品または製品バリエーションにわたって再利用可能なプラットフォームレイヤーを提供し、再利用可能な構成要素を通じて標準的なデバイスおよびデータ管理を処理することで、エンジニアリングチームがハードウェア、ワークフロー、およびユーザーエクスペリエンスに集中してカスタム開発に取り組むことを可能にします。
共通の基盤であっても、実際の製品の違いに対応できる余地を残しておく必要があります。新しいデバイスには、異なるデータモデル、構成フロー、統合、または制御ロジックが必要になる場合があり、それらの違いは容易に導入できるものでなければなりません。目標は、あらゆる違いが別のデバイスレジストリ、テレメトリパイプライン、プロビジョニングメカニズム、またはフリート管理ツールセットにまで影響を及ぼすことを避けることです。
プラットフォームは、チームが最初の製品を開発している間はオーバーヘッドのように見えるかもしれませんが、2つ目、3つ目の製品を開発する頃には資産のように感じられるでしょう。共通の運用メカニズムが確立されれば、新しいバージョンは既に機能している基盤を引き継ぐことができ、チームが製品のライフサイクル全体にわたって維持管理しなければならない別のバックエンドを持ち込む必要がなくなります。
製品が実際に異なる部分については、カスタムエンジニアリングを維持する
再利用可能なプラットフォームは、接続製品をより汎用的なものにするべきではない。その役割は、差別化につながらない部分から、重複した設計作業を排除することにある。
デバイスの動作、ドメイン固有のロジック、ワークフロー、ユーザーエクスペリエンス、特殊な統合、そして特定の製品が物理世界とどのように相互作用するかといった点において、カスタマイズの取り組みは依然として重要です。これらの領域こそ、エンジニアリング上の選択によって、ある製品が他の製品よりも明らかに優れていると言える部分なのです。
同じ扱いを受けることがほとんどないのが、周囲の運用インフラです。同じ機械の基本バージョンと産業用バージョンでは、異なるセンサー、制御装置、インターフェースが必要になるかもしれませんが、デバイスの識別、ファームウェアバージョンの追跡、フリートの管理に別々の方法を必要とするべきではありません。
エンジニアには、チームが既に別の製品のために構築している仕組みを再構築するよりも、現場での製品の動作を改良することに時間を費やしてほしい。共有基盤はカスタムエンジニアリングの範囲を狭めるものではなく、むしろその労力がインフラストラクチャに費やされるのを防ぐものだ。
本当の試練は、チームが2つ目の製品の開発に着手したときに訪れる。
優れたプラットフォームがあれば、次の製品開発は最初の製品開発よりも容易になる。
製品2が製品1とほぼ同じプラットフォーム作業を必要とする場合、実際に再利用されている部分はごくわずかである。
新しいバリアントは、運用モデルの中で変更されていない部分（プロビジョニングフロー、ID管理、ライフサイクルメカニズム、フリートツール、ファームウェアプロセス、サポートの可視性、共通統合など）を継承できる必要があります。そして、エンジニアリングの労力は、基盤を再構築するのではなく、新しいセンサーパッケージ、別の制御ワークフロー、顧客固有の統合といった、相違点に集中することになります。
新しいハードウェア世代が登場すると、同じコンセプトに対するプレッシャーはさらに高まります。旧世代の製品が現場で稼働し続ける一方で、新世代のハードウェアの機能は大幅に変化する可能性があります。成熟したプラットフォームであれば、顧客が依然として一つの製品ファミリーと認識している製品に対して、開発チームが二つの異なるプラットフォームスタックを維持する必要なく、両方をサポートできます。
これらすべては、単一の巨大なバックエンドを必要とするものではありません。異なる製品であっても、明確なアーキテクチャ上の境界が必要となる場合があります。重要なのは、正当な理由なく、同じエンジニアリング責任を二度も担うことを避けることです。
こうなると、プラットフォームは蓄積されたオーバーヘッドではなく、資産へと変わります。サポート担当者が理解すべきツールが減り、リリースはより一貫した流れで行われ、新たな製品の追加は、企業が永久に引き継ぐことになる別のバックエンドではなく、管理された拡張機能となります。
プラットフォームを製品アーキテクチャの一部として扱う
物理的な製品は、改訂、保守性、製造性、そして将来の変更を念頭に置いて設計されます。コネクテッド製品も、ソフトウェア面において同様の規律が求められます。
最初のバックエンドは一時的なものでも構いません。最初のプロビジョニングスクリプトやサポートツールも同様です。それ自体に本質的な問題はありません。問題となるのは、製品自体が進化し続ける中で、そうした一時的な仕組みがいつの間にか恒久的なアーキテクチャになってしまう場合です。
その段階になると、コネクテッド製品はもはやハードウェア、ファームウェア、アプリだけにとどまらなくなります。各デバイスを識別し、その機能を理解し、適切な構成を適用し、アップデートをサポートし、出荷後何年も経ってからでもチームが問題を診断できるよう支援するインフラストラクチャにも依存するようになります。
その層を製品アーキテクチャとして扱うようになると、区分がより明確になる。標準的な仕組みは再利用可能なままで、カスタム作業は実際に製品や製品ファミリーを区別する部分に費やされる。
最も強力なプラットフォームとは、単に最初のコネクテッド製品を実現できるプラットフォームではない。エンジニアリングチームが、毎回新しいバックエンドを引き継ぐことなく、2番目、3番目、4番目の製品を構築できるプラットフォームこそが、真に強力なプラットフォームなのだ。
