成果物の確認に「学習と判断」の視点を加える

　ディープテックの共同研究で陥りやすいのが、「試作品の完成」といった成果物だけを節目に置くことです。もちろん成果物は必要ですが、不確実性の高い研究開発では、想定した成果に到達しないことも珍しくありません。「達成／未達」だけで評価すると、重要な知見を得ていてもプロジェクトとしては失敗扱いになってしまいます。

　そこで私は、成果物の達成状況に加え、「この期間で、何の不確実性が減ったのか」の確認を推奨します。図4は、成果物の確認と学習・判断の確認を組み合わせた進捗管理です。成果物管理を廃止するのではなく、何がわかり、どの仮説が否定され、次に何を判断できるようになったかをあわせて評価します。

　たとえば、目標性能に達しなかった場合でも、性能を制約する条件が明らかになれば、設計変更や用途の見直しを判断できます。ただし、「学びがあった」という説明だけでは不十分です。検証条件、得られた結果、残る不確実性、判断理由を記録し、研究開発と事業開発が同じ証拠に基づいて議論できる状態をつくります。

　運用上は、半年や1年先の成果目標に加え、検証に必要な期間に応じて短い節目を設定します。例として2〜3ヵ月を一つの目安とし、「仮説を設定→検証を実施→証拠を評価→継続・修正・中止を判断→次の仮説を設定」の循環を回します。検証に長い時間を要する領域では、その特性に合わせて節目を設計し、探索の自由度と意思決定の規律を両立させます。

技術成熟度と事業実装の準備度を二軸で確認する

　もう一つ重要なのが、TRLだけでプロジェクトを評価しないことです。TRLが高く実環境で動作しても、顧客課題が未検証だったり、規制や知財の壁があったりすれば事業化は成立しません。

　図5では、縦軸に技術成熟度、横軸に事業実装の準備度を置いて整理しました。技術側では原理、性能、再現性、実環境での動作を、事業側では顧客価値、採算、知財、規制、供給、運用を確認します。ここでいう「事業実装の準備度」は本稿の整理であり、標準化された数値尺度ではありません。

　二軸で確認することで、「技術は進んでいるが顧客価値や採算が未検証」「需要は見込めるが性能や量産性が不足」といった状態を区別できます。右上は社会実装に向けた条件が整う領域を示しますが、事業成功を保証するものではなく、導入・運用を通じた検証が必要です。技術担当者だけで閉じず、事業、知財、法務、調達部門などを適切な時期に巻き込み、両面を並行して成熟させることが重要です。