2026/09/23

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事⑦

 

3章 技術テーマではなく「顧客の損失」を探せ

儲かるプロダクト企画は、技術ではなく「困りごと」から始まる

 

研究開発テーマは、どこから生まれているのか

企業の研究開発会議に出ると、よく目にする光景がある。

新しい材料が見つかったので用途を探したい。AIを使った新製品を考えたい。競合が取り組んでいるので、自社でも始めたい。社内に長年蓄積してきた技術があるので、それを生かせる市場を探したい。

どれも研究開発テーマとして不自然ではない。

実際、優れた技術シーズから新しい事業が生まれることはあるし、技術の蓄積そのものが企業の重要な資産であることも間違いない。

しかし、一つ注意しなければならない。

「技術があるから、それを使える製品を考える」という順番だけで研究開発テーマを作ると、技術的には魅力的でも、事業としては弱いプロダクトが生まれやすい。

技術者にとって面白いことと、顧客がお金を払いたいことは同じではないからである。

前回、研究開発とは本質的に「賭け」であると述べた。

だとすれば、最初に考えるべきなのは「どの技術に賭けるか」ではない。

どの顧客課題に賭けるかである。

技術は、その課題を解決するための手段として後から選べばよい。

 

顧客は「製品」ではなく「損失の解消」にお金を払う

企業が製品を販売していると考えると、商品企画はスペックの競争になりやすい。

もっと速くしよう。もっと軽くしよう。精度を上げよう。耐久性を高くしよう。機能を追加しよう。

しかし、顧客の側から見ると少し違う。

顧客は、性能そのものを買っているとは限らない。

その性能によって、自分が抱えている問題が解決されるからお金を払っている。

たとえば工場で使われるバルブを考えてみよう。

顧客が欲しいのは、必ずしも「高性能なバルブ」ではない。

液漏れが起きて設備が停止する時間を減らしたい。薬液交換時の作業負担を減らしたい。保守周期を延ばしたい。製品への異物混入を防ぎたい。設備立ち上げ時の調整時間を短縮したい。

顧客にとって価値があるのは、このような損失が減ることである。

設備停止が1時間短くなれば、いくらの利益が生まれるのか。

保守作業が年間10回から2回になれば、人件費や交換部品費はどれだけ減るのか。

歩留まりが0.5%改善すれば、年間いくらの価値になるのか。

そこまで考えると、「高性能」という曖昧な言葉が、具体的な経済価値へ変わってくる。

私は、研究開発テーマを考えるときに最初に見るべきものは、この顧客が現在負担している損失だと考えている。

 

「困っている」と「お金を払う」は同じではない

ただし、顧客が困っていれば何でも事業になるわけではない。

ここも重要である。

顧客にヒアリングすると、さまざまな不満が出てくる。

もっと軽いほうがよい。表示が見にくい。操作が少し面倒だ。デザインを変えてほしい。報告書を自動で作ってほしい。

どれも要求としては正しい。

しかし、その要求を解決するために顧客が追加で100万円を払うかというと、話は別である。

事業になる顧客課題には、一定の「痛み」がある。

問題が発生すると生産が止まる。人手が大量に必要になる。不良が出る。事故の可能性が高まる。顧客からクレームを受ける。熟練者がいなければ仕事ができない。

このような問題には、すでに何らかのコストが発生している。

言い換えれば、顧客は現在も、その問題を放置するための「料金」を払っている。

それが人件費として表れているかもしれない。

廃棄損失かもしれない。

設備停止による機会損失かもしれない。

あるいは担当者の膨大な時間として埋もれているかもしれない。

ここに事業機会がある。

顧客が現在1000万円の損失を負担している問題を、200万円で大幅に減らせるのであれば、そこには明確な経済合理性がある。

反対に、年間1万円程度の不便を解決するために100万円の製品を開発しても、よほど別の価値がない限り事業にはなりにくい。

つまり、商品企画で問うべきなのは、

「顧客は何を欲しがっているか」

だけではない。

「顧客は今、何にどれだけ損をしているのか」

なのである。


※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/22

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事⑥

DQLは「不確実性を減らす順番」を考える

ここで、設計品質リーダー(DQL)の役割が見えてくる。

DQLは、最初から正解を知っている人ではない。

研究開発テーマに存在する不確実性を整理し、「何から確かめるべきか」を考える人である。

ある製品では、最大の不確実性が技術にあるかもしれない。

別の製品では、技術的には簡単だが、顧客がお金を払うかどうかが分からないかもしれない。

また別のテーマでは、市場性は十分でも、原価が下がらなければ事業にならないこともある。

こうした状況で、手当たり次第に実験していてはいけない。

事業の成否を最も左右する不確実性から先に潰していく必要がある。

そのために、顧客調査を使うこともある。

QFDを使って顧客価値を整理することもある。

FMEAによって重大な技術リスクを洗い出す場合もある。

実験計画法や統計解析を使って、少ない試験回数で技術仮説を検証する場合もある。

重要なのは、どの手法を使ったかではない。

限られた時間と費用で、意思決定に必要な不確実性をどれだけ減らせたか

である。

ここでも、手法は目的ではない。

より良い賭けをするための道具なのである。

 

優れたDQLは「やる理由」と同時に「やめる条件」を決める

研究開発を始めるとき、多くの企業は「なぜこのテーマをやるのか」を議論する。

市場が成長している。顧客ニーズがある。自社技術が使える。競合より有利である。

ところが、「どのような状態になったらやめるのか」は、あまり議論されない。

これは危険である。

研究開発が始まると、担当者にはそのテーマへの思い入れが生まれる。

設備を購入する。人員を投入する。顧客にも説明する。役員会で承認を受ける。

時間が経つほど、「今さらやめられない」という心理が強くなる。

そして、本来なら撤退すべきテーマに追加投資を続けてしまう。

ギャンブルでいう「負けを取り戻そうとする状態」とよく似ている。

だからこそ、優れた研究開発では、テーマを始める段階で撤退条件を考えておく必要がある。

