優れた研究テーマは、「大きな損失」と「未解決」から生まれる
研究開発テーマの魅力度を考えるとき、私は二つの軸を見ると分かりやすいと考えている。
一つは、顧客損失の大きさである。
もう一つは、その損失が現在どの程度解決されているかである。
損失が大きく、しかも既存の解決策が不十分な領域には、大きな事業機会がある。
逆に損失が小さい領域では、技術的に面白くても市場は小さい可能性が高い。
また、損失が大きくても、すでに安価で優れた解決策が存在するなら、後発企業が利益を得る余地は限られる。
研究開発テーマを探索するときには、「市場規模が大きいか」だけでは足りない。
その市場の中で、どのような問題がまだ十分に解決されていないのかを見る必要がある。
たとえば成熟した市場でも、顧客の現場を詳しく観察すると、意外なほど大きな未解決問題が残っていることがある。
装置の調整に熟練者が必要である。
異常原因の特定に何時間もかかる。
点検のためだけに設備を停止している。
帳票作成に人が張り付いている。
予防保全のために、まだ使える部品を大量に交換している。
こうした問題は、一見地味である。
しかし、顧客が毎年払い続けている損失を合計すると、非常に大きな金額になることがある。
そこにAI、センシング、制御、材料、シミュレーションなどの技術を当てれば、新しいプロダクトが生まれる。
この順番が重要である。
AIがあるからAI製品を考えるのではない。解決すべき損失があり、その解決手段としてAIが有効ならAIを使う。
これがDQLに求められる発想である。
技術者は「要求仕様」の一歩手前まで行かなければならない
設計者は通常、要求仕様を受け取って仕事を始める。
流量はいくら必要か。温度範囲はいくつか。重量は何kg以下か。精度はいくらか。寿命は何年か。
こうした要求を満たすことは設計者の重要な役割である。
しかしDQLは、要求仕様のさらに一歩手前へ行く。
なぜその流量が必要なのか。
なぜその精度が必要なのか。
その性能を達成すると、顧客のどの損失が減るのか。
もし要求を少し緩めても顧客価値が変わらないのであれば、もっと安い設計ができないか。
逆に、要求されていない性能でも、顧客損失を大きく減らせるのであれば、新しい提案ができないか。
ここまで考えると、技術者は単に要求仕様を満たす人ではなくなる。
要求仕様そのものを設計できる人になる。
これはスマイルカーブの上流へ技術者が踏み出すということである。
顧客要求を技術特性へ展開するQFDなどの手法も、この段階で有効になる。
ただし、QFDの表を完成させることが目的ではない。
何を重視すれば、顧客にとって最も大きな価値を生み出せるかを考えるために使うのである。
顧客が語る「欲しいもの」を、そのまま信じてはいけない
顧客起点というと、「顧客に聞けばよい」と思われがちである。
しかし、これは半分正しく、半分危険である。
顧客は現在の困りごとについては詳しい。
一方で、その問題をどのような新しい技術で解決できるかまでは分からない場合が多い。
もし20年前に顧客へ「どんな携帯電話が欲しいですか」と聞けば、より小さく、電池が長持ちし、通話音質の良い携帯電話という答えが多かっただろう。
全面タッチパネルで、カメラ、地図、決済、動画、SNSまで統合された端末を要求仕様として答えられた人は多くなかったはずだ。
だから、顧客の言葉をそのまま製品仕様にしてはいけない。
DQLが聞くべきなのは、「何が欲しいですか」だけではない。
現場で何をしているのか。
どこで時間がかかっているのか。
何が失敗しているのか。
その失敗が起こると何が困るのか。
現在はどのような代替手段を使っているのか。
そこにどれだけの金、人、時間が投入されているのか。
顧客が口にする要求の奥にある「本当に解決したい問題」を探す。
ここがプロダクト企画の腕の見せどころである。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
0 件のコメント:
コメントを投稿