開発テーマを中断できないとは 新規事業・新商品を生み出す技術戦略(その43)

更新日

投稿日

 
  技術マネジメント
 
 今回は「開発テーマを中断できない問題への対策」というタイトルで記事を進めます。
 
 このテーマを扱うことに決めた背景には「一度、走り出したテーマを止める判断ができない」という悩みを何度も耳にする機会に遭遇したためです。実はこの悩み、経営者・事業トップ・開発担当者みなさん共通の悩みとして話題に上がります。ふと、私自身の経験からも同様の事例は多くありました。
 
 特に、大きな開発リソースが割り当てられている期待値の大きな新規事業・新商品開発テーマでは目にする光景です。
 
 初期開発ステップ(研究開発ステップ)に多い事例として、コア技術の完成度が想定より低く、目標仕様を達成できなそうな場合に「できない」ことを発信できないことがあります。
 
 後期開発ステップ(実用化開発ステップ)にありがちな事例として、要求されるモジュール仕様を全て盛り込むことで複雑かつ高コストな製品仕様となり、そのまま後戻りできずズルズルと進んでしまうことがあります。
 
 どちらの事例においても、Q:品質、C:コスト、D:納期の目標を立てていたにも関わらず、開発テーマを中断することはありませんでした。
 
 いえ、正確には「もう手遅れ」という状況で初めて「STOP」の号令がかかったのです。
 
 このような「開発テーマを中断できない問題」へどのような対策が必要なのでしょうか?
 
 これは、「開発テーマを中断できない」ことが問題なのではなく、QCD目標を達成できなかった場合のシナリオ(≒行動計画)が明確ではないことが問題であることをご説明します。
 
 ご存知の通り新規事業・新商品開発テーマの開発は、既存事業とは異なりQCD目標を達成できないことが大半をしめます。このような性質を抱えている以上、評価基準に合わせて単純にGO or No-GOを判定することこそが実は大きなリスクに繋がる可能性が高いのです。
 
 多くの開発テーマは、達成できていない評価指標を重要度・緊急度などに応じて数値化し、開発ステップの合否を判定します。数値化による開発テーマ状況の可視化は重要なツールです。
しかし、数値による判定だけでは不十分なのです。それでは、どのように対策するべきなのでしょうか。
 
 数値による判定で目標達成できなかった場合、次に行う行動を早い段階でシナリオ化(≒行動計画)し、経営者・事業トップ・開発担当者間でコミットメントすることが必要です。
 
 「次に行う行動」とは、開発目標・開発リソース配分見直しによる再スタートを行うなのか、コア技術の棚入れを行って中断するなのか…といった具体的な行動です。
 
 「早い段階」とは、できれば開発ステップスタート時のQCD目標をコミットする時です。
 
 余談になりますが、「目標を達成できなかった」ことを想定したシナリオ作成は誰もが考えたくない、まさに臭い物に蓋をしたいという感情が優先されます。私自身、これが原因で失敗した開発テーマは多数あります。
 
 この事例はまた別の機会にご紹介しますが、こういった場合には「最悪の状況を想定して対策を...
 
  技術マネジメント
 
 今回は「開発テーマを中断できない問題への対策」というタイトルで記事を進めます。
 
 このテーマを扱うことに決めた背景には「一度、走り出したテーマを止める判断ができない」という悩みを何度も耳にする機会に遭遇したためです。実はこの悩み、経営者・事業トップ・開発担当者みなさん共通の悩みとして話題に上がります。ふと、私自身の経験からも同様の事例は多くありました。
 
 特に、大きな開発リソースが割り当てられている期待値の大きな新規事業・新商品開発テーマでは目にする光景です。
 
 初期開発ステップ(研究開発ステップ)に多い事例として、コア技術の完成度が想定より低く、目標仕様を達成できなそうな場合に「できない」ことを発信できないことがあります。
 
 後期開発ステップ(実用化開発ステップ)にありがちな事例として、要求されるモジュール仕様を全て盛り込むことで複雑かつ高コストな製品仕様となり、そのまま後戻りできずズルズルと進んでしまうことがあります。
 
 どちらの事例においても、Q:品質、C:コスト、D:納期の目標を立てていたにも関わらず、開発テーマを中断することはありませんでした。
 
 いえ、正確には「もう手遅れ」という状況で初めて「STOP」の号令がかかったのです。
 
 このような「開発テーマを中断できない問題」へどのような対策が必要なのでしょうか?
 
 これは、「開発テーマを中断できない」ことが問題なのではなく、QCD目標を達成できなかった場合のシナリオ(≒行動計画)が明確ではないことが問題であることをご説明します。
 
 ご存知の通り新規事業・新商品開発テーマの開発は、既存事業とは異なりQCD目標を達成できないことが大半をしめます。このような性質を抱えている以上、評価基準に合わせて単純にGO or No-GOを判定することこそが実は大きなリスクに繋がる可能性が高いのです。
 
 多くの開発テーマは、達成できていない評価指標を重要度・緊急度などに応じて数値化し、開発ステップの合否を判定します。数値化による開発テーマ状況の可視化は重要なツールです。
