リスクマネジメント 新規事業・新商品を生み出す技術戦略(その81)

更新日

投稿日

技術マネジメント

 

◆ 共創におけるリスクマネジメント

 今回は「共創におけるリスクマネジメント」というタイトルで解説します。

 昨今オープンイノベーションにより、高度で複雑な商品・サービスを開発することは、当たり前になってきました。しかしながらオープンイノベーションに取り組んだものの、思ったような開発成果が得られないという企業の声も耳にします。

 これは、どちらの企業が技術を獲得するかといったパワーゲームによる理由ももちろんありますが、開発そのものが目標に達しない、連携がうまくできないといった開発現場における要因も少なくありません。

 開発現場による失敗を極力少なくするために、全体を統括するリーダーには、徹底したリスクマネジメントスキルが求められます。

 大学や研究機関といった社外組織との技術開発だけではなく、研究開発組織と社内事業部との協業においても、開発リーダーが抑えておくべきリスクマネジメントのポイントを3つ紹介します。

 

1. 自部門=内部よりも他部門=外部の進捗、課題、リスクに注意する

 オープンイノベーションの現場で目にするケースとして、全体マネジメントを行うリーダーが自社の開発に注力し過ぎ、共創先の開発にあまり注目しないことで、開発成果が得られないことがあります。

 これは「共創先の開発に口出ししてはいけない」という意識なのかもしれません、もしくは責任範囲を明確に分けているという意識の表れかもしれません。さらに言えば、どうしても自社・自部門の開発に対する思い入れが強くなり、他社・他部門への関心が低くなるということでもあります。

 全体マネジメントを行うリーダーは全体を俯瞰(ふかん)し、内部よりも意識的に外部の進捗、課題、リスクに向き合うことで、バランスよくリスクマネジメントを行うことができるでしょう。

 

2. 自部門の常識で都合よく解釈しない

 社内の研究開発と事業部、大企業とベンチャーの共創では、開発完了レベルが異なることがあります。

 例えば、商品設計側が期待する実用化開発レベルと研究開発部門が成果とする実用化開発レベルが違うことで、機能仕様、公差や動作温度範囲などが異なるといった問題が該当します。このように自部門の常識をもとに、意図しないものの、他部門の開発結果を都合よく解釈してしまうことで、商品リリースが間に合わないということもあります。

 協業開発では、実用化開発完了とは具体的にどのような状態を示すのか、目標値とともに共通認識することで、正確なリスクマネジメントへとつながります。

 

3. 正確かつリアルタイムで情報を入手する

 協業開発でも、あるステップでは開発項目の責務を決め、各部門が独立して開発を行うことがあります。また物理的に遠隔地で共同開発を行うこともあるでしょう。

 このように物理的、もしくは開発活動ごとに距離が発生する場...

技術マネジメント

 

◆ 共創におけるリスクマネジメント

 今回は「共創におけるリスクマネジメント」というタイトルで解説します。

 昨今オープンイノベーションにより、高度で複雑な商品・サービスを開発することは、当たり前になってきました。しかしながらオープンイノベーションに取り組んだものの、思ったような開発成果が得られないという企業の声も耳にします。

 これは、どちらの企業が技術を獲得するかといったパワーゲームによる理由ももちろんありますが、開発そのものが目標に達しない、連携がうまくできないといった開発現場における要因も少なくありません。

 開発現場による失敗を極力少なくするために、全体を統括するリーダーには、徹底したリスクマネジメントスキルが求められます。

 大学や研究機関といった社外組織との技術開発だけではなく、研究開発組織と社内事業部との協業においても、開発リーダーが抑えておくべきリスクマネジメントのポイントを3つ紹介します。

 

