「テーマを創出できるように部下にフィードバックしているか」~技術企業の高収益化:実践的な技術戦略の立て方(その39)

投稿日

 「テーマを創出できるように部下にフィードバックしているか」~技術企業の高収益化:実践的な技術戦略の立て方(その39)
【目次】

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

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

    「ということはフィードバックをしていないということですよね?」と私が言うと、その場にいる皆さんは「あーそうそう」と言わんばかりの表情になりました。その場所はA社の会議室でした。私とともに会議をしていたのはA社のマネージャー(管理職)の皆さんです。マネージャーの皆さんは、各々複数の部下を抱えており、受け持ちの部下のパフォーマンスを上げる必要がありました。そのパフォーマンスとは研究開発テーマの創出です。部署のパフォーマンスには色々なものがありますが、A社ではここ数年、研究開発テーマの創出に力を注いできました。この会議の話題も研究開発テーマの創出で、マネージャーのお悩みとしては、部下に研究開発テーマを出させるようにしたいというものでした。

    「テーマを創出できるように部下にフィードバックしているか」~技術企業の高収益化:実践的な技術戦略の立て方(その39)

    ただ、テーマを出すというのはシンプルなようで意外と難問に見えることが多いと思います。その原因の一つに、間違った常識が多いことがあります。間違った常識とは「テーマを出すには技術の棚卸しから」「10%ルールが必要」とか「アイデアを出すためにブレストを」などがあります。一見正しいように見えるこのような言説ですが、結構鵜呑みにして取り入れる企業が多くて、結果が出ないことに後々悩むことになるのです。では、A社ではどうだったのでしょうか?実はA社では、私のようなコンサルタントから見て非常に高度なことに悩んでいました。どういうことかと言えば、一般的に研究開発テーマの創出に必要だと言われることはしていたのです。というのも、この会議に臨む前に、私は会議参加者のマネージャーの皆さんと個別に面談していました。面談の目的は調査で、会社でどのようなことを実施しているのかをお尋ねするものでした。調査によってA社にはどのような問題があるのかを、明らかにしたかったのです。

     

    1. A社の問題点はどのようなものだったのか?

    質問で問題を明らかにするという意味ではお医者さんの問診がイメージしやすいと思います。お医者さんが患者さんを診療しようとする時には問診票がありますよね。患者の症状を聞き取ったり機器で計測したりして疾患を特定する手順は明確に定まっています。もちろん、問診票や手順に合わない未知の疾患は特定できませんが、大抵の疾患はそれで特定できます。

     

    同じように、コンサルタントも問診票のようなのがありそれに沿って質問します。今回の話で言えば「テーマ創出できない」という症状の原因を特定するための質問です。お医者さんの場合、問診や診断手順などは学会で定められた標準的なものがあって当然ですが、コンサルタントにはそういう標準的なものはありません。そのため私のようなコンサルタントは自前で問診票のようなものを作っています。

     

    話をA社に戻しますと、私はA社でも問診...

     「テーマを創出できるように部下にフィードバックしているか」~技術企業の高収益化:実践的な技術戦略の立て方(その39)
    【目次】

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

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

      「ということはフィードバックをしていないということですよね?」と私が言うと、その場にいる皆さんは「あーそうそう」と言わんばかりの表情になりました。その場所はA社の会議室でした。私とともに会議をしていたのはA社のマネージャー(管理職)の皆さんです。マネージャーの皆さんは、各々複数の部下を抱えており、受け持ちの部下のパフォーマンスを上げる必要がありました。そのパフォーマンスとは研究開発テーマの創出です。部署のパフォーマンスには色々なものがありますが、A社ではここ数年、研究開発テーマの創出に力を注いできました。この会議の話題も研究開発テーマの創出で、マネージャーのお悩みとしては、部下に研究開発テーマを出させるようにしたいというものでした。

      「テーマを創出できるように部下にフィードバックしているか」~技術企業の高収益化:実践的な技術戦略の立て方(その39)

      ただ、テーマを出すというのはシンプルなようで意外と難問に見えることが多いと思います。その原因の一つに、間違った常識が多いことがあります。間違った常識とは「テーマを出すには技術の棚卸しから」「10%ルールが必要」とか「アイデアを出すためにブレストを」などがあります。一見正しいように見えるこのような言説ですが、結構鵜呑みにして取り入れる企業が多くて、結果が出ないことに後々悩むことになるのです。では、A社ではどうだったのでしょうか?実はA社では、私のようなコンサルタントから見て非常に高度なことに悩んでいました。どういうことかと言えば、一般的に研究開発テーマの創出に必要だと言われることはしていたのです。というのも、この会議に臨む前に、私は会議参加者のマネージャーの皆さんと個別に面談していました。面談の目的は調査で、会社でどのようなことを実施しているのかをお尋ねするものでした。調査によってA社にはどのような問題があるのかを、明らかにしたかったのです。

       

      1. A社の問題点はどのようなものだったのか?

      質問で問題を明らかにするという意味ではお医者さんの問診がイメージしやすいと思います。お医者さんが患者さんを診療しようとする時には問診票がありますよね。患者の症状を聞き取ったり機器で計測したりして疾患を特定する手順は明確に定まっています。もちろん、問診票や手順に合わない未知の疾患は特定できませんが、大抵の疾患はそれで特定できます。

       

      同じように、コンサルタントも問診票のようなのがありそれに沿って質問します。今回の話で言えば「テーマ創出できない」という症状の原因を特定するための質問です。お医者さんの場合、問診や診断手順などは学会で定められた標準的なものがあって当然ですが、コンサルタントにはそういう標準的なものはありません。そのため私のようなコンサルタントは自前で問診票のようなものを作っています。

       

      話をA社に戻しますと、私はA社でも問診票を使って質問していました。どのようなことを聞くかと言えば、例えば「技術の棚卸しをしたか?」「テーマ提案制度はあるのか?どのようなものか?」などでした。そのような質問をしていたのですが、この面談で私が感じた印象がどのようなものだったかと言えば、「テーマ創出のために実施すべきことはきちんと実施しているな」というものでした。どういうことかと言えば、A社のマネージャー達は私がする質問にはかなりの程度「それについては〜になっています」とスムーズに答えられ、回答に詰まることがなかったのです。

       

      通常、この手のインタビューでは質問の趣旨が分からずに質問の意図から説明する必要があります。なぜかと言えば、マネージャーでも研究開発テーマを出すことに関しては素人同然だからです。私のようなコンサルタントが質問する時、お相手は通常何も知りません。そのため、質問の背景や趣旨を説明する必要があるのです。

       

      しかし、A社のマネージャーに対しては、私がする質問の背景や意図を説明する必要は特になかったのです。それだけ、A社のマネージャーは背景や意図(「テーマを創出するためには◯◯が必要」という〇〇の部分)の理解があり、マネージャーが答えられるということは、A社ではすでに対応する試作を実施済みという事でした。

       

      2. 通常では把握できない問題点とは?

      そのため、私は「やるべきことをやっているな」という印象を持ったのです。それで「一般的にやるべきことをやっているのになぜテーマが出ないのだろうか」と疑問を持ちました。せっかく用意していた問診票が役に立たなかった、正確に言えば問診票では捉えられない問題があることに気づいた瞬間でした。

       

      先程のお医者さんの例に戻ると、病気にかかった患者さんを一般的な手順で問診してみたところ、意外なことに健康的な生活をしている様子が分かった。そんな時、お医者さんは一旦戸惑い、患者の症状をより正確に理解する必要を感じるだろうと思います。

       

      私も同じように感じました。通常は問診票に沿って調査をすれば何らかの問題点が見つかるのですが、A社ではそれが見つかりませんでした。一通り面談を終えて、私自身がA社でテーマが出せない原因についての疑問を解消しきれないままに冒頭の会議に臨むことになったのです。

       

      会議の冒頭で、私は一通り調査結果について報告し「一般的にやるべきことはやっています」と締めくくりました。その上で「一般的でない問題点があるようなので、今日はその点を話し合いましょう」と投げかけました。一同頷いて話し合いが始まったのです。

       

      先述の通りA社は「一般的にやるべきことはやっている状態」だったので、私はテーマ創出に至るまでのプロセスを確認することにしました。プロセスとは、個人のアイデア創出から会社でのテーマ提案に至るまでの一連の流れのことです。

       

      それで私は最初に「皆さんの部下の方は、個人でアイデアをどのように出していますか?」と質問をしました。会議室には4名のA社マネージャーがおられたのですが、皆さん全然違うことを言われました。「部下任せです」という方もいれば「ブレストが良いのでは?」という答えの方もいて、各人各様の答えがありました。

       

      3. A社の問題点は何だったのか?

      次に私は「部下の出したアイデアについて、マネージャの皆さんはどういう指導をするのですか?」と質問しました。そうすると、皆さん一様に困った顔になりました。答えを聞いた所、異口同音に「そういう指導はしていない」という趣旨の答えが帰ってきたのです。

       

      この答えが帰ってきた時、私は心の中で膝を打ちました。なるほど、と。疑問が解けたのです。どういうことかと言えば、A社マネージャーは、アイデアを部下に任せ、部下の出したアイデアについてもフィードバックをしていなかったのです。フィードバックをされないと部下はどうなるでしょうか?放置された部下は困ってしまうことが私には分かりました。コンサルタント経験から、放置されても一人でやり遂げられる人はそれほど多くないことを知っていたからです。

       

      それで私は「アイデアを出した部下に対してフィードバックしていないですよね?」と話をしたのですが、参加者のマネージャーは皆さん、虚を突かれたように「確かに」と頷いたのです。それを言った時、一同に「そんなフィードバックが必要だったのか」という気付きが共有できたように感じられました。

       

      なぜフィードバックが必要かをもう少し説明すると、誰しもアイデアを出した人は自分の出したアイデアに自信が持てないのです。アイデアはそもそも概念的で曖昧なもの、具体化や肉付けをしないと他人に受け入れてもらえませんが、アイデアを出した人は自分だけではそれに気づかないことが多いです。

       

      そのため、アイデアをひらめいた人はいろんな人に話してフィードバックをもらい、その過程で抽象的だったものを具体的にしたり、骨だけだったものに肉をつけたりして誰にでも理解できるものにします。本来はそのような過程が必要なのにA社マネージャーは何ら関わっていなかった、という訳です。

       

      それで部下たちはどうしていたのかと言えば、アイデアを出しっぱなしにしてそれ以上深掘りをしていなかったり、深掘りをしていてもフィードバックを得ずにしているので個人の思い込みの強いテーマになっていたりしていて、結局テーマにはならない、そんな状態が続いていたというわけだったのです。

       

      会議で私は上記のような話をマネージャー達に伝えました。そうすると皆さん納得された様子でした。「なるほどフィードバックが必要だったのか」という気づきを得てその会議は締めくくられました。A社ではその後「では、どうやってフィードバックするのか」という話題での検討が別途続いたのですが、今回の記事では紙幅の都合上それについては書けません。

       

      では、この記事を締めくくります。読者の皆さんの会社では、上司が部下にフィードバックをしているでしょうか?アイデアを出した部下をフォローするだけでなく、どのようにアイデアを出すかについてもフォローしてあげていますか?「テーマ創出に向けて一通りのことをしているはずなのに結果がでないな」とお悩みの方はぜひチェックをしてみてください。

       

      「制度的なことは他社と同じように既に実施している」という会社では特に要注意です。制度的なものは形式知になりやすいですから、他社のマネがしやすく導入も容易です。しかし、上司と部下の日常的なやり取りにこそあります。そこにテーマ創出に至るプロセスが隠されていることにお気づきですか?

       

      次回に続きます。

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

       

         続きを読むには・・・


      この記事の著者

      中村 大介

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

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


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

      もっと見る
      開発テーマ選定における3つの視点 新規事業・新商品を生み出す技術戦略(その6)

              新規事業・新商品を開発するにあたって「何を」開発するべきかを決定することは難しく、結果を左右...

              新規事業・新商品を開発するにあたって「何を」開発するべきかを決定することは難しく、結果を左右...


      『価値づくり』の研究開発マネジメント (その4)

          前回は、「自社の市場と技術を目いっぱい広げ活動する」の中の「市場」について議論しました。今回は「市場」に関する活動を、オープン・...

          前回は、「自社の市場と技術を目いっぱい広げ活動する」の中の「市場」について議論しました。今回は「市場」に関する活動を、オープン・...


      調査結果は記録しカテゴライズする 新規事業・新商品を生み出す技術戦略(その17)

             新規事業・新商品開発を行うにあたって実施する、ベンチマークや市場調査など調査をした、そのままになっていま...

             新規事業・新商品開発を行うにあたって実施する、ベンチマークや市場調査など調査をした、そのままになっていま...


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

      もっと見る
      手戻りのフィードバック・ループを小さくするとは プロジェクト管理の仕組み (その9)

       ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...

       ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...


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

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

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


      スーパーマンではなくプロフェッショナルな技術者に(その3)

      【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...

      【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...