第12章（最終章） 会社を変えるのは「正しく賭けられる技術者」である
― 自律的に考え、技術を利益へ変えるDQLをどう育てるか
本連載では、研究開発や新製品開発を、あえて「賭け」という言葉を使って考えてきた。
この表現に違和感を持った人もいるかもしれない。
しかし、研究開発とは本質的に、不確実な未来に現在の資源を投入する行為である。
新しい製品を開発する。新しい市場へ入る。新しい技術へ投資する。若い技術者を将来の重点分野へ配置する。
そのどれも、結果が完全に分かった状態で行うことはできない。
だから企業に必要なのは、「賭けをしないこと」ではない。
どこに賭けるのかを考え、賭け金を管理し、途中で学び、見込みがなくなれば撤退し、勝ち筋が見えたときには大胆に資源を投入できることである。
これが、本連載でいう「正しく賭ける」という意味である。
そして、その意思決定を技術の現場で担う人材こそ、これからの設計品質リーダー、DQLなのである。
「品質を守る人」から「利益を生む品質を設計する人」へ
DQL（設計品質リーダー）という名称から、品質保証や設計審査の専門家を想像する人もいるだろう。
しかし、本連載で考えてきたDQLの役割はもっと広い。
製品が完成した後で問題がないかを確認するだけではない。
そもそも何を開発すべきなのかを考える。
誰のどの問題を解決するのかを考える。
その問題にどれだけの経済価値があるのかを考える。
どの技術を使えば、自社ならではの優位性をつくれるのかを考える。
そして、不確実な部分を小さな実験や試作で確認しながら、研究開発投資を段階的に進める。
ここまで含めて、設計品質である。
言い換えれば、DQLは「良い製品をつくる人」ではなく、
「顧客にとって価値があり、会社にとって利益になるプロダクトを設計する人」
である。
技術者が「何をつくるか」まで考える時代になった
従来、技術者の仕事は「どうつくるか」が中心だった。
要求仕様が与えられ、その仕様を満たす方法を考える。
もちろん、この能力は今後も重要である。
しかし、スマイルカーブの上流で大きな価値を生み出そうとすれば、その一つ前の問いに踏み込まなければならない。
「何をつくるべきか」である。
たとえば、あるメーカーに優秀なAI技術者がいるとする。
その技術者に、
「AIを使った新製品を考えてほしい」
と指示する。
すると、画像認識、予知保全、自動診断、文書生成など、さまざまな技術案が出てくるだろう。
しかし、技術候補が増えても、それだけでは事業にはならない。
顧客が年間数千万円の損失を被っている問題を見つけ、その問題をAIで大幅に減らせるなら、初めて強いテーマになる。
つまり、技術から製品を考えるだけでなく、
顧客の損失から技術を選ぶ
という発想が必要になる。
DQLは、この順番を理解している人材である。
未来を当てるのではなく、「学びながら賭ける」
優れたDQLは、未来を正確に予言できる人でもない。
むしろ、未来が分からないことを前提として行動する。
新規テーマにいきなり1億円を投じるのではなく、まず数百万円で最大の不確実性を確認する。
顧客ニーズが分からなければ顧客に聞く。
技術成立性が分からなければ簡易実験をする。
原価が分からなければ概算モデルを作る。
そして有望だと分かれば、次の投資へ進む。
これは、川を渡るときに一気に向こう岸まで飛ぼうとするのではなく、足場を一つずつ確かめながら進むことに似ている。
重要なのは、絶対に足を滑らせないことではない。
もし一つの足場が危険なら、そこで引き返せることである。
研究開発でも同じである。
失敗をゼロにするのではなく、
失敗したときの損失を小さく設計することで、挑戦回数を増やす。
これが自律的な研究開発の基本になる。
「やめる判断」ができる人こそ、本当のリーダーである
研究開発で難しいのは、テーマを始めることより、やめることかもしれない。
ここまで三年やった。
5000万円使った。
役員にも説明した。
顧客にも期待させている。
こうなると、合理的には撤退すべきでも、「あと少しだけ」という判断が出やすくなる。
これはギャンブルで負けを取り戻そうとして賭け金を増やす状態と似ている。
DQLに必要なのは、テーマへの情熱と同時に、テーマから距離を取る能力である。
「自分がこの技術を好きだから」ではなく、
「今、この時点から新たに1000万円を投資する価値があるか」
と問い直す。
そして見込みがなければ撤退する。
ただし、単に捨てるのではない。
得られたデータや技術、人材を次のテーマへ移す。
優れた撤退とは、敗北ではない。
次の勝負のための資源再配置なのである。
全勝を目指す会社は、むしろ弱くなる
研究開発では、すべてのテーマを成功させようとしてはいけない。
一見、奇妙に聞こえるかもしれない。
しかし、すべてのテーマが成功している組織は、成功確率の高い小さなテーマばかりを選んでいる可能性がある。
たとえば10件中9件を製品化した研究所がある。
しかし、すべて既存製品の小改良で、利益貢献は合計1億円だったとする。
一方、10件中6件しか成功しなかった研究所がある。
4件は途中で撤退した。
しかし、成功した1件が新市場を開き、年間10億円の利益を生んだ。
どちらが会社へ貢献しているだろうか。
研究開発では、「何勝何敗だったか」だけを見ても意味がない。
大切なのは、
ポートフォリオ全体としてどれだけ価値を生み出したか
である。
だからDQLは、自分のテーマだけを見るのではなく、会社全体のテーマ構成も見る必要がある。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード
0 件のコメント:
コメントを投稿