1. 自部門=内部よりも他部門=外部の進捗、課題、リスクに注意する

 オープンイノベーションの現場で目にするケースとして、全体マネジメントを行うリーダーが自社の開発に注力し過ぎ、共創先の開発にあまり注目しないことで、開発成果が得られないことがあります。

 これは「共創先の開発に口出ししてはいけない」という意識なのかもしれません、もしくは責任範囲を明確に分けているという意識の表れかもしれません。さらに言えば、どうしても自社・自部門の開発に対する思い入れが強くなり、他社・他部門への関心が低くなるということでもあります。

 全体マネジメントを行うリーダーは全体を俯瞰(ふかん)し、内部よりも意識的に外部の進捗、課題、リスクに向き合うことで、バランスよくリスクマネジメントを行うことができるでしょう。

 

2. 自部門の常識で都合よく解釈しない

 社内の研究開発と事業部、大企業とベンチャーの共創では、開発完了レベルが異なることがあります。

 例えば、商品設計側が期待する実用化開発レベルと研究開発部門が成果とする実用化開発レベルが違うことで、機能仕様、公差や動作温度範囲などが異なるといった問題が該当します。このように自部門の常識をもとに、意図しないものの、他部門の開発結果を都合よく解釈してしまうことで、商品リリースが間に合わないということもあります。

 協業開発では、実用化開発完了とは具体的にどのような状態を示すのか、目標値とともに共通認識することで、正確なリスクマネジメントへとつながります。

 

3. 正確かつリアルタイムで情報を入手する

 協業開発でも、あるステップでは開発項目の責務を決め、各部門が独立して開発を行うことがあります。また物理的に遠隔地で共同開発を行うこともあるでしょう。

 このように物理的、もしくは開発活動ごとに距離が発生する場合では、担当者にリアルタイムで確認を行い、正確に状況を理解することが重要です。みなさんも経験されているように、特に初動は状況が逐一変化し、朝一番の開発結果が180°変わることなど、当たり前のように発生します。

 全体を統括するリーダーは開発現場を回り、担当リーダーと積極的にコミュニケーションをとることで、リスクを抑える行動をとっていきましょう。

 

・・・・・・・・・・・

 社外組織との技術開発、研究開発組織と社内事業部との協業・開発では、全体を統括するリーダーは、リスクマネジメントを徹底することが重要です。

   続きを読むには・・・


この記事の著者

川崎 響子

革新的なテクノロジー事業を最速&確実に量産まで立ち上げます。 世界No.1商品を創る企業を世の中に送り出し続けることが私の使命です。

革新的なテクノロジー事業を最速&確実に量産まで立ち上げます。 世界No.1商品を創る企業を世の中に送り出し続けることが私の使命です。


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

もっと見る
バリューチェーン・サプライチェーンとその普遍化 普通の組織をイノベーティブにする処方箋 (その62)

   今回も、前回に引き続き、「思い付く」ための「知識・経験を整理するフレームワーク」です。今回は、バリューチェーン・サプライチェーンとそ...

   今回も、前回に引き続き、「思い付く」ための「知識・経験を整理するフレームワーク」です。今回は、バリューチェーン・サプライチェーンとそ...


『価値づくり』の研究開発マネジメント (その11)

     今回は、オープンイノベーションを経済学のキーワードから「競争原理」について、解説します。 ◆関連解説『技術マネジメ...

     今回は、オープンイノベーションを経済学のキーワードから「競争原理」について、解説します。 ◆関連解説『技術マネジメ...


体感で思考する 普通の組織をイノベーティブにする処方箋 (その161)

         これまで五感を一つ一つとりあげ、それぞれの感覚のイノベーション創出における意義...

         これまで五感を一つ一つとりあげ、それぞれの感覚のイノベーション創出における意義...


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

もっと見る
研究開発部門にスパークを起こすとは

◆市場を継続的に長く、広く、深く知る  企業の研究開発部門は、「金ばかり使って、良い技術が全然出てこない」と非難されることが多いようです。企業にとっての...

◆市場を継続的に長く、広く、深く知る  企業の研究開発部門は、「金ばかり使って、良い技術が全然出てこない」と非難されることが多いようです。企業にとっての...


システム設計5 プロジェクト管理の仕組み (その37)

 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。...

 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。...


進捗の見える化:第3回 プロジェクト管理の仕組み (その12)

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...