この性能が達成できなければ中止する。この原価を超えるなら再検討する。この期限までに顧客評価が得られなければ撤退する。

あらかじめ条件を決めておけば、結果が悪かったときにも冷静に判断しやすい。

挑戦する勇気と、撤退する勇気はセットなのである。

 

「賭けない会社」は、本当に安全なのか

研究開発に対する最大の誤解は、「投資しなければ損をしない」と考えることである。

確かに、開発をしなければ開発費は発生しない。

新しい技術に挑戦しなければ、技術的な失敗も起こらない。

しかし、市場は止まってくれない。

顧客要求は変化する。競合は新製品を出す。新技術が既存製品の価値を変える。異業種から新しいプレイヤーが参入する。

企業が何もしなくても、周囲は動いている。

つまり「現状維持」もまた、一つの選択である。

そして、その選択にもリスクがある。

研究開発テーマへの投資額は会計上はっきり見えるが、挑戦しなかったことで失った将来の売上は、損益計算書には「損失」として表示されない。

ここに組織経営の難しさがある。

見えるリスクだけを減らすと、見えないリスクが膨らんでいく。

DQLには、製品の故障リスクだけでなく、

「その技術を開発しないリスク」

まで見る視点が必要になる。

 

企業に必要なのは「正しいギャンブラー」である

ここまで「賭け」という少し刺激的な表現を使ってきた。

しかし、私が言いたいのは、経営や研究開発を運任せにしようということではない。

むしろ逆である。

未来には不確実性があるという事実から目をそらさず、その中でできるだけ合理的な判断をしようということである。

何に賭けるのか。

どれだけ賭けるのか。

何を確認してから次の投資へ進むのか。

どこまで損失を許容するのか。

どの条件になれば撤退するのか。

そして、成功した場合にはどれほど大きな価値を得られるのか。

これらを考えたうえで意思決定するのであれば、それは無謀なギャンブルではない。

企業経営そのものである。

これからのDQLに求められるのは、失敗を恐れてすべての挑戦を止めることでも、技術への情熱だけで突っ走ることでもない。

不確実性を認識し、それを少しずつ減らしながら、勝負すべきところでは会社の資源を投入する。

そして、仮説が間違っていたなら、過去への執着を捨てて次の機会へ移る。

そんな「正しく賭けられる技術者」を、企業の中にどれだけ育てられるか。

それが、研究開発型企業の競争力を大きく左右する時代になっている。

では、その「賭け先」はどのように探せばよいのだろうか。

新しいAIが登場したからAI製品を考える。新素材を開発したから用途を探す。競合が始めたから自社も研究テーマにする。

これでは、技術が先にあり、顧客が後からついてくることになる。

次回は視点を逆転させたい。

研究開発テーマを探すとき、最初に見るべきものは「技術」ではない。

顧客が現在支払っている損失である。

3章では、「技術テーマを探す」のではなく、「顧客の損失を探す」という考え方から、儲かるプロダクト企画の出発点を考えてみたい。

※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/21

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事⑤

 研究開発では「成功確率」だけを見てはいけない

企業の研究開発会議では、「成功確率はどのくらいか」という問いがよく出る。

もちろん重要な質問である。

しかし成功確率だけでテーマを判断すると、組織は次第に小さなテーマばかりを選ぶようになる。

既存製品の改良なら成功確率は高い。既存顧客向けの追加機能も比較的読みやすい。すでに成熟した技術を使えば、技術リスクも小さい。

その結果、「確実にできそうな開発」がテーマ一覧を埋め尽くしていく。

ところが、それでは会社の未来を変えるような事業は生まれにくい。

研究開発で本当に考えるべきなのは、成功確率だけではなく、成功した場合にどれほど大きな価値が生まれるのか、失敗した場合にどこまで損失が発生するのかという全体像である。

単純化すれば、

成功する可能性 × 成功時の価値

失敗する可能性 × 失敗時の損失

の両方を見る必要がある。

これは期待値という考え方に近い。

成功確率90%でも、成功時の利益が小さければ魅力的なテーマとは限らない。

反対に成功確率30%でも、成功すれば巨大な市場を開拓でき、途中で撤退すれば損失を限定できるのであれば、十分に挑戦する価値がある。

重要なのは「当たりやすさ」ではない。

会社として、その賭けを繰り返したときに利益が残る構造になっているかどうかである。

 

「失敗しないテーマ」ばかりを選ぶ会社は、少しずつ弱くなる

組織には不思議な性質がある。

失敗したテーマの担当者は説明を求められるが、「挑戦しなかったこと」について説明を求められることは少ない。

そのため、組織の合理的な人間ほど、次第に安全なテーマを選ぶようになる。

成功する可能性が高い。既存技術が使える。既存顧客がいる。投資額が小さい。社内の反対も少ない。

一つひとつを見ると、非常に合理的に見える。

しかし、それを10年続けた会社はどうなるだろうか。

商品は少しずつ改良される。品質も少しずつ良くなる。コストも毎年数%下がる。

ところが、競争のルールそのものを変える技術や、新しい顧客価値を生み出す商品には投資していない。

気がついたときには、市場そのものが縮小している。

あるいは、まったく別の技術を持つ企業が市場を奪っている。

これは典型的な「何もしなかったリスク」である。

企業では、行動した結果の失敗は見えやすい。

一方で、行動しなかったために失った利益は見えにくい。

だからこそ、リスク管理という言葉が「何もしないための論理」になってはいけない。

本来のリスク管理とは、リスクをゼロにすることではない。

取る価値のあるリスクと、取ってはいけないリスクを区別することである。

 

「小さく賭ける」という技術

ここまでの話をすると、「それでは大胆なテーマにどんどん投資すればよいのか」と思うかもしれない。

もちろん、そうではない。

研究開発にはギャンブルと決定的に違うところがある。

自分たちの行動によって、成功確率を変えられることである。

市場について分からなければ、顧客に聞くことができる。

技術成立性が分からなければ、実験できる。

