IoTプロジェクトを軌道にのせる PoCの始め方 株式会社ソラコム ソリューションアーキテクト 須田 桂伍

本日のハッシュタグ #SORACOM 使用例 #SORACOM の検索で、最新情報が！ @SORACOM_PR fb.com/soracom.jp youtube.com/c/SORACOM_Japan instagram.com/soracom.official

本セッションでお話する範囲 企画 構想 PoC 本番導入 運用保守 パイロット運用

本セッションについて 話すこと ○ PoCの進め方、特にPoCの要となる計画の立て方を中心にお話します 話さないこと ○ 新規事業や企画の立案 ○ IoTシステムの設計・開発方法 持って帰ってほしいこと ○ PoCが陥りがちな事と防ぐためのアプローチ ○ どうやってPoCを計画して進めていくのか ○ プロトタイプをどうやって準備するのか

自己紹介 株式会社ソラコム / シニアソリューションアーキテクト 須田 桂伍 (すだ けいご) ソラコムでProfessional Service（有償での支援）を担当 数多くのIoTプロジェクトにてIoTシステムの構築支援やPoC支援を実施 趣味で技術同人誌を書いています

目次 ● PoCの基礎 ● PoCで終わってしまうアンチパターン ● PoCの進め方 - 計画編 ● プロトタイプをどう用意するか

目次 ● PoCの基礎 ● PoCで終わってしまうアンチパターン ● PoCの進め方 - 計画編 ● プロトタイプをどう用意するか

PoCの定義 PoC は、あるアイデア、製品、サービス、技術などのコンセプトが実際に 実現可能であるかどうかを実証するために行われる小規模な実験やテスト のことを指します PoC の特徴 ● コンセプトやアイデアを検証するための実験的なアプローチ ● ⼩規模で低コストの実装による検証 ● エラーや問題を発⾒し、改善するための試験 NOT PoCの特徴 ● 完全に開発された製品やサービス ● 完成した製品やサービスのテスト ● 製品やサービスの宣伝やマーケティング活動 PoCの基礎

PoCの役割 実現性評価のためのPoC ○ アイデアや企画の実現性を評価するための役割 ○ 実現性にはビジネス・業務、技術、運用、コストの4つの観点から評価が必要 学びと発見のPoC ○ 準備や評価実施の過程で実際に⼿を動かしながら仕組みを理解できる役割 ○ 机上では気づけなかったポイントを発⾒でき、より深みのある設計につなげる 予算確保のためのPoC ○ 本番導入に向けた予算を確保するための役割 ○ 実機での計測ができるためより確度の高い見積のインプットを得られる PoCの基礎 PoCの基礎

フィージビリティスタディとPoC ● フィージビリティスタディはアイデアに対する事前の実現性や実現手段の 調査であり、フィージビリティスタディで目星を付けた対象を具体的に評 価していくのがPoC ● 事前のノックアウトファクターの洗い出しやあたりを付けるプロセス 検討している施策の 実現方式を調査する 調査した実現方式から 目星を付ける 目星を付けた実現方式を もとに施策の評価を進める フィージビリティスタディ PoC PoCの基礎

PoCの期間 年 日 週 月 四半期 時間 アウトプットへの 期待 洒落に ならない ライン "検証" だったことを忘れちゃう → 失敗できなくなる 失敗するなら 1か月後より「明日」 PoCの基礎

論より動くもの PoCの基礎 ● 机上の議論だけでは、各々が持つイメージが異なるために議論が発散 しやすくなり物事を前進させることが難しくなります。 ● PoCではプロトタイプを作成することでアイデアを具体化し、実際に 見せることができ、本質的な議論への誘導ができます。 ● 一方で、こうした動くものが早い段階であることで、視野が限定され てしまう可能性もある点には注意が必要です。また、プロトタイプそ のもののレビューになってしまうこともよくある落とし穴です。 ● フィードバック時にどういったフィードバックが欲しいのかを明示す ること、または最初はあえてペーパープロトタイピングのように自由 度を残した形で評価を進めるというのも効果的です。

目次 ● PoCの基礎 ● PoCで終わってしまうアンチパターン ● PoCの進め方 - 計画編 ● プロトタイプをどう用意するか

PoCで終わってしまうアンチパターン 1. とりあえずPoC 2. 際限なきPoC 3. 失敗が許されないPoC PoCのアンチパターン

