“コーチング”のよくある失敗パターンを知っておこう

 例えば、こんな例があったとしましょう。あなたの部下が、あるプロジェクト計画書の構成について”A案”と”B案”で悩みに悩み、上司であるあなたのところに相談に来たのです。ここでよく起きる“3つの失敗パターン”を見てみましょう。

失敗パターン1: そもそも“効かないコーチング”をしている

 たとえば、「もし君がお客様だったら、どちらの構成案の方が知りたいことが網羅されているかな?」や、「なぜこの2案にしたのかな? あえて他の構成も考えるとしたら、何か他の案は考えられるかな?」など、いかにも“コーチング”っぽい質問をしたとしましょう。でも、そもそもの大前提として、コーチングが機能するためには、“部下が答えを持っていること”が必要です。今回のケースで言えば、お客様が誰で、どんな要望を持っているのかを部下が把握していなければなりません。それを正しく説明・共有されていない部下だとしたら、彼にいくら質問を投げても“気づき”にはならず、部下は「そんなこと聞かれても困るよ!」と理不尽な気持ちを抱くだけなのです。

失敗パターン2: 勝手な“フィードバック”をしている

 ”A案”と”B案”について、そこに書いてあること(事実)ではなく、自分の勝手な解釈でフィードバックをしてしまうと、部下は非常に嫌な気持ちを持つものです。なぜなら、解釈の仕方は人によって異なるからです。例えば、グラフの見せ方について、「全体的によく書けてると思うけど……。ああ、このページの折れ線グラフはちょっと読み取りにくいね。何も考えずにグラフ化するからこうなっちゃうんだよ」というフィードバックは、典型的な“解釈”によるものです。もしかしたら部下は、考えに考え抜いて“折れ線グラフ”にしたのかもしれませんよ。こういう勝手な解釈でフィードバックをしていると、部下は上司に強い不信感を抱くようになります。これでは、百害あって一利なしですね。

失敗パターン3:すぐに“解決策”を示そうとしてしまう

 “自分は上司だから、答えを持っていなければいけない”と思い、すぐに「今回の場合はA案 にしよう!」と答えを示してしまうのもまずいパターンです。もちろん、本当に部下が決められずにいるのであれば、どこかの段階で“答え”を示してあげることも必要です。でも、“答え”を示す前に、もっとやっておくべきことがあるのです。