原因追求型のフィードバックをされると、気がめいる：仕事が「つまんない」ままでいいの？（57）（2/3 ページ）

部下や同僚にネガティブなフィードバックをしなければならないことがありますが、伝え方に気を付けないと、相手のやる気を削いだり人間関係を崩したりします。本来、どのようなコミュニケーションをとるべきなのかをエンジニア視点で考えてみました。

LINE

Hatena

ビジネスで行われているのはフィードバックなのか？

　では、ビジネスシーンで行われているフィードバックは、本来のフィードバックなのでしょうか。

　先日、知人のMさんから話を聞いたときのことです。Mさんは「上司の度重なる指摘に心が折れそう」と訴えます。何でも上司は、Mさんに「あなたの○○がダメだ」「なぜ、あなたはいつもそうなの？」といった「問題の指摘」ばかりしてくるそうです。

　Mさんの上司の発言は、一見フィードバックのように見えます。けれども、Mさんは上司の言動によって心が折れそうになっています。つまり、結果が良い状態ではなくなっています。

　本来、フィードバックは、「結果を理想に近づける」「より良くしていく」ためのものです。それにもかかわらず、ビジネスシーンでは批判や人格否定、プレッシャーをかけ、相手のやる気やテンションを下げている状況も少なくありません。これは、本来のフィードバックとはいえません。

　ネガティブなフィードバックをする際にやってしまいがちなのは、相手の、過去の言動に目を向けて、「なぜ、その問題行動をしたのか？」という原因追及です。そして、原因を取り除くことによって、問題の状況を改善しようとします。

　一方、本来のフィードバックとは、エアコンの温度を制御するように、まず、目標値（理想）があります。それに対して現状と比較します。目標値と現状の間に差があれば、目標値に近づくような改善策を立てます。

　つまり、本来のフィードバックには、「現状」と「理想」、ギャップを埋めるための「改善策」があります。

　このように、本来のフィードバックの意味から考えると、「結果を理想に近づける」ためには、「過去」に目を向けた「原因追求」型の問題解決よりも、「未来」に目を向けた「解決志向」であるべきなのが分かります。

新入社員への適切な接し方
エンジニアがエンジニアとして生き残るためには、ビジネス的な観点が必要だ。ビジネスのプロである経済評論家の山崎元さんがエンジニアに必要な考え方をアドバイスする本連載。今回は新入社員の迎え方を指南する
ググる世代との付き合い方――違いを認めて指導する
ITエンジニアの周りにはストレスがいっぱい。そんな環境から心身を守るためのヒントを、IT業界出身のカウンセラーが分かりやすく伝えます
「管理」を勘違いするPMが、メンバーに翻弄される理由
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！そんな新任PMの悩みを解決するTipsを紹介します
あなたの「先輩力」が測れるマネジメント診断ツール
ITエンジニアのモチベーションを考える連載。第1回は、ITエンジニアが抱えるモチベーションの問題を事例を基に紹介。第2～3回は、モチベーション診断ツールを掲載する。あなたのモチベータ（やる気のもと）を明らかにする！