2026/10/05

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

失敗した研究開発から「回収できるもの」を考える

研究開発テーマを中止すると、「何も残らなかった」という評価になりやすい。

しかし、本当にそうだろうか。

あるテーマを二年間研究した結果、事業化を断念したとする。

それでも、材料データが残っている。

試験方法が確立された。

顧客の未解決課題が分かった。

競合技術の情報が集まった。

若手技術者が経験を積んだ。

新しい解析手法も身についた。

これらは次のテーマに使える。

つまり、研究テーマそのものの事業化に失敗しても、会社としての学習までゼロになるわけではない。

重要なのは、その知識を個人の経験だけで終わらせず、次の研究へ再利用できる形にすることだ。

この意味で、優れた撤退とは単なる「中止」ではない。

知識と人材を次の賭けへ移すことである。

 

人材もまた、撤退できずに固定化される

この問題は研究テーマだけではない。

人材育成でも同じことが起こる。

ある技術分野を将来の重点領域と考え、若手技術者を五年間育成したとする。

ところが市場環境が変わり、その技術の重要性が低下した。

それでも、

「せっかく五年間育成したのだから」

という理由で、その人を同じ分野に置き続けてしまうことがある。

しかし、本当に重要なのは、その人が過去に何を学んだかではなく、

これから会社のどこで最も大きな価値を生み出せるか

である。

研究テーマと同じように、人材ポートフォリオも見直さなければならない。

技術分野が変われば、再教育する。

別の事業へ移す。

専門性を隣接領域へ展開する。

DQL自身も、特定技術だけに自分の価値を固定してはいけない。

研究開発環境が変わる以上、人材もまた学び直し、役割を変えていく必要がある。

この柔軟性は、自律した技術人材にとって重要な能力になる。

 

「失敗した人」を責める組織では、誰も早くやめられない

撤退を難しくしているのは、個人心理だけではない。

組織文化も大きい。

テーマを中止した担当者が、

「失敗した人」

として扱われる会社では、誰も早く撤退しようとしなくなる。

当然である。

やめれば評価が下がるなら、担当者は何とか継続する理由を探す。

追加実験を提案する。

条件を変える。

目標を修正する。

市場予測を楽観的に作り直す。

その結果、本来500万円の損失で済んだテーマが、5000万円の損失になる。

これは個人の問題というより、評価制度の問題である。

良い研究開発組織では、「成功したかどうか」だけでなく、

適切なタイミングで正しい意思決定をしたか

を見る必要がある。

十分な根拠を持って挑戦し、新しい情報から見込みが薄いと判断し、早期撤退したのであれば、それは優れた仕事である。

失敗を隠して追加投資を続けるより、はるかに会社へ貢献している。

 

DQLは「損切り」をする人でもある

株式投資では、「損切り」という言葉がある。

買った価格より株価が下がっていても、将来性がなくなったと判断すれば売却する。

過去の購入価格に執着しない。

研究開発にも、同じ原則が必要である。

ただしDQLが行う損切りは、単に「このテーマをやめましょう」と言うことではない。

今まで何が分かったのか。

成功確率はどう変化したのか。

残された技術課題は何か。

市場価値はまだ存在するのか。

追加投資に対して、どの程度のリターンが期待できるのか。

人材や知識をどこへ再配置するのか。

そこまで考えて初めて、合理的な撤退になる。

研究開発には、始める能力が必要である。

続ける能力も必要である。

そして同じくらい、

やめる能力が必要である。

優れたDQLは、情熱を持ってテーマを推進する。

しかし、その情熱によって事実が見えなくなることは避ける。

自分が正しかったことを証明するためではなく、会社が将来勝つために判断する。

それが自律した研究開発リーダーの条件である。

 

「勝率の高いテーマ」だけを残しても、会社は強くならない

ここまで読むと、見込みの薄いテーマを早くやめ、確実なテーマへ集中すればよいように思えるかもしれない。

しかし、それにも落とし穴がある。

撤退判断を厳しくしすぎると、今度は成功確率の高いテーマだけが残る。

既存技術を使った改良。

既存顧客向けの派生品。

小さなコストダウン。

これらは成功しやすい。