原価が不明なら、簡易モデルを作ることができる。

量産性が不安なら、小規模な試作を行うことができる。

つまり研究開発では、一度に全資源を投入する必要はない。

最初は小さな投資で仮説を検証し、確信が高まるにつれて投資額を増やしていけばよい。

私はこれを、「小さく賭ける」と考えると分かりやすいと思う。

たとえば1億円の開発をいきなり承認するのではなく、まず300万円で顧客ニーズと技術成立性を確認する。

そこで有望なら次に1000万円を投入する。

さらに市場性や量産性を確認し、成功可能性が高まったところで本格投資する。

反対に、途中で仮説が崩れれば止める。

この考え方を徹底すれば、挑戦回数を増やしながら、一つの失敗で会社が大きな損失を被ることを防げる。

研究開発の強い企業とは、必ずしも未来を正確に予測できる企業ではない。

未来が分からないことを前提として、安く、早く学べる企業なのである。

 

※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/20

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事④

 2章 研究開発とは、本質的に「賭け」である

不確実な未来に、企業はどう資源を投じるべきか

「確実に成功する研究開発」は存在しない

新しい製品や技術の研究開発を始めるとき、経営者や技術者はしばしば「成功確率をもっと高めてから判断したい」と考える。

その気持ちはよく分かる。

研究開発には金がかかる。設備も必要になる。人材も投入しなければならない。数年間取り組んだ末に事業にならなければ、会社にとって大きな損失になる。

だから、できるだけ確実なテーマを選びたい。

しかし、ここには根本的な矛盾がある。

もし成功がほぼ確実に分かっているのであれば、それはもはや「研究」ではない場合が多い。技術的にも市場的にも答えが見えているなら、競合企業にも同じことが見えている可能性が高い。

大きな事業機会が生まれるのは、多くの場合、その先に何があるかまだ十分に分かっていない領域である。

新しい材料、新しい製造方法、新しいソフトウェア、新しい顧客価値、新しいビジネスモデル。そのどれにも不確実性がある。

技術が成立するかどうか分からない。成立しても量産できるか分からない。量産できても顧客が買うか分からない。顧客が買っても十分な利益が出るか分からない。

研究開発とは、こうした不確実性を抱えたまま、それでも未来に資源を投じる行為なのである。

この意味では、研究開発は本質的に「賭け」である。

もちろん、競馬やカジノと研究開発が同じだと言いたいわけではない。

重要なのは、「結果が確定していない未来に、現在の資源を投入する」という構造が共通しているということである。

 

企業はすでに毎日のように「賭け」をしている

ギャンブルという言葉には、どうしても無謀、浪費、偶然任せといった否定的なイメージがつきまとう。

そのため経営の世界では、「われわれはギャンブルをしているのではない」と言いたくなる。

しかし現実には、企業は毎日のように未来へ賭けている。

新しい工場を建てる。新製品の開発に数億円を投入する。若い技術者を特定分野の専門家として育成する。スタートアップと共同研究を始める。AIや自動化設備を導入する。新しい市場へ営業拠点を置く。

これらはすべて、「将来、投入した資源以上の価値が返ってくる」という仮説に基づく投資である。

将来が確実なら投資判断は簡単だ。

しかし実際には、未来は確定していない。

だから経営とは、ある意味では無数の不確実な選択肢から、「どこに会社の資源を置くか」を決め続ける仕事である。

問題なのは、賭けをすることではない。

良い賭けと悪い賭けを区別できるかどうかである。

これは研究開発でもまったく同じだ。

 

「無謀な賭け」と「合理的な賭け」は何が違うのか

では、研究開発をギャンブルになぞらえるなら、無謀なギャンブルと優れた研究開発は何が違うのだろうか。

最大の違いは、結果ではない。

成功したから良い判断だったとは限らないし、失敗したから悪い判断だったとも限らない。

たとえば成功確率が10%しかなく、成功してもわずかな利益しか得られないテーマに巨額の投資をしたとする。

たまたま成功すれば、担当者は英雄になるかもしれない。

しかし、それは良い意思決定だったとは言えない。

逆に、成功確率が60%あり、成功すれば大きな市場を獲得でき、失敗した場合の損失も限定されているテーマがあったとする。

十分な検討のうえで投資した結果、たまたま失敗したとしても、その判断そのものが間違っていたとは限らない。

この区別は非常に重要である。

私たちは結果を見た後で、過去の判断を評価してしまいがちだからだ。

成功企業を見ると、「あの経営者は先見の明があった」と言う。失敗すると、「最初から無謀だった」と言う。

しかし、その時点で入手できた情報を使って、どのような判断をしたのかを見なければ、本当の意思決定の質は評価できない。

DQLに必要なのも、この視点である。

結果論ではなく、

その時点で、どの選択肢にどれだけの価値が期待できたのか

を考える力である。


※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/19

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事③

手法を知っているだけでは「稼げる人材」にはならない

製造業では、さまざまな優れた手法が使われている。

顧客要求を整理するQFD、リスクを検討するFMEA、効率的に実験するための実験計画法、ばらつきに強い製品をつくるロバスト設計、データから事実を読み取る統計解析などである。

これらはいずれも重要な道具である。

しかし、ここで注意しなければならない。

手法を使えることと、事業を成功させられることは同じではない。

立派なQFDを作ったのに売れない製品もある。膨大なFMEAを作成したのに市場で問題を起こす製品もある。高度な解析を行い、性能的には素晴らしいものができたにもかかわらず、利益が出ないこともある。

原因は単純である。

「手法を正しく使うこと」が目的になってしまったからである。

DQLにとって、QFDFMEAも統計も目的ではない。

顧客価値を発見し、技術を選び、リスクを判断し、より良い意思決定をするための道具である。

極端に言えば、目的を達成できるなら、すべての手法を使う必要はない。

反対に、必要であれば複数の手法を組み合わせればよい。

重要なのは手法に忠実であることではなく、事業の目的に忠実であることだ。

「売れる製品」を考えるところから設計品質は始まる

