2026/10/16

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

 第9章　AI時代に価値が上がるのは「問いを決める人」

― 答えを出す力より、何を問うかを決める力が重要になる



AIは「知っている人」の価値を下げるのか

生成AIの普及によって、技術者の仕事は大きく変わり始めている。

少し前まで、専門知識を持っていること自体に大きな価値があった。論文を探す。規格を調べる。技術資料をまとめる。統計解析を行う。簡単なプログラムを書く。報告書を作る。こうした仕事には、それなりの知識と経験が必要だった。

しかし現在では、AIを使えば多くの作業を短時間で行えるようになってきた。

もちろん、AIの出力をそのまま信じてよいわけではない。技術的な誤りや、もっともらしい誤情報も含まれる可能性がある。だからこそ専門家の確認は必要である。

それでも、「情報を探す」「文章にまとめる」「候補案を出す」といった作業のコストが下がっていることは間違いない。

ここで、多くの技術者が不安を感じる。

「自分の仕事もAIに置き換えられるのではないか」。

しかし私は、DQL（設計品質リーダー）のような人材については、むしろ逆のことが起こると考えている。

AIが答えを出す能力を高めるほど、

「何を問うべきか」を決める人の価値が上がるからである。

 

答えが速く出るほど、「間違った問い」の損失は大きくなる

AIは、与えられた問いに対して非常に速く答えを返す。

これは大きな強みである。

しかし、問いそのものが間違っていれば、どれだけ速く答えを出しても意味がない。

たとえば、あるメーカーが「既存製品のコストを10％下げたい」と考え、AIに材料変更や部品削減の案を大量に出させたとする。

AIは数分で数十案を出してくれるかもしれない。

しかし本当の顧客課題が、「価格が高いこと」ではなく「導入後の保守工数が大きいこと」だったとしたらどうだろう。

企業は高速で、しかし間違った方向へ進んでいることになる。

これは、非常に性能のよい自動車で道を間違えるようなものである。

速度が速いほど、目的地から遠ざかる速度も速い。

AI時代には、効率化そのものよりも、

「今、本当に解くべき問題は何か」

を見極める能力が重要になる。

 

AIは「問いの答え」を出せても、「会社がどの問いを選ぶか」は決めにくい

研究開発には、常に複数の選択肢がある。

性能を上げるべきか。

原価を下げるべきか。

新市場へ進出するべきか。

既存顧客を深掘りするべきか。

AIを使うべきか。

新素材を使うべきか。

サービス化するべきか。

AIにそれぞれの選択肢を分析させることはできる。

市場情報を整理し、技術動向を比較し、メリットとデメリットを出すこともできる。

しかし、最終的に、

「この会社はどの問いに資源を使うべきか」

という判断には、企業の事情が入る。

自社の技術資産。

顧客との関係。

人材。

資金。

ブランド。

リスク許容度。

そして経営戦略。

これらを総合して、どこに賭けるかを決める必要がある。

AIは優秀な参謀にはなれる。

しかし、戦場のどこで戦うかを決める責任まで完全に委ねることは難しい。

DQLは、この「問いを選ぶ側」に立つ人材である。

 

AIがあるほど、仮説の質が重要になる

研究開発では、AIを使うことで仮説を大量に出せるようになる。

たとえば新製品のアイデアを考える場合でも、顧客課題、競合製品、技術トレンドを入力すれば、多数の候補案を生成できる。

これは非常に便利である。

しかし、候補が増えたからといって、そのまま良いテーマが見つかるわけではない。

重要なのは、その中からどの仮説を選ぶかである。

たとえばAIが、新しい工場向けサービスとして「画像検査」「予知保全」「自動帳票」「省エネ制御」の四つを提案したとする。

どれも技術的には可能そうに見える。

しかし顧客の現場を調べると、画像検査の不良損失は年間100万円、予知保全による設備停止損失は年間3000万円だったとする。

この場合、優先順位は大きく変わる。

AIは選択肢を広げる。

DQLは、

どの選択肢に価値があるかを見極める。

この役割分担が重要になる。

 

AI時代の「賢さ」は、知識量ではなく判断力に移っていく

これまでの技術者教育では、「たくさん知っている人」が評価されやすかった。

材料に詳しい。

規格に詳しい。

解析方法をたくさん知っている。

過去の不具合事例を覚えている。

もちろん、これらは今後も重要である。

しかしAIによって知識へのアクセスが容易になると、知識量そのものの価値は相対的に下がる。

代わりに重要になるのが、

「どの知識を使うべきか」。

「どの情報を信じるべきか」。

「どこまで確認すれば意思決定できるか」。

という判断力である。

料理にたとえると分かりやすい。

AIによって、世界中のレシピを瞬時に取り出せるようになった。

しかし、冷蔵庫にある材料、食べる人の好み、予算、時間を考えて「今日は何を作るべきか」を決めるのは別の能力である。

DQLに必要なのは、レシピをたくさん暗記することではない。

状況に応じて、何を作るかを決められることである。


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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

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

2026/10/15

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

若手技術者に「PLを見る経験」をさせる

では、こうした能力をどう育てればよいのだろうか。

研修で会計用語を教えるだけでは不十分である。

実際のテーマで、売上、原価、粗利、開発費、投資回収などを見る経験をさせる必要がある。

たとえば若手技術者に新製品の一部を任せるとき、「技術仕様を決めてください」だけではなく、

「この仕様変更で原価はいくら増えるのか」

「顧客はいくらなら払うのか」

「年間販売台数が半分なら事業は成立するか」

まで考えさせる。

最初は粗い計算でよい。

重要なのは、自分の設計判断が損益計算書につながっていることを体感することである。

技術者が初めてPLを見ると、「売上が増えれば会社は儲かる」と単純に考えていたことに気づく場合もある。

そこから、利益率、固定費、投資回収といった経営の視点が育っていく。

 