しかし、会社の未来を大きく変える可能性も小さい。

つまり研究開発では、「失敗しそうなテーマをやめる」だけでは不十分なのである。

成功確率が低くても、成功したときの価値が非常に大きいテーマには投資する意味がある。

反対に成功確率が高くても、ほとんど利益を生まないテーマなら、優先順位は低いかもしれない。

ここで必要になるのが、

「当たりやすさ」ではなく「期待値」でテーマを見る考え方

である。

次回は、研究開発テーマの選び方をもう一段掘り下げたい。

全勝を目指す会社は、本当に強いのか。

成功確率の高いテーマばかりを選ぶことは、果たして合理的なのか。

第6章では、「成功確率ではなく、期待値でテーマを選べ」いう視点から、研究開発ポートフォリオとDQLの意思決定を考えてみたい。


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

[無断転載禁止]

 


Posted by at 0 件のコメント:
Labels: , , ,

2026/10/03

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

「成功させる責任」が、撤退を遅らせることもある

日本企業では、責任感の強い技術者ほど、この罠に入りやすい。

テーマを任された。

だから最後までやり切らなければならない。

途中でやめるのは無責任だ。

この考え方自体は、決して悪くない。

しかし研究開発では、「最後までやる」ことが会社にとって正しいとは限らない。

たとえば新しい制御装置を開発していて、当初想定した市場が急速に縮小したとする。

技術的にはあと半年で完成できそうである。

担当チームは優秀で、完成させる自信もある。

しかし、完成時には市場そのものが小さくなっている可能性が高い。

この場合、技術者の責任は「何としてでも完成させること」ではない。

むしろ、

会社の資源を、より価値の高いテーマへ移すこと

かもしれない。

研究開発では、「完成させること」と「成功すること」は同じではないのである。

 

「あと少し」は、本当にあと少しなのか

研究開発会議でよく聞かれる言葉がある。

「あと半年あれば」。

「あと一回試作すれば」。

「あと少し精度が上がれば」。

もちろん、本当にあと少しで解決する場合もある。

しかし、不確実性の高い研究開発では、「あと少し」が何度も繰り返されることがある。

たとえば新材料の開発で、耐久性の目標が1000時間だとする。

最初の試験では600時間だった。

材料配合を改良して750時間になった。

さらに改良して820時間まで伸びた。

ここまで来ると、「あと少しで1000時間」と感じる。

ところが、900時間付近から劣化メカニズムそのものが変わり、そこから先は別の技術課題だったと分かることもある。

数値が目標に近づいているからといって、残された開発量まで小さいとは限らない。

登山でいえば、山頂が近くに見えていても、途中に深い谷があるかもしれない。

DQLは、進捗率だけを見るのではなく、

残された不確実性の質

を見なければならない。

 

撤退基準は「始める前」に決めておく

では、どうすればサンクコストに支配されにくくなるのだろうか。

有効なのは、研究開発を始めるときに、継続条件だけでなく撤退条件も決めておくことである。

たとえば、

「一年以内に主要顧客三社から一定以上の評価が得られなければ再検討する」。

「試作三回目までに性能目標の80％へ到達しなければ、方式そのものを見直す」。

「想定量産原価が目標価格の70％以下に下がる見通しが立たなければ中止する」。

こうした条件をテーマ開始時に決めておく。

なぜ始める前なのか。

テーマに思い入れが生まれてからでは、条件を緩めたくなるからである。

試験結果が悪ければ、「今回は条件が厳しかった」と言いたくなる。

顧客評価が低ければ、「顧客がまだ新しい価値を理解していない」と説明したくなる。

人間には、自分の仮説を守る方向へ事実を解釈する傾向がある。

だからこそ、冷静な段階で「どんな結果ならやめるか」を決めておく意味がある。

 

一度決めた撤退基準も、機械的に守ればよいわけではない

ただし、撤退基準を設定すればすべて解決するわけではない。

研究開発には、新しい発見があるからだ。

当初の性能目標には届かなかったが、実験中に別の市場で使える可能性が見つかることもある。

想定顧客には評価されなかったが、別業界の顧客から強い関心を示される場合もある。

