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

◆ 共創におけるリスクマネジメント
今回は「共創におけるリスクマネジメント」というタイトルで解説します。
昨今オープンイノベーションにより、高度で複雑な商品・サービスを開発することは、当たり前になってきました。しかしながらオープンイノベーションに取り組んだものの、思ったような開発成果が得られないという企業の声も耳にします。
これは、どちらの企業が技術を獲得するかといったパワーゲームによる理由ももちろんありますが、開発そのものが目標に達しない、連携がうまくできないといった開発現場における要因も少なくありません。
開発現場による失敗を極力少なくするために、全体を統括するリーダーには、徹底したリスクマネジメントスキルが求められます。
大学や研究機関といった社外組織との技術開発だけではなく、研究開発組織と社内事業部との協業においても、開発リーダーが抑えておくべきリスクマネジメントのポイントを3つ紹介します。
1. 自部門=内部よりも他部門=外部の進捗、課題、リスクに注意する
オープンイノベーションの現場で目にするケースとして、全体マネジメントを行うリーダーが自社の開発に注力し過ぎ、共創先の開発にあまり注目しないことで、開発成果が得られないことがあります。
これは「共創先の開発に口出ししてはいけない」という意識なのかもしれません、もしくは責任範囲を明確に分けているという意識の表れかもしれません。さらに言えば、どうしても自社・自部門の開発に対する思い入れが強くなり、他社・他部門への関心が低くなるということでもあります。
全体マネジメントを行うリーダーは全体を俯瞰(ふかん)し、内部よりも意識的に外部の進捗、課題、リスクに向き合うことで、バランスよくリスクマネジメントを行うことができるでしょう。
2. 自部門の常識で都合よく解釈しない
社内の研究開発と事業部、大企業とベンチャーの共創では、開発完了レベルが異なることがあります。
例えば、商品設計側が期待する実用化開発レベルと研究開発部門が成果とする実用化開発レベルが違うことで、機能仕様、公差や動作温度範囲などが異なるといった問題が該当します。このように自部門の常識をもとに、意図しないものの、他部門の開発結果を都合よく解釈してしまうことで、商品リリースが間に合わないということもあります。
協業開発では、実用化開発完了とは具体的にどのような状態を示すのか、目標値とともに共通認識することで、正確なリスクマネジメントへとつながります。
3. 正確かつリアルタイムで情報を入手する
協業開発でも、あるステップでは開発項目の責務を決め、各部門が独立して開発を行うことがあります。また物理的に遠隔地で共同開発を行うこともあるでしょう。
このように物理的、もしくは開発活動ごとに距離が発生する場合では、担当者にリアルタイムで確認を行い、正確に状況を理解することが重要です。みなさんも経験されているように、特に初動は状況が逐一変化し、朝一番の開発結果が180°変わることなど、当たり前のように発生します。
全体を統括するリーダーは開発現場を回り、担当リーダーと積極的にコミュニケーションをとることで、リスクを抑える行動をとっていきましょう。
・・・・・・・・・・・
社外組織との技術開発、研究開発組織と社内事業部との協業・開発では、全体を統括するリーダーは、リスクマネジメントを徹底することが重要です。
続きを読むには・・・
この連載の他の記事
現在記事
「技術マネジメント総合」の他のキーワード解説記事
もっと見るイノベーションの創出 普通の組織をイノベーティブにする処方箋 (その132)
【この連載の前回:普通の組織をイノベーティブにする処方箋 (その131)へのリンク】 現在「切り取った知識の重要部分を発想するフレー...
【この連載の前回:普通の組織をイノベーティブにする処方箋 (その131)へのリンク】 現在「切り取った知識の重要部分を発想するフレー...
フロントローディング、開発重視、源流管理の考え方とは
製造プロセスにおける設計部門を中心とした業務を表す開発の初期段階であるエンジニアリングチェーンエンジニアリングチェーン( engine...
製造プロセスにおける設計部門を中心とした業務を表す開発の初期段階であるエンジニアリングチェーンエンジニアリングチェーン( engine...
優先順位の付け方と取り組み方 新規事業・新商品を生み出す技術戦略(その42)
日々の業務に追い回されていないでしょうか。せっかく計画を立てて進めているにも関わらず、急な...
日々の業務に追い回されていないでしょうか。せっかく計画を立てて進めているにも関わらず、急な...
「技術マネジメント総合」の活用事例
もっと見る仕組みの見直しに成功する組織2 プロジェクト管理の仕組み (その26)
前回の仕組みの見直しに成功する組織1に続いて解説します。 仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...
前回の仕組みの見直しに成功する組織1に続いて解説します。 仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...
成功体験が重荷となる製品開発プロセス(その2)
◆ 解決策 成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...
◆ 解決策 成功体験が重荷となる製品開発プロセス(その1:現状の課題)では、スマートフォンで起きていることを例にして、従来の組み込みソ...
開発者が意識したいスケジューリングのコツ(朝~午前編)
先日、ある開発リーダーからこんな相談がありました。「一日のスケジューリングをしても、当日になると急な会議やら雑務が入ってしまって仕事が進まないんだよ...
先日、ある開発リーダーからこんな相談がありました。「一日のスケジューリングをしても、当日になると急な会議やら雑務が入ってしまって仕事が進まないんだよ...