「経営感覚」は座学ではなく、意思決定で身につく

商売の感覚は、知識だけでは身につきにくい。

自分で判断し、その結果を見ることで育つ。

たとえば、三つの開発案から一つを選ぶ小さなプロジェクトを若手に任せる。

A案は性能が高いが高コスト。

B案は性能は中程度だが早く市場投入できる。

C案は革新的だが成功確率が低い。

どれを選ぶかを考えさせる。

そのとき、技術評価だけでなく、顧客価値、原価、市場投入時期、競合状況、投資額まで含めて判断させる。

これは、いわば小さな経営シミュレーションである。

失敗しても会社が大きな損失を受けない範囲で、実際の意思決定を経験させる。

DQL（設計品質リーダー）育成では、このような「小さな経営経験」が非常に重要である。

 

技術者に商売を教えることは、専門性を薄めることではない

ここで一つ誤解を避けておきたい。

技術者に商売を教えるというと、

「技術者をゼネラリストにしてしまうのではないか」

「専門性が浅くなるのではないか」

という懸念が出る。

しかし、目指しているのはそこではない。

DQLには、まず技術者としての軸が必要である。

専門技術を理解していなければ、技術リスクも競争優位性も判断できない。

そのうえで、顧客や事業を見る視点を加える。

深さを捨てて広さを得るのではなく、

専門性の深さに、事業視点の広さを加える

のである。

専門技術という一本の強い根を持ちながら、顧客、市場、経営へ枝を伸ばしていくイメージに近い。

根がなければ倒れる。

しかし枝がなければ、果実は実らない。

 

「技術が分かる経営人材」を社内で育てる

製造業やテック企業では、経営と技術の距離が事業競争力を左右する。

経営側に技術が分かる人がいない。

技術側に事業が分かる人がいない。

この状態では、重要な研究開発投資の判断が難しくなる。

経営は「市場規模は大きいのか」と聞き、技術は「性能は世界最高です」と答える。

しかし、その間にある、

「自社は本当に勝てるのか」

「いくら投資すべきか」

「どの段階で撤退すべきか」

という問いに答える人がいない。

DQLは、その空白を埋める人材である。

技術者でありながら、顧客価値と収益構造を理解し、経営の意思決定に参加できる。

これからの製造業では、こうした「技術が分かる経営人材」を社内からどれだけ育てられるかが重要になる。

 

DQLは「技術を売る人」ではなく「価値を事業にする人」である

ここまでの話をまとめると、DQLに求められる商売の理解とは、単に販売や会計の知識を持つことではない。

顧客が何に困っているのかを知る。

その問題を解決したときの価値を考える。

その価値に見合った価格を考える。

原価と開発費を見積もる。

どれだけ売れれば投資を回収できるかを考える。

そして、継続的に利益を生む仕組みまで考える。

この一連の流れを、技術と結びつけて考えることである。

だからDQLは、単に「技術を売る人」ではない。

技術を顧客価値へ変換し、その価値を事業として成立させる人である。

日本企業には優秀な技術者が多い。

しかし、その技術をどこに使い、どう価値へ変え、どう利益につなげるかまで考える人材は、必ずしも十分ではない。

この層を厚くすることが、研究開発力を経営成果へ変える鍵になる。

そして、ここからさらに大きな変化が始まっている。

生成AIの普及によって、調査、分析、文書作成、設計支援、プログラミングなど、これまで専門家が多くの時間を使っていた仕事の一部が急速に自動化されつつある。

そうなると、技術者の価値はどこに残るのだろうか。

私はむしろ、DQLのような人材の価値は高まると考えている。

なぜならAIが答えを出せる時代ほど、

「何を問うか」「何をつくるか」「どこに賭けるか」を決める人間の価値が高くなるからである。

次回は、このAI時代の技術人材の価値について考えてみたい。

第9章は、「AI時代に価値が上がるのは『問いを決める人』」である。


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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

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

2026/10/14

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

技術者は「誰が払うのか」を考える必要がある

優れた技術でも、支払者が明確でなければ事業にならない。

たとえば工場の省エネ技術を考えてみよう。

設備担当者は非常に高く評価している。

しかし購入予算を持っているのは別部門で、しかも省エネによる利益は工場全体に分散してしまう。

すると、「良い技術だけれど、誰の予算で買うのか分からない」という状況が起こる。

逆に、品質不良を直接減らす装置なら、品質部門や製造部門の予算として通りやすいかもしれない。

商品企画では、「誰が使うのか」だけでなく、「誰が購入を決め、誰の予算で払うのか」

まで理解する必要がある。

BtoB製品では特に重要である。

DQL（設計品質リーダー）が顧客企業の意思決定構造まで理解できれば、技術提案の仕方も変わってくる。

 

「顧客が欲しい」と「事業になる」の間には距離がある

営業部門から、

「顧客が欲しいと言っている」

という話が研究開発に持ち込まれることがある。

これは重要な情報だが、そのまま開発テーマにしてはいけない。

たとえば一社の大口顧客が、特殊仕様の製品を強く求めているとする。

開発すれば確実に買ってくれる。

一見、良いテーマに見える。

しかし、その顧客専用の設計が必要で、年間100台しか売れないとする。

開発費5000万円、専用設備2000万円、さらに保守対応も必要になる。

これでは、売れることは確実でも儲からない可能性がある。

逆に、一社の要望を抽象化すると、同じ問題を抱える顧客が数百社あるかもしれない。

その場合、個別対応ではなく、標準製品として開発する価値が出てくる。

DQLは「顧客が欲しいと言っている」という情報を、

どこまで横展開できる事業機会なのか

まで考えなければならない。

 

研究開発投資を「いくら使うか」ではなく「いつ回収するか」で見る

技術者にとって、研究開発費は「使える予算」として見えやすい。

しかし経営から見ると、それは投資である。

たとえば新製品開発に1億円かかるとする。