設計品質という言葉を聞くと、多くの人は設計図面ができた後の品質を想像する。

強度は十分か。寿命は満足しているか。安全性に問題はないか。製造ばらつきに耐えられるか。

もちろん、それらは重要である。

しかし、本来の設計品質はもっと上流から始まっている。

そもそも、その製品は顧客が必要としているものなのか。

その問題は、解決するだけの経済価値を持っているのか。

顧客はその価値に対して、十分な金額を支払うのか。

競合よりも優れた解決方法を提供できるのか。

そして、その事業を自社が続けることで利益を生み出せるのか。

この問いに答えられなければ、いくら製品そのものの完成度を上げても、「良い設計」とは言い切れない。

これからのDQLに必要なのは、図面の中だけを見る目ではない。

製品の向こう側にいる顧客を見る目であり、そのさらに向こう側にある事業を見る目である。

 これからの技術者には「正しく賭ける能力」が必要になる

ここまで読むと、「そんなことは経営者や事業企画部門が考えればよい」と思う人もいるかもしれない。

しかし、それでは遅い。

ディープテック、AI、半導体、エネルギー、モビリティ、産業機器など、技術そのものが事業競争力を左右する領域では、技術を理解しないまま有望なテーマを選ぶことは難しい。

一方で、技術だけを知っていても、儲かるテーマを選ぶことはできない。

だからこそ、技術と事業の間をつなぐ人材が必要になる。

そして、ここにはもう一つ重要な問題がある。

研究開発の未来は、誰にも正確には分からない。

どの技術が成功するのか。どの市場が伸びるのか。顧客要求がどう変わるのか。競合が何を出してくるのか。

すべてを確実に予測してから研究開発を始めることはできない

つまり研究開発とは、本質的に不確実性の中で資源を投じる行為である。

言い換えれば、企業は常に「賭け」をしている

問題は、賭けることそのものではない。

何も考えずに賭けるのか。それとも、不確実性を理解し、期待できる成果と失敗したときの損失を考えたうえで、合理的に賭けるのか。

この違いが、これからの研究開発の成否を分ける。

DQLとは、リスクを嫌ってすべての挑戦を止める人ではない。

かといって、「とにかくやってみよう」と無謀な勝負をする人でもない。

顧客価値を考え、技術の可能性を評価し、どこまでなら失敗できるかを見極めながら、会社として取るべきリスクを選ぶ。

いわば「正しく賭けられる技術者」である。

次回は、この考え方をさらに掘り下げたい。

研究開発とはなぜ、本質的に「賭け」なのか。そして、不確実な未来に投資しなければならない企業は、無謀なギャンブルと合理的な研究開発をどこで区別すればよいのか。

「リスクを取らないことが、実は最大のリスクになる」。

2章では、この少し逆説的なテーマから、これからの技術開発とDQLの役割を考えてみたい。


※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/16

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事②

  技術者は「与えられた問題を解く人」でよいのか

日本企業の技術者教育を振り返ると、ある特徴がある。

学校でも企業でも、技術者は長いあいだ「与えられた問題を正しく解く能力」を鍛えられてきた。

要求仕様が提示されれば、それを満たす設計を考える。目標性能が与えられれば、それを達成する。故障が起きれば原因を分析する。コスト目標が設定されれば、部品や構造を見直す。

これらはもちろん重要な能力である。

しかしスマイルカーブの上流で必要になる能力は、少し違う。

そこでは、問題そのものが与えられていない。

「次に何を開発すべきか」という問いに、正解を示してくれる人はいない。「この技術に投資すべきか」「この市場に入るべきか」「この顧客課題は、本当に事業になるのか」という問いにも、解答集は存在しない。

必要になるのは、答えを出す能力よりも、まず「問う能力」である。

顧客は何に困っているのか。その困りごとはどれほど大きいのか。現在はどのような方法で対応しているのか。そこにまだ満たされていない要求はないか。技術が変われば、新しい価値を提供できないか。

そして、見つけた問いに対して仮説を立てる。

「この問題なら、われわれの技術で解決できるのではないか」。

ここから初めて研究開発が始まる。

この順序は重要である。

技術を持っているから用途を探すのではなく、価値のある問題を見つけ、その解決のために技術を使うのである。

もちろん、技術シーズから革新的な製品が生まれる場合もある。ただしその場合であっても、最終的に事業になるかどうかを決めるのは、その技術がどのような顧客価値に変換されるかである。

 


「品質を守る人」から「価値を設計する人」へ

そこで必要になるのが、私が「設計品質リーダー(Design Quality LeaderDQL)」と呼んでいる人材である。

DQLという名前から、品質保証部門のリーダーや、設計審査の専門家を想像する人もいるかもしれない。

しかし、ここでいうDQLの役割はもっと広い。

DQLは、完成した設計をチェックする人ではない。

開発の初期段階から、「何をつくるべきか」「誰のどの問題を解決するのか」「どの技術に投資するのか」「どのリスクなら取る価値があるのか」を考え、研究、企画、設計、評価、事業化をつないでいく人である。

つまり、品質という言葉を「不良を出さないこと」と狭く捉えるのではなく、顧客にとって価値のある製品を、事業として成立する形で実現することまで広げて考える。

ここにDQLの本質がある。

そのためには技術だけでは足りない。

顧客を理解しなければならない。市場を見なければならない。競合を知らなければならない。原価も価格も考えなければならない。研究テーマにどこまで投資するのかを判断しなければならない。

しかも、一人ですべてを担当するという意味ではない。

営業、マーケティング、研究、設計、生産、品質、サービスなど、それぞれの専門家が持つ知識をつなぎ、製品として一つの方向へまとめる。その中心に立てる技術者が必要なのである。

この能力は、従来型の専門技術者の育成だけでは、なかなか身につかない。



※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/15

【新規連載】品質を守るだけでは会社は勝てない ― 自律するDQLの仕事①

 

1章 「良いものをつくれば売れる」は、もう通用しない

