手段としてのオープンイノベーション

更新日

投稿日

1.オープンイノベーション...

1.オープンイノベーションの現状

 
 オープンイノベーションものづくり企業のR&Dにおいて「オープンイノベーション」が注目されています。様々なものづくり会社の経営者、R&Dのトップマネジャーが、オープンイノベーションに積極に取り組む主旨の発表をすることが多くなりました。メディアではオープンイノベーションの華々しい事例が紹介され、書店ではオープンイノベーションの実践方法を紹介した書籍も目につくようになりました。もはや、注目というよりもブームになっているような感じさえあります。
 
 確かに、外部の資源とりわけ技術を積極的に自社のイノベーションに活用することにより、事業展開のスピードアップ、R&Dの効率化を図るという意味でオープンイノベーションが重要であることに否定の余地はありません。市場のチャネルやサプライチェーンを支配している会社であれば、オープンイノベーションが事業成果に直結することも十分あると思います。また、自前の技術にこだわり過ぎているR&Dのマインドを、事業及び価値起点のR&Dに変えるために、オープンイノベーションをコンセプトとした改革を進めることに意味がないとは思いません。
 
 しかし、言うまでもなく、オープンイノベーションは手段であり、目的ではありません。顧客価値を創造し、収益の伴う強い事業を実現するための手段にすぎないのです。単に自社の技術を公開する、あるいは外部の技術を取り入れることで、競争力のある商品や事業が生み出せることはありません。最近のR&D現場では、ともすればオープンイノベーションというキーワードばかりが先行し、外部技術の導入、外部との連携、自社技術の公開など、いかにオープン化するかばかりが議論されている状況を目にします。R&D現場をフィールドとするコンサルタントとして、多少の違和感を感じます。
 

2.技術は、知識の複合体

 
 R&Dが考えるべき最も重要なことは、いかにオープン化するかではなく、自社の技術の「何を」「どのように」クローズ化するかを明確にすることだと私は思います。クローズ化する技術を明確にしなければ、何をオープン化すればよいかもわかりません。しかし、実際のR&Dにおいてクローズすべき技術は何かが明確にされ、必要な関係者間で共有されているかと言うと、実際にはそうでもない場合が多いのです。クローズ化する技術が明確でない中でオープンイノベーションのキーワードばかりが先行すると、ともすれば、「オープンにすることはよいことだ」的な、それそのものが目的になった極端な思考に陥ってしまいがちです。
 
 クローズ化する技術(以降、これをコア技術と呼びます)を明確にするためには、事業(もしくは製品)における自社の強みと弱みを明確にしなければなりません。強い競争力を持つ事業であれば、「なぜ自社は強いのか」「どのような価値を顧客に提供していることが強さの源泉なのか」を具体化し、それに紐づいている自社技術を明確にする必要があります。強い競争力を持たない事業であれば「なぜ自社は弱いのか」「競合他社に比較し、自社が提供できていない顧客価値は何か」を具体化し、顧客価値につながる自社技術はあるのか、また、どのような技術が不足しているのか、を分析する必要があります。
 
 さらに、コア技術をどう守り切るかについても明確にすることが重要です。一言で技術といっても、その中身は、技術思想として確立・標準化したロジックや方法論、市場や技術検討の中で蓄積したデータ、経験に基づくノウハウなど、様々な形が組み合わさった知識の複合体です。これらを守るためには、特許のみならず、意匠、商標、著作権、そして秘匿、さらには契約などの手法を組み合わせる必要があります。また、リスク回避(クロスライセンスに持ち込まれない、技術的な陳腐化を防ぐ)のために、将来を先読みしながら改良技術及び代替技術の知財権を継続して確立していくシナリオを描くことも重要です。
 

3.技術者、研究者ではなくビジネスパーソンとしての取組み

 
 クローズ化する技術と、それを守り切る戦略を明確にした次の段階として、オープン化する技術を具体化することになります。この際、技術者、研究者にはマインドチェンジが必要です。技術者、研究者はともすれば自分でやりたいと思いがちです。また、時間さえあれば実際にやれてしまうことも多いでしょう。しかし、ここでは、技術者、研究者ではなく事業の一役を担うビジネスパーソンとしての視角で、目的に基づき大胆に考えなければなりません。目的は技術開発することではなく、顧客価値の創造であり、強い事業を作ることです。この目的を実現するために、自社の枠を越えたビジネス・エコシステムを大胆に構想し、自社技術の積極的な公開や外部技術の導入に取り組むというマインドが必要です。そして、事業・知財・R&Dがチームとなり、知恵を出し合う三位一体の取り組みが鍵になります。
 
 

   続きを読むには・・・


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
リスクベース設計とは

 今回は、潜在不良流出を防止するリスクベースの設計手法について解説します。設計終了後の評価テストや、製造工程の試験、検査で発見できない不具合が市場で発生す...

 今回は、潜在不良流出を防止するリスクベースの設計手法について解説します。設計終了後の評価テストや、製造工程の試験、検査で発見できない不具合が市場で発生す...


ニーズとシーズ 設計機能(その4)

【設計機能 連載目次】 設計機能(その1)機能とは  設計機能(その2)設計上の機会損失  設計機能(その3)機能の分類&n...

【設計機能 連載目次】 設計機能(その1)機能とは  設計機能(その2)設計上の機会損失  設計機能(その3)機能の分類&n...


技術力の根源とは何か

1. 従来の技術力の定義  技術力とはそもそも何でしょうか。学者たちは、「長い時間を掛けて積み上げた老練な技の集積であり、また同時にそれを継承し、巧みに...

1. 従来の技術力の定義  技術力とはそもそも何でしょうか。学者たちは、「長い時間を掛けて積み上げた老練な技の集積であり、また同時にそれを継承し、巧みに...


「技術マネジメント総合」の活用事例

もっと見る
プロジェクトの問題を見極める2 プロジェクト管理の仕組み (その24)

 前回のプロジェクトの問題を見極める1に続いて解説します。    図58はアクティビティ軸からシステム設計だけを抽出し、サブグループごとの工...

 前回のプロジェクトの問題を見極める1に続いて解説します。    図58はアクティビティ軸からシステム設計だけを抽出し、サブグループごとの工...


設計部門の仕組み構築(その3)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


ソフトウェア開発の成果物による進捗管理 プロジェクト管理の仕組み (その16)

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...