たとえば高精度な画像検査技術を半導体向けに開発していたが、要求精度に届かなかったとする。

普通なら中止候補である。

しかし、その途中で食品工場の異物検査なら十分な精度があり、しかも市場ニーズも大きいと分かった。

この場合、元のテーマはやめても、技術そのものを捨てる必要はない。

市場を変える。

用途を変える。

技術を別テーマへ移す。

つまりDQLに必要なのは、「続けるか、全部捨てるか」という二択ではない。

何をやめ、何を残すかを判断する能力である。


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

[無断転載禁止]

 

Posted by at 0 件のコメント:
Labels: , , ,

2026/10/01

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

 

第5回　研究開発で最も危険なのは、「やめられないこと」

― サンクコストに支配されないDQLの判断力

 

研究開発は、始めるより「やめる」ほうが難しい

研究開発の会議では、新しいテーマを始めるときには多くの議論が行われる。

市場性はあるか。技術的に実現できそうか。どのくらいの投資が必要か。競合に勝てるか。顧客は本当に欲しがっているか。

ところが、いったんテーマが始まると、状況は少し変わる。

半年経っても思ったほど性能が出ない。

一年経っても顧客評価が芳しくない。

原価を計算してみると、当初想定よりかなり高い。

それでも会議では、「もう少し続けてみよう」という意見が出やすい。

なぜなら、すでに時間も金も人も使っているからである。

ここに、研究開発の難しさがある。

新しいテーマを始めるには勇気がいる。

しかし実際には、見込みの薄くなったテーマをやめるほうが、もっと大きな勇気を必要とする。

 

「ここまでやったのだから」が最も危険な言葉になる

簡単な例を考えてみよう。

あるメーカーが、新しいセンサー技術の研究開発に取り組んでいるとする。

当初の計画では、2年で製品化し、開発費は5000万円程度の予定だった。

ところが1年半が経過しても、必要な精度が安定して出ない。

追加実験も行った。外部の専門家にも相談した。設備も購入した。

すでに4000万円を使っている。

ここで担当者が言う。

「ここまで4000万円使ったのだから、あと1000万円だけ追加して完成させたい」。

一見すると合理的に聞こえる。

しかし、本当に見るべきなのは過去の4000万円ではない。

その4000万円は、もう戻ってこない。

今考えるべきなのは、

これから1000万円を追加したときに、その1000万円に見合う成果が期待できるか

という一点である。

過去にいくら使ったかは、本来、次の投資判断とは切り離して考えなければならない。

これがサンクコストの問題である。

 

ギャンブルでいう「追い銭」は、研究開発でも起こる

ギャンブルで最も危険な状態の一つは、負けた金を取り戻そうとして賭け金を増やすことである。

1万円負けた。

次は2万円賭ける。

それでも負けた。

今度は5万円賭ける。

本人の頭の中では、「勝てばこれまでの損失を取り戻せる」と考えている。

しかし、過去の負けは次の勝率を高めてくれるわけではない。

研究開発にも、これとよく似たことが起こる。

一年間研究した。

二年間研究した。

設備を購入した。

専任チームも作った。

経営会議でも「重点テーマ」として発表した。

こうなると、撤退する心理的なハードルは急激に高くなる。

そして本来なら、

「今の情報で判断すれば、このテーマにはもう追加投資しない」

という結論になるはずなのに、

「ここまでやったのだから、もう一年だけ」

という判断に変わってしまう。

これは研究開発における「追い銭」である。


テーマそのものより、「自分の判断」を守ろうとしてしまう

研究開発がやめられなくなる理由は、金だけではない。

人間の心理も大きく関係している。

ある技術者が三年間、新しい製品の開発リーダーを務めていたとする。

その人は社内で、「この技術は必ず伸びる」と説明してきた。

部下にもそう言っている。

経営層にも投資を求めてきた。

顧客にも将来構想を話している。

この状態で、「やはり、このテーマはやめたほうがよい」と言うのは簡単ではない。

それは単に研究テーマを止めることではない。

自分の過去の判断が間違っていた可能性を認めることでもあるからだ。

そこで無意識のうちに、テーマの将来性を評価するのではなく、自分の過去の判断を正当化するためにテーマを続けるようになる。

