2020年06月23日

デジタルトランスフォーメーション

コラム

※所属・役職は記事公開当時のものです。

IoTサービス事業の立ち上げにおいて、マーケティング・営業担当は、情報システム担当者とコミュニケーションをとりながら、プロジェクトを進めていかなくてはならない。

しかし、ITに不慣れな担当者にとっては、情報システム部門に企画内容を伝え、出来上がってきたシステムに対して適切なフィードバックをするのは容易ではない。

本稿では、ITが得意ではないマーケティング・営業担当者の方でも、ビジネスやサービスの要件から、最適なIoTサービスの基盤を導出できる3つのポイントを解説する。

なぜIoTサービスに取り組むのか、その背景

約15年前、「ユビキタス社会」という言葉が流行していた。「あらゆるものが、インターネットを介して、どこでも、いつでも、つながるという社会」という趣意だったが、現在は、「Internet of Things:IoT」という概念で、ユビキタス社会のようなサービスが普及しつつある。

身近なものだとスマートウォッチと呼ばれるIoTサービスがイメージしやすいかもしれない。腕に着けるだけで、時計の基本機能を有しながら、自身のバイタルデータ(心拍、呼吸数、血圧など)や行動(歩数、移動距離など)を記録し、1日の行動記録のグラフやデータを踏まえたコンテンツ情報の提供(健康情報や生活関連情報など)をしてくれるものである。

利用者は、普段見えないものが見え、知ること自体に喜びを感じる、または、知って生活をより豊かにするアクションを考え実行できること等、ベネフィットを得て継続的に利用していく。

IoTサービスに企業が取り組む理由のひとつに、「売り切りビジネス」から「買い手をサポートするパートナービジネス」に領域を拡大できることが挙げられる。

購入後もデータを介在して顧客の接点を保有し続けることができるため、顧客の利用データをもとに自社製品を活用したライフスタイルの向上支援やサポート活動を行うことができるようになる。

買ってもらったら終わりの売り切りビジネスから、購入後も継続的な関係性を保つパートナービジネスになり、他社へのスイッチング防止(離脱抑止)、新商品へのアップセルや関連商材のクロスセルなどの商機が望めるからである。

実現の要となっているのが、モノに付けたセンサーである。センサーや通信コストが相対的に安価になっていること、また従前より「モノからコト」化が求められていることもあり、メーカーによるIoTサービス事業立ち上げが増えている。

良質なサービス形成に、マーケティングとITの融合は不可欠

IoTサービス事業の検討プロジェクト体制で、一般的に多いのは、経営企画、マーケティング・営業、情報システムの組み合わせだ(情報システムの部分は、グループ会社やベンダーに外注することが多いが)。

この事業において、経営企画は、主に経営戦略に基づく計画策定、新規事業の予算計画策定、コスト管理がミッションである。マーケティング・営業担当のミッションは、IoTサービスの企画やその売上予算の達成。情報システム部門は、マーケや営業担当の考えるサービス企画・要求に応えられるIoTサービスの基盤づくりが求められる。

このようなプロジェクトでは、主にマーケティング・営業担当が、サービスの企画や、どのような価値を提供したいのかを、情報システム部門に具体的に伝え、そして出来上がってきたシステムの仕組みに対して、フィードバックをしていかなければならない。

ここでとても高い壁が現れる。往々にして、マーケティング・営業担当者にITに関するケイパビリティはほぼないにもかかわらず、IoTサービスというITサービスに対して、フィードバックをしなくてはならないのである。

マーケティング・営業担当者は難度の高い課題を与えられるわけだが、この壁を乗り越えない限り、良質なサービスを作ることはできない。ニーズや要件の理解が浅いままでは、情報システム部門も、Canベース(できること)でのプロダクトアウトにならざるをえない。とにかく"形"にしただけものに、事業収益性やサービスの拡張性が伴う理由は見つからないのである。

マーケッターと情報システム担当者が共通言語をもってサービスの基盤を企画できるよう、本稿は、ITの知識が不十分と課題を抱えているマーケティング・営業担当者に向けて、IoTサービス基盤を企画する際のポイントをお伝えしたい。

IoTサービス基盤の最適化に向けた3つの確認ポイント

まず、読者の皆さまと話の土台を共有するために、言葉の定義やIoTサービスの構造を整理したい。ご理解いただけるようなるべく簡略化してご説明したい。

〈言葉の定義〉

①センサー・デバイス
モノに付けて、データの収集や処理を行う装置のこと。データを取得するセンサー、センサーから収集したデータの加工処理や、ネットワークにつなげ自社のシステムにデータを流すマイクロコンピューター(以後、マイコン)なども含む。

②システムインフラ
センサー・デバイスで収集・整形加工したデータの保管や処理を行うシステムのこと。自社のデータセンターにサーバを構築する場合もあれば、GoogleやAmazonのクラウドサービスを利用する場合もあるが、本稿ではクラウドサービスの利用を前提とする。

③アプリ
IoTサービス利用者の端末(PCやスマートフォン)で動く、アプリケーションのこと。収集したデータをリアルタイムでモニタリングできるような時系列グラフの表示や、アラート機能や履歴管理など、いわゆるアプリと呼ばれるもの。