設計品質リーダー(DQL)は、品質を守る人から「価値をつくる人」へ

日本の製造業には、長いあいだ一つの強い信念があった。

「良いものをつくれば、売れる」。

性能が高く、壊れにくく、ばらつきが少なく、しかも適正な価格である。そうした製品を真面目につくり続ければ、顧客はきっと評価してくれる。この考え方は、決して間違っていたわけではない。むしろ日本の製造業は、それを徹底することで世界市場に大きな存在感を築いてきた。

設計を磨き、製造工程を改善し、不良を減らし、コストを下げる。品質管理、品質保証、生産技術、IEVAVE、統計的品質管理など、多くの手法もこの流れの中で発展してきた。

ところが現在、この「良いものをつくる」という能力だけでは、企業が十分な利益を上げられない場面が増えている。

製品の品質が低くてもよいという話ではない。むしろ逆である。一定以上の品質は市場参加の前提条件となり、品質が良いことそのものが差別化になりにくくなってきたのである。

技術者にとっては、少々厳しい時代になった。

一生懸命に性能を高めても、その性能に顧客がお金を払ってくれるとは限らない。信頼性をさらに高めても、その差が顧客には見えないこともある。設計者が「これは良い製品だ」と自信を持っていても、競合製品のほうが使いやすかったり、導入しやすかったり、サービスまで含めた総費用が安ければ、商売では負けてしまう。

技術的に正しいことと、事業として成功することは、同じではないのである。


 利益は「ものをつくる場所」から移動している

この変化を考えるうえで、よく使われるのが「スマイルカーブ」という考え方である。

製品の価値連鎖を、研究、企画、設計、製造、販売、サービスと並べたとき、利益率が中央の製造工程では低く、上流の研究開発や企画、あるいは下流のブランド、サービス、ソフトウェアなどで高くなる。その形が笑った口のように見えることから、スマイルカーブと呼ばれている。

もちろん、すべての産業がきれいなスマイルカーブになるわけではない。しかし、現在の製造業を見るうえで、この考え方はかなり示唆的である。

製造技術が世界中に広がり、部品や設備も購入できるようになった結果、「高品質なものを製造できる」という能力だけでは、かつてほど大きな超過利益を生みにくくなった。




一方で、「何をつくるのか」を決める力の価値は高まっている。

どの顧客の、どの問題を解決するのか。その問題には、顧客が対価を払うほどの大きな価値があるのか。その価値を実現するために、どの技術を育てるべきなのか。自社がその市場で勝てる理由は何なのか。

こうした問いに答えられる企業は、製品をつくる前から競争を有利に進めることができる。

逆に、ここを曖昧にしたまま、「とにかく良い製品をつくろう」と走り始める企業は危うい。

どれほど優秀な設計者を集めても、どれほど精密な解析を行っても、そもそも顧客が必要としていないものを完成させてしまえば、研究開発投資を回収することはできない。

つまり、製造業にとって最大の品質問題は、製品の不良だけではない。

「売れないものを、正しくつくってしまうこと」もまた、極めて大きな品質問題なのである。


※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/14

【新規連載】新規研究開発テーマの決め方と進め方(FAビジネスを例にとって)⑰(最終)

7.経営・組織としての実行方法

テーマを継続的に生み出す仕組み

ここまで、新規研究開発テーマの探索、評価、事業化までを順に見てきました。

最後に考えたいのは、こうした活動を一度きりで終わらせず、継続的にテーマを生み出せる組織にするにはどうすればよいかという点です。

新規テーマ探索は、年に一度のアイデア募集では続きません。

「何か新しいテーマを出してください」と号令をかけても、出てくるのは既存製品の改良案か、流行技術を使った思いつきになりがちです。

必要なのは、普段の事業活動そのものからテーマの種が入ってくる仕組みです。

製品別組織をいったん横に切る

FAメーカーでは、PLC、センサー、サーボ、HMIなど、製品別の組織になっていることが多いと思います。

既存製品を効率よく開発するには合理的です。

しかし新規テーマを考えるとき、この組織構造が壁になることがあります。

たとえば設備異常診断を考えると、

PLCの制御ログ、
センサーの計測値、
サーボの電流・位置情報、
HMI
の警報履歴、
エッジ側の解析

を組み合わせた方が強い。

ところが、それぞれが別部門だと「どの部門の商品なのか」という話になってしまいます。

そこで新規研究開発では、製品別組織とは別に、制御・計測・駆動・表示・DXを横断するチームを作った方がよいでしょう。

顧客の問題は、社内の組織図に合わせて発生してくれるわけではありません。

技術責任者と事業責任者を分ける

新規研究開発では、技術責任者がそのまま事業責任者を兼ねることがあります。

小規模なテーマなら問題ありませんが、事業化を狙うテーマでは役割を分けた方がよいと思います。

技術責任者は、

「実現できるか」
「性能は出るか」
「安全性は確保できるか」

を見る。

一方、事業責任者は、

「誰が買うか」
「いくらで売れるか」
「標準化できるか」
「どう横展開するか」

を見る。

前回までに述べた「技術仮説」と「事業仮説」を、それぞれ責任を持って追う人を置くわけです。

この二人が対立するくらいで、ちょうどよい場合もあります。

技術側が「できました」と言い、事業側が「でも誰が買うのですか」と聞く。

逆に事業側が「顧客が欲しいと言っています」と言い、技術側が「その精度では安全を保証できません」と返す。

このやり取りがテーマを強くします。

営業やサービスを途中から呼ばない

研究テーマが完成してから営業に説明する。

これも避けたいところです。

営業、サービス、品質、セキュリティ部門は、初期段階から参加させます。

営業は顧客の困りごとを知っています。
サービスは故障や保全の実態を知っています。
品質部門は市場不具合を知っています。
セキュリティ部門は、商品化後に必要となる対応を知っています。

研究部門だけでは見えない情報が、これらの部門にはあります。

とくにサービス部門には、新規テーマの種が大量にあります。