これは非常に危険である。

DQLに必要なのは、技術への自信だけではない。

自分の仮説が間違っていたときに、それを認められる強さである。


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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/30

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

実験とは「性能確認」ではなく「意思決定」のために行う

技術者にとって、実験は身近なものである。

しかし、研究開発の上流では実験の目的を少し広く考えたほうがよい。

実験は単に「この性能が出るか」を確認するものではない。

次に何をするかを決めるために行うものである。

たとえば、三種類の技術方式があるとする。

A方式は性能が高いが高価である。

B方式は性能は中程度だが量産しやすい。

C方式はまだ不安定だが、成功すれば大幅な低コスト化が期待できる。

このとき、すべてを完成レベルまで開発して比較する必要はない。

簡単な実験を組んで、「どの方式に投資を続ける価値があるか」を判断できればよい。

ここでは実験計画法や統計手法が役に立つ。

少ない試験回数でも、主要因や傾向を把握できれば、次の投資判断がしやすくなる。

大切なのは高度な解析を行ったかどうかではない。

その実験によって、意思決定が前に進んだかどうかである。

 

失敗のコストを小さくすれば、挑戦回数を増やせる

企業が挑戦を避ける理由の一つは、「失敗すると大きな損失になる」からである。

それならば、失敗そのものをなくそうとするのではなく、失敗したときの損失を小さくすればよい。

たとえば一つの研究テーマに最初から1億円を投資する会社と、500万円の初期検証を20件行う会社を比べてみる。

前者では、一つのテーマが失敗すると大きな損失になる。

そのため、テーマ選定は慎重になり、社内承認も厳しくなる。

結果として、挑戦できるテーマ数が減っていく。

後者では、20件のうち15件が途中で終了してもよい。

残った5件に追加投資し、そのうち1件か2件が大きな事業になれば、ポートフォリオ全体として成功する可能性がある。

これはベンチャーキャピタルの投資にも似ている。

すべての投資先が成功することを前提にしていない。

重要なのは、失敗を限定しながら、成功した案件から大きなリターンを得ることである。

研究開発にも同じ考え方を導入できる。

失敗を許容できる大きさに設計すれば、会社はもっと大胆に挑戦できる。

 

「試作品を作る」のではなく「仮説を試す」

研究開発現場では、「まず試作品を作りましょう」という言葉がよく使われる。

しかし、私はここでも少し注意が必要だと思う。

何を確認するのかが曖昧なまま試作品を作ると、試作そのものが目的になってしまう。

見栄えのよい試作品ができる。

展示会にも出せる。

経営者にも説明しやすい。

しかし、本当に重要な仮説は何も検証されていない。

たとえば業務支援用のAIシステムなら、最初から立派な画面を作る必要はない。

Excelと既存AIサービスを組み合わせた簡易版でも、顧客が本当にその機能を使うかどうかは確認できる。

新しい機械装置でも、最初から量産に近い試作機を作る必要はない。

重要な原理だけを確認する治具で十分な場合もある。

つまり、

試作品の完成度ではなく、検証した仮説の重要度を見る。

この考え方を持つだけで、研究開発のスピードと費用は大きく変わる。

 

DQLは「学習速度」を設計する

ここまで述べてきたことを整理すると、DQLの仕事は製品を設計することだけではない。

研究開発という学習プロセスそのものを設計することでもある。

何が分かっていないのか。

その中で、何が事業の成否を最も左右するのか。

それを最も安く確認する方法は何か。

どの結果なら次へ進み、どの結果なら修正し、どの結果ならやめるのか。

ここまで考えてから実験や試作を行う。

この能力は、これからますます重要になる。

AIによって調査や解析の速度が上がれば、情報を集めること自体の価値は下がっていく。

一方で、「何を確かめるべきか」を決める能力の価値は高まる。

未来を完全に予測することはできない。

しかし、小さく試すことはできる。

仮説が間違っていれば、早く修正できる。

正しければ、確信を持って次の投資へ進める。

研究開発で強い企業とは、失敗しない企業ではない。

一回の失敗を小さくし、失敗から学び、次の意思決定を速くできる企業である。

