6-2．事業化ステージゲート
研究開発テーマを事業化まで持っていくには、「いい技術ができたら商品化する」という考え方だけでは不十分です。
実際には、
機会領域の発見 → 顧客損失の確認 → 技術コンセプト → 試作品 → 顧客設備での実証 → 標準製品化
という段階を踏んで進みます。
このとき有効なのが、各段階に判断ポイントを設けるステージゲートです。
基本形は次のようになります。
G0 機会領域
→ G1 顧客損失確認
→ G2 技術コンセプト
→ G3 実機・試作品
→ G4 顧客設備PoC
→ G5 標準製品・事業化
重要なのは、ゲートを「進捗報告会」にしないことです。
各ゲートでは必ず、
Go／Hold／Pivot／Kill
のいずれかを判断します。
G0では「面白そう」から始めてよい
最初のG0は、機会領域を見つける段階です。
人手不足、品質変動、設備停止、エネルギー、サイバーセキュリティなどから、
「このあたりには将来大きな市場がありそうだ」
という仮説を立てます。
この段階では、多少曖昧でも構いません。
たとえば、
「熟練保全員の減少に対応する設備診断」
「旧型設備のデータ活用」
「設備立上げの自動化」
といった粒度です。
ここで細かい仕様まで決めてしまう必要はありません。
G1では「本当に困っているか」を確認する
次のG1では、顧客損失を確認します。
ここから急に現実的になります。
設備停止なら年間何時間か。
段取りなら何人・何時間かかっているか。
品質問題なら廃棄、手直し、検査にいくら使っているか。
できるだけ金額に換算します。
また、一社だけの特殊事情ではないかも確認します。
たとえば三社、五社とヒアリングして、
「同じ問題が複数の顧客で繰り返し起きている」
と分かれば、テーマとしての確度は上がります。
反対に、損失が小さい、あるいは特定顧客だけの特殊問題であれば、ここでKillすることもあります。
G2で初めて「どう解くか」を決める
G2は技術コンセプトです。
G1で確認した顧客損失に対して、
どんな情報が必要か。
どんな機能が必要か。
どの自社技術が使えるか。
を整理します。
たとえば設備停止であれば、
「モーター電流とPLCログから異常兆候を検出する」
という技術コンセプトになるかもしれません。
ここで重要なのは、最初からAIありきにしないことです。
統計処理で十分なのか。
物理モデルを使うのか。
AIを使うのか。
目的に対して最も適した方法を選びます。
この段階では、目標精度や応答時間、安全条件なども設定しておきます。
G3では「研究室で動く」を確認する
G3では、試作品や実機レベルで技術を検証します。
たとえば異常検知であれば、
実際のPLC、センサー、サーボなどからデータを取得し、アルゴリズムが動作するかを確認します。
ここでは、
検知精度、
誤警報、
処理時間、
通信負荷、
安全性
など、技術面を中心に評価します。
ただし、この段階でも事業仮説を忘れてはいけません。
試作品を顧客に見せながら、
「この結果なら実際に使えそうか」
「どこに表示すれば使いやすいか」
「既存設備へ導入する場合の障害は何か」
を聞いておきます。
G4が最も重要なゲートになる
そして重要なのが、G4の顧客設備PoCです。
研究室で動いたものを、実際の工場へ持ち込みます。
ここでは、技術性能だけでなく、現場で本当に価値を出せるかを確認します。
研究室ではきれいだった信号が、現場ではノイズだらけになるかもしれません。
正常設備と思っていたものが、設備ごとに特性が違うかもしれません。
通信制約やセキュリティ規則によって、予定していたデータが取れないこともあります。
そして何より、
顧客の業務が本当に変わるか
を確認します。
設備停止時間は減ったか。
調整時間は短くなったか。
保全担当者は実際に診断結果を使ったか。
ここを検証します。
G5は「量産できるか」ではなく「事業として回るか」
PoCが成功すると、つい「商品化しよう」と考えます。
しかしG5では、もう一段厳しい評価が必要です。
一社で成功した仕組みを、他社でも使えるのか。
設置するたびに開発者が現地調整する必要はないか。
顧客ごとにAIモデルを一から作り直す必要はないか。
営業担当者が説明できるか。
サービス部門が保守できるか。
セキュリティアップデートを継続できるか。
つまり、G5で問うのは、
「作れるか」ではなく「繰り返し売って運用できるか」
です。
ここまで成立して、初めて標準製品・サービスとしての事業化に進みます。
Goだけが正解ではない
ステージゲートというと、GoかKillの二択だと思われがちです。
しかし実際には、HoldとPivotが非常に重要です。
Goは、そのまま次へ進む。
Holdは、条件が整うまで一時停止する。
たとえば市場ニーズはあるが、必要なセンサー技術がまだ成熟していない場合です。
Pivotは、テーマの方向を変える。
たとえば予知保全を狙っていたが、故障データが少なすぎるため、
「故障予測」から「異常状態の早期検知」へ変える。
あるいはクラウド診断を想定していたが、顧客のセキュリティ制約が厳しいため、
「エッジ側で完結する診断」
へ変更する。
こうした方向転換は、失敗ではありません。
むしろPoCで得た情報を使ってテーマを修正できたということです。
Killを決められる仕組みにする
最も難しいのはKillです。
研究開発テーマには担当者の思い入れがあります。
だからこそ、ゲート前に判断基準を決めておきます。
顧客損失が一定額以上確認できなければKill。
誤警報を所定水準以下にできなければKill。
三社以上で共通ニーズを確認できなければHoldまたはPivot。
といった具合です。
こうしておけば、「せっかくここまでやったから」という理由でテーマを続けにくくなります。
ステージが進むほど投資を増やす
もう一つのポイントは、最初から大きな予算を付けないことです。
G0やG1では、調査や顧客ヒアリングを中心に小さく始めます。
技術仮説が固まったG2、G3で試作費を増やす。
顧客価値まで確認できたG4以降で、本格的な商品化投資を行う。
つまり、
不確実性が高いうちは小さく投資し、確度が上がるにつれて投資を増やす
という考え方です。
これは研究開発費を抑えるためというより、限られた資源を有望テーマへ集中するための仕組みです。
ステージゲートの目的は、研究者を審査することではありません。
仮説を一つずつ確認しながら、会社として投資リスクを下げていくことにあります。
そして、この中でも特に多くのことが分かるのが、G4の顧客設備PoCです。
研究室では見えなかった技術上の問題だけでなく、現場運用、価格、導入負担、保守方法など、事業化に必要な情報が一気に見えてきます。
次回は、「6-3．顧客実証で確認すること」として、PoCを単なる「技術のお披露目」で終わらせず、事業化判断につながる実証にするための確認事項を整理していきます。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
0 件のコメント:
コメントを投稿