5-3．中止基準を先に決める
新規研究開発では、「何を始めるか」には多くの時間を使います。
市場性を調べ、技術課題を整理し、経営会議で説明し、予算を確保する。ところが、いったん始めたテーマを「いつやめるか」については、意外なほど曖昧なことがあります。
その結果、
「ここまで投資したのだから」
「もう少しやれば成果が出るかもしれない」
「担当者が長年取り組んでいるから」
といった理由で、テーマが惰性で継続されます。
研究開発には不確実性がありますから、途中で計画通りにいかないのは当然です。しかし、不確実性があることと、判断基準がないことは別です。
むしろ新規テーマほど、始めるときに中止基準まで決めておくことが重要です。
「市場があるはず」では続けない
まず見るべきなのは、顧客損失です。
たとえば設備診断の新技術を開発しているとします。
技術的には面白く、顧客からも「あると便利ですね」と言われる。しかし、その設備停止や保全工数による損失を金額換算すると、年間数十万円しかない。
その問題を解決するシステムが数百万円するのであれば、導入は難しいでしょう。
この場合、
顧客損失を合理的に金額換算できない
こと自体を、中止あるいは再設定の基準にしてよいと思います。
「ニーズがある」と「お金を払うほど困っている」は違います。
既存製品との差が説明できるか
新規研究開発でよく起きるのが、開発を続けている間に既存製品が追いついてくるケースです。
当初は新しかった機能が、数年後には標準PLCに搭載されている。クラウドサービスの標準機能で同じことができる。
こうなると、研究テーマの前提そのものが崩れています。
定期的に、
「市販のPLCでできないのか」
「既存のクラウドサービスを使った方が安くないか」
と問い直す必要があります。
自社で研究開発する理由が説明できなくなったら、そのテーマは見直すべきです。
「AI精度95％」でも使えないことがある
AI関連では、評価指標の置き方に注意が必要です。
たとえば設備異常検知で、
「判定精度95％を達成した」
という結果が出たとします。
数字だけを見ると良さそうです。
しかし、正常設備を異常と判定する誤警報が1日に20回発生するのであれば、現場では使われなくなるでしょう。
最初のうちは担当者も確認してくれますが、毎日誤警報が出れば、やがて画面を見なくなります。
FAの研究では、平均的な精度だけではなく、
誤警報率、見逃し率、応答時間、異常時の影響
まで含めて実用性を判断しなければなりません。
技術的に成立したことと、現場で使えることは別です。
個別対応が増えたら要注意
PoCではうまくいったのに、事業化すると儲からない。
この原因として多いのが、顧客ごとの個別開発です。
A社ではセンサー配置が違う。
B社ではPLCが違う。
C社ではデータ形式が違う。
D社では設備仕様が非公開。
そのたびに技術者が現地へ行き、解析モデルや設定を作り直す。
これでは売上が増えるほど技術者も増やさなければならず、事業としてスケールしません。
そこで、
標準機能で何割の顧客に対応できるか
を評価します。
個別対応が一定割合を超えるなら、製品アーキテクチャを見直すか、場合によってはテーマ自体を中止する判断が必要です。
データが取れないAI事業は続かない
AIや設備診断では、研究段階のデータ確保だけで満足しないことも重要です。
最初の顧客から大量のデータを提供してもらい、高性能なモデルを作れた。
しかし商品化後は設備データを取得できない。
これでは、モデルを改善できません。
設備条件も変わります。部品も変わります。顧客の生産品種も変わります。
数年前のデータだけで作ったモデルが、その後も同じ性能を維持するとは限りません。
したがって、
事業化後も継続して現場データを取得できるか
は、テーマ継続の重要な条件です。
「できるけれど製品には載せられない」もある
FA分野では、安全性とリアルタイム性が大きな制約になります。
研究室ではAI制御がうまく動いた。ところが実機では、演算時間が安定しない。通信遅延が発生する。異常時の安全側動作を保証できない。
こうした場合、研究としては成功していても、製品として採用できないことがあります。
そのため初期段階から、
「何ミリ秒以内に応答する必要があるか」
「誤動作した場合の影響は何か」
「AIが停止したとき、従来制御へ戻せるか」
といった条件を決めておきます。
安全性やリアルタイム性を保証できないなら、対象用途を限定するか、中止する判断も必要です。
セキュリティは販売後にも費用がかかる
デジタルFAでは、販売後のコストも無視できません。
ネットワークにつながる製品を販売すれば、脆弱性への対応、ソフトウェア更新、顧客への通知などが必要になります。
つまりセキュリティ対応は、開発時の一回限りの費用ではありません。
製品を10年間供給するのであれば、その期間中の更新費用を誰が負担するのかを考えなければなりません。
それを製品価格や保守契約に転嫁できないのであれば、
「売れるが儲からない商品」
になる可能性があります。
研究テーマ評価にも、ライフサイクル全体の保守費用を入れる必要があります。
「あの人しかできない」は技術資産ではない
もう一つ、見落とされやすい中止基準があります。
特定の技術者しかシステムを構築できないテーマです。
研究段階では、優秀な担当者が一人いれば動きます。
しかし事業化すると、
営業が提案する。
サービス担当が設定する。
顧客が運用する。
別の技術者が保守する。
という状態にしなければなりません。
毎回、開発者本人が現場へ行かなければ動かない製品は、なかなか事業にはなりません。
研究成果を、
標準ソフトウェア、設定ツール、設計ルール、教育プログラム
などへ落とし込めるかを見る必要があります。
中止は「失敗」ではない
研究開発でテーマを中止すると、「失敗した」という印象を持たれがちです。
しかし本来は逆です。
市場性がないことが早く分かった。
必要精度を実現できないことが分かった。
標準化できないことが分かった。
これは立派な研究成果です。
問題なのは、分かっているのに続けることです。
研究開発資源には限りがあります。
有望でないテーマを半年早く中止できれば、その半年分の人員と予算を次のテーマへ回せます。
したがって、中止基準は研究者を評価するためのものではなく、会社の研究開発資源を守るための仕組みと考えた方がよいでしょう。
そして、研究テーマが技術的に成立した後にも、まだ大きな壁があります。
「作れる」ことと「事業になる」ことは同じではありません。
次回からは 「6．研究開発から事業化への移行」 に入り、まず *「6-1．技術仮説と事業仮説を分ける」として、技術的成功と事業的成功をどのように切り分けて検証すべきかを考えていきます。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
