6．研究開発から事業化への移行
6-1．技術仮説と事業仮説を分ける
技術仮説と事業仮説を分ける
研究開発テーマが技術的に成立すると、社内ではつい「これで事業化できる」と考えたくなります。
しかし、ここには大きな落とし穴があります。
技術としてできることと、顧客がお金を払うことは別です。
たとえば、モーターの電流波形から故障予兆を高い精度で検出できたとします。技術的には立派な成果です。
ただし、それだけでは事業にはなりません。
顧客が本当にその機能を必要としているのか。
設備停止を避けるために、毎月あるいは毎年料金を支払うのか。
既存の保全方法より経済的なメリットがあるのか。
これらが成立して、初めて事業になります。
そこで研究開発から事業化へ移る段階では、技術仮説と事業仮説を分けて考えることが重要です。
|
技術仮説 |
事業仮説 |
|
電流波形から故障予兆を検出できる |
顧客は停止回避に継続料金を支払う |
|
AIでサーボ調整を自動化できる |
立上げ工数削減効果が価格差を上回る |
|
デジタルツインで動作検証できる |
装置メーカーが開発ツールとして採用する |
|
電力と生産条件を同時最適化できる |
削減額の一部をサービス料金にできる |
|
セキュアな遠隔更新ができる |
顧客が年間保守契約を締結する |
技術仮説は「できるか」を問う
技術仮説では、主に実現可能性を検証します。
たとえば故障予兆なら、
どの信号を使うのか。
何日前、何時間前に予兆を検出できるのか。
誤警報はどの程度か。
設備や機種が変わっても成立するのか。
といったことです。
サーボの自動調整なら、
機械特性を自動推定できるか。
調整時間をどこまで短縮できるか。
熟練者と同等の性能を得られるか。
を確認します。
この部分は、研究開発部門が比較的得意な領域です。
問題は、その次です。
事業仮説は「買うか」を問う
技術的に優れていても、顧客が買うとは限りません。
たとえばAIによるサーボ自動調整で、立上げ時間を8時間から4時間へ短縮できたとします。
技術成果としては十分でしょう。
しかし、その顧客が年に2回しか設備を立ち上げないのであれば、年間の削減工数は8時間です。
一方で、その機能によって装置価格が100万円上がるなら、顧客は採用しないかもしれません。
逆に、装置メーカーが年間200台を立ち上げているなら、同じ技術でも価値は大きくなります。
つまり、性能だけを見ても事業性は判断できません。
誰が、どのくらい頻繁に、その機能を使うのか
まで確認する必要があります。
デジタルツインも「動いた」で終わらせない
デジタルツインも典型例です。
実機を作る前に仮想空間でPLCプログラムや設備動作を検証できた。
ここまでは技術仮説の検証です。
次に見るべきなのは、
装置メーカーが本当に使うか。
現在の立上げ方法より工数が減るか。
設備モデルを作る手間は許容できるか。
設計者が追加費用を払ってでも導入するか。
という事業仮説です。
特に注意したいのが、導入のための準備工数です。
仮想立上げによって現地調整を20時間削減できても、デジタルモデルを作るために30時間必要なら、顧客にとってはメリットがありません。
研究者は技術の効果を見る。顧客は仕事全体を見る。
この違いを意識する必要があります。
省エネルギーでは「削減額」と「料金」を同時に見る
エネルギー最適化も同様です。
AIによって設備の消費電力を10％削減できたとします。
それだけ聞くと、有望な技術に見えます。
しかし顧客の年間電力費が100万円なら、削減額は10万円です。高額なシステムを導入する理由にはなりにくいでしょう。
一方、大規模工場で年間数億円のエネルギーを使っているなら、数％の改善でも大きな金額になります。
さらに、
「削減額の20％をサービス料金として受け取る」
といった成果連動型の事業モデルも考えられます。
このように研究段階から、
技術性能 → 顧客効果 → 金額効果 → 料金体系
までつなげて考えることが重要です。
遠隔更新では「安全にできる」だけでは足りない
セキュアな遠隔ソフトウェア更新について考えてみます。
暗号化通信、認証、署名、ロールバックなどを使い、安全に更新できる仕組みを開発した。
これは技術仮説です。
しかし事業としては、
顧客が遠隔更新を許容するか。
誰が更新責任を持つのか。
夜間や設備停止中に更新するのか。
年間保守料金を支払うのか。
を確認しなければなりません。
工場によっては、技術的に安全でも、
「外部から設備を書き換えること自体を認めない」
という運用方針もあり得ます。
その場合、技術を変えるのではなく、提供方法を変える必要があります。
PoCでは二種類の検証をする
ここで重要なのがPoCの位置づけです。
PoCというと、試作品を作って顧客設備で動かすことだと思われがちです。
しかし、それだけでは半分しか検証していません。
PoCでは、
技術PoC
「本当に動くのか」
と、
事業PoC
「本当に使われ、対価が支払われるのか」
の両方を見るべきです。
たとえば設備診断なら、検知精度を評価すると同時に、
誰がアラームを見るのか。
その後どんな行動を取るのか。
保全時間は本当に短くなるのか。
月額3万円なら契約するのか。
まで聞きます。
「この機能、どうですか」と聞いてはいけません。
多くの顧客は「いいですね」と答えてくれます。
それより、
「これが有料サービスになったら契約しますか」
と聞いた方が、ずっと現実に近い回答が得られます。
技術成功だけでは前に進めない
研究開発部門では、技術目標を達成するとテーマを成功と評価します。
もちろん、それは重要です。
しかし事業化を前提にするなら、
技術仮説 ○
事業仮説 ×
というテーマを、そのまま商品化へ進めてはいけません。
逆に、
市場ニーズは非常に強いが、現在の技術では十分な性能が出ない
というケースもあります。
この場合は事業仮説が○で、技術仮説が△です。
これはむしろ、追加研究を行う価値が高いテーマかもしれません。
このように二つを分けて評価すると、
「技術をもう少し研究すべきテーマ」
「顧客価値を再設定すべきテーマ」
「事業モデルを変えるべきテーマ」
「中止すべきテーマ」
が見えやすくなります。
研究と事業開発を並行させる
ありがちなのは、
研究開発部門が3年間研究する。
技術が完成する。
その後で営業部門に渡す。
という流れです。
これでは、技術完成後に初めて、
「顧客はそこまで困っていなかった」
「価格が合わない」
「現場の運用に入らない」
と分かることがあります。
それでは遅い。
研究開発の初期から顧客ヒアリングや試験導入を行い、技術仮説と事業仮説を同時に更新していく方がよいでしょう。
研究開発から事業化への移行とは、完成した技術を営業部門へ渡すことではありません。
技術を育てながら、顧客価値と事業モデルも同時に育てることです。
では、その二つをどの段階で、どの程度まで確認すれば次へ進めてよいのでしょうか。
次回は、「6-2．事業化ステージゲート」として、アイデア、PoC、実証、商品化、事業拡大の各段階で何を確認し、何を理由に次のステージへ進めるのかを整理していきます。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