そして、その学習サイクルの中心に立つのがDQLである。

ただし、ここで一つ厄介な問題が残る。

小さく試した結果、「このテーマはやめたほうがよい」と分かったとする。

理屈では撤退すべきである。

ところが、実際の企業では簡単にはやめられない。

すでに何千万円も使っている。

三年間研究してきた。

担当者が人生をかけている。

経営幹部が期待している。

すると、本来は「損失を小さくするための研究開発」が、いつの間にか「ここまで使った金を取り戻すための研究開発」に変わってしまう。

ギャンブルで最も危険なのは、負けたことそのものではない。

負けを認められず、さらに賭け金を増やすことである。

次回は、この研究開発における「追い銭」の問題を考えたい。


第5章では、「研究開発で最も危険なのは、やめられないこと」である。

 


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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/29

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

 研究開発の初期投資は、「成果を買う金」ではなく「情報を買う金」である

研究開発では、投資した金額に対して「何が完成したか」を評価したくなる。

しかし初期段階では、完成品ができなくても価値がある。

重要な仮説が間違っていると分かったなら、それは十分に成果である。

たとえば新しい樹脂材料を使った部品を開発していたとする。

材料メーカーのデータシートでは、従来材よりも耐薬品性が高い。

そこで製品設計を進める前に、実際の使用環境を模擬した簡単な浸漬試験を行った。

すると、特定の薬液条件では想定以上に膨潤することが分かった。

この試験に50万円かかったとする。

「50万円使ったのに開発が前に進まなかった」と考えることもできる。

しかし本当は逆である。

もしこの試験をせず、金型を作り、量産評価まで進んでから問題が発覚していれば、数千万円の損失になったかもしれない。

つまり50万円で、

「このまま進むと危険である」という情報を買った

のである。

研究開発初期の投資は、完成品を買うための投資だけではない。

不確実性を減らすための投資でもある。

 

何を先に試すかで、開発効率は大きく変わる

「小さく試す」といっても、何でも片っ端から試せばよいわけではない。

重要なのは、事業の成否を左右する不確実性から先に確認することである。

たとえば新しいセンシング製品を開発するとしよう。

技術者としては、まずセンサー精度を高めたくなる。

精度1％を0.5％にしたい。応答速度をもっと速くしたい。ノイズを減らしたい。

しかし、その製品の最大のリスクが「顧客が既存設備にセンサーを追加する工事を嫌がること」だとしたら、精度向上を半年続けても事業リスクはほとんど減らない。

この場合、先に確認すべきなのは取り付け性かもしれない。

既存設備を止めずに取り付けられるのか。

現場作業者が30分で設置できるのか。

無線通信でデータを送れるのか。

こうした条件が成立しなければ、どれほど高精度なセンサーでも売れない。

DQLは、技術的に面白い課題から取り組むのではなく、事業を止める可能性が最も高い不確実性から潰していく必要がある。

 

「最も危険な仮説」を最初に探す

研究開発テーマには、必ず複数の仮説がある。

「この顧客課題は本当に大きい」。

「この技術で解決できる」。

「この価格なら買ってもらえる」。

「量産できる」。

「競合より優位性がある」。

これらすべてが正しければ事業は成立する。

しかし、一つでも致命的な仮説が崩れれば、事業全体が成立しない場合がある。

そこでDQLは、最初にこう問う。

「この事業が失敗するとしたら、最もありそうな理由は何か」

この問いは非常に有効である。

たとえば、新しい画像検査装置を企画しているとする。

技術者は画像認識精度が最大の課題だと思っている。

ところが顧客へ確認すると、「精度90％でもいいから、既存ラインに一日で導入できることのほうが重要だ」と言われるかもしれない。

すると、最大の不確実性はAIモデルではなく、設備との接続性や導入工数だったことになる。

ここを早い段階で知ることができれば、開発の方向を大きく誤らずに済む。

 

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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/27

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

 

第4章 未来を当てるより、「小さく賭ける」

― 研究開発で重要なのは、予測精度より学習速度である

 

研究開発では、最初から正解は見えない

前回は、研究開発テーマを技術からではなく、顧客が現在被っている損失から考えるべきだと述べた。