とりあえずPoC 症状 PoC のゴールや何をどこまで評価をすればよいかが曖昧もしくは存在しない状態で始まってしま った PoC です。PoC での評価に着⼿したものの、評価すべき項⽬が曖昧なためにやったものの 具体的な評価ができず、PoC 後の次アクションを決めるための結果が得られず終わってしまう PoC です。 症例 ○ とりあえずデータを取得してみた ○ まずは可視化してみた 処方箋 PoC に着⼿するより前にその⽬的を明確にし、⽬的を達成するための具体的な評価項⽬を作成し ます。この PoC を終えた後にどのような状態にあればよいのか、どういった情報を PoC から導 きだせると良いのかをステークホルダー間で明確にしてから PoC に着⼿していきましょう。調 査⽬的での機能確認であれば PoC の⼿前にフィージビリティスタディの時間をとって単体での 機能検証をすることも効果的です。 PoCのアンチパターン

際限なきPoC 症状 PoC のスコープが広すぎる、またはステークホルダー間でゴールのすり合わせができていないた めに、あれもこれもと評価項⽬が増え続け収拾のつかなくなってしまった PoC です。そのため PoC に要する時間も⻑期化していき、何のための評価をしているのかという軸もぶれやすくなり ます。 症例 ○ メンバー同⼠で関⼼が異なるために評価項⽬はたくさん出てくるが取捨選択ができない ○ フィードバックの度に追加評価しなくてはいけないことが増える ○ 当初決めた PoC 期間内では満⾜いく評価ができず、PoC の継続状態が続いている 処方箋 PoC のスコープを明確にし、あわせて PoC の中でやらないこと・やれないことを明⽰しましょ う。こうした PoC で取り扱う範囲はステークホルダー間で合意し、チーム間での議論やフィー ドバックの機会においても発散しないように都度スコープは説明するようにします。 PoCのアンチパターン

失敗が許されないPoC 症状 PoC 中のトライアンドエラーがやりにくい、PoC で想定と異なる結果が許されない PoC です。 この場合、PoC の取り組みが本番導⼊時と同等に評価されてしまっていることも多いです。また、 PoC の期間が⻑期化していってしまい、周囲の期待値とのギャップが⽣じていき、次第にネガテ ィブな結果を共有しにくくなり、結果的に⾃ら失敗が許されない状況を作ってしまっていケース もあります。 症例 ○ PoC やプロトタイプへの評価基準が本番導⼊時と同様のものを適⽤されてしまう ○ PoC がどんどん収拾がつかなくなり、課題を⼼理的に共有しにくくなっている 処方箋 PoC のスコープだけでなく、どういった評価観点を確認できれば⼗分とするのかをステークホル ダー間で共有するだけでなく、こうした評価観点を確認するためには最低限の設計と開発で⼗分 であるという点もインプットしましょう。また、PoC を開始する前にフィードバックのタイミン グを計画として組み込んでおき、定期的に状況をオープンに相談できる場所とし設定します PoCのアンチパターン

目次 ● PoCの基礎 ● PoCで終わってしまうアンチパターン ● PoCの進め方 - 計画編 ● プロトタイプをどう用意するか

PoCのステップ クローズ 次アクション 決定 結果整理 再評価 フィード バック 評 価 準 備 計 画 評価期間中のフィードバックは定期的に実施する 評価しきれなかった項目、試行錯誤に時間がかかりそうな項目は一 度優先度を落とし他の評価項目を進めていく PoCの進め方 - 計画編

PoC計画に含めたいアイテム No. 項目 説明 1 PoCの背景と目的 PoCを実施することになった背景と目的を明確にします 2 PoCの実施にあたっての制約事項 PoCを実施するにあたって既知の前提事項や制約事項を明確にします 3 PoCのスコープ 本PoCでの評価対象となるスコープを明確にします 4 やらないこと・やれないこと 本PoCのスコープ外であるもの、やらないことを明確にします 5 評価軸及び評価項目 評価にあたっての評価軸と具体的な評価項目を整理します 6 PoC評価時のシステム構成・開発対象 評価を進めるために必要となるシステムやプロトタイプを整理します 7 評価の実施環境 評価を実施するための場所を選定します 8 遵守すべきレギュレーションへの対応 評価にあたり必要なレギュレーション対応を明確にします 9 実施スケジュール PoC実施のスケジュールを作成します 10 体制 PoC実施にあたりステークホルダーを含む体制を確定します 11 タスクと担当者 評価実施に必要な準備作業を整理しアサインしていきます 情報 粒度 小 大 PoCの進め方 - 計画編

