開発テーマを中断できないとは 新規事業・新商品を生み出す技術戦略(その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商品を創る企業を世の中に送り出し続けることが私の使命です。


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

もっと見る
行動の重要性 普通の組織をイノベーティブにする処方箋 (その146)

  前回まで「失敗のコストのマネジメント」を考えてきました。失敗のコストを低減して、多くの失敗をし、そこから多くを学ぼうという内容でした。...

  前回まで「失敗のコストのマネジメント」を考えてきました。失敗のコストを低減して、多くの失敗をし、そこから多くを学ぼうという内容でした。...


開発効率向上、活動計画 2 開発効率を上げる(その5)

【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1  ...

【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1  ...


普通の組織をイノベーティブにする処方箋 (その186) 他人の妄想・思考プロセスをたどる

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

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


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

もっと見る
システム設計8 プロジェクト管理の仕組み (その40)

 前回のシステム設計7に続いて解説します。    システム要件の一つひとつについて、サブシステム構成における振る舞いを記述し、各々のサブシス...

 前回のシステム設計7に続いて解説します。    システム要件の一つひとつについて、サブシステム構成における振る舞いを記述し、各々のサブシス...


CMMIの要件管理 プロジェクト管理の仕組み (その2)

 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。   ...

 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。   ...


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

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

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