「また同じ故障で呼ばれた」
「この調整は毎回時間がかかる」
「この警報について問い合わせが多い」

こうした情報こそ、新しい診断機能や自動化機能の入口です。

四半期ごとにテーマを動かす

テーマ管理も年に一度では遅すぎます。

市場も技術も顧客要求も変わります。

そこで、たとえば四半期ごとにステージゲート審査を行います。

そのとき重要なのは、「進捗率80%」のような管理をしないことです。

見るべきなのは、

顧客損失の仮説は確認できたか。
技術仮説はどこまで検証できたか。
事業仮説は変わったか。
次の3か月で何を確認するか。

です。

そして必要ならGoだけでなく、HoldPivotKillを判断します。

テーマは計画通り進めることより、学習した結果に応じて変えることの方が重要です。

社内に散らばったデータをテーマ探索に使う

新規研究開発に使えるデータは、実は社内にかなりあります。

故障履歴。
修理履歴。
警報ログ。
調整記録。
顧客問い合わせ。
品質不具合。
営業からの要望。

問題は、それぞれ別のシステムやExcelに入っていることです。

これらを共通データ化すると、

「最近どの不具合が増えているか」
「どの製品で調整工数が多いか」
「複数顧客から同じ要望が出ていないか」

を横断して見られるようになります。

ここから新規テーマ候補を自動的に抽出することも可能です。

AIは「テーマを考えてもらう」より整理に使う

生成AIを新規研究開発に使う場合も、使い方を少し工夫した方がよいでしょう。

「次世代FAの新規テーマを100件考えてください」

と聞けば、それらしい案はいくらでも出ます。

しかし、それだけでは自社らしいテーマにはなりません。

むしろAIに、

市場動向、
特許、
規格、
顧客要求、
社内不具合情報、
修理履歴

などを整理させ、

「どの顧客課題が増えているか」
「自社技術とどこで重なるか」
「過去に似たテーマをやっていないか」

を探させる方が実務的です。

AIはアイデア発生器というより、大量の情報からテーマの兆候を拾う補助者として使うと効果的です。

技術伝承も研究開発テーマに変えられる

もう一つ、FA企業では重要なのが熟練者のノウハウです。

熟練技術者が、

音を聞いて異常を判断する。
波形を見て調整条件を変える。
振動の出方から機械状態を推定する。

こうした知識を、単に若手へ教育して終わらせるのはもったいない。

その判断過程をデータとして残し、

AI診断、
自動調整、
設計支援、
復旧ナビゲーション

などの機能へ実装できれば、技術伝承そのものが新規研究開発になります。

「人から人へ教える」だけでなく、人の知識を製品やサービスへ組み込むわけです。

これは熟練者不足への対応であると同時に、新しい競争力にもなります。

テーマ探索を「行事」にしない

新規研究開発を継続させるために重要なのは、特別なアイデア会議を増やすことではありません。

営業活動から顧客課題が入る。
サービス活動から故障情報が入る。
品質部門から市場不具合が入る。
技術部門から新技術が入る。
AI
がそれらを横断して整理する。

そして四半期ごとにテーマ候補を見直す。

この循環が回れば、新規テーマ探索は年に一度のイベントではなく、通常の経営活動になります。


まとめ:幹部に伝える三つの要点

この連載で述べてきたことを、最後に三つに絞っておきます。

1FA機器の新規テーマは、機器の高性能化ではなく、製造現場の損失削減から定義する。

PLCを速くする、センサーを高精度にする、AIを搭載する。その前に、「顧客の何を改善するのか」を決めます。

2.ハードウェア、ソフトウェア、データ、サービスを一つの事業として設計する。

これからのFA事業では、機器を売って終了とは限りません。設置ベースと現場データを生かし、診断、更新、保守まで含めて事業を設計することが重要です。

3AIDXテーマでは、技術精度だけでなく、安全性、標準化、継続的なデータ取得、有償化可能性を早期に確認する。

PoCで高い精度が出ても、それだけでは事業になりません。現場で使え、複数顧客へ展開でき、継続的に利益を生む仕組みになっているかまで確認します。

新規研究開発テーマを決めるという仕事は、未来の技術を当てる仕事ではありません。

顧客の変化を読み、現場の損失を見つけ、自社の技術資産と結びつけ、それを事業として成立させる。

この一連の仕組みを持てるかどうかが、これからのFA企業の研究開発力を大きく左右するのではないかと思います。 

(連載おわり)

  

※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/13

【新規連載】新規研究開発テーマの決め方と進め方(FAビジネスを例にとって)⑯

6-4.経営貢献金額で比較する

研究開発テーマを事業化の視点で評価するとき、「売上はいくらになるか」だけを見てはいけません。

特にデジタルFAのテーマでは、価値の出方が従来のハードウェア販売より複雑です。

PLCやセンサーを何台売るか。
サーボアンプの売上がいくら増えるか。

もちろん、これは重要です。

しかし実際には、その周辺にソフトウェア、保守、アップデート、サービス、既存製品への波及効果があります。

したがって新規研究開発テーマは、単体商品の売上ではなく、経営への総合的な貢献金額で見る必要があります。

ハードウェア売上だけでは小さく見えるテーマがある

たとえば、既存PLCに設備診断機能を追加するテーマを考えてみます。

新しいハードウェアを大きく販売するわけではないため、「売上規模が小さい」と評価されるかもしれません。

しかし、その診断機能を年間ライセンスとして販売できればどうでしょうか。

さらに、

診断モデルの更新料金、
年間保守契約、
遠隔監視サービス

まで付けば、収益は継続します。

また、「この診断サービスを使うには当社PLCとセンサーを採用してください」という形になれば、既存製品の売上にも波及します。

つまり、一つの研究テーマから生まれる事業価値は、

機器売上+ソフトウェア+サービス+既存製品への波及

で考えた方が実態に近くなります。

「標準採用」の価値は大きい

FA分野では、装置メーカーへの標準採用も重要です。

ある装置メーカーが新しい設備診断機能を自社標準仕様として採用すると、その後の装置にも継続して搭載される可能性があります。