製品化後、年間利益が5000万円出るなら、単純計算では2年で回収できる。

年間利益が1000万円しか出ないなら、10年かかる。

技術的に同じくらい魅力的なテーマでも、投資回収の構造は大きく違う。

もちろん、すべての研究テーマに短い回収期間を求めるべきではない。

長期研究には長期研究の役割がある。

しかし、少なくとも事業化段階では、

「開発費はいくらか」

だけでなく、

「その投資を何年で回収できるのか」

という視点が必要である。

これが研究と事業の境界線を考えるうえで重要になる。

 

「売切り」だけでなく、収益モデルまで設計する

これからの製造業では、製品を一度売って終わるビジネスだけではない。

機器にソフトウェアを組み込み、月額利用料を得る。

保守サービスを提供する。

消耗品や交換部品で継続収益を得る。

取得データを使って分析サービスを提供する。

こうした収益モデルが増えている。

たとえば100万円の装置を一度販売するのと、装置価格を80万円に抑えながら、年間20万円の予知保全サービスを提供するのでは、事業の性質がまったく違う。

後者なら顧客との接点が継続し、データも蓄積できる。

そのデータによってサービス精度が上がれば、さらに競争優位性が強くなる可能性もある。

つまりDQLは、製品そのものだけでなく、

その製品からどうやって継続的に利益を生むか

というビジネスモデルにも関心を持つ必要がある。

 

技術者が商売を理解すると、設計の優先順位が変わる

商売を理解することは、技術者を「金のことばかり考える人」にすることではない。

むしろ、技術をどこに使えば最も価値が出るかを判断できるようにすることである。

たとえば、性能を5％高めるために開発費2000万円が必要な案と、保守工数を半分にするために1000万円が必要な案があったとする。

技術者だけの視点なら、性能向上のほうが魅力的に見えるかもしれない。

しかし顧客調査の結果、性能はすでに十分であり、保守工数が最大の不満だと分かった。

さらに保守時間の短縮が顧客に年間100万円の価値を生む。

そうであれば、後者を優先するほうが事業的には合理的である。

この判断をできるようにするのが、商売を理解するということである。

 

DQLは「技術の言葉」を「経営の言葉」へ翻訳する

技術者と経営者の会話が噛み合わないことは珍しくない。

技術者は、

「この方式なら精度が10％上がります」

と説明する。

経営者は、

「それで、いくら儲かるのか」

と聞く。

技術者は、

「技術的には非常に重要です」

と答える。

このやり取りでは、話がつながらない。

DQLは、この間を翻訳する必要がある。

「精度10％向上により検査漏れが年間200件減り、顧客の再検査工数を年間1000時間削減できます。顧客価値として約800万円が見込めるため、現行品より20％高い価格でも競争力があります」

と説明できれば、技術と事業がつながる。

経営者にも判断材料ができる。

つまりDQLは、

性能値を、顧客価値と利益へ翻訳する人

なのである。


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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

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

2026/10/13

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

 第8章　技術者に「商売」を教えなければならない

― 技術を利益に変える力まで含めて、DQL（設計品質リーダー）を育てる


技術が分かるだけでは、事業はつくれない

これまで、研究開発テーマは顧客の損失から考え、不確実性を前提に小さく試し、期待値で投資判断し、複数テーマをポートフォリオとして管理する必要があると述べてきた。

ここまで来ると、DQLに必要な能力が、従来の「設計品質」の枠をかなり超えていることが分かる。

技術に詳しいだけでは足りない。

顧客が何に困っているのかを理解し、その問題がどの程度の経済価値を持つのかを考え、どこまで投資してよいかを判断し、最終的に会社として利益が残るかまで見なければならない。

つまり、これからの技術リーダーには「商売」を理解する力が必要になる。

ここでいう商売とは、営業テクニックを覚えることではない。

値引き交渉が上手になることでもない。

自分たちの技術が、どのように顧客価値へ変わり、その価値がどのように売上や利益へ変わるのかを理解することである。

 

「良い技術」と「儲かる技術」は同じではない

技術者にとっては、性能が高い、精度が良い、寿命が長い、構造が美しい、といった技術的な優秀さは非常に大切である。

しかし、技術的に優秀であることと、事業として儲かることは必ずしも一致しない。

たとえば、あるメーカーが既存製品より精度を2倍にした新型センサーを開発したとする。

技術者から見れば大きな成果である。

しかし顧客の使用環境では、既存精度でも十分だったとする。

この場合、精度を2倍にしたこと自体に顧客価値はほとんどない。

それどころか、高精度化のために高価な部品を使い、原価が30％上がってしまえば、事業としてはむしろ不利になる。

逆に、精度は従来品と同じでも、設置時間が半分になり、保守回数も減る製品であれば、顧客にとっては大きな価値になるかもしれない。

つまり、技術の価値は技術の中だけでは決まらない。

顧客の使い方と経済性の中で決まる。

 

技術者は「原価」だけでなく「価値」を見る必要がある

製造業の技術者は、原価には比較的なじみがある。

部品費はいくらか。

加工費はいくらか。

組立工数はいくらか。

歩留まりはどうか。

これらは重要である。

しかし、原価だけを見ていると「安くつくること」が目的になりやすい。

本当に重要なのは、顧客にどれだけの価値を提供できるかである。

たとえば、ある装置部品の価格が10万円から13万円に上がるとする。

一見すると高くなっただけに見える。

しかし、その部品を使うことで設備停止が年間10時間減り、顧客の損失が100万円減るのであれば、追加3万円は十分に合理的である。

技術者は、原価差3万円だけを見るのではなく、

「顧客側で100万円の損失削減を生む」

という価値まで考える必要がある。

この視点があれば、設計判断も変わる。

単純なコストダウンだけでなく、顧客価値を増やすために、どこへコストをかけるべきかという判断ができるようになる。

 