では、顧客にとって価値のある課題が見つかったら、次に何をすればよいのだろうか。

ここで多くの企業が陥るのが、「もっと調べてから動こう」という考え方である。

市場規模を精緻に予測する。競合を詳しく分析する。技術ロードマップを作る。五年後、十年後の需要を推定する。原価計算を何度もやり直す。

もちろん、こうした検討は必要である。

しかし、不確実性の高い研究開発では、分析を増やせば増やすほど正解に近づくとは限らない。

なぜなら、そもそも答えがまだ存在していない場合があるからである。

新しい技術が本当に安定して動くのか。顧客が実際に使ってくれるのか。現場の業務が変わるのか。想定価格で購入してもらえるのか。

これらは、会議室の中で資料を増やしても分からない。

実際に試してみなければ分からない。

このときDQLに必要なのは、「未来を正確に当てる能力」ではない。

できるだけ安く、できるだけ早く、間違いに気づく能力である。

 

完璧な事業計画を作ることが、必ずしも賢いとは限らない

企業の新規テーマでは、しばしば立派な事業計画書が作られる。

市場規模、売上予測、開発費、投資回収期間、競合分析、技術課題、量産計画まで、数十ページにわたって整理されている。

しかし、そこに書かれている数字の多くは、まだ確認されていない仮説である。

たとえば「五年後に市場規模100億円」と書かれていても、その市場自体がまだ存在していないこともある。

「顧客の30％が購入する」と予測しても、実際に顧客へ見せたことがなければ、その数字に根拠はほとんどない。

私はこうした計画を否定しているわけではない。

問題は、仮説を、事実であるかのように扱ってしまうことである。

研究開発初期の事業計画は、本来「未来を説明する文書」ではない。

「何がまだ分かっていないか」を明確にする文書であるべきだ。

そして、その分からないことを一つずつ確認していく。

この姿勢が重要である。

 

大きく賭ける前に、まず300万円で確かめる

簡単な例を考えてみよう。

ある製造装置メーカーが、AIを使った故障予知サービスを新規事業として検討しているとする。

経営会議では、「今後は予知保全市場が伸びる」「AIは重要だ」という意見が出ている。

そこでいきなり、AI開発チームを10人集め、クラウド基盤を構築し、数億円規模のシステム開発を始めたとする。

これはかなり大きな賭けである。

しかし、この段階では重要なことがまだ分かっていない。

本当に顧客は故障予知に困っているのか。困っているとして、その問題にいくら払うのか。必要なデータは取得できるのか。実用的な精度で異常を検出できるのか。

そこで、最初の投資を300万円程度に抑え、数社の顧客設備からデータを取得して簡易モデルを作ってみる。

同時に、保全部門へ「この故障を一日前に予測できたら、いくらの価値がありますか」と聞く。

もし顧客が「故障しても予備機に切り替えるだけなので、それほど困っていない」と答えたなら、そこで重要なことが分かる。

AIの精度を高める前に、そもそも事業価値が小さいのである。

逆に、「一時間停止すると500万円の損失になる」という顧客が何社も見つかれば、次の投資へ進む意味が出てくる。

これが「小さく賭ける」という考え方である。


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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/25

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

 「顧客損失」を金額に変えると、技術テーマの優先順位が見える

研究開発テーマの会議では、テーマの魅力度が形容詞で語られることが多い。

「将来性がある」。

「重要な顧客から要望されている」。

「技術的に面白い」。

「成長市場である」。

どれも間違いではないが、複数テーマを比較するときには弱い。

そこで、可能な限り顧客損失を金額へ変換してみる。

設備停止なら、1時間停止した場合の生産損失はいくらか。

不良なら、廃棄費だけでなく、再加工、検査、顧客対応まで含めていくらかかっているか。

保守なら、作業者の工数、交換部品、設備停止を含めた年間費用はいくらか。

熟練者依存なら、その人が退職した場合にどれだけの生産性や品質が失われるか。

厳密な数字でなくてもよい。

最初は概算でもいい。

重要なのは、技術テーマを「面白いかどうか」から、「どれほどの経済価値を生み出せる可能性があるか」へ翻訳することである。