〈IoTサービスの構造〉

IoTサービスは、大まかには、以下5点で成り立っているとする。

図1 IoTサービスの構造

図1 IoTサービスの構造

以降は、この仮定で話を進める。

筆者は、これまでの経験から、マーケティング・営業担当者がIoTサービス基盤へのフィードバックを行う際に、次のポイント3つを押さえるとよいと考えている。

  • ミッションクリティカルの有無

  • 事業拡大の方針

  • 即時性ニーズの有無、その程度

以下、順番に説明していく。

ミッションクリティカルの有無

ミッションクリティカルとは、「目的を達成するにあたり、なくてはならない重要な要素」を指す。要するに、本IoTサービスが、何かしらの理由で停止・遅延したときに、利用者に致命的な影響を与えるものかどうか、という問いである。

致命的な影響とは、人間の生命を脅かすものといった一般的な理解を得られるものから、利用者側の価値観によって致命的であると位置づけられるものまで、幅広い。いずれにせよ、IoTサービス提供者側が、「本IoTサービスはミッションクリティカルなものである」と宣言すれば、ミッションクリティカル性を有するサービス(利用者にとっては、ひとつのコンポーネントという言い方が正しいかもしれない)になるし、あくまで補助的な役割であるとすれば、ミッションクリティカル性を有さない。

ミッションクリティカル性を有する場合は、IoTサービス基盤は、耐久性、可用性、対応サービスで高いレベルが求められる。上述のIoTサービスの構造①~⑤にあてはめると、フィードバックポイントの例は、以下のようになる。

①センサー・デバイス

  • センサー・デバイスは、どの程度の耐久性があるのか。壊れにくいものになっているか

  • 故障の予兆を検知する仕組みはあるか

  • 故障した場合、どのように検知して、アラートが通知されるのか

  • 故障した場合でも、継続してサービス提供が可能な仕組みがあるのか

  • データ送信や処理が遅延した場合、どのように検知して、アラートが通知されるのか

  • データ送信や処理が遅延した場合、リカバリーの仕組みはあるのか、どの程度時間を要するか

②システムインフラ

  • 故障の予兆を検知する仕組みはあるか

  • 故障した場合、どのように検知して、アラートが通知されるのか

  • 故障した場合でも、継続してサービス提供が可能な仕組みがあるのか

  • データ受信や処理が遅延した場合、どのように検知して、アラートが通知されるのか

  • データ受信や処理が遅延した場合、リカバリーの仕組みはあるのか、どの程度時間を要するか

  • 受信するデータの容量・頻度が急激な増加をした場合、能力超過による遅延が発生しない仕組みがあるか

③アプリ

  • ①や②に起因する障害の発生をいち早く通知する仕組みがあるか

④ネットワーク

  • ネットワークの障害や遅延を、どのように検知して、アラートが通知されるのか

⑤サービス運用(ヘルプデスク、製品故障対応、システム保守運用、障害対応)

  • 24時間365日の問い合わせ、障害対応の窓口を設置しているか

  • サービスのSLAは、高い数値を約束できるか(たとえば99.xx%以上)

  • 障害発生時、24時間365日で即時対応するか

ミッションクリティカル性を有するサービス(利用者にとってはコンポーネント)の場合、高いレベルの耐久性・可用性・サービス対応が求められるため、高コストになる。一方、一度利用されれば、本サービスがないと利用者は不便を感じることになるので、競争力のある価格(高価格)設定も可能だろうし、継続的な利用も見込むことができる。

結局のところ、品質とコストのバランスをどう取るかだとは考える。いずれにせよ、ミッションクリティカル性を有するのかどうかを決め、耐久性、可用性、対応サービスのレベル感を、関係者間で統一し、議論の土台を整えることに意味があると考えている。

事業拡大の方針

続いて、「事業拡大の方針」について述べる。経営戦略を検討するうえで、有名なフレームワーク「アンゾフの成長マトリックス」を用いて、説明をしていきたい。

図2 アンゾフの成長マトリックス

図2 アンゾフの成長マトリックス

大多数の企業が、IoTサービスにおいて、よっぽど勝てる見込みがない限り、いきなりB)、C)、はたまたD)の領域に参入し、新規事業を立ち上げようとはしないだろう。

まずは、A)の領域において、特に自社で取り扱いのあるプロダクトなどにセンサーを付けて、サービス化して、と始めることが通常と考える。

ここでいう事業拡大の方針とは、

  • A)だけにリソースを集中し、既存商材の高度化の一点で、事業を継続していくのか

  • A)を足掛かりに、B)やC)、さらにはD)にまで、事業拡大していくのか

という問いである。

前者と後者の選択により、大きく変化する点は、センサー側で収集したデータの取り扱いである。

前者は、高度化した初期サービスのまま拡張しない(新しいイベントを計測できる等)といった極端な場合、生データは不要で、加工処理後のサービスに利用するデータだけであればよいので、センサー・デバイス側で処理した後、生データは捨てることができる(結果として、通信コストが安くなる)が、後者は、その生データが、何か新しいサービスを生み出す可能性を持つため、容易に捨てることができない(結果として、通信コストやデータ保管にかかるコストが高くなる)。