価格は「原価＋利益」で決めるだけではない

製造業では、価格を「原価に一定の利益率を加えて決める」考え方が根強い。

もちろん、その方法は一つの基本である。

しかし、新しいプロダクトや高付加価値製品では、それだけでは不十分な場合が多い。

たとえば、製品原価が5万円で、社内ルール上20％の利益を乗せて6万円で売るとする。

一方で、その製品を導入すると顧客は年間50万円の保守費を削減できるとする。

この場合、6万円という価格は安すぎる可能性がある。

反対に、原価が5万円だからといって20万円で売れるとは限らない。

顧客が感じる価値が3万円しかなければ、その製品は売れない。

価格は原価からだけでなく、

顧客がどれだけの価値を受け取るか

という視点からも考える必要がある。

この感覚を持つことが、上流の技術者には重要である。

 

簡単な例で考える「儲かる設計」

ある工場向けのバルブを開発するとしよう。

従来品は20万円で、年間1回の定期交換が必要だった。

新製品は30万円するが、交換周期を3年に延ばすことができる。

さらに交換作業には設備停止が伴い、1回の停止で顧客に50万円の損失が出るとする。

この場合、顧客が見るべきなのは製品価格だけではない。

3年間で考えると、従来品は製品代が60万円、さらに交換のたびに停止損失が発生する。

新製品は30万円で済み、交換回数も減る。

単純な購入価格では高く見えても、顧客全体のコストでは大幅に有利になる可能性がある。

このような価値が明確なら、技術者は「30万円では高い」と思う必要はない。

むしろ、なぜ30万円でも顧客にとって得なのかを説明できることが重要である。

ここに、技術と商売の接点がある。

 

「たくさん売れる」と「儲かる」は違う

技術者が事業性を考えるとき、もう一つ注意したいのは売上と利益の違いである。

売上が大きい製品が、必ずしも良い事業とは限らない。

たとえば100億円売れる製品でも、価格競争が激しく、利益率が2％しかなければ、利益は2億円である。

一方、売上30億円でも、独自技術やサービスがあり、利益率20％なら6億円の利益が出る。

研究開発テーマの魅力を見るときには、「市場規模が大きい」という言葉だけでは足りない。

その市場で自社がどの程度の価格決定力を持てるのか。

競合と差別化できるのか。

継続的に利益を得られるのか。

そこまで考える必要がある。

川に例えるなら、売上は流れている水量であり、利益は実際に自社の水車を回してくれる水である。

川が大きくても、水車に流れてこなければ意味がない。

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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

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

2026/10/12

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

人材育成にも「苗木」を育てる時間が必要である

人材育成も、短期・中期・長期で考える必要がある。

現在の主力事業を支える専門家は必要である。

同時に、数年後の新しい事業を担う人材も育てなければならない。

さらに、その先の技術変化に対応できる若い人材も必要になる。

たとえば、現在は機械製品が中心の企業でも、五年後にはソフトウェアやデータサービスが利益の大きな部分を占めると考えているとする。

その場合、五年後になってから「デジタル人材が必要だ」と言い始めても遅い。

今の段階で人を選び、学ばせ、実際のテーマを経験させる必要がある。

果樹園の苗木と同じで、人材も一晩では育たない。

専門技術だけでなく、顧客理解、事業性評価、プロジェクト推進、データ活用などの経験を数年かけて積ませる必要がある。

この意味で、研究開発ポートフォリオと人材育成計画は、本来一つの戦略として設計されるべきなのである。

 

DQL自身も「ポートフォリオ型人材」である

DQL（設計品質リーダー）自身の能力についても、同じことが言える。

DQLは、専門性を持たないゼネラリストではない。

むしろ、何か一つの技術領域についてしっかりした専門性を持つことが前提になる。

そのうえで、顧客課題を理解する力、事業性を見る力、データを扱う力、リスクを判断する力、異なる専門家をまとめる力、経営層へ説明する力などを身につけていく。

すべての分野で専門家になる必要はない。

しかし、必要な専門家と対話でき、その知識を意思決定につなげられる幅は必要である。

つまりDQLは、専門技術を核としながら複数の能力を組み合わせた、いわば「ポートフォリオ型人材」である。

このタイプの人材は、一つの専門領域だけを深く掘る人材育成では生まれにくい。

異なるテーマ、異なる職種、異なる顧客との接点を意図的に経験させる必要がある。

 

優秀な人材を、現在の主力事業だけに置いてはいけない

企業の人材配置には、一つ大きな矛盾がある。

最も優秀な人材ほど、現在の主力事業へ配置される。

売上の大きな製品を任せる。重要顧客を担当させる。難しい不具合を解決してもらう。

短期的には当然の判断である。

しかし、その結果、新規事業や長期テーマには、若手や経験の浅い人だけが配置されることがある。

すると経営は「新規事業がなかなか育たない」と嘆く。

しかし考えてみれば当然である。

会社の未来をつくるテーマに、会社のエースを一人も置いていないからだ。

野球チームが「この試合は絶対に勝ちたい」と言いながら、主力選手を全員ベンチに置くようなものである。

未来の事業を本気で育てたいなら、そこにも勝てる人材を配置しなければならない。

研究開発ポートフォリオを見る際には、予算だけでなく、

どのテーマに、どのレベルの人材を置いているか

を見る必要がある。

 

DQLは、自分のテーマだけを勝たせる人ではない

ここまで来ると、DQLの役割は、一つの研究テーマの推進者を超えてくる。

DQLは、自分のテーマを成功させることに責任を持ちながらも、会社全体の研究開発の中で、そのテーマがどのような位置を占めているかを考えなければならない。

短期収益を守るテーマなのか。

中期的な成長を狙うテーマなのか。

長期的に新しい事業をつくるテーマなのか。

そして、今このテーマに人と金を置くことが、会社全体にとって本当に合理的なのか。