DQLは、技術の言葉と経営の言葉をつなぐ必要がある。

「このセンサーは精度が高い」という説明だけでなく、

「この精度が実現すれば、現在年間3000万円発生している停止損失を半減できる可能性がある」

と説明できることが重要である。

この瞬間、技術開発は単なる研究費ではなく、投資候補になる。

 

顧客損失が大きくても、自社が勝てなければ意味がない

ただし、顧客損失が大きいからといって、すぐに研究開発テーマにしてよいわけではない。

事業機会には、もう一つの条件がある。

自社がその問題を解決する合理的な理由があるか

ということである。

市場が大きいから参入する。

AIが伸びているからAI事業を始める。

半導体市場が成長しているから関連製品を開発する。

これだけでは弱い。

競合企業も同じ市場を見ているからである。

自社にしか持っていない顧客接点がある。

独自技術がある。

蓄積したデータがある。

製造ノウハウがある。

既存製品と組み合わせられる。

規制や品質要求に対応できる。

サービス網がある。

こうした優位性と顧客課題が重なったところに、強い研究開発テーマが生まれる。

したがってDQLは、顧客だけを見ていてもいけない。

顧客の損失と、自社の強みの交点を探す必要がある。

そこに競合の状況や市場成長性を重ねる。

その結果として初めて、「このテーマには会社の資源を賭ける価値がある」という判断ができる。

 

DQLは「顧客」と「技術」と「経営」を往復する

ここまで来ると、DQLに必要な役割がさらに明確になる。

DQLは市場調査の専門家ではない。

営業担当者でもない。

研究者でも、設計者でも、品質保証担当者でもない。

しかし、それらすべての領域をつながなければならない。

顧客の現場へ行き、問題を理解する。

その問題を技術課題へ翻訳する。

研究者や設計者と解決方法を考える。

技術的な不確実性を評価する。

必要なら試作や実験を行う。

そして、解決できた場合にどれほどの事業価値が生まれるかを経営へ説明する。

つまりDQLは、顧客、技術、経営の三つの世界を往復する人である。

この往復ができなければ、研究開発は分断される。

営業は「顧客が欲しいと言っている」と言い、技術者は「技術的に難しい」と言い、経営者は「いくら儲かるのか」と聞く。

それぞれが正しいことを言っているのに、話がつながらない。

その翻訳者となるのがDQLである。

 

「何をつくるか」を決めるところから、技術者の仕事は始まる

日本の製造業では長いあいだ、「どうやって良いものをつくるか」が技術者の中心課題だった。

これからは、その一つ前の問いが重要になる。

何をつくるべきなのか。

さらに言えば、

誰の、どの損失を減らすためにつくるのか。

ここが明確になれば、技術開発の方向性も変わる。

必要な性能が見える。

許容できるコストが見える。

優先すべき研究テーマが見える。

顧客にとって不要な過剰品質も見えてくる。

そして何より、技術者自身が、自分たちの仕事がどのように顧客価値と企業利益につながっているかを理解できるようになる。

これが「稼げる技術者」の出発点である。

DQLは、優れた設計をする人である前に、価値のある問題を選べる人でなければならない。

技術テーマを探すのではない。

まず、顧客が現在支払っている損失を探す。

その損失を大きく減らせる可能性があり、自社に解決する力があるなら、そこに研究開発資源を投じる。

この順序を守るだけでも、研究開発テーマの質は大きく変わるはずである。

しかし、ここで次の問題が出てくる。

魅力的な顧客課題を見つけても、その解決策が本当に成功するかどうかは、まだ分からない。

市場性にも技術にも不確実性が残っている。

では、その状態でどこまで投資すればよいのか。

完璧な事業計画を作ってから動くべきなのか。それとも、まず試してみるべきなのか。

次回は、未来を予測することに時間を使いすぎるのではなく、「小さく賭けて、早く学ぶ」という研究開発の考え方を取り上げたい。

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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/24

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

優れた研究テーマは、「大きな損失」と「未解決」から生まれる

研究開発テーマの魅力度を考えるとき、私は二つの軸を見ると分かりやすいと考えている。

一つは、顧客損失の大きさである。

