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


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

もっと見る
1400件の顧客特許を読んだらどうなるか~技術企業の高収益化:実践的な技術戦略の立て方(その17)

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...


普通の組織をイノベーティブにする処方箋 (その25)

 前回はKETICモデルの中の知識(Knowledge)の内、技術知識について議論をしましたが、今回も引き続きその議論をしたいと思います。 ◆関連解説『...

 前回はKETICモデルの中の知識(Knowledge)の内、技術知識について議論をしましたが、今回も引き続きその議論をしたいと思います。 ◆関連解説『...


普通の組織をイノベーティブにする処方箋 (その167) 体感での思考とアナロジーとの関係

【目次】 【この連載の前回:普通の組織をイノベーティブにする処方箋 (その166)へのリンク】 ◆連載記事紹介:ものづくりドットコ...

【目次】 【この連載の前回:普通の組織をイノベーティブにする処方箋 (その166)へのリンク】 ◆連載記事紹介:ものづくりドットコ...


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

もっと見る
技術者の逆襲:イノベーションの必要性とは

  ◆ 現場からのイノベーション  最近、様々な場所でイノベーションという言葉を聞きます。普通の技術者にとって、イノベーションは技術革新や技術によって...

  ◆ 現場からのイノベーション  最近、様々な場所でイノベーションという言葉を聞きます。普通の技術者にとって、イノベーションは技術革新や技術によって...


品質の仕組みとは3 プロジェクト管理の仕組み (その29)

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...


設計部門の課題と原因分析(その1)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...