すべてのDQLが研究所長になる必要はない。

しかし、自分のテーマしか見ていない技術者と、会社全体のポートフォリオを理解したうえで自分のテーマを判断できる技術者とでは、意思決定の質は大きく違う。

「自分の研究を続けたい」ではなく、

「会社にとって、今ここに資源を置く価値があるか」

と考えられる。

そこまで視野が広がったとき、技術者は専門家からリーダーへ変わっていく。


会社の五年後は、今のポートフォリオにすでに表れている

五年後の会社がどうなっているかを知りたければ、五年後の経営計画を見るだけでは十分ではない。

むしろ現在の研究開発ポートフォリオを見たほうがよい。

どの技術に投資しているのか。

どの顧客課題を追いかけているのか。

どの市場を狙っているのか。

誰を育てているのか。

どこに優秀な人材を配置しているのか。

現在の売上は、数年前の研究開発の結果である。

同じように、現在の研究開発が、数年後の売上をつくる。

そう考えれば、研究開発ポートフォリオは単なるテーマ一覧ではない。

会社が未来のどこに賭けているかを示す資源配分そのものなのである。

そして、そのポートフォリオを実際の事業へ変えていくためには、技術だけを知っている人材では足りない。

顧客価値と利益の構造を理解し、研究開発テーマを「商売」として考えられる技術者が必要になる。

ところが、日本企業の技術者教育では、専門技術や設計手法は教えても、原価、価格、収益モデル、投資判断、市場構造といった「商売の仕組み」を体系的に学ばせる機会は、それほど多くない。

これからのDQLを育てようとするなら、ここを変える必要がある。

次回は、いよいよ人材育成の核心に入りたい。

第8章は、「技術者に『商売』を教えなければならない」である。

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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

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

2026/10/11

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

長期研究だけでも、会社は稼げない

一方で、「それなら長期研究を増やせばよい」という話でもない。

研究者が興味のあるテーマを自由に追求することは、技術の蓄積という点では重要である。しかし、事業との接点を失えば、研究はいつまでも研究のまま終わる。

たとえば、ある企業が非常に優れた新材料を10年間研究していたとする。論文も発表し、特許も取得した。技術的には高い評価を受けている。

しかし、「その材料で誰のどの問題を解決するのか」が曖昧なままであれば、事業にはつながりにくい。

技術テーマは存在しているが、プロダクトテーマになっていないのである。

だからDQL（設計品質リーダー）は、長期研究に対しても「来年いくら売れるのか」と急かすのではなく、少なくとも将来どのような顧客価値につながる可能性があるのかという仮説を持たなければならない。

すぐに答えを出す必要はない。

しかし、技術と顧客価値をつなぐ仮説は必要である。

すべてのテーマを同じ物差しで評価してはいけない

研究開発ポートフォリオを運営するときに、もう一つ注意が必要なのは、すべてのテーマを同じ評価基準で比較しないことである。

たとえば短期テーマなら、売上、利益、原価低減額、顧客評価などを比較的明確に設定できる。

しかし長期テーマに対して、「来年度の売上はいくらか」と問うても意味がない。

まだ市場そのものが形成されていないかもしれないからである。

長期テーマで見るべきなのは、重要な技術原理を確認できたか、競合との差が見えてきたか、用途仮説が増えたか、顧客との対話が始まったか、といった学習の進展である。

これはサッカーにたとえると分かりやすい。

フォワードとゴールキーパーを、得点数だけで比較する人はいない。役割が違うからである。

研究テーマも同じである。

それぞれがポートフォリオの中でどの役割を担っているのかを明確にしたうえで、その役割に応じた評価を行う必要がある。

 

テーマ数ではなく、実際の資源配分を見る

企業では「短期10件、中期10件、長期10件あります」という資料を見かけることがある。

これだけを見ると、非常にバランスのよいポートフォリオに見える。

しかし、実際の投入資源を確認すると状況が違うことがある。

短期テーマに研究開発人員の80％が配置され、中期テーマには15％、長期テーマには5％しかいない。

予算も同じである。

この場合、テーマ数は均等でも、実質的には短期テーマへ大きく偏っている。

研究開発ポートフォリオで本当に見るべきなのは、テーマの件数ではない。

人員、予算、設備、そして経営幹部がどれだけ時間を使っているかまで含めた資源配分である。

企業の本当の戦略は、経営計画書に書かれた言葉よりも、人と金をどこに置いているかに表れる。

「新規事業を重視する」と書いてあっても、優秀な人材も予算もすべて既存事業に置かれているのであれば、それは新規事業を重視しているとは言いにくい。

 

探索するときは広く、勝ち筋が見えたら集中する

ポートフォリオという言葉から、「できるだけ多くのテーマに分散すればよい」と考えることもある。

しかし、研究開発は金融資産とは少し違う。

人材や設備には限りがあり、テーマを増やしすぎると一つひとつに十分な力を注げなくなる。

たとえば20人の研究者で50テーマを抱えているとする。

表面的には、非常に多くの可能性を探索しているように見える。

しかし、一人が複数のテーマを掛け持ちし、どのテーマにも十分な時間を使えない。

その結果、どれも少しずつしか進まない。

畑いっぱいに種をまいたものの、水をやる人が足りず、どの芽も十分に育たない状態に似ている。

研究開発の初期段階では、広く探索してよい。

多数のアイデアを小さく試す。

しかし、そこから有望なテーマが見つかったら、資源を集中させる必要がある。

つまり、

探索段階では分散し、勝ち筋が見えた段階では集中する。

この切り替えが重要なのである。

 

ポートフォリオは、一度決めたら終わりではない

研究開発ポートフォリオは、年度初めに作成する一覧表ではない。

本来は、常に入れ替わるものである。

あるテーマで予想以上に良い実験結果が出る。顧客から強い反応が返ってくる。競合が撤退する。

そのような情報が得られれば、追加投資を考える。

