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

更新日

投稿日

技術マネジメント

 

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

技術マネジメント

 

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

・・・・・・・・・・・

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

   続きを読むには・・・


この記事の著者

川崎 響子

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

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


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

もっと見る
普通の組織をイノベーティブにする処方箋 (その184) 妄想とイノベーション創出

  ・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら!...

  ・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら!...


時間軸(Time) 普通の組織をイノベーティブにする処方箋 (その53)

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...


ロードマップの作り方

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...


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

もっと見る
人的資源マネジメント:インダストリー4.0 を追いかけるその前に(その2)

 前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...

 前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...


ハイヒール型プルタブオープナー  異分野市場での事業化事例 (その1)

「部品技術の見える化」で、B2Bの部品からB2Cの完成品事業に成功したクライアントの事例を紹介します。A社は、金属加工の部品メーカーであり、田植え機、AT...

「部品技術の見える化」で、B2Bの部品からB2Cの完成品事業に成功したクライアントの事例を紹介します。A社は、金属加工の部品メーカーであり、田植え機、AT...


仕組みの見直しに成功する組織2 プロジェクト管理の仕組み (その26)

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...