PoC計画に含めたいアイテム No. 項目 説明 1 PoCの背景と目的 PoCを実施することになった背景と目的を明確にします 2 PoCの実施にあたっての制約事項 PoCを実施するにあたって既知の前提事項や制約事項を明確にします 3 PoCのスコープ 本PoCでの評価対象となるスコープを明確にします 4 やらないこと・やれないこと 本PoCのスコープ外であるもの、やらないことを明確にします 5 評価軸及び評価項目 評価にあたっての評価軸と具体的な評価項目を整理します 6 PoC評価時のシステム構成・開発対象 評価を進めるために必要となるシステムやプロトタイプを整理します 7 評価の実施環境 評価を実施するための場所を選定します 8 遵守すべきレギュレーションへの対応 評価にあたり必要なレギュレーション対応を明確にします 9 実施スケジュール PoC実施のスケジュールを作成します 10 体制 PoC実施にあたりステークホルダーを含む体制を確定します 11 タスクと担当者 評価実施に必要な準備作業を整理しアサインしていきます 情報 粒度 小 大 PoCの進め方 - 計画編

網羅性を高める評価軸 ビジネス・業務面 新しい施策が本当に収益を⽣むものなのか、業務を効率化できるものなのか、といった期待 しているビジネスや業務への効果が得られるかどうかという観点です。 技術面 施策を実現するために採⽤するテクノロジーやシステムが期待通りに動き、利⽤できるもの なのかという観点です。 運用面 施策を実現するために必要な仕組みが無理なく運⽤していけるか、運⽤のためにどういった 変化や対応、教育が必要なのかという観点です。 コスト面 施策を実現するために必要なコストはどのぐらいか、そしてその⾦額は適切かどうかという 観点です。 PoCの進め方 - 計画編

評価項目を整理するテクニック No. 項目 説明 1 まずは出し切る まず、確認点を出しあい、その後各評価軸で評価項目が存在することを確 認します。必須であり達成しなければ進まないノックアウトファクターを 定め、それを最優先にします。最後に、他の評価項目の優先度を設定し、 関連項目があれば同時に評価することで効率を向上させます。 2 ライフサイクルに沿って考える 運用に関連する評価項目はデバイスのライフサイクルに沿って考えると網 羅性を高められます。『調達→キッティング→設置→稼働→メンテナンス →破棄・交換』の各ライフサイクルで必要な作業は何かを整理していきま す。 3 公開ガイドラインや規約の活用 公開ガイドラインや規約を利用して検討の網羅性を高めることができます。 ⼀から評価項⽬を洗い出す前に、⾃分たちのユースケースに応じたガイド ラインや規約がないかを調べてみるのもおすすめです。 4 評価項目の種類を意識する 評価項⽬には 、期待する挙動や結果が得られるかどうかで判断できる定量 的な評価項⽬、対象や仕組みを把握したり情報を得るための定性的な評価 項⽬があります。定性的な評価を通して「評価対象がどのような特性や癖 を持つのか」や「その使い⽅はどういったものなのか」を評価します。 PoCの進め方 - 計画編

例）PoC計画作成の議論 PoCの進め方 - 計画編

目次 ● PoCの基礎 ● PoCで終わってしまうアンチパターン ● PoCの進め方 - 計画編 ● プロトタイプをどう用意するか

プロトタイプをどう用意するか No. 項目 説明 1 機能・実用性評価のプロトタイプ UI とバックエンドの両⽅で最⼩の動くものを実装し、機能性や 実⽤性を評価するためのプロトタイプです 2 デザイン評価のプロトタイプ 本番時の利⽤を想定した UI を準備し、デザイン⾯や操作性を中 ⼼に評価するプロトタイプです 3 コンセプト評価のプロトタイプ 検討しているアイデアや施策を体験できるコンテンツを⽤意し、 実際のユーザーに疑似的な体験をしてもらい、コンセプトの評価 を進めるプロトタイプです プロトタイプの種類

プロトタイプの種類 プロトタイプをどう用意するか No. 項目 説明 1 機能・実用性評価のプロトタイプ UI とバックエンドの両⽅で最⼩の動くものを実装し、機能性や 実⽤性を評価するためのプロトタイプです 2 デザイン評価のプロトタイプ 本番時の利⽤を想定した UI を準備し、デザイン⾯や操作性を中 ⼼に評価するプロトタイプです 3 コンセプト評価のプロトタイプ 検討しているアイデアや施策を体験できるコンテンツを⽤意し、 実際のユーザーに疑似的な体験をしてもらい、コンセプトの評価 を進めるプロトタイプです

IoTシステムにおける開発範囲 プロトタイプをどう用意するか デジタル化 対象 デバイス ネットワーク クラウド 利用者 アプリケーション ストレージ データ 処理 ゲートウェイ パケット交換 (ISP/IX) バックホール アクセス ポイント 通信 モジュール マイコン センサー デリバリー / ロジスティクス ペイメント オペレーション セキュリティ

フィールド側のデバイス選定 1. 既存デバイスの利用 既存デバイスの利用は、市場で購入可能なデバイスを活用することで開発コストや時間を節約する ことが可能です。これは既存業務の改善や効率化を目指すユースケースに適しており、商用化への 導入も容易です。 2. プロトタイプデバイスの開発 一方、自社の特定の要求に適合するデバイスが見つからない場合や他社との差別化が難しい場合に は、プロトタイプデバイスの開発を検討します。近年では、Raspberry PiやArduinoなどのシングル ボードコンピュータをベースにしたデバイスが利用可能です。これにより新規ビジネスや独自技術 の開発が可能となりますが、開発コストと時間がかかることを覚悟する必要があります。 3. 推奨する進め方 推奨する進め方としては、まずは既製品のデバイスを用いたPoCを実施することです。その結果、そ のまま本番導入にも適用できそうであれば、継続して当該デバイスの展開を進めます。また、将来 的に自分たちでデバイス開発をする際にも、PoCの結果をベンチマークとして活用することができま す。 プロトタイプをどう用意するか

エッジ側の考慮事項 エッジ側処理では、センサーからのデータ取得とその形式の理解が重要です。しかし、センサーの 特性や使用環境により、データは影響を受けることがあります。これに対応するためには、物理的 な調整だけでなく、ソフトウェアによるデータ補正などのキャリブレーションが必要となることが あります。キャリブレーションが必要な箇所は、外部からパラメーターを変更できるように設計す ることが推奨されます。 プロトタイプをどう用意するか デバイス センサー 計測対象 キャリブレーション 外からパラメーターを変更できるようにし 後からキャリブレーションできるようにしておく センサーの物理的なキャリブレーションは 現地対応が必要

クラウドの考慮事項 フィールド側評価時: フィールドデータの収集・分析に注力し、シンプルなクラウド側仕組みの準備が効果的。適切なビュ ーとデータ可視化を確保します。 他システム接続部分評価時: 他のシステムとのデータ連携を実際に確認し、検証や開発環境でPoCを行います。重要なのは安全な 操作と分離された評価環境です。 UIUX確認評価時: 評価に必要なUI部分のみを組み込み、詳細な作り込みは避けます。デザインツールを活用し、データ 取得後のUI作成を別枠で評価も可能です。 クラウドサービス評価時: 本番導入を想定したシステムを構築し、サービス構成を確認します。非機能要素が対象でなければ、 最小構成での動作確認を推奨します。 プロトタイプをどう用意するか

LLMの活用 プロトタイプをどう用意するか

どこまでセキュアに作りこむべき データ暗号化: データ漏洩リスクに対処するため、保存・通信中のデータの暗号化が重要です。特に、IoTデバイスの消費リソース や主処理への影響を評価するため、暗号化処理を組み込むことが推奨されます。 データのマスキング: PoCではテストデータとして本番環境からのデータを用いる場合がありますが、そのデータが機密情報を含む場合は、 マスキングすることが重要です。特に、保存データの暗号化だけでは防ぎきれないリスクも考慮する必要があります。 認証・認可: PoCの目的や扱うデータに応じて、適切な認証と認可範囲を設定します。これはユーザーだけでなく、接続するデバ イスにも適用されます。初期段階でこれらを組み込むことで、後の開発フェーズでのセキュリティの問題を未然に防 ぎます。 盗難対策: IoTシステムにおける物理的なセキュリティ対策も重要で、本番導入時には対策が必要になります。PoC段階では予 想されるセキュリティリスクとその検知・対処方法の確認に重点を置き、詳細な対策は後回しにします。 プロトタイプをどう用意するか

SORACOM の願い クラウド ⇒ 多くの Web サービス SORACOM ⇒ 多くの IoT システム 日本から、世界から、たくさんの IoT プレイヤーが生まれますように

IoTの「つなぐ」を簡単に You Create. We Connect.