逆に、技術的な壁が見つかる。競合が圧倒的な製品を発売する。市場そのものが縮小する。

そうであれば、縮小や撤退を検討する。

たとえば10件の初期テーマに1000万円ずつ投資したとしよう。半年後、そのうち2件に明確な顧客ニーズと技術的な優位性が見えてきた。

そのとき、残り8件を同じ金額で続ける必要はない。

見込みの薄いテーマを止め、有望な2件に人と金を移す。

この資源の移動こそがポートフォリオ管理である。

テーマを選ぶことよりも、新しい情報に応じて資源を動かせることのほうが重要なのである。

 

技術ポートフォリオと人材ポートフォリオは切り離せない

ここで、DQL育成という本連載のもう一つのテーマが見えてくる。

研究開発テーマを変えるだけでは、会社は変わらない。

それを実行する人材が必要だからである。

たとえば、会社が「今後はAI、予知保全、デジタルサービスを重点領域にする」と決めたとする。

ところが研究開発人材の大部分が、従来の機械設計や既存製品改善しか経験していない。

この状態で研究テーマ一覧だけをAIやDXへ書き換えても、新規事業が自然に生まれるわけではない。

誰を新しい領域へ移すのか。

誰に新しい専門性を学ばせるのか。

既存の機械系人材とソフトウェア人材をどう組み合わせるのか。

必要なら採用するのか、大学やスタートアップと組むのか。

ここまで考えなければ、研究開発戦略にはならない。

つまり、

技術ポートフォリオを変えるということは、人材ポートフォリオを変えるということでもある。


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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

 

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

2026/10/09

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


 第7章　技術ポートフォリオを持つ会社は強い

― 研究開発は「どのテーマを選ぶか」ではなく「どう組み合わせるか」で決まる

 

一つの有望テーマだけでは、会社の未来はつくれない

前回は、研究開発テーマを成功確率だけで見るのではなく、期待値で評価することの重要性を述べた。成功しやすいテーマが、必ずしも企業にとって価値の高いテーマとは限らない。逆に、成功確率が多少低くても、成功したときの利益が大きく、失敗時の損失を限定できるのであれば、十分に投資する価値がある。

では、最も期待値の高いテーマを一つ選び、そこに研究開発資源を集中すればよいのだろうか。実際には、そう単純ではない。

研究開発には常に不確実性がある。どれほど魅力的なテーマでも、技術的な壁に突き当たることがある。競合企業が予想より早く製品を出すこともあれば、市場そのものが縮小することもある。逆に、当初は小さなテーマだと思っていたものが、途中から大きな事業機会へ育つこともある。

だからこそ、企業の未来を一つの研究テーマだけに預けることは危険である。

重要なのは、複数のテーマを持ち、それぞれ異なる時間軸、リスク、リターンを組み合わせることである。これが研究開発ポートフォリオという考え方である。

 

研究開発も、金融投資とよく似ている

金融投資では、一つの銘柄に全資産を投じることは危険だとされる。どれほど有望に見える企業でも、不祥事、競争激化、規制変更、技術革新などによって突然価値を失う可能性があるからである。

そこで投資家は、安定した資産と成長性の高い資産を組み合わせる。

研究開発も、基本的な考え方はよく似ている。

たとえば、あるメーカーが年間10億円の研究開発費を持っているとする。10億円すべてを革新的な新技術に投じれば、成功したときのリターンは大きいかもしれない。しかし失敗すれば、数年間の研究開発成果がほとんど残らない可能性もある。

反対に、10億円すべてを既存製品の改良や顧客要望への対応に使えば、失敗は少なくなるだろう。しかし五年後、十年後の新しい事業の柱が育たない。

企業に必要なのは、どちらか一方ではない。

現在の利益を支えるテーマと、将来の利益を生むテーマを同時に持つことである。

 

短期・中期・長期の時間軸で考える

研究開発ポートフォリオを考えるとき、最も分かりやすいのは、短期・中期・長期という三つの時間軸に分けることである。

短期テーマは、現在の事業を支える。既存製品の性能向上、原価低減、品質改善、顧客要望への対応などが中心になる。成果が比較的早く見え、売上や利益にもつながりやすい。

中期テーマになると、既存技術を使って新しい市場へ入ったり、新しい機能を持つ製品へ展開したりする。技術的にも市場的にも、短期テーマより不確実性は高くなるが、成功すれば新たな成長領域をつくることができる。

長期テーマはさらに不確実である。新材料、新原理、新しいデジタル技術、新市場など、現在の事業とは距離のあるテーマを扱う。すぐに売上にはならない。しかし、そこから将来の主力事業が生まれる可能性がある。

この三つは、どれか一つが優れているのではない。

短期テーマだけでは未来がなく、長期テーマだけでは現在の利益が持たない。

だからこそ、企業は三つの時間軸を同時に持つ必要がある。

 

研究開発は「果樹園」のようなものである

この考え方は、果樹園にたとえると分かりやすい。

果樹園には、今年たくさん実をつける成木が必要である。それがなければ、今年の収穫がなくなってしまう。

しかし、成木ばかりを大切にし、若木や苗木を植えなければどうなるだろうか。数年後には木が老い、収穫量が減っていく。

だから果樹園では、今実をつけている木を管理しながら、数年後に実をつける若木も育てる。さらに、その先のために苗木も植える。

研究開発もまったく同じである。

既存製品の改善は、今収穫している成木である。中期テーマは、数年後に収穫を期待する若木であり、長期研究は、まだ実がなるかどうかも分からない苗木である。

苗木はすべて育つわけではない。途中で枯れるものもある。

しかし、苗木を植えない果樹園には未来がない。

企業の研究開発ポートフォリオとは、いわば「会社の未来の果樹園をどう育てるか」を考えることである。

 

なぜ短期テーマばかりが増えていくのか