最初の一台だけを見ると、小さな売上です。

しかし年間100台の装置に採用され、それが5年間続くなら話は変わります。

さらに海外工場や別シリーズへ横展開されれば、研究テーマの経営貢献は大きくなります。

したがって、

「初年度売上はいくらか」

だけでなく、

顧客内でどこまで標準化・横展開される可能性があるか

を見る必要があります。

コスト削減も研究開発の成果である

研究開発の経営貢献は、外部売上だけではありません。

たとえば共通の通信プラットフォームを開発したとします。

これによって、PLCHMI、エッジ端末ごとに別々に開発していた通信機能を共通化できれば、開発工数を削減できます。

同様に、

設計自動化による設計工数削減、
仮想立上げによる評価工数削減、
自己診断機能による問い合わせ削減、
共通ソフトウェア基盤による保守費削減

なども立派な経営効果です。

研究テーマによっては、売上を増やすよりも、会社全体の開発コストを下げる効果の方が大きいことがあります。

ここを評価しないと、共通基盤技術のようなテーマが不当に低く評価されます。

まず顧客価値を金額で考える

事業価値を考える前に、顧客側の経済効果を計算します。

考え方は比較的単純です。

顧客価値
= 停止損失削減+不良削減+工数削減+エネルギー削減
-(導入費+運用費+変更リスク)

たとえば設備診断システムによって、

停止損失を年間500万円削減、
緊急保全工数を年間100万円削減

できるとします。

一方、システム導入費が150万円、年間運用費が50万円なら、初年度でも400万円程度の経済効果が残ります。

こうなれば、顧客が購入する理由を説明しやすい。

逆に、年間50万円しか改善しないのに導入費が300万円では、技術が優れていても普及は難しいでしょう。

重要なのは、顧客価値を「便利になった」「作業が楽になった」で終わらせないことです。

「変更リスク」も忘れない

FAでは、導入費と運用費だけでなく、変更リスクも無視できません。

新しいPLCへ変更すれば、制御プログラムの検証が必要になる。

ネットワーク構成を変えれば、設備停止のリスクがある。

AI診断を導入すれば、保全手順や責任分担を変更する必要がある。

顧客にとっては、こうした変更そのものがコストです。

新技術を導入することで得られる効果が多少大きくても、

「今の設備を触りたくない」

という理由で採用されないことがあります。

そのため顧客価値を考える際には、金銭的な導入費だけでなく、設備変更、教育、検証、運用変更に伴う負担も含めて考える必要があります。

自社側は将来キャッシュフローで考える

次に、自社にとっての事業価値です。

考え方の一例として、

リスク調整後事業価値
= 将来キャッシュフロー × 段階別成功確率
- 研究開発費・認証費・事業立上げ費

と置くことができます。

ポイントは、「最大売上予想」をそのまま評価しないことです。

たとえば、成功すれば5年間で50億円の利益を生むテーマがあったとしても、技術成功確率が30%、事業化成功確率が40%なら、そのまま50億円として評価するのは危険です。

一方、将来利益は10億円でも、既存技術を使えて成功確率が80%というテーマもあります。

両者を比較するためには、不確実性を織り込む必要があります。

ステージが進むほど成功確率を更新する

前回紹介したステージゲートは、ここでも役に立ちます。

G0の機会探索段階では、成功確率はまだ低い。

G1で顧客損失が確認できれば、市場面の確度が上がる。

G3で実機試験に成功すれば、技術面の確度が上がる。

G4の顧客PoCで有償化の可能性まで確認できれば、事業成功確率はさらに高くなります。

つまり、研究テーマの事業価値は固定値ではありません。

ステージが進むたびに、期待売上、利益、成功確率を更新していくものです。

研究開発テーマの評価を年初に一度だけ行うのではなく、ゲートごとに事業価値を再計算する方が合理的です。

テーマを同じ物差しで比較できる

経営貢献金額で評価する利点は、性質の違うテーマを比較できることです。

たとえば、

Aテーマは新型センサーで年間5億円の売上。
B
テーマは診断サービスで年間2億円の継続収入。
C
テーマは共通プラットフォームで年間1億円の開発費削減。

売上だけで見るとAが一番です。

しかし粗利益や継続年数、開発費削減まで入れると、BCの方が会社にとって価値が大きいかもしれません。

このように、

売上、利益、サービス収入、波及売上、コスト削減をできるだけ金額に置き換える

ことで、研究開発テーマを経営の言葉で議論できるようになります。

もちろん、基盤研究や将来技術のすべてを短期的な金額だけで判断する必要はありません。

それでも、

「このテーマは将来、会社のどの経営指標に効くのか」

を考えておくことには意味があります。

研究開発部門の成果を「特許件数」「試作品完成」「技術発表」で終わらせず、

顧客にどれだけ価値を生み、自社にどれだけ利益や競争力を残したか

まで追う。

ここまでできると、研究開発はコストセンターではなく、将来利益を作るための投資として経営とつながってきます。

ただし、優れた評価方法を作っても、テーマ候補そのものが定期的に出てこなければ意味がありません。

一度大規模なテーマ募集をして終わり、ではなく、顧客課題や技術変化を継続的に取り込み、新しいテーマの種を生み続ける仕組みが必要です。

次回からは 7.経営・組織としての実行方法」 に入り、まず 7-1.テーマを継続的に生み出す仕組み」として、新規研究開発を一過性のイベントにしないための運営方法を考えていきます。

  

※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]

2026/09/12

【新規連載】新規研究開発テーマの決め方と進め方(FAビジネスを例にとって)⑮

 6-3.顧客実証で確認すること

新規研究開発テーマの決め方

15回 顧客実証で確認すること

研究開発テーマが試作品の段階まで進むと、いよいよ顧客設備でのPoCに入ります。

ここで注意したいのは、PoCを「技術が動くことを見せる場」にしないことです。

研究室で動作した技術を顧客設備に持ち込み、

