ソラコムの須田です。プロフェッショナルサービスとして、お客様のソラコムサービス導入を支援しています。
IoT活用を始める際、「何から着手し、どう進めるべきか」というご相談をよくいただきます。この種の具体的な情報は、まだ世の中に少ないのが現状です。これまで、様々な規模や業種のプロジェクトで、量産を伴うケースも含めてご支援させていただきました。その経験に基づき、実際に私がこれまでご支援を通して経験したきた内容をもとにIoTプロジェクトが実際にどのように進行するのかをまとめました。
はじめに ～ 対象読者
なぜこの記事を書くのか
IoTプロジェクトは、その性質上、多岐にわたる技術要素とステークホルダーが関与するため、全体像の把握が難しく感じるかもしれません。そのため、漠然としたアイデアはあっても、それを具体的なシステムに落とし込み、価値を生み出すまでの道のりは複雑で、多くの企業がこの初期段階で立ち往生してしまうケースが少なくありません。
実際のIoTプロジェクトはどのように始まっていくのかを擬似体験できれば具体的なイメージを持って進められるのではないか、そういう思いから本記事を書きました。
前提
本記事はIoTプロジェクトの一連の流れを把握していただくことを目的としています。そのため、一つ一つの詳細は参考情報も含めてご参照ください。
対象読者
この記事は、以下のような方々を対象としています。
| 対象読者 | 状況・ニーズ |
|---|---|
| プロジェクトマネージャー／事業責任者 | IoTプロジェクトの企画や推進を担当している方 |
| IoTプロジェクト初心者 | これからIoTプロジェクトを始めようとしているが、具体的な進め方がわからず不安を感じている方 |
| IoTプロジェクト推進中の方 | すでにIoTプロジェクトを進めているが、次のフェーズに進む際の判断基準や注意点を整理したい方 |
| エンジニア | プロジェクト全体の中での自分の役割を理解したい方 |
IoTプロジェクトの代表的なパターン
業務改善型
自社の既存の業務をIoTで効率化するケースです。例としては現地に赴く必要があった業務をリモートからできるようにしたり、これまで確認できていなかったものをデータで可視化できるようにしたりといった取り組みがあたります。
例: カメラ活用で売場をデジタル化、値引きや廃棄を削減し売上向上を実現
新規ビジネス型
新規ビジネスでIoTを活用するケースです。通信機能を搭載した製品開発や、業務改善型で自社で取り組んだものを外販するような場合などがあたります。新規ビジネス型では自社でデバイスを開発するケースも多く、その場合は量産を見据えた進め方が求められます。
例: IoTで店舗端末に新コンテンツを配信、ユーザー体験を拡張
デバイス調達アプローチ
既製品の活用
目的に応じた既製品のデバイスを利用するアプローチです。市場には既に多くの多様なデバイスがあり、ほとんどのニーズを満たすことができます。さらに、デバイスとセットでSaaSを提供する商品も多く、ゼロからシステムを開発する手間も抑えられることが多いです。また評価段階では、まずは既製品を利用することで自分達のニーズを検証したり明らかにするといった用途でも活用できます。このように既製品を活用することで、素早く導入・評価・展開ができます。既製品デバイスだけで要求が満たせない場合、運用そのものを見直す、既製品の部分的なカスタムをメーカーに依頼できないかを相談する、足りない機能をクラウド側の開発で補えないかを検討します。
自社開発・量産
既製品ではどうしても要件を満たせない場合や、デバイスそのものが新規ビジネスが価値となるケースでは自社開発を選択します。自社で量産できない場合、デバイス開発パートナーに参画してもらいます。デバイスの要求仕様をまとめたり、クラウド側とのインタフェースとなる仕様や設計をシステム開発担当も交えて詰めたりと求められる役割は多岐に渡ります。また、デバイスの量産は規模の経済が大きく働くので、生産台数が少数の場合は高額になる傾向があります。そのため、中大規模の台数展開が前提となることが多く、小規模展開の場合は既製品をベースにした個別カスタムやデバイス開発パートナーが過去に開発したデバイスをベースにしてもらい価格を抑えるなどの検討が必要になることがあります。
後付けIoT / 組み込みIoTという観点
また、IoT導入の方式としては、次の2つのアプローチがあります。
| 方式 | 概要 | メリット | 主な用途 |
|---|---|---|---|
| 後付けIoT | 既存設備・機器にセンサーや通信機能を取り付ける | 既存資産を活用できる / スピーディに開始できる | 工場・物流・店舗などの業務改善型 |
| 組み込みIoT | 製品そのものに通信や制御機能を組み込む | 体験の作り込み / サブスク等の新ビジネス展開 | コネクテッド製品・IoTサービス型ビジネス |
はじめは後付けIoTでスピーディに検証し、価値が確認できた段階で組み込みIoTへ発展させるなど、段階的に進めるケースも多く見られます。
💡プロジェクトマネジメント視点でのチェックポイント
- 自社の取り組みは業務改善型か新規ビジネス型か、そのパターンに応じた進め方を選択できているか
- まずは既製品で実現できないか、既製品+クラウド側開発や部分カスタムで要件を満たせないか検討したか
- 後付けIoTか、組み込みIoTかのアプローチを事業目的に応じて選定できているか
- 自社開発・量産を選択する場合、想定展開台数でのコストは事業として成立するか試算できているか
- 自社開発を選択する場合、デバイス開発から量産までをデリバリーできる体制・ケイパビリティがあるか
- デバイスのリードタイムはプロジェクトの展開スケジュールと整合しているか
- 小規模展開の場合、既製品ベースのカスタムや既存デザインの流用でコストを抑える選択肢を検討したか
📝参考
ソラコムではSORACOMサービスの動作確認をしているSORACOM認定デバイスを取り扱っています。
後付けIoT / 組み込みIoTの詳細についてはこちらの記事をご参照ください。
プロジェクト全体像
プロジェクトの流れ
IoTプロジェクトは、大きく以下のフェーズに分けることができます。
| フェーズ | 主な活動内容 | 重要なポイント |
|---|---|---|
| 企画 | ・プロジェクトの目的と課題を明確化・仮説を立てる・ステークホルダーを把握する | どのようなビジネス価値を生み出すのか、誰のどんな課題を解決するのかを定義する重要な段階。このフェーズで方向性を誤ると、後続のすべてのフェーズに影響が出るため、十分な時間をかけて検討が必要。 |
| PoC | ・企画で立てた仮説を技術的に検証・既製品デバイスや簡易プロトタイプを使用・最小限のシステムで実現可能性を確認 | 「本当にできるのか」「期待した効果が得られるのか」を確認。 |
| システム設計・開発 | ・詳細な要件定義・デバイスとクラウドのインターフェース仕様確定・本番システムの設計・開発・パートナー選定と体制構築 | PoCで検証した内容をもとに、本番運用に耐えるシステムを構築。デバイス開発とクラウド開発を並行して進め、統合テストで動作を確認。品質計画と開発プロセスを確立。 |
| デバイス量産 | ・試作機による動作検証・量産メーカーとの調整・受入検品手順の整理・保管場所の確保・出荷〜受入のフロー整備 | 試作機と量産品では品質や仕様が異なる可能性があるため、事前の検証が重要。物流・保管・検品体制を整備し、量産前に仕様を確定させる。 |
| 本格展開・運用開始 | ・フィールドへの段階的な展開・現場での設置・設定作業・ユーザートレーニング・システムの監視体制構築・インシデント対応フローの確立・運用データの収集と分析・継続的な改善活動 | 運用開始後は、想定外のトラブルに迅速に対応できる体制を整備。デバイスのライフサイクル管理と、クラウドシステムの継続的な改善が長期的に必要。 |
これらのフェーズは必ずしも一方向に進むわけではなく、各フェーズでの学びをもとに前のフェーズに戻って再検討することもあります。特にPoCや試験導入では、期待した結果が得られない場合、企画に戻って仮説を見直すことも珍しくありません。
体制と役割
IoTプロジェクトを成功させるためには、適切な体制と明確な役割分担が不可欠です。代表的な体制とそれぞれの役割を以下の表にまとめます。
| 役割 | 主な責任 | 必要なスキル・経験 |
|---|---|---|
| プロジェクトリーダー | プロジェクト全体の推進、意思決定、ステークホルダー調整、予算・スケジュール管理 | プロジェクトマネジメント、ビジネス理解、コミュニケーション能力、IoTプロジェクトの経験 |
| プロジェクトメンバー | 各フェーズのタスク実行、要件整理、パートナー調整、ドキュメント作成 | 特定領域の専門知識、関係者との調整力、ドキュメンテーション能力 |
| デバイス担当者 | デバイスの選定・調達・開発、デバイス側の仕様策定、品質管理、量産対応 | ハードウェア知識、組込み開発経験、通信技術、量産プロセス理解 |
| クラウド開発担当者 | システム設計・開発、API設計、データ基盤構築、セキュリティ実装、運用設計 | クラウドアーキテクチャ、バックエンド開発、データベース設計、セキュリティ知識 |
| 現場担当者 | 実際の運用、デバイス設置・管理、現場からのフィードバック、業務オペレーション | 業務知識、現場対応力、ITリテラシー |
プロジェクトの規模や性質によっては、一人が複数の役割を兼任することもあります。特に初期フェーズでは少人数で始まることも多く、柔軟な体制を取ることが一般的です。重要なのは、誰がどの責任を持つのかを明確にし、必要なスキルセットが揃っているかを確認することです。
また、専門的な知識や技術が求められる場合、外部パートナーとして、デバイス開発パートナー、システム開発パートナーが参画することも多くあります。
プロジェクトマネジメント視点でのチェックポイント
- 各フェーズの主要活動と必要なスキルセットは把握できており、自社で実行可能か外部パートナーが必要か判断できているか
- 協力が必要になりそうな社内・社外のステークホルダーは整理し特定できているか
- フェーズ間で戻って再検討する可能性を考慮し、スケジュールにバッファや意思決定のチェックポイントを設けているか
企画フェーズ
課題と仮説の作成
IoTプロジェクトではHOWから始まってしまうケースを散見します。IoTでXXができないか、もIoTそのものが手段であるためHOWから始まってしまっている代表的な例です。誰の(WHO)どんな課題(WHAT)をなぜ(WHY)解決する必要があるのか、どんなユーザー体験を届けたいのか、といった課題設定や価値の仮説から始めてください。そのためのソリューションとして本当にIoTである必要があるのかを考えることが重要です。これがないと、この後PoCをやっても、あくまで技術的にできた・できないの評価しかできず、取り組みそのものの有用性を評価できません。
必要なデータの整理
どういったデータがあれば目的を達成できそうか、そのデータは既にあるが収集できていないのか、そもそもデータを取得するところから始める必要があるのか、データの取得先があるのかを整理します。後続のPoCで詳細を確認することになりますが、PoCの中で闇雲に試すのは非効率です。また、取得したデータの特性によっては、個人情報にあたるため特別な配慮が必要になったり、セキュリティの観点でデータの取得がそもそも難しい、あるいは部分的になってしまうといったことがあります。こうしたリスクを前もって検討するためにも、どういったデータが必要なのかは企画段階でもある程度整理をしておく必要があります。
成果指標
業務改善型、新規ビジネス型ともにその取り組みによってどれだけのビジネスインパクトがあるかの整理です。特に業務改善型や、新規ビジネス型でデバイスの実際の導入・設置・運用が自社で発生するケースにおいては、得られる改善効果に対してどれだけの人による稼働が発生するかは意外と見落とされがちです。例えば導入の度に多大な現場での協力作業が必要となり、得られる効果よりも手間の方が大きくなってしまうであったり、設置の度に現場でのセンサーの調整が必要で手順を標準化できないなど、こうした要因は導入のコストが高くなるだけでなく、うまくいっても他拠点や他顧客に展開がしにくいといったスケール可能性に課題が出がちです。こうした人の稼働といった直接価格に見えにくいコストも加味した成果指標の有用性を検討する必要があります。
セキュリティ・法令の初期確認
検討している取り組みのセキュリティや法令的な観点での考慮事項はないかは企画段階から整理します。必要なデータの整理でも触れたように、取得したいデータへの考慮だけではなく、グローバル展開する場合は、その国における法令への対応や、デバイスをその国で利用するために必要な認証を調査する必要があります。また、例えば他社の回線を利用して通信サービスを提供するビジネスを始める場合には電気通信事業の届出や登録が必要になるケースがあったりと、取り組む内容によって考慮事項も様々です。多くの場合、専門家を交えながら進めていきます。
💡プロジェクトマネジメント視点でのチェックポイント
- WHO（誰の）、WHAT（どんな課題）、WHY（なぜ解決する必要があるか）が明確に定義され、HOW（IoT）はその手段として適切か検証できているか
- 取り組みのビジネス価値と成果指標が検討できており、ステークホルダーに説明できる状態になっているか
- 必要なデータの取得元、取得方法、個人情報やセキュリティ上の制約は企画段階で整理できているか
- 現場での作業負荷や運用コストを含めた総合的な成果指標で事業性を評価できているか
- 考慮すべき法令、認証要件、社内ポリシーは専門家を交えて確認できているか
📝参考
IoTを活用した取り組みの検討にあたっては弊社ではワークショップでのご支援もご提供しております。
PoC
PoCのレベル
PoCには確認したい目的や得たい評価によってレベルがあります。
| レベル | アプローチ | 目的・特徴 |
|---|---|---|
| L0 | ヒアリング／価値検証インタビュー | 仮説の価値を検証する最も軽量な方法。技術的な実装なしで、ユーザーのニーズや課題を探索。 |
| L1 | 紙／ペーパープロトタイプ | 実装せずにコンセプトを可視化。ユーザー体験やUIの基本的な流れを検証。 |
| L2 | 中身は手作業でも体験を検証 | システムが自動化されているように見せかけて、裏側は人が手作業で対応。ユーザー体験の検証に集中。 |
| L3 | 既製品＋最小クラウドで動作確認 | 実際のデバイスとシステムを使った技術検証。最小限の機能で動作の実現可能性を確認。 |
| L4 | 限定現場で小さく運用 | 実際の現場環境で小規模に運用。技術面だけでなく、運用面・ビジネス面も含めた総合的な検証。 |
L3からPoCを開始しようとするプロジェクトが多いのですが、新しい取り組みが本当に期待している価値があるのかを検証するためにはもっとライトなやり方でも十分評価ができます。L3以上はビジネス的な評価だけでなく、技術面での評価の側面も強くなってくるので、その前段でそもそも価値があるものなのかを評価して、期待できそうであればL3以上のPoCに進むという数段階のPoCを経ることもあります。
評価観点
PoCの評価は多角的に行う必要があります。主な評価観点は以下の4つです。PoCはなるべく短期決戦が望ましいです。何をもってPoCを完了とできるのかのめやすがないために、結局次に進めるのかどうかの判断がつけられません。また、多くのケースでPoCにそこまで多くの時間と労力を割けないため、最低限確認すべき項目、ノックアウトファクターを洗い出すためにやらないといけないことを定めた上で取り組む方が結果的に検証のスピードも高められます。
| 評価軸 | 評価の目的 | 主な評価項目の例 |
|---|---|---|
| ビジネス・業務面 | 検討している施策がビジネス・業務面で期待通りの効果を得られそうかを評価する | ・業務KPIや目標値に対する効果測定・業務改善効果の定量的な確認・予実管理への影響度・現場の業務効率向上度 ※定量的な目標値を設定できれば理想的だが、初めての取り組みでは実際にデータを収集し、その結果をもとに現実的な目標数値を設定するアプローチも有効 |
| 技術面 | 検討している実現方式、技術方式が採用できるものかを評価する | ・ノックアウトファクター（必達要件）の確認・センサーの精度やデータ取得可能性・通信の安定性と頻度調整の可否・データ処理の速度と変換機能・システム連携方式とプロトコル ・既存設備への負荷や影響 |
| 運用面 | 検討している施策や技術構成を運用していくにあたり、その運用の容易さを評価する | ・デバイスのキッティング作業内容・設置手順と取り外し・交換の容易性・現場作業者のみでの対応可否・必要なサポート内容の把握・メンテナンス頻度と工数・トラブル時の切り分けやすさ・学習コストや社員教育コスト・設置環境への適合性（電断、耐環境性など） ※技術的にできても運用が複雑だと実用的ではない。運用面での複雑さは最終的にコストにもつながる |
| コスト面 | 想定する規模で展開した場合のコストが事業として成立するかを評価する | ・デバイス調達コストとランニング費用・通信費（データ通信量の実測含む）・サービス利用料金・システム運用費・運用に伴う人件費 ※目に見えるコストだけでなく、運用に伴うコストもあわせて評価することで、本番導入を判断するための材料とする |
デバイス戦略
PoC段階では多くのケースで既製品を利用する、もしくは簡易的なプロトタイプを用意して取り組みます。もしデバイスを自社開発して量産を計画していても、同じ進め方を推奨しています。というのも、この段階ではデバイスへの要求仕様が定まり切っていないため、PoCを通して実際に必要な要求事項を固めていくことになるため、そのためのベンチマークとして既製品を活用したり、自分達で簡単なプロトタイプを作ってみて、足りない機能は何か、逆に不要だった機能は何かを整理していくことができるためです。
通信・クラウドの最小構成
評価内容によって最小限のシステムを用意する必要があります。よくあるのは、取得したデータの収集、蓄積、可視化までを行いたいケースです。こうした場合、デバイスだけでなくそのためのシステムも用意する必要があります。ただし、評価に支障がない限りは最低限の機能だけがあれば十分です。たとえば、可視化も綺麗なUIはそのUI機能そのものの使い勝手やユーザー体験自体が評価の対象でなければ、簡単なグラフで十分ですし、データさえ蓄積されていればダウンロードして必要な時に手元でスプレッドシートでグラフにするでも十分なはずです。
💡プロジェクトマネジメント視点でのチェックポイント
- PoCのレベル（L0〜L4）は適切に選択されているか
- PoCの完了基準とノックアウトファクターは事前に定義され、関係者間で合意されているか
- 評価観点（ビジネス・技術・運用・コスト）ごとの評価項目と優先順位は明確になっているか
- システム構成は評価に必要な最小限の機能に絞り込まれており、過剰な実装をしていないか
- PoCのスケジュールは短期決戦を意識しており、何をもって次フェーズに進むか判断基準が明確か
- PoCの結果をもとに企画に戻る可能性も考慮し、意思決定プロセスは整備されているか
📝参考
IoTプロジェクトのPoCの進め方についてはこちらの記事もご参照ください。
プロジェクトキックオフ
PoCで一定の成果が得られ、本格的な開発に進むことが決まったら、正式なプロジェクトとしてキックオフします。体制、契約、要件、品質基準などを明確にし、関係者全員が同じ方向を向いて進められる基盤を整えます。
パートナー選定・契約(システム開発／デバイス開発)
本格開発に向けて、必要なパートナー企業を選定し、契約を締結します。
キックオフでは改めて、プロジェクトの目的とゴール、責任範囲、アウトプット、スケジュールを参加者全員で明確にします。特にIoTプロジェクトでは、デバイスとクラウドの接点となるインターフェース部分の責任分界点を明確にすることが重要です。
スケジュール・マイルストン・予算
IoTプロジェクトではデバイスの調達や量産といった、大きなリードタイムが発生します。そのため、前もってスケジュールとマイルストンを整理しておかないと、必要なタイミングでデバイスが揃わないといったことが容易に起き得ます。また展開台数が多くなるほどデバイスが締める費用の割合も大きくなってくるため、あらかじめ予算感を整理しておくことで、デバイスの選択肢も柔軟に考慮にいれることができます。
ステークホルダーの巻き込み
ここでいうステークホルダーはIoTプロジェクトを導入して運用するために関わる人たちです。業務改善型であれば導入して、実際に利用する自社の社員もステークホルダーに含まれます。特に業務改善型では、現場側でデバイスの導入や設置、運用が必要になるため、現場担当者の理解と協力を得ることは必須です。そのため、設計段階からこうしたステークホルダーにも意見をもらいながらオペレーションの観点で実現不可能になってしまうといった大きな手戻りを防ぐことができます。
💡プロジェクトマネジメント視点でのチェックポイント
- プロジェクトの目的、ゴール、各社の責任範囲は参加者全員で明確に合意されているか
- デバイスとクラウドの接点となるインターフェース部分の責任分界点は明文化されているか
- デバイス調達や量産のリードタイムを考慮したマイルストンとスケジュールは整理されているか
- 展開台数に応じたデバイスコストと予算の整合性は確認できており、柔軟な選択肢を残せているか
- 現場担当者を含むステークホルダー全員と連携が取れる体制と会議体は設定されているか
- 各担当者の役割と責任、情報連携方法は明確で、全員がマイルストンと作業内容を把握しているか
- 設計段階から現場の意見を取り入れる仕組みがあり、運用面での大きな手戻りを防げる体制か
IoTシステムの設計開発
進め方のスタイル
IoTプロジェクトの進め方の特徴として、ウォーターフォールとアジャイルを組み合わせた形になりやすい点です。例えば、デバイス開発はウォーターフォールで進め、クラウド側のシステム開発はアジャイルで進めるといった形です。クラウド側は通常のシステム開発と同じものの、デバイス側は特に自社開発、既製品のカスタムの場合、先に仕様を決めた上で開発が行われるためウォーターフォール的な進め方になります。そのため、デバイスとクラウドが互いに関係しあうインタフェース仕様の早期確定が重要です。
要件定義・設計
本格開発に向けて、詳細な要件定義を行います。
機能要件、非機能要件への対応はイテレーションで対応が可能ですが、インタフェース仕様は初期の段階で作り込んでいく必要があります。既製品を使う場合はデータのフォーマットが固定されている場合もあるので、早期にフォーマットの仕様を確認し、それをもとにクラウド側のデータベースのスキーマ設計などに利用します。また自社開発する場合はどういったデータを含めるかから設計する必要があるためより時間を要します。インターフェース仕様には、データペイロードの構造だけでなく、MQTTやHTTPなどの利用する通信プロトコル、デバイス認証と暗号化の方式、通信頻度と帯域の想定、エラーコードとリトライポリシーが必要になります。
またこのタイミングでOTAの方式、デバイスの初期起動時のプロビジョニングの方式についても検討します。
| 要件種別 | 定義 | 主な項目例 | 重要なポイント |
|---|---|---|---|
| 機能要件 | システムが実現すべき機能を具体的に定義 | ・大量のデバイス管理・ユーザー権限管理・データのバックアップとリカバリー・監視とアラート ・レポート機能 | PoCで検証した内容をベースに、本番運用に必要な機能を追加。何ができるべきかを明確に定義する。 |
| 非機能要件 | 性能、拡張性、可用性、セキュリティ、保守性などを定義 | ・同時接続デバイス数・データ処理のレイテンシ・システムの稼働率・データの保持期間・セキュリティレベル・障害復旧時間 | 具体的な数値で定めることが重要。システムの品質を左右する要件。 |
| インターフェース仕様 | デバイスとクラウド間の通信仕様を詳細に定義 | ・データフォーマット・通信プロトコル・認証方式・エラーハンドリング・通信頻度と帯域 | IoTプロジェクトにおいて最も重要な合意事項の一つ。この仕様が確定しないと、デバイス開発とシステム開発を並行して進めることができない。デバイス開発チームとシステム開発チームの両方が合意し、文書化する。 |
開発・テスト
クラウド側の開発やテストは通常のシステム開発と変わりません。デバイスからクラウドまで、エンドツーエンドでテストをしたい場合、毎回デバイスから実際にデータを送信するのは手間なため、ソフトウェアでエミュレーターを作っておくなどすると便利です。
💡プロジェクトマネジメント視点でのチェックポイント
- インターフェース仕様（データフォーマット、通信プロトコル、認証方式、エラーハンドリング）は早期に確定し、両チームで合意されているか
- OTA更新方式とデバイスプロビジョニング方式は設計段階で決定されているか
- エンドツーエンドテストのためのエミュレーターなど、効率的なテスト環境は準備されているか
- デバイスとシステムのエンドツーエンドテストのタイミングとマイルストンはスケジュールに組み込まれているか
📝参考
ソラコムを活用したIoTシステムの開発についてはこちらもご参照ください。
デバイス量産
デバイス仕様の確定
量産デバイスの仕様は、PoC段階で検証した要件をもとに確定していきます。
| 検討項目 | 主な内容 |
|---|---|
| ハードウェア | 通信モジュール、センサー種別と必要な精度、電源仕様、筐体（IP等級、動作温度） |
| ソフトウェア | ファームウェア機能、OTAアップデート方式、ログ・デバッグ機能 |
| 認証・規制 | 技適認証、業界特有の規制対応 |
| コスト | 量産規模別の単価目標、初期費用（金型、認証、NRE）、最小発注数量（MOQ） |
実機での評価
量産デバイスを使用する場合は、量産に向けた試作段階のデバイスを使用することになります。この段階では、EVT (Engineering Validation Test) や DVT (Design Validation Test) と呼ばれる段階の試作品を使用し、実際の運用環境での動作を確認します。またデバイス仕様は、EVT段階で技術的な実現可能性を確認しながら、DVT段階で最終確定します。
量産を伴うプロジェクトでは、NPI (New Product Introduction) と呼ばれる製品導入プロセスを経ます。
| フェーズ | 段階 | 主な検証内容 | 重点ポイント |
|---|---|---|---|
| EVT (Engineering Validation Test) | 初期試作 | ・回路設計・ソフトウェアの基本機能 ・通信性能 | 設計した機能が実現できるかを検証。外装やコストよりも機能実現に重点を置く。設計上の問題を洗い出す。 |
| DVT (Design Validation Test) | 設計検証 | ・信頼性試験（温度、湿度、振動など）・EMC（電磁適合性）試験・長期動作試験・製造プロセスの実現可能性 | 量産を見据えた設計になっているかを検証。 |
| PVT (Production Validation Test) | 量産試作 | ・実際の量産ラインでの製造・品質と歩留まりの検証・製造手順の確定・検査項目と基準の確定 | 数百〜数千台規模で製造し、初期不良率を確認。 |
| MP (Mass Production) | 本格量産 | ・大量生産・継続的な品質監視・プロセス改善 | PVTで確立した製造プロセスで安定した供給を実現。 |
品質管理手順の整備
量産デバイスの品質維持のため、受け入れから運用開始までのプロセスを整備します。
| 項目 | 内容 |
|---|---|
| 受け入れ検査 | 外観、起動、通信、基本動作の確認。大量納品時はサンプリング検査 |
| 不良判定基準 | 不良の重大度を分類し対応方針を決定。致命的な不良（通信不可など）は返品、機能不良は用途により使用可否を判断、外観不良は許容範囲を定めて使用可否を判断 |
| 物流・保管 | 受け入れまでの物流の流れ、保管場所、シリアル番号での追跡 |
| 記録管理 | 検査日時、ロット番号、不良内容を記録。スプレッドシートやDBで一元管理 |
デバイスの需要予測と供給計画
既製品や自社開発問わず、展開スケジュール、故障交換、拠点増加を考慮した需要予測を行いリードタイム、価格を管理します。特に半導体など長納期部材は、リードタイムが数ヶ月に及ぶため早期発注が必須で、クリティカルな部材は安全在庫も検討します。
プロジェクトマネジメント視点でのチェックポイント
- EVT/DVT/PVT各フェーズでのGo/No-Go判定基準は事前に定義され、ステークホルダー間で合意されているか
- デバイス量産のリードタイムと本格展開スケジュールは整合しており、十分なバッファ期間が確保されているか
- 製造パートナーとの契約条件（MOQ、納期、品質保証、不良品対応）は明確化されているか
- 長納期部材や単一サプライヤー依存のリスクは特定され、代替調達先や設計変更の準備はできているか
- PVT段階での初期不良率は許容範囲内にあり、量産開始後も定期的に品質指標を追跡できているか
📝参考
ソラコムではネットワークのパフォーマンスを維持しつつ効率的なデバイスを設計するためのガイドラインとしてデバイス実装ガイドラインを公開しています。
本格展開・運用開始
試験導入で十分な検証が完了したら、いよいよ本格的な展開フェーズに入ります。このフェーズでは、大規模なデバイス展開、システムの本番運用、そして量産を伴う場合は製造プロセスの確立が必要になります。試験導入とは規模が大きく異なるため、スケールに対応した体制とプロセスが求められます。
キッティング・設置
製造されたデバイスを現場に届け、設置するプロセスを設計します。キッティングでは、ファームウェアの書き込み、デバイスID登録、アクセサリー（ケーブル、マウント、説明書等）の梱包を行い、効率化のため専用治具やツールを開発することもあります。設置支援は、現場担当者の自力設置、専門担当者による実施、外部施工業者への委託がよくとられるパターンです。設定手順だけでなく、設置後の動作確認を標準化したチェックリストで実施します。
トレーニング・マニュアル整備
エンドユーザーがシステムを使いこなせるよう、教育体制を整えます。トレーニングプログラムでは、システムの使い方、日常メンテナンス、簡単なトラブルシューティングを、適切な方法で教育します。
利用状況の確認
展開した仕組みが日常で利用されているかをウォッチします。これは仕組みそのものが正しく稼働しているかという観点だけではなく、想定された通りエンドユーザーに利用されているかを確認する目的もあります。想定よりも利用されていない場合、何が障壁になっているのかを調査する必要があります。それがシステム的な理由なのか、あるいは想定していた価値が正しく届けられていないのかを確認し改善につなげていく必要があるためです。
サポート問合せ
本格展開直後は想定外の事態が多く発生しがちです。そのため、エンドユーザーからの問合せをうける社内の窓口が機能しているか、外部のデバイスパートナーやシステム開発パートナーへの問合せは適切にできているかを確認します。
運用・改善
IoTシステムの運用では、デバイスからクラウドまでの複数の層を監視する必要があります。
現場担当は、デバイスの設置後に電波状況を確認したり、故障したデバイスを交換したりする作業を行います。業務改善型のプロジェクトでは、現場担当者がこれらの作業を自分たちで行えるよう、標準作業手順書を整備し、トレーニングを行います。 重要な指標を一覧で確認できるようにダッシュボードを整備したりします。特にデバイスの設置を伴う取り組みでは、最初のうちは設置作業がまだこなれていないために動作確認がとれるまで色々な問合せが予想されます。こうした問合せ窓口をどうするかも運用設計の中で取り決めておくといいです。
💡プロジェクトマネジメント視点でのチェックポイント
- キッティング作業、設置手順は文書化され、効率化のための治具やツールの必要性は検討されているか
- 教育トレーニングの方法は整備され、現場に無理のない移行期間が設定されているか
- 操作マニュアル、トラブルシューティングガイド、動画マニュアル、FAQは用意され、継続的に更新する体制はあるか
- エンドユーザーからの問合せ窓口は機能しており、デバイス/システムパートナーへのエスカレーションフローは整備されているか
- 導入した仕組みは日常的に利用されているか、利用が想定より低い場合の障壁調査プロセスはあるか
- 想定と異なる利用のされ方や、価値が正しく届けられていない兆候を検知する仕組みはあるか
- デバイスからクラウドまでの複数層を監視するダッシュボードと定期タスクは設定され、機能しているか
- 受け入れデバイスの不良率は安定しており、品質問題が発生した場合のプロセスは明確か
- 本格展開直後の想定外事態に対応できる体制は整っているか
📝参考
ソラコム回線の運用内容やその効率化についてはこちらをご参照ください
まとめ
いかがでしたか。IoTプロジェクトは複数の技術要素だけでなく多くのステークホルダーを巻き込みながら進めていく必要があり、一見すると非常に難しく感じてしまいがちです。しかし、必要なことから小さく始めていくことで、着実に成果を出しながら進めることは十分可能です。また、実際にIoTプロジェクトを進める際は、経験豊富なパートナーやコンサルタントの支援を受けることも検討することをおすすめします。
本記事が、あなたのIoTプロジェクトの成功の一助となれば幸いです。
― ソラコム須田（kei）