部下が求めているのは「結論へのアドバイス」ではなく「一緒に順番に考えてくれる」こと　「フィードバック」あるある失敗例5選 [2/2]

若手は「丁寧に教えてくれる上司」を望んでいる

というわけで、フィードバックってやはり難しいんです。こんなふうに失敗してしまう。だから、それを乗り越えなきゃいけないです。我々は、「課題解決フィードバックの達人」になるためには5つのポイントがあると思っています。


まず1つ目。一生懸命伝えたが、伝わっていない。アウトプットに対してフィードバックをするんじゃないんです。思考のプロセスなんです。思考のプロセスを可視化し、助言するんです。

2つ目は、質問返しで部下に考えさせてしまう。ちゃんとフィードバックのサイクルを学びましょう。
3つ目は、ピントのずれたアドバイスをしてしまう。部下からの相談、いろんな問題がありますので、その問題の種類に合わせて対応しなきゃいけません。

4つ目は、「これで合っていますか？」という問いから逃げる。逃げないでください。逃げないために評価基準を持ちましょう。そして、５つ目はフィードバックできる自信が持てない。正直難しいので、共通フォーマットを活用してください。これでいけます。1個ずつ見ていきましょう。

一生懸命伝えたが、伝わらない。それに対する対策としては、「思考プロセスを可視化し、助言する」です。

まず、自分で物事を理解する流れ、考える流れというのは、こうです。「どうしたらいいかよくわからないな」「何が起きているのかな？」と要素を抽出して、「こういうことが起きているんだ」と。で、関係性は、「こうなっているんだ。だからこうしよう」。こんなふうに人間の思考は進んでいきます。

よくありがちなのは、一般的に上司は、結論に対してアドバイスを行う。「ここ、こうしたほうがいいよ」……先ほど言いました、「3ページ目は……6ページ目は……」、これが一般的な上司のアドバイス。

でも、それで直せる人だったらいいんですけど、それができなくて困っているわけです。そして、今の若手の方は丁寧に教えてくれる上司を望んでいます。丁寧に教えるっていうのは、アウトプットに対して丁寧なフィードバックが欲しいんじゃなくて、メンバーが求めているのは、順番に一緒に考えてくれる。どう考えたらいいかを教えてくれる人なんです。

「フィードバックに自信が持てない問題」の解消法

つまり、要素を抽出する。今、何が起きているか一緒に言語化をして、関係性の把握、「今、こういうことが起きているんだよね」。そこに対して上司が支援をしてくれる。言語化して図解を一緒にしてくれる上司を求めています。ここをまず理解しないといけないです。

質問返しは駄目です。どんなふうにフィードバックをすればいいか、これには基本の流れがあります。

（スライドを示して）1番、図解。上司は、部下が今何を考えているか可視化する。「なんとかさん、今、こんなふうに考えているよね」と図解してください。次に評価。上司が客観的に評価し、Good＆More、「ここはいいね。そしてここをもうちょっとしたら良くなるんじゃないかな」と。そして助言。上司から「こんなふうに考えたらどうか？」と助言して、部下からのコメントをもらう。図解、評価、助言のフィードバックサイクルを繰り返します。

いきなり、助言したら駄目です。「まず、こういうふうに考えてよね」と、共通認識を作って、評価する。もちろん良いところは褒めてくださいね。Moreばっかりだと、さすがにきついので、良いところもあるはずです。

そして助言。評価していきなり考えさせたくなるかもしれませんが、まず上司から「こんなふうにしたらどうかな？」と言ってください。評価したあとに「どう思う？」って言ったら、「あっ、この上司は味方じゃないんだ」っていう感じになりますよ。上司は味方なんです。そのためには助言までしてください。

「こんなふうに考えたらどう？」というかたちですることによって、部下は安心します。そのサイクルを回してください。徐々に自分でできるようになってきますから。図解、評価、助言、このサイクルでやっていきましょう。

「ピントのずれたアドバイス」をなくすには

次に、ピントのずれたアドバイスをしてしまう。いろんな相談が来るから大変なんですけど、それに対応しなきゃいけないです。

（スライドを示して）一般的な問題解決の流れというのはこうです。テーマを設定して問題を定義して、構造化して現状分析して、なぜなぜ分析、そして課題設定、イシューは何かと。そして解決策立案、アイデア発想をして、目標設定、KPI（Key Performance Indicator）を設定する。こんな感じかなと思います。

ただ、いろんな相談が来るから、やはり一般的なやり方だとうまくいかないこともある。例えばこんなことが起きます。「問題解決はこうなんだ」と。「この考え方は正しいですか？」と8つ挙げています。

1つ目「何が問題なのかを最初に確認するようにしている」。正しいような気がするんだけど、不正解です。いつも最初に問題が定義できるとは限りません。明確にこれが問題だってわかることもあるけど、そもそも何が問題かがわからないこともあるわけです。

2つ目「業務ミスを解決する際には、何が一番の課題なのかを確認している」。なんとなく展開が見えてきましたね。これも不正解です。業務ミスの場合は、例えばメールの誤送信とかスケジュール遅れの場合には、課題はまとめません。

課題というのは「何に取り組むか？」ですが、業務ミスや重要なインシデントが起きてしまった時に、「ここを直せばいい」と課題をまとめられたら不安で仕方ありません。業務ミスの場合はすべての原因を解決すること必要です。また、（3つ目）「なぜなぜ分析は常に5回行うようにしている」。いやいや、5回とは限らないよねとか。

評価基準を明確にする

4つ目。これが、めっちゃあるんです。「営業の目標未達。取引実績が伸び悩んでしまった取引先対策に全力を注ぐように話した」。正しいような気がしますけど、いやいや違います。そうかもしれないけど、取引実績が伸びている取引先に注力するという作戦もあるんです。もう伸びていないところはちょっと無理だから、他でなんとか挽回するという方法もあるわけです。

5つ目。「お客さまの提案を考えている際に、課題をピラミッドストラクチャーでまとめるように話した」。ピラミッドストラクチャーは、こういう研修でよく出てきますね。帰納的で伝えることが相手にとって納得感があるとは限らない、他の伝え方もあるわけです。

6つ目。「常に問題が先で、課題が後だ」。通常はそうだが、課題が先で問題、つまり目標を後に設定することもあるわけなんです。

7つ目。「解決策の妥当性を確認するため、どんな結果が期待できるかを確認するように話した」。こういうことを言っちゃうんですね。「それをやったらどれぐらい効果が期待できるの？」と。いやいや、やってみないとわからないよ。

やってみないとわからないことも多いわけです。どんな条件を満たしたら効果が出るかを考えてもよいわけです。何をやったら効果が出るかじゃなくて、効果の出る施策とはどういう条件を満たしているのか。そういう考え方を知らないと上司が、部下を突き放すような感じになっちゃう。「それはどれぐらい効果があるの？」みたいな。いや、言われたらあなたも困るでしょうと。

8つ目。「10年後に向けた提案を作るために、まずは組織のありたい姿を描いてもらった」。これも、ありがちなんですけど、組織のありたい姿を描く前に、外部環境の変化を認識して、あなたたちがどういう社会とかどういうビジョンを描きたいかを考えたほうがいいよね。先に組織のありたい姿を描いちゃうことは、意外とあります。

つまり、一般的な問題解決の考え方を知っているだけでは、いろんな相談に対応できないというわけで、上司はやはり、知識を増やさなきゃいけないんです。