「そのSTOP判断、本当に必要ですか?」~技術企業の高収益化:実践的な技術戦略の立て方(その36)

New

  「そのSTOP判断、本当に必要ですか?」~技術企業の高収益化:実践的な技術戦略の立て方(その36)
【目次】

    ▼さらに深く学ぶなら!
    「技術マネジメント」に関するセミナーはこちら!

    ▼さらに幅広く学ぶなら!
    「分野別のカリキュラム」に関するオンデマンドセミナーはこちら!

    今日のテーマは、先日、あるクライアントで助言をした内容です。実は頻繁に話題になるので、読者の皆さんの会社でも起こっているのではないかと思いました。お役に立つ情報だと思いますので、今回の記事でそのシェアをします。最初にクライアントの会社で起こったことを紹介します。研究開発部長のAさんと私でテーマの編成について協議をしていました。Aさんの会社は大きな会社で技術者は100人程度います。そのため研究開発テーマも多数あるのですが、その取捨選択が話題でした。「取捨選択」と言うと、たくさんやりすぎてしまっているので捨てなければならない、そんな状況を思い浮かべるかも知れませんが、実態はその逆でした。

     

    というのも、A部長が統括する研究開発部門で実施しているのは、事業部(営業)依頼のテーマだったのです。事業部の依頼ですから、実施する必要性は一般的に見て高いです。そのため、捨てられるテーマが多数あるわけではなくて「やらないと怒られてしまう」テーマが多数あるという状況でした。やらないと事業部に怒られるのでやらざるを得ないのですが、では「それで儲かるのか?」と言えば、それが分からない状況でした。A部長の手元には、テーマ一覧表やテーマの詳細(技術開発の目標、計画や採算性)の情報はあったのですが、テーマが本当に儲かるのか?検証された情報はなかったのです。いえ、正確に言えばテーマの採択段階できちんと企画書は作られますので、儲かるかの検証はなされている「はず」でした。儲かるのかの判断ができる企画書のフォーマットはありました。そしてフォーマット内に文章が埋められており、承認のハンコは押されていたのです。

     

    1. 儲かるカタチは整っていても

    カタチは整っていました。しっかりと検討された文書が残されていましたので。しかし、どうもA部長をはじめとして、関係者全員がしっくり来ていないのです。というのは、過去同じようなことを数十年繰り返してきており、売上成長はしたものの、すっかり利益の出ない体質になってしまっているからでした。

     

    「そのSTOP判断、本当に必要ですか?」~技術企業の高収益化:実践的な技術戦略の立て方(その36)

     

    上記のような企画書の仕組みがあるので、儲かるはずでした。しかし、現実的には、儲かりそうに「ない」テーマが多数ある状況だったのです。A部長を悩ませてい...

      「そのSTOP判断、本当に必要ですか?」~技術企業の高収益化:実践的な技術戦略の立て方(その36)
    【目次】

      ▼さらに深く学ぶなら!
      「技術マネジメント」に関するセミナーはこちら!

      ▼さらに幅広く学ぶなら!
      「分野別のカリキュラム」に関するオンデマンドセミナーはこちら!

      今日のテーマは、先日、あるクライアントで助言をした内容です。実は頻繁に話題になるので、読者の皆さんの会社でも起こっているのではないかと思いました。お役に立つ情報だと思いますので、今回の記事でそのシェアをします。最初にクライアントの会社で起こったことを紹介します。研究開発部長のAさんと私でテーマの編成について協議をしていました。Aさんの会社は大きな会社で技術者は100人程度います。そのため研究開発テーマも多数あるのですが、その取捨選択が話題でした。「取捨選択」と言うと、たくさんやりすぎてしまっているので捨てなければならない、そんな状況を思い浮かべるかも知れませんが、実態はその逆でした。

       

      というのも、A部長が統括する研究開発部門で実施しているのは、事業部(営業)依頼のテーマだったのです。事業部の依頼ですから、実施する必要性は一般的に見て高いです。そのため、捨てられるテーマが多数あるわけではなくて「やらないと怒られてしまう」テーマが多数あるという状況でした。やらないと事業部に怒られるのでやらざるを得ないのですが、では「それで儲かるのか?」と言えば、それが分からない状況でした。A部長の手元には、テーマ一覧表やテーマの詳細(技術開発の目標、計画や採算性)の情報はあったのですが、テーマが本当に儲かるのか?検証された情報はなかったのです。いえ、正確に言えばテーマの採択段階できちんと企画書は作られますので、儲かるかの検証はなされている「はず」でした。儲かるのかの判断ができる企画書のフォーマットはありました。そしてフォーマット内に文章が埋められており、承認のハンコは押されていたのです。

       

      1. 儲かるカタチは整っていても

      カタチは整っていました。しっかりと検討された文書が残されていましたので。しかし、どうもA部長をはじめとして、関係者全員がしっくり来ていないのです。というのは、過去同じようなことを数十年繰り返してきており、売上成長はしたものの、すっかり利益の出ない体質になってしまっているからでした。

       

      「そのSTOP判断、本当に必要ですか?」~技術企業の高収益化:実践的な技術戦略の立て方(その36)

       

      上記のような企画書の仕組みがあるので、儲かるはずでした。しかし、現実的には、儲かりそうに「ない」テーマが多数ある状況だったのです。A部長を悩ませていたのはまさにそこ。そう、仕組みにあったのです。しかし、A部長と私の会議で議題に上がったのは仕組みの話というよりも「GO/STOP」の判断でした。

       

      「儲かるテーマはGO、儲からないテーマはSTOPしたいのですが、やめられないのですよね」とA部長は暗い表情でつぶやきました。A部長の思いとしては、テーマを続けていても儲からないから止めるのが良いのではないか、そして、止めるのは自分だと思っていたようです。

       

      確かに、テーマの進捗管理と言えばステージゲート法が思い浮かびます。ステージゲート法は所定の基準をクリアすればGO、クリアできなければSTOPを判断するもの。そのため、GO/STOPという型通りの判断が必要だと思うのも一般的には理解できます。

       

      しかし、A部長の言葉を聞いて、私が考えたのは型通りのGO/STOPの話ではありませんでした。これには経験の蓄積があったからです。

       

      話はA部長から逸れますが、コンサルタントである私は、様々な背景を持つ会社からのご相談を受けます。そしてその中には、GO/STOPでの判断を徹底した会社からのご相談が多かったのです。

       

      そうしたご相談の中で典型的かつ深刻なのは「ゲートを厳しくしてSTOPさせる案件を増加させたら、テーマがなくなってしまった」というものでした。テーマがなくなるだけならばマシなのですが、私が深刻だと感じたのは「社員のモチベーションが大幅ダウンした」というコメントが異口同音に寄せられることでした。

       

      なぜ社員のモチベーションが下がるのか?と思われるかも知れません。説明のために、STOPを一人称で表現すると「自分の担当テーマ(仕事)を誰かの判断で奪われること」です。自分から見れば、判断した誰かを悪く思って不自然ではないですし、仕事を奪われたことを恨めしく思うのはよくある話ではないでしょうか。

       

      2. GO/STOPの判断を慎重に

      こうした事があるため、私はSTOPの判断は慎重にすべきだと常々考えていました。そのため、A部長のコメントに対して「GO/STOPの判断をするという型通りの判断をしなくても良いのではないですか?」と答えました。

       

      こう答えると、A部長は口を開けたまま固まりました。私の発言が意表をついたものだったようです(私にはその意図はないのですが)。当然といえば当然です。今まで決められてきた仕組みがステージゲートであり、GO/STOPの判断をするというものですから。その仕組みから外れるという発想はなかったのだろうと思います。

       

      「客観的に見れば、現在の仕組みが機能して全てのテーマをGOとしても儲からなさそうなのですから、その仕組みを外れた判断をすることに何ら問題はないと思います」と私が説明すると、A部長は腑に落ちたような表情をしたのです。

       

      A部長が頷く様子を見ながら私は続けました「そもそもSTOPするというのは『今のままじゃダメ』という評価に過ぎないんですよ。それをSTOPさせることには本来意味がありません。STOPさせるよりも『見直し』とか『再出発』できるようにした方が『今のままじゃダメ』という評価を受けた修正になりますし、評価を受け取る技術者に受け入れやすいじゃないですか?」

       

      3. 技術者にしてほしいことは

      ここまで言うとA部長もだいぶ表情が明るくなってきました。というのも、テーマを実行する技術者に対してSTOPをかけるのは自分(A部長)だということから、気が滅入る仕事をしなければならないと思っておりそれがあって暗い表情になっていたのです。

       

      「『見直し』とか『再出発』って良いですね。」とA部長が言うので、私は「そうです。評価する側が恨まれないことにも繋がりますし、なにより問題の先送りがなくなり、会社全体で建設的な議論ができます」と応じました。

       

      その後、会社では社内にあるテーマを客観的に評価し直しました。そして担当の技術者に伝えたのですが、その際に、STOPではなく「見直し」をするようにA部長から伝えてもらいました。そうすると、担当技術者は「痛いところを突かれた」と苦笑いして、モチベーションを落とすこともなくテーマの見直しが始まったのです。

       

      さて、皆さんの会社でも「STOPさせられてモチベーションが大幅にダウンした」などという不平不満はありませんか?その不満を持つのはすごく正当なことだと思います。

       

      ただでさえ、やめさせられる側はすごくイヤな気分になりますし、やめさせる側も気が滅入ります。それだけでなく、新規事業の評価をするのは主観的な評価になりやすいですし、好き嫌いの問題も入り込む余地があります。そのため不平不満に繋がりやすい、ですから。

       

      今日のコラムでは、こうした不平不満が「GO/STOP判断をしなければならない」という呪縛に基づく誤った意思決定に基づいて起こされてきたことを説明しましたがご理解いただけたことと思います。

       

      この解説記事を書くまでに、私は複数のクライアントから同種の相談を受けてきました。恐らく、皆さんの会社でも同種の問題があるはずです。ピンと来る事があれば、ぜひ解説記事の内容をお役立ていただければと思います。そして常に視点をずらして創造的な解決策を探りましょう。今回のGO/STOP判断のように、常識だと思われていることが実は必要ないなんていうことは、世の中にたくさんありますからね。

       

      次回に続きます。

      【出典】株式会社 如水 HPより、筆者のご承諾により編集して掲載

       

         続きを読むには・・・


      この記事の著者

      中村 大介

      若手研究者の「教育」、研究開発テーマ創出の「実践」、「開発マネジメント法の導入」の3本立てを同時に実践する社内研修で、ものづくり企業を支援しています。

      若手研究者の「教育」、研究開発テーマ創出の「実践」、「開発マネジメント法の導入」の3本立てを同時に実践する社内研修で、ものづくり企業を支援しています。


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

      もっと見る
      MVPの活用 新規事業・新商品を生み出す技術戦略(その82)

        ◆ 研究開発にMVPを活用する  今回は「研究開発にMVPを活用する」をテーマに解説します。  MVPとは、Minimum Via...

        ◆ 研究開発にMVPを活用する  今回は「研究開発にMVPを活用する」をテーマに解説します。  MVPとは、Minimum Via...


      どんな時もすぐ動く 新規事業・新商品を生み出す技術戦略(その52)

              新規事業・新商品を開発するにあたって、その組織や個人には「すぐ動く」ことが求められます。 ...

              新規事業・新商品を開発するにあたって、その組織や個人には「すぐ動く」ことが求められます。 ...


      課題や阻害・成功の要因 オープンイノベーションとは(その5)

               【オープンイノベーションとは 連載目次】 1. オープンイノベーショ...

               【オープンイノベーションとは 連載目次】 1. オープンイノベーショ...


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

      もっと見る
      設計部門と組織政治の影響(その3)

       前回のその2に続いて解説します。   ◆政治的要因の検討で決まるスケジュールの確度・精度    日程を決めるときには、仕組み...

       前回のその2に続いて解説します。   ◆政治的要因の検討で決まるスケジュールの確度・精度    日程を決めるときには、仕組み...


      製品開発部へのカンバン導入記(その3)

              前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...

              前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...


      設計部門の仕組み構築(その1)

      【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

      【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...