もう一つは、その損失が現在どの程度解決されているかである。

損失が大きく、しかも既存の解決策が不十分な領域には、大きな事業機会がある。

逆に損失が小さい領域では、技術的に面白くても市場は小さい可能性が高い。

また、損失が大きくても、すでに安価で優れた解決策が存在するなら、後発企業が利益を得る余地は限られる。

研究開発テーマを探索するときには、「市場規模が大きいか」だけでは足りない。

その市場の中で、どのような問題がまだ十分に解決されていないのかを見る必要がある。

たとえば成熟した市場でも、顧客の現場を詳しく観察すると、意外なほど大きな未解決問題が残っていることがある。

装置の調整に熟練者が必要である。

異常原因の特定に何時間もかかる。

点検のためだけに設備を停止している。

帳票作成に人が張り付いている。

予防保全のために、まだ使える部品を大量に交換している。

こうした問題は、一見地味である。

しかし、顧客が毎年払い続けている損失を合計すると、非常に大きな金額になることがある。

そこにAI、センシング、制御、材料、シミュレーションなどの技術を当てれば、新しいプロダクトが生まれる。

この順番が重要である。

AIがあるからAI製品を考えるのではない。解決すべき損失があり、その解決手段としてAIが有効ならAIを使う。

これがDQLに求められる発想である。

 

技術者は「要求仕様」の一歩手前まで行かなければならない

設計者は通常、要求仕様を受け取って仕事を始める。

流量はいくら必要か。温度範囲はいくつか。重量は何kg以下か。精度はいくらか。寿命は何年か。

こうした要求を満たすことは設計者の重要な役割である。

しかしDQLは、要求仕様のさらに一歩手前へ行く。

なぜその流量が必要なのか。

なぜその精度が必要なのか。

その性能を達成すると、顧客のどの損失が減るのか。

もし要求を少し緩めても顧客価値が変わらないのであれば、もっと安い設計ができないか。

逆に、要求されていない性能でも、顧客損失を大きく減らせるのであれば、新しい提案ができないか。

ここまで考えると、技術者は単に要求仕様を満たす人ではなくなる。

要求仕様そのものを設計できる人になる。

これはスマイルカーブの上流へ技術者が踏み出すということである。

顧客要求を技術特性へ展開するQFDなどの手法も、この段階で有効になる。

ただし、QFDの表を完成させることが目的ではない。

何を重視すれば、顧客にとって最も大きな価値を生み出せるかを考えるために使うのである。

 

顧客が語る「欲しいもの」を、そのまま信じてはいけない

顧客起点というと、「顧客に聞けばよい」と思われがちである。

しかし、これは半分正しく、半分危険である。

顧客は現在の困りごとについては詳しい。

一方で、その問題をどのような新しい技術で解決できるかまでは分からない場合が多い。

もし20年前に顧客へ「どんな携帯電話が欲しいですか」と聞けば、より小さく、電池が長持ちし、通話音質の良い携帯電話という答えが多かっただろう。

全面タッチパネルで、カメラ、地図、決済、動画、SNSまで統合された端末を要求仕様として答えられた人は多くなかったはずだ。

だから、顧客の言葉をそのまま製品仕様にしてはいけない。

DQLが聞くべきなのは、「何が欲しいですか」だけではない。

現場で何をしているのか。

どこで時間がかかっているのか。

何が失敗しているのか。

その失敗が起こると何が困るのか。

現在はどのような代替手段を使っているのか。

そこにどれだけの金、人、時間が投入されているのか。

顧客が口にする要求の奥にある「本当に解決したい問題」を探す。

ここがプロダクト企画の腕の見せどころである。


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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/23

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

ここも重要である。

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

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

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

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

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

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

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

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

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

廃棄損失かもしれない。

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

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

ここに事業機会がある。

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

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

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

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

だけではない。

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

なのである。


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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,

2026/09/22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

である。

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

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

 

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

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

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

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

これは危険である。

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

むしろ逆である。

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

何に賭けるのか。

どれだけ賭けるのか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[無断転載禁止]

Posted by at 0 件のコメント:
Labels: , , ,
登録: 投稿 (Atom)