たとえば、人間のバイタルデータ(心拍数や呼吸数など)のデータを収集する際、1/200~1/100秒の頻度で、振動のデータ収集が必要になる。つまり、1秒間に生成されるデータ数は、100~200個。1分間に換算すると、その60倍なので、6,000~12,000個になる。

この生データから、1分間あたりの心拍数を算出しているわけだが、

  • 生データは、1分間あたり6,000~12,000個

  • 心拍数は、1分間あたり1個(たとえば、ある1分間の心拍数が72回なら「72」という数値データ)

もし、心拍数だけでよいのであれば、センサー・デバイスから、1分間あたり1個のデータを送信するだけでよいが、生データまで必要になると、最大で12,000倍のデータが、ネットワークに流れ、システム側での管理コストもかかるわけである。

さらには、前者の場合、センサー・デバイス側の処理負荷がかかるので、マイコンの処理性能を高める必要性やプログラムの開発が必要になることも容易に想像できるであろう。

いわゆる、エッジコンピューティングという概念が求められる(エッジというのは、筆者は、"現場・先端"という意味で捉えており、エッジコンピューティングとは、なるべく端末の近くにサーバを分散配置し、処理負担を軽減するネットワーク技法だ。現場で処理をスムーズにスピーディに行うことでメリットを享受しようとするコンセプトという捉え方をしている)。

つまり、IoTサービス基盤のコンセプトが、分散処理型になるということである。

一方、システムインフラ側に生データを収集するのであれば、システムインフラ側にて一括でデータ処理をかけてしまった方が早いので、中央集権型になる。

図3 分散処理型と中央集権型のメリット・デメリット

図3 分散処理型と中央集権型のメリット・デメリット

まとめると、事業拡大方針において、

・A)だけにリソースを集中し、既存商材の高度化の一点で、事業を継続していく場合
⇒分散処理型のIoTサービス基盤のコンセプト。センサー・デバイス側に処理性能の高いマイコンが必要。一方、システムインフラ側で複雑な処理は想定しないため、機能はシンプルで安価で構わない。

・A)を足掛かりに、B)やC)、さらにはD)にまで、事業拡大していく場合
⇒中央処理型のIoTサービス基盤のコンセプト。センサー・デバイス側は、データ収集がメインで、複雑な処理は実施しない想定。ただし、システムインフラ側で複雑な処理や大量のデータの保管を想定しているため、データ整形・加工の機能やサイズの大きいハードウェアが必要になる。

今後の事業方針を明確にすることで、センサー・デバイス側に軸足を置くのか、システムインフラ側に軸足を置くのかが見えてくる。

即時性ニーズの有無、その程度

最後に「即時性ニーズの有無、その程度」についてだが、IoTサービスは、データが肝であることはご理解いただいているとおりである。しかし、センサー・デバイスから取得したデータを送信する量や頻度が増えると、通信コストに跳ね返ってくる。

IoTサービスのコストは、センサー・デバイスのコストや、システムインフラ構築・運用のコスト、ヘルプデスクなどのオペレーションコストなどあるが、ランニングコスト(月額コスト)として、大きな割合を占めるのは、この通信コストである(システムインフラは、ある意味このデータ量と頻度が基となってコストが決まると考えれば、データに着目すべきである)。

まずデータの量については、通信プロトコルなどを工夫することで、ある程度コスト削減することも可能な場合がある。だが、およそ必要なデータで設計されていることが多いため、内容そのものを削るといったことは難しく、コスト削減につながるとは限らない。

一方、データの送信頻度は検討の余地があると考えられる。サービスによっては、利用者アプリへの通知や表示に、リアルタイムが求められるものもあれば、1時間おき、半日おき、1日おきに通知や表示があればよい、いわゆるバッチ処理(一定期間集めたデータを一括処理する方法)でも構わないものもある。

従って、サービス品質のバランシング(過剰品質になっていないか)を考えて、サービス提供上、リアルタイムでなければならないもの、とバッチで対応可能なものの選り分けを行い、センサー・デバイスからデータ送信頻度を検討することが事業コストの最適化を図るためには欠かせない。

まとめ

IoTサービス基盤の企画のポイントごとに、チェックすべき事柄をまとめると、次のようになる。

・ミッションクリティカル性の有無
⇒IoTサービス構成品の耐久性、可用性、サービスの求められるレベル

・事業拡大の方針
⇒IoTサービス基盤のコンセプト(分散処理型、中央処理型)

・即時性ニーズの有無、その程度
⇒デバイス・センサーからのデータ送信頻度

業界・企業のDX(デジタルトランスフォーメーション)が求められている現在、異なる領域を掛け合わせて、新しい価値を提供することに私たちはチャレンジしていかなくてはならない。IoTサービスもまた、マーケッター×IT人材が、互いを理解し、ユーザーを知り、どこまで融合していけるかどうかが問われていると考えている。

本稿がその解決に少しでも役に立ち、良質なサービスが世の中に生まれていく一助になればありがたい。