「異常を検出できました」
AI精度95%でした」

で終わってしまうと、事業化に必要な情報はほとんど得られません。

顧客実証で確認すべきなのは、技術性能だけではなく、その技術によって顧客の仕事と経済的な成果が本当に変わるかです。

顧客は「完成してから探す」のでは遅い

できれば重点顧客は、PoCの段階で初めて探すのではなく、テーマ探索の初期から3社程度を巻き込んでおきたいところです。

一社だけでは、その企業固有の問題なのか、市場共通の問題なのか判断しにくいからです。

たとえば設備診断でも、

A社では突発停止が問題。
B
社では保全員不足が問題。
C
社では交換部品の判断が問題。

ということがあります。

三社程度と話をすると、共通している部分と個別部分が見えてきます。

この共通部分が、将来の標準製品やサービスの核になります。

実証前の状態を測っておく

PoCで非常にありがちな失敗が、改善前のデータを取っていないことです。

導入後に、

「便利になりました」
「以前より良くなった気がします」

と言われても、事業性の判断には使えません。

したがって、実証前に基準値を取っておきます。

設備停止なら年間または月間停止時間。
品質なら不良率、手直し率、検査工数。
立上げなら調整時間。
省エネルギーなら生産量当たりの電力量。

つまり、PoCは新技術を試す前から始まっています。

改善前と改善後を比較できて初めて、

「この技術によってどれだけ顧客損失が減ったか」

を評価できます。

AI精度より、その後の行動を見る

AIを使ったテーマでは、とかく予測精度や正解率ばかりを評価します。

もちろん精度は重要です。

しかし、設備診断AIが異常を正しく検出しても、その情報を誰も使わなければ価値は生まれません。

たとえば、

AIが「ベアリング劣化の可能性80%」と表示した。

そのとき保全担当者はどうするのか。

すぐ確認するのか。
次回点検まで待つのか。
部品を事前手配するのか。
そもそもAIの判断を信用しないのか。

ここまで見る必要があります。

良いPoCでは、

AIの判断精度ではなく、AIによって人の意思決定が変わったか

を確認します。

予知保全であれば、最終的に設備停止や緊急修理が減ったかまで見たいところです。

「普通に動いているとき」だけ試さない

顧客設備での実証では、正常運転だけを見ると危険です。

FA機器では、むしろ異常時の挙動が重要だからです。

少なくとも、

正常時、
異常時、
通信切断時、
誤操作時

は確認しておきます。

たとえばクラウドを使った設備診断なら、ネットワークが切れたときどうなるのか。

診断結果が届かなくなるだけで設備運転には影響しないのか。それとも制御側に何らかの支障が出るのか。

AIが誤判定した場合に、作業者がそれを打ち消せるのか。

FAでは「正常時には動きます」だけでは製品になりません。

ばらつきを意図的に入れる

研究段階では、同じ設備、同じ条件で繰り返し試験したくなります。

しかし実際の工場では条件が変わります。

品種が変わる。
設備個体が変わる。
夏と冬で環境が変わる。
作業者が変わる。

こうした違いを避けて実証すると、PoCでは高い性能が出たのに、商品化後に性能が安定しないということが起きます。

そこで、

品種、設備個体、季節、作業者などを誤差因子として意識的に評価する

ことが重要です。

たとえば異常検知AIなら、一台の設備で95%の精度が出ることより、複数設備・複数品種でも安定して90%を維持できる方が、製品としては価値があります。

研究開発では最高性能を競うより、現場条件が変わっても性能が崩れないことを見るべきです。

個別仕様を増やしすぎない

PoCでは顧客からさまざまな要求が出ます。

「この画面を追加してほしい」
「この設備だけ特殊な信号を使いたい」
「自社独自の帳票形式にしてほしい」

営業的には対応したくなります。

しかし全部受け入れると、PoCは成功しても標準製品になりません。

そこで、顧客ごとの要求を、

共通プラットフォーム部分

個別設定部分

に分けます。

たとえばデータ収集、診断アルゴリズム、通信、安全機能などは共通化し、画面表示やしきい値などは設定で変更できるようにする。

この境界をPoC段階から意識しておくと、二社目、三社目への展開が容易になります。

「無償PoC」から抜け出せるか

そして事業化で非常に重要なのが、PoCの有償化です。

新技術なので最初は無償で試してもらう。

これはよくあります。

問題は、二社目、三社目でもずっと無償で続けることです。

顧客は無料なら使ってくれます。

しかし、それでは本当に価値を感じているのか分かりません。

そこで実証を始める前に、

「この条件を達成したら有償サービスへ移行する」

という基準を決めておきます。

たとえば、

設備停止時間を20%削減。
段取り工数を30%削減。
エネルギー原単位を5%改善。

これを達成した場合、

月額いくら、年間いくら、あるいは設備1台あたりいくら

で契約するのかまで話しておきます。

多少厳しい話に見えますが、ここを避けると「PoCは好評なのに誰も買わない」という状態になりがちです。

PoCの成果は技術データだけではない

顧客実証で得るべきものを整理すると、大きく三つあります。

一つ目は、技術性能。

二つ目は、顧客の行動変化。

三つ目は、経済効果です。

この三つがそろって初めて、事業化の判断材料になります。

技術的に動いた。
現場で使われた。
そして顧客損失が減った。

ここまで確認できれば、その研究テーマはかなり強い。

逆に、AI精度は高いが誰も使わない、顧客には好評だが経済効果が小さい、といった場合は、商品化の前にもう一度テーマを見直すべきです。

研究開発から事業化へ進むためには、技術性能を「顧客価値」、さらに「金額」へ変換する必要があります。

次回は、「6-4.経営貢献金額で比較する」として、設備停止削減、品質改善、省人化、エネルギー削減などの成果をどのように金額換算し、複数の研究開発テーマを同じ土俵で比較するかを考えていきます。

 


※御社のプロダクト(製品・サービス)分野で同様の話が聞きたい!という場合は、どうぞご相談ください。

[無断転載禁止]