[レポート] 【ランチセッション】IoT プロジェクトはなぜ失敗するのか #AWSSummit

2016.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、せーのです。今日はAWS Summit Tokyo 2016 2日目からランチセッション「IoTプロジェクトはなぜ失敗するのか」をレポートします。
スピーカーは株式会社ウフル IoTイノベーションセンターマネージャーの竹之下 航洋氏です。ちなみに会場のランチはこんな感じです。

レポート

  • ウフルは数年IoTに取り組んできて知見が溜まってきた。失敗も沢山してきたので今日はその話をしたい。

2016年IoTを取り巻く状況

  • 2016年に至るまで色々なところで「IoTがビジネスの未来を牽引する」「2020年に500億のモノがインターネットにつながる」と言われている
  • IoTは世の中の「ヒト」「プロセス」「データ」「モノ」が全て繋がる世界
    • ヒト: より価値が高まる方法で人々をつなぐ
    • プロセス: 適切な情報を適切なヒトとマシンに自動連携する
    • データ: 意思決定にデータをリアルタイムで活用する
    • モノ: デバイスとオブジェクトが相互につながる

IoTの背後にある潮流

  • IoTの背後には「全てがデジタルに繋がり境目がなくなっていく」という潮流がある
  • 「社内と社外」「広告とコンテンツ」「上司と部下」「企業と個人」「自社と他社」「コンシューマと法人」「リアルとバーチャル」「男性と女性とLGBT」「人間とロボット」「ハードとソフト」などが繋がり、一つに収束していく。境目を超え、今まで繋がらなかったものがつながっていく
  • 例えば複業が増えたのもデジタル化でリモートワークが可能になったから

IoTの真価は"事業ドメイン拡張によるイノベーション"

  • GEの例がわかりやすい。元々ジェットエンジンを作っていた。今はモノを売って終わりではなくそれを保守することでサブスクリプション型のモデルに移行してきている
  • 航空機メーカーから予防保全メンテナンスで航空会社、更に航空機在配置の最適化、フライトプランの最適化などで空港、とお客様が変わってくる。
  • 生産ラインのデジタル化により新しい事業ドメインが可能になった
  • 機器の提供からサービスへ進出することでドメインを拡張子、イノベーションを目指す

  • 三菱重工様事例。風力発電の状態をIoTで繋いでモニタリング

  • 今までは風車のデータはCSVで週一で送られてくる。これを一日単位にしたいという課題があった
  • 今後は何号機がいつ壊れそうか、という予測をしていく予定

  • 総務省事例。ビッグデータの活用における路面管理の高度化実証実験

  • どこを走ったらどこの地面がボコボコしていたか、というデータを集めている
  • IoT関連投資のピークは今年いっぱいで落ち着く、とみている
  • 2020年がインフラ投資の一つのマイルストーンと考えると逆算して今年始めないと間に合わない

IoTプロジェクトの難しさ

IoTは相対的な取り組みである

技術的側面

  • デバイスは直接インターネットに繋がるわけではなく必ずフィールドエリアネットワークにつなぐ必要がある
  • まずデバイスの特性をしる必要がある。フィールドエリアネットワークのプロトコルは色いろある。お客様のネットワークはすぐに使わせてくれない。
  • ◯万台を超えるとデータの集約にかかる負荷が変わってくる。うまくブローカーがスケールしない場合もある。
  • データを集めてどうするんですか。誰が分析するんですか。どのようにするのですか。アプリケーションプラットフォームを毎回作るんですか。という課題の山
  • デバイスのロットはどうするんですか。という製造部分の課題もある。
  • 企画から始まりPoC、試作、商用化開発、量産開発、運用保守、製造と全てに精通しないと失敗する。が、全てのレイヤー、フェーズに長けたプレイヤーはいない。
  • ウフルは開発は得意だが運用は不得意。

ビジネスの側面

  • サブスクリプション型のビジネスモデルを組み立てても、モノは製造した瞬間にお金を払わないと行けないので、キャッシュフローは一時的にマイナスになる。
  • デバイスを初期費0円でサブスクリプション型にした場合、今までの製品は売れなくなる。既存事業を否定しかねない。
  • ドメインを拡張する際にこれまで経験のない分野に取り組む必要が出てくるが、どの他業種と組めばよいかよくわからない。
  • 結局経営者のコミットがないと"やってみた"で終わる

やってしまった失敗

  • デバイス内でFluentdを動かしたが128MBしかメモリがなかった。SDカードにSWAP入れるとR/Wが発生するのですぐ壊れる
  • モバイル通信、3Gは必ず切れる、という特性を理解していなかった。一日に数秒はまず切れる特性がある。Websocketクライアントはセッションタイムアウトを待って接続団を検出するのでそれまでの間死んでいる。WebSocketと3Gは相性が悪い。
  • データの特性として本来は後で分析するので実運用上は欠損だけに気をつけてファイルにためておけばよかったのに、デモ用にリアルタイムで反映させる必要があるからと、そのまま本番運用していた
  • コマンドをPush通知する際に"システム停止処理"はミッションクリティカルなのでものすごく難易度が高い
  • こんな失敗を改善するために開発にコストをかけるとPoCの見積がかさんでプロジェクトがスタートしない

IoTへの取り組み方

パターン化

  • IoTのデータはイベントで送られるもの、継続的に送られるもの、コマンドに対して送られるものの3種類
  • レガシーデバイスを活用する、となるとめんどくさい話になる。
  • threashold(閾値)くらいであればAWS IoTで行ける。もう少し込み入ったことをするならKinesisが必要になるかなと思っている

  • Node-redで作ったものをherokuやラズパイにデプロイする

プロジェクト体制

  • 試行錯誤の段階では準委任の方が向いているが、商用サービスになった場合は請負に契約を変更して切る

売れる製品、サービスを作る

  • PoCや開発の前後にビジネスモデルのデザイン、本当に必要なのかをやろう
  • 開発した後マーケティングを行う必要がある
  • webサイト、イメージビデオを作って支援していく
  • 自社のカメラのウェブサイトにどれくらい流入しているのかを可視化することでマーケターが直感的にわかるようにする
  • 経営者に対して決断を促すような支援をしている

まとめ

  • IoTは総体的な取り組みである
  • ビジネス的にはビジネスモデルの変革を伴う取り組みであること
  • 課題を乗り越えるにはパターン化すること、商用化までを見据えた計画を立てること、開発の前後のプロセスを軽視しないこと