多くの企業で起こるのは、短期テーマの膨張である。

理由は単純である。短期テーマには期限がある。

顧客から「来月までに対応してほしい」と言われる。営業部門から競合対策の機能追加を求められる。不具合が起きれば、すぐに原因究明が必要になる。原価低減目標も毎年度設定される。

こうした仕事は、放置することができない。

その結果、研究開発部門の人員は次々と短期案件へ吸収されていく。

一方、長期研究には「来月まで」という期限がないことが多い。

そのため、

「今期は忙しいから来年度にしよう」

という判断が繰り返される。

すると、研究開発部門は非常に忙しくなる。テーマ数も多い。会議も多い。試作品もたくさん作られている。

しかし五年後に振り返ってみると、主力製品はほとんど変わっていない。

この状態は珍しくない。

活動量が多いことと、未来をつくっていることは同じではないのである。

 

長期研究だけでも、会社は稼げない

一方で、「それなら長期研究を増やせばよい」という話でもない。

研究者が興味のあるテーマを自由に追求することは、技術の蓄積という点では重要である。しかし、事業との接点を失えば、研究はいつまでも研究のまま終わる。

たとえば、ある企業が非常に優れた新材料を10年間研究していたとする。論文も発表し、特許も取得した。技術的には高い評価を受けている。

しかし、「その材料で誰のどの問題を解決するのか」が曖昧なままであれば、事業にはつながりにくい。

技術テーマは存在しているが、プロダクトテーマになっていないのである。

だからDQL（設計品質リーダー）は、長期研究に対しても「来年いくら売れるのか」と急かすのではなく、少なくとも将来どのような顧客価値につながる可能性があるのかという仮説を持たなければならない。

すぐに答えを出す必要はない。

しかし、技術と顧客価値をつなぐ仮説は必要である。


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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

 


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

2026/10/08

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

 一つのテーマではなく、研究開発全体で勝つ

ここまでの話は、一つのテーマだけを見ていると分かりにくい。

研究開発は、ポートフォリオ全体で考えると理解しやすい。

たとえば10件の研究テーマを持っている会社があるとする。

そのうち6件は、既存製品の改良や顧客要望への対応である。

成功確率は高いが、大きな成長は期待できない。

3件は、新技術を使った新製品である。

成功確率は中程度だが、成功すれば新しい市場へ入れる。

そして1件は、成功確率は低いものの、成功すれば会社の事業構造を変える可能性がある。

この組み合わせなら、短期の収益を確保しながら将来への挑戦もできる。

ところが10件すべてが安全な改良テーマなら、現在の売上は守れても未来は弱い。

反対に10件すべてが大勝負なら、会社の資金が持たないかもしれない。

必要なのは、

異なるリスクとリターンを持つテーマを組み合わせること

である。

これは金融投資のポートフォリオと非常によく似ている。

 

「九勝一敗」より「六勝四敗」のほうが強いこともある

研究開発組織の評価では、失敗件数が少ないほど優秀に見える。

しかし、たとえば二つの組織を比較してみよう。

X研究所は10件中9件を製品化した。

しかし、どれも既存製品の小規模改良で、利益への貢献は1件1000万円だった。

合計9000万円である。

Y研究所は10件中6件しか製品化できなかった。

4件は途中で撤退した。

しかし6件のうち1件が大きな新市場を開拓し、5億円の利益を生み出した。

どちらの研究所が会社に貢献しているだろうか。

単純な「成功率」ならXは90％、Yは60％である。

しかし経営成果ではYが圧倒的に大きい。

これはスポーツでも同じである。

すべての打席でヒットを狙う選手と、ときには三振しても長打を打てる選手では、チームへの貢献の仕方が違う。

研究開発でも、

失敗件数の少なさを競うのではなく、トータルで勝つこと

が重要である。

 

ただし「一敗で会社が死ぬ」テーマは避けなければならない

ここで、期待値だけでは不十分なもう一つの理由がある。

企業には倒産という状態がある。

理論上の期待値が高くても、一度の失敗で会社が存続できなくなる賭けはできない。

たとえば、成功確率70％で、成功すれば100億円儲かるテーマがあるとする。

非常に魅力的に見える。

しかし失敗した場合に300億円の損失が発生し、自社の財務では耐えられないのであれば、その賭けをしてはいけない。

これもギャンブルの鉄則と同じである。

どれほど有利な勝負でも、全財産を一度に賭けてしまえば、一回の不運で退場する。

企業経営では、

期待値を高めることと、破滅確率を下げることを同時に考える

必要がある。

DQL（設計品質リーダー）も、研究開発テーマの魅力だけでなく、会社がどこまでその失敗を許容できるかを考えなければならない。

 

期待値は、途中で変わる

研究開発テーマを開始した時点で決めた期待値は、固定ではない。

研究が進めば新しい情報が入る。

技術実験で良い結果が出れば成功確率は上がる。

競合企業が画期的な製品を発売すれば、成功時の利益は下がるかもしれない。

顧客から想定以上の反応が得られれば、市場価値は上がる。

逆に原材料価格が高騰すれば、事業性は悪化する。

つまり研究開発テーマの価値は常に変化している。

だからこそ、テーマを開始したときの事業計画を最後まで守ることが必ずしも正しいとは限らない。

DQLは定期的に、

「今、このテーマをゼロから提案されたとして、それでも投資するだろうか」

と問い直す必要がある。

この問いを使うと、過去の投資や思い入れをある程度切り離して判断できる。

前回取り上げたサンクコストへの対策にもなる。

 

DQLは「研究テーマの選手」ではなく「監督」になる

専門技術者は、自分の担当テーマを成功させようとする。

それは当然である。

しかしDQLは、一段上の視点を持たなければならない。

一つのテーマだけを勝たせることではなく、

限られた研究開発資源を、会社全体として最も価値の高いところへ配分する

ことを考える必要がある。

野球にたとえるなら、個々の技術者は選手である。

一方DQLは、選手としての能力も持ちながら、監督の視点も持つ。

この投手をここで使うのか。

代打を出すのか。

若手を育てるのか。

一点を取りに行くのか。

長打を狙うのか。

試合全体を見て判断する。

研究開発も同じである。

短期の売上を支えるテーマ。

中期的な成長を狙うテーマ。

長期的に大きな事業を生むテーマ。

それぞれを組み合わせる。

この視点を持った人材がいなければ、研究開発テーマは各部門の希望を集めただけの一覧表になってしまう。

 

「全部成功させる」発想を捨てる

研究開発には失敗がある。

これは避けられない。

むしろ不確実なテーマに挑戦しているのに、すべて成功しているとしたら、挑戦の水準が低すぎる可能性さえある。

重要なのは、失敗を放置することではない。

小さく失敗する。

早く学ぶ。

見込みがなくなればやめる。

有望なテーマには追加投資する。

そして成功したテーマから大きなリターンを得る。

この一連の仕組みを作ることである。

つまり研究開発で目指すべきなのは、

「すべてのテーマを成功させること」ではなく、「テーマ群全体で勝ち越すこと」

なのである。

DQLには、そのための判断力が必要になる。

技術的な成功確率だけを見るのではない。

顧客価値を見る。

市場を見る。

競合を見る。

成功時のリターンを見る。

失敗時の損失を見る。

そして会社全体の研究開発ポートフォリオの中で、そのテーマがどの役割を持つのかを考える。

ここまでできて初めて、研究開発は「テーマ管理」から「投資マネジメント」へ変わる。

では、実際にはどのような研究開発テーマを、どのくらいの比率で持てばよいのだろうか。

短期的な改良テーマだけでは未来がない。

しかし長期テーマだけでも会社は生きていけない。

次回は、この問題を研究開発ポートフォリオの視点から考えてみたい。

第7章は、「技術ポートフォリオを持つ会社は強い」である。

 

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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

 

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

2026/10/07

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

DQLは「勝つ確率」だけでなく「負け方」まで設計する

優れたDQL（設計品質リーダー）は、成功させる方法だけを考えない。

もし失敗した場合に、どこまで損失が出るのかも考える。

たとえば新しい生産設備を必要とする製品開発なら、最初から専用ラインを作らず、既存設備や外部委託を使って市場性を確認できないかを考える。

新しいAIサービスなら、最初から大規模なクラウドシステムを構築せず、既存ツールを使った簡易版で顧客価値を検証する。

新材料なら、量産金型を作る前に簡易試験片や加工品で重要特性を確認する。

つまり、

「成功する設計」だけでなく「失敗しても致命傷にならない開発の進め方」を設計する。

この能力があれば、成功確率の低いテーマにも挑戦しやすくなる。

これはギャンブルでいう資金管理に近い。

勝つ可能性があっても、一回の負けで全財産を失うような賭け方はしない。

研究開発も同じである。

 

「大穴狙い」と「高期待値テーマ」は違う

ここで注意したいのは、期待値で考えることと、大きな夢のあるテーマなら何でもよいということは違うという点である。

たとえば、

「成功すれば1000億円市場になる」

という研究テーマがあったとする。

しかし技術成立性はほとんど確認されていない。

顧客ニーズも曖昧である。

競合優位性もない。

それでも「成功すれば1000億円」と言えば、魅力的に聞こえる。

これは期待値というより、単なる夢物語である。

競馬でいえば、100倍の配当が付いているからといって、どんな馬でも買えばよいわけではない。

勝つ可能性がほとんどなければ、期待値は高くならない。

DQLが見るべきなのは、

市場規模だけではない。

顧客損失の大きさ。

自社の技術優位性。

競合との差。

成功までの時間。

必要投資額。

そして途中で得られる学習。

これらを総合して判断する必要がある。

つまり、

「夢が大きいテーマ」ではなく、「リスクに対してリターンが大きいテーマ」を選ぶ。

これが重要である。

 

技術テーマにも「オッズ」がある

ギャンブルの世界にはオッズがある。

勝つ可能性と、勝った場合の配当の関係である。

研究開発にも、目には見えないが似たものがある。

ある技術はすでに成熟している。

成功確率は高いが、競合企業も簡単に参入できる。

つまり成功しても大きな利益は得にくい。

別の技術は難しい。

成功確率は低い。

しかし成功すれば競合が簡単には追随できず、高い利益率を長期間維持できる。

この場合、後者には技術的な「オッズ」がある。

たとえば特殊材料、独自アルゴリズム、製造ノウハウ、特許、データ蓄積などが組み合わさると、成功したときの競争優位は非常に大きくなる。

DQLは技術テーマを見るとき、

「できるか、できないか」

だけを見るのではない。

「できたときに、どれだけ他社との差になるのか」

まで見る必要がある。

 

期待値の高いテーマには「非対称性」がある

魅力的な研究開発テーマには、ある特徴がある。

それは、成功したときの利益が大きく、失敗したときの損失が比較的小さいことである。

これを「非対称性」と考えると分かりやすい。

失敗すれば1000万円を失う。

しかし成功すれば数億円の新規事業になる。

こうしたテーマを複数持つことができれば、研究開発全体の魅力は高くなる。

逆に、

成功しても3000万円程度しか利益が出ないのに、失敗すれば1億円失う

というテーマは危険である。

成功確率が多少高くても、割に合わない。

簡単な例えを使えば、コイン投げである。

表なら100円もらえる。

裏なら100円失う。

これなら五分五分である。

しかし、

表なら1000円もらえる。

裏なら100円失う。

という条件なら、何度も参加する価値がある。

研究開発でも、

「当たるかどうか」だけでなく、「当たったときと外れたときの差」を見る。

これが期待値の考え方である。

  

 

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

[無断転載禁止]

DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード

 

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