AIを使えば「小さく賭ける」コストをさらに下げられる
本連載では、研究開発では最初から大きく賭けるのではなく、小さく試しながら不確実性を減らすことが重要だと述べてきた。
AIは、この「小さく賭ける」能力を大きく高める。
たとえば新製品の企画段階で、市場調査を行うとする。
以前なら、調査会社へ依頼し、数週間かけて資料を集める必要があった。
現在では、AIを使って公開情報を整理し、競合製品を比較し、顧客課題の仮説を短期間で作ることができる。
もちろん、その結果を顧客ヒアリングなどで確認する必要はある。
しかし、最初の仮説形成にかかる時間は大幅に短縮できる。
同じことは技術開発にも言える。
実験条件の候補を出す。
過去データを整理する。
技術文献を比較する。
シミュレーション用のコードを作る。
こうした作業をAIで速く回せれば、より多くの仮説を低コストで試せる。
つまりAIは、
一回の賭け金を小さくし、試行回数を増やすための道具
にもなる。
AIで速くなった分だけ、「確認すべきこと」を間違えてはいけない
ただし、AIによって開発スピードが上がると、新しい危険も生まれる。
それは、「たくさん試したので、十分検討した」と錯覚することである。
AIを使えば、候補案を100個出すこともできる。
シミュレーションを大量に回すこともできる。
市場分析資料も短時間で作れる。
しかし、100個の案を出したことと、重要な仮説を検証したことは同じではない。
たとえば新しい業務支援AIを企画し、画面案を20種類作ったとする。
しかし、顧客がそもそもその業務にお金を払ってでも困っているのかを確認していなければ、20案すべてが無意味になる可能性がある。
DQLは、AIによってできることが増えるほど、
「この検討は、どの不確実性を減らしているのか」
を問い続ける必要がある。
AIは「専門家の代わり」ではなく「専門家を束ねる道具」になる
DQLの役割を考えるうえで、AIにはもう一つ大きな意味がある。
異なる専門領域をつなぎやすくなることである。
新しい製品を企画するには、機械、材料、電気、ソフトウェア、品質、法規、マーケティングなど、多くの知識が必要になる。
従来は、一人の技術者がこれらすべてを理解することは難しかった。
そこで各分野の専門家を集める必要があった。
もちろん、今後も専門家は必要である。
しかしAIを使えば、DQL自身が専門外の領域について基礎的な理解を短時間で得やすくなる。
たとえば機械系のDQLが、ある新製品でサイバーセキュリティが重要だと感じたとする。
AIを使って基本概念や関連規格、想定リスクを整理し、そのうえでセキュリティ専門家と議論する。
こうすれば、最初からすべてを専門家任せにするより、質の高い対話ができる。
AIは専門家を不要にするのではない。
専門家同士をつなぐ人の能力を高める。
この点でもDQLとの相性は非常に良い。
「AIが出した答え」を疑える人が必要になる
AI時代には、もう一つ重要な能力がある。
疑う力である。
AIは、非常に自然な文章で答えを出す。
そのため、内容が正しいように見えやすい。
しかし研究開発では、小さな誤りが大きな判断ミスにつながる。
材料物性。
規格要求。
安全条件。
市場データ。
統計解析。
これらを誤って解釈すれば、研究テーマの優先順位そのものが変わることもある。
たとえばAIが「この市場は年率20％で成長している」と説明したとする。
数字だけを見ると魅力的である。
しかし、その数字が世界市場なのか国内市場なのか。
装置全体なのか特定部品なのか。
売上高なのか出荷台数なのか。
定義が違えば意味はまったく変わる。
DQLには、AIの出力を便利な「答え」として受け取るのではなく、
意思決定に使える証拠かどうかを確かめる姿勢
が必要になる。
AI時代には「問いを分解する能力」が重要になる
大きな問いを、そのままAIに投げても良い答えは得にくい。
たとえば、
「次に何を開発すれば儲かりますか」
と聞いても、一般論しか返ってこない。
しかし問いを分解すれば、状況は変わる。
現在の顧客が最も大きな損失を抱えている工程はどこか。
その損失はいくらか。
既存製品ではなぜ解決できないのか。
競合はどこまで対応しているのか。
自社が持つ技術資産で何が使えるか。
技術成立性を確認する最小実験は何か。
このように問いを構造化すると、AIも有効に使えるようになる。
つまりAI活用能力とは、単にプロンプトを書く技術ではない。
複雑な問題を、検証可能な問いへ分解する能力
なのである。
これはDQLがこれまで身につけるべきだと述べてきた能力とほとんど同じである。
簡単な事例――AIで100案を出すより、「一つの良い問い」を持つ
ある産業機器メーカーが、新規事業テーマを探していたとする。
担当チームは生成AIを使い、「製造業向けのAI新製品アイデアを100個出してほしい」と依頼した。
AIはさまざまな案を出した。
予知保全。
外観検査。
作業支援。
エネルギー最適化。
自動報告。
どれもそれらしく見える。
しかし、どれを選ぶべきか分からない。
そこでDQLが現場へ行き、顧客の保全部門に話を聞いた。
すると、「故障そのものより、故障した後に原因を特定するまで平均6時間かかることが困っている」と分かった。
ここで問いが変わる。
「予知保全AIを作るか」ではなく、
「設備異常後の原因特定時間を6時間から30分に短縮できないか」
になる。
この問いなら、必要なデータも技術も顧客価値も具体化できる。
AIはその後で使えばよい。
※御社のプロダクト（製品・サービス）分野で同様の話が聞きたい！という場合は、どうぞご相談ください。
[無断転載禁止]
DQL（設計品質リーダー）育成コースの詳細なご案内は下記よりダウンロードできます。
ダウンロード
過去の故障履歴を整理する。
原因候補を分類する。
必要なセンサーデータを考える。
診断ロジックを作る。
つまりAIによって100個のアイデアを出すことよりも、価値ある一つの問いを発見するほうが重要なのである。