しかし、数値による判定だけでは不十分なのです。それでは、どのように対策するべきなのでしょうか。
 
 数値による判定で目標達成できなかった場合、次に行う行動を早い段階でシナリオ化(≒行動計画)し、経営者・事業トップ・開発担当者間でコミットメントすることが必要です。
 
 「次に行う行動」とは、開発目標・開発リソース配分見直しによる再スタートを行うなのか、コア技術の棚入れを行って中断するなのか…といった具体的な行動です。
 
 「早い段階」とは、できれば開発ステップスタート時のQCD目標をコミットする時です。
 
 余談になりますが、「目標を達成できなかった」ことを想定したシナリオ作成は誰もが考えたくない、まさに臭い物に蓋をしたいという感情が優先されます。私自身、これが原因で失敗した開発テーマは多数あります。
 
 この事例はまた別の機会にご紹介しますが、こういった場合には「最悪の状況を想定して対策を考えられる私たちはすばらしい!優秀だ!」と奮起して挑んでください。そして経営者・事業トップは、このような部下(開発担当者)を評価してください。
 
 「開発テーマを中断できない問題への対策」は、次ステップへの移行がGOであっても目標の見直し、No-GOであっても技術の棚入れなど、早い段階で具体的なシナリオ(≒行動計画)を決めることが秘訣です。具体的な進め方については、この連載で随時ご紹介していきます。
 

   続きを読むには・・・


この記事の著者

川崎 響子

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

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


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

もっと見る
思考の頻度 普通の組織をイノベーティブにする処方箋 (その150)

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための1つ目の要素「行動を増やすことで思考を促進す...

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための1つ目の要素「行動を増やすことで思考を促進す...


イノベーションの創造 普通の組織をイノベーティブにする処方箋 (その137)

  【この連載の前回:普通の組織をイノベーティブにする処方箋 (その136)へのリンク】 前回は会社の経営陣やマネジャークラスがイノベー...

  【この連載の前回:普通の組織をイノベーティブにする処方箋 (その136)へのリンク】 前回は会社の経営陣やマネジャークラスがイノベー...


「期」について 普通の組織をイノベーティブにする処方箋 (その64)

 今回も、前回に引き続き、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて解説します。 ◆関...

 今回も、前回に引き続き、「思い付く」ための「知識・経験を整理するフレームワーク」の中の、知識・経験を時系列で整理する「期」ついて解説します。 ◆関...


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

もっと見る
品質の仕組みとは1 プロジェクト管理の仕組み (その27)

 製品開発を行っている組織において、設計・製造の仕組みを構築したり見直したりするというとき、品質向上に貢献することが何らかの形でゴールのひとつとなっている...

 製品開発を行っている組織において、設計・製造の仕組みを構築したり見直したりするというとき、品質向上に貢献することが何らかの形でゴールのひとつとなっている...


設計部門とリスク管理(その1)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...


設計部門の仕組み改革(その3)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...