$30 off During Our Annual Pro Sale. View Details »

IoTプロジェクトを軌道にのせるPoCの始め方【SORACOM Discovery 2024】

IoTプロジェクトを軌道にのせるPoCの始め方【SORACOM Discovery 2024】

IoTプロジェクトの初期フェーズとしてPoC(概念実証)は欠かせません。PoCをやるだけで終わる状況を打開するには、本番導入を見据えたPoCの推進が求められます。これまで多くのお客様とIoTプロジェクトを進めてきた経験をもとに、IoTプロジェクトを軌道にのせるPoCのベストプラクティスを共有します。

株式会社ソラコム シニアソリューションアーキテクト 須田 桂伍

SORACOM

July 17, 2024
Tweet

More Decks by SORACOM

Other Decks in Technology

Transcript

  1. 本セッションについて 話すこと ◦ PoCの進め方、特にPoCの要となる計画の立て方を中心にお話します 話さないこと ◦ 新規事業や企画の立案 ◦ IoTシステムの設計・開発方法 持って帰ってほしいこと

    ◦ PoCが陥りがちな事と防ぐためのアプローチ ◦ どうやってPoCを計画して進めていくのか ◦ プロトタイプをどうやって準備するのか
  2. 自己紹介 株式会社ソラコム / シニアソリューションアーキテクト 須田 桂伍 (すだ けいご) ソラコムでProfessional Service(有償での支援)を担当

    数多くのIoTプロジェクトにてIoTシステムの構築支援やPoC支援を実施 趣味で技術同人誌を書いています
  3. PoCの定義 PoC は、あるアイデア、製品、サービス、技術などのコンセプトが実際に 実現可能であるかどうかを実証するために行われる小規模な実験やテスト のことを指します PoC の特徴 • コンセプトやアイデアを検証するための実験的なアプローチ •

    ⼩規模で低コストの実装による検証 • エラーや問題を発⾒し、改善するための試験 NOT PoCの特徴 • 完全に開発された製品やサービス • 完成した製品やサービスのテスト • 製品やサービスの宣伝やマーケティング活動 PoCの基礎
  4. PoCの役割 実現性評価のためのPoC ◦ アイデアや企画の実現性を評価するための役割 ◦ 実現性にはビジネス・業務、技術、運用、コストの4つの観点から評価が必要 学びと発見のPoC ◦ 準備や評価実施の過程で実際に⼿を動かしながら仕組みを理解できる役割 ◦

    机上では気づけなかったポイントを発⾒でき、より深みのある設計につなげる 予算確保のためのPoC ◦ 本番導入に向けた予算を確保するための役割 ◦ 実機での計測ができるためより確度の高い見積のインプットを得られる PoCの基礎 PoCの基礎
  5. PoCの期間 年 日 週 月 四半期 時間 アウトプットへの 期待 洒落に

    ならない ライン "検証" だったことを忘れちゃう → 失敗できなくなる 失敗するなら 1か月後より「明日」 PoCの基礎
  6. 論より動くもの PoCの基礎 • 机上の議論だけでは、各々が持つイメージが異なるために議論が発散 しやすくなり物事を前進させることが難しくなります。 • PoCではプロトタイプを作成することでアイデアを具体化し、実際に 見せることができ、本質的な議論への誘導ができます。 • 一方で、こうした動くものが早い段階であることで、視野が限定され

    てしまう可能性もある点には注意が必要です。また、プロトタイプそ のもののレビューになってしまうこともよくある落とし穴です。 • フィードバック時にどういったフィードバックが欲しいのかを明示す ること、または最初はあえてペーパープロトタイピングのように自由 度を残した形で評価を進めるというのも効果的です。
  7. とりあえずPoC 症状 PoC のゴールや何をどこまで評価をすればよいかが曖昧もしくは存在しない状態で始まってしま った PoC です。PoC での評価に着⼿したものの、評価すべき項⽬が曖昧なためにやったものの 具体的な評価ができず、PoC 後の次アクションを決めるための結果が得られず終わってしまう

    PoC です。 症例 ◦ とりあえずデータを取得してみた ◦ まずは可視化してみた 処方箋 PoC に着⼿するより前にその⽬的を明確にし、⽬的を達成するための具体的な評価項⽬を作成し ます。この PoC を終えた後にどのような状態にあればよいのか、どういった情報を PoC から導 きだせると良いのかをステークホルダー間で明確にしてから PoC に着⼿していきましょう。調 査⽬的での機能確認であれば PoC の⼿前にフィージビリティスタディの時間をとって単体での 機能検証をすることも効果的です。 PoCのアンチパターン
  8. 際限なきPoC 症状 PoC のスコープが広すぎる、またはステークホルダー間でゴールのすり合わせができていないた めに、あれもこれもと評価項⽬が増え続け収拾のつかなくなってしまった PoC です。そのため PoC に要する時間も⻑期化していき、何のための評価をしているのかという軸もぶれやすくなり ます。

    症例 ◦ メンバー同⼠で関⼼が異なるために評価項⽬はたくさん出てくるが取捨選択ができない ◦ フィードバックの度に追加評価しなくてはいけないことが増える ◦ 当初決めた PoC 期間内では満⾜いく評価ができず、PoC の継続状態が続いている 処方箋 PoC のスコープを明確にし、あわせて PoC の中でやらないこと・やれないことを明⽰しましょ う。こうした PoC で取り扱う範囲はステークホルダー間で合意し、チーム間での議論やフィー ドバックの機会においても発散しないように都度スコープは説明するようにします。 PoCのアンチパターン
  9. 失敗が許されないPoC 症状 PoC 中のトライアンドエラーがやりにくい、PoC で想定と異なる結果が許されない PoC です。 この場合、PoC の取り組みが本番導⼊時と同等に評価されてしまっていることも多いです。また、 PoC

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

    準 備 計 画 評価期間中のフィードバックは定期的に実施する 評価しきれなかった項目、試行錯誤に時間がかかりそうな項目は一 度優先度を落とし他の評価項目を進めていく PoCの進め方 - 計画編
  11. PoC計画に含めたいアイテム No. 項目 説明 1 PoCの背景と目的 PoCを実施することになった背景と目的を明確にします 2 PoCの実施にあたっての制約事項 PoCを実施するにあたって既知の前提事項や制約事項を明確にします

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

    3 PoCのスコープ 本PoCでの評価対象となるスコープを明確にします 4 やらないこと・やれないこと 本PoCのスコープ外であるもの、やらないことを明確にします 5 評価軸及び評価項目 評価にあたっての評価軸と具体的な評価項目を整理します 6 PoC評価時のシステム構成・開発対象 評価を進めるために必要となるシステムやプロトタイプを整理します 7 評価の実施環境 評価を実施するための場所を選定します 8 遵守すべきレギュレーションへの対応 評価にあたり必要なレギュレーション対応を明確にします 9 実施スケジュール PoC実施のスケジュールを作成します 10 体制 PoC実施にあたりステークホルダーを含む体制を確定します 11 タスクと担当者 評価実施に必要な準備作業を整理しアサインしていきます 情報 粒度 小 大 PoCの進め方 - 計画編
  13. 評価項目を整理するテクニック No. 項目 説明 1 まずは出し切る まず、確認点を出しあい、その後各評価軸で評価項目が存在することを確 認します。必須であり達成しなければ進まないノックアウトファクターを 定め、それを最優先にします。最後に、他の評価項目の優先度を設定し、 関連項目があれば同時に評価することで効率を向上させます。

    2 ライフサイクルに沿って考える 運用に関連する評価項目はデバイスのライフサイクルに沿って考えると網 羅性を高められます。『調達→キッティング→設置→稼働→メンテナンス →破棄・交換』の各ライフサイクルで必要な作業は何かを整理していきま す。 3 公開ガイドラインや規約の活用 公開ガイドラインや規約を利用して検討の網羅性を高めることができます。 ⼀から評価項⽬を洗い出す前に、⾃分たちのユースケースに応じたガイド ラインや規約がないかを調べてみるのもおすすめです。 4 評価項目の種類を意識する 評価項⽬には 、期待する挙動や結果が得られるかどうかで判断できる定量 的な評価項⽬、対象や仕組みを把握したり情報を得るための定性的な評価 項⽬があります。定性的な評価を通して「評価対象がどのような特性や癖 を持つのか」や「その使い⽅はどういったものなのか」を評価します。 PoCの進め方 - 計画編
  14. プロトタイプをどう用意するか No. 項目 説明 1 機能・実用性評価のプロトタイプ UI とバックエンドの両⽅で最⼩の動くものを実装し、機能性や 実⽤性を評価するためのプロトタイプです 2

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

    2 デザイン評価のプロトタイプ 本番時の利⽤を想定した UI を準備し、デザイン⾯や操作性を中 ⼼に評価するプロトタイプです 3 コンセプト評価のプロトタイプ 検討しているアイデアや施策を体験できるコンテンツを⽤意し、 実際のユーザーに疑似的な体験をしてもらい、コンセプトの評価 を進めるプロトタイプです
  16. IoTシステムにおける開発範囲 プロトタイプをどう用意するか デジタル化 対象 デバイス ネットワーク クラウド 利用者 アプリケーション ストレージ

    データ 処理 ゲートウェイ パケット交換 (ISP/IX) バックホール アクセス ポイント 通信 モジュール マイコン センサー デリバリー / ロジスティクス ペイメント オペレーション セキュリティ
  17. フィールド側のデバイス選定 1. 既存デバイスの利用 既存デバイスの利用は、市場で購入可能なデバイスを活用することで開発コストや時間を節約する ことが可能です。これは既存業務の改善や効率化を目指すユースケースに適しており、商用化への 導入も容易です。 2. プロトタイプデバイスの開発 一方、自社の特定の要求に適合するデバイスが見つからない場合や他社との差別化が難しい場合に は、プロトタイプデバイスの開発を検討します。近年では、Raspberry

    PiやArduinoなどのシングル ボードコンピュータをベースにしたデバイスが利用可能です。これにより新規ビジネスや独自技術 の開発が可能となりますが、開発コストと時間がかかることを覚悟する必要があります。 3. 推奨する進め方 推奨する進め方としては、まずは既製品のデバイスを用いたPoCを実施することです。その結果、そ のまま本番導入にも適用できそうであれば、継続して当該デバイスの展開を進めます。また、将来 的に自分たちでデバイス開発をする際にも、PoCの結果をベンチマークとして活用することができま す。 プロトタイプをどう用意するか
  18. SORACOM の願い クラウド ⇒ 多くの Web サービス SORACOM ⇒ 多くの

    IoT システム 日本から、世界から、たくさんの IoT プレイヤーが生まれますように