1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

概要

先日、エンジニアリング組織論というテーマで社内勉強会を開催しました。
そこで次のような質問をいただき、とても良い質問でしたので、記事にまとめて回答します!

質問
「コミュニケーションにおいて、 上司が部下に「助言」=「命令」にとらえられがちだと思います。
助言方法のアドバイスがあれば教えてください。」

回答
「基本的に上司が部下に助言をする必要はありません。
部下の中に答えがあると信じて、引き出すことに徹するのも一つの手段です。成長を促すという観点では、自分の話・助言・アドバイスは控えめにするとよいとされています。」

前提:エンジニアリング組織論とは

「コミュニケーションにおける不確実性を減らすには?」
「技術的負債を解消する方法とは?」
「経営陣とエンジニア間の認識のずれを解消するには?」

といった、エンジニアリングにおける課題を解決する思考法やメンタリング手法がエンジニアリング組織論です。

「エンジニアリング組織論への招待」という本は、広木大地さんという、様々な企業の技術組織アドバイザーを務めている方が執筆した本で、各方面で高い評価を得ています。

勉強会ではこちらの本をメインに、他にも「ヤフーの1on1」「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」といった本を参考に、学んだことを発表しました。

前提:この記事における「助言」の定義

「助言」という単語は、前後の文章で意味合いが変わる言葉です。
仕事という場面で使う助言では、主に2つのシチュエーションが考えられます。

  • 業務的に最低限できてほしい事柄に対する助言
    • 例1)「GitのCommitの前は修正箇所をすべて確認すると、レビュアーの負担が減ると思います。」
    • 例2)「進捗状況を共有するときは、結論から話すといいと思います。」
  • 本人がさらに成長するために、これからの行動に対する助言
    • 例1)「この本を読むと、DB設計に詳しくなれるよ。」
    • 例2)「オープンソースプロジェクトに参加すると、実践的なスキルが身につくと思うよ。」

前者の「業務的に最低限できてほしい事柄に対する助言」は、上司が部下に指示として伝えなければならないことです。そのため、助言=指示として伝えることは、全く問題ありません。

本記事では、後者、助言=「本人がさらに成長するために、これからの行動に対する助言」として扱います。

なぜ基本的に助言をしなくてもよいのか

質問でいただいた「上司が部下に「助言」=「命令」にとらえられがちだと思います」という点について、
質問者さんは助言を「〜したほうがいいと思う。けど、実際にはしても、しなくても大丈夫だよ。」というニュアンスで伝えたいのだと推測します。

しかし、普段からバリバリ仕事をこなしている、超コワモテの上司がいたとします。
その人に「◯◯君さ、もっと勉強した方がいいんじゃない(^^)」と言われたら、本人が優しくアドバイスしているだけと思っていても
相手からしたら「あ..これやんなきゃいけないやつだ...」と捉えてしまう可能性は大いにあります。
(あくまでも例です)

上司という上の立場の人が助言をすると、命令に捉えられてしまうのは、構造上仕方のないことです。
それと同時に、以下の理由も考えられるため、そもそも助言をするのは控えめにした方がよいとされています。

理由1:自分で自分を説得したときにいちばん納得できるから

助言など、他者からの情報を通じて行動する状態を 「他者説得」といいます。

他者説得は「どうしてほしいか?」「何が必要か?」を説明して、そのとおりに動いてもらう説得の仕方です。

他者説得は

  • 他人が答えを教える
  • 体感・理解を伴わない

という特徴があり、効果が持続しづらいとされています。

対して、「自己説得」は自らわからなかったことを理解し、納得した状態です。
自己説得はどんな行動が望ましいかを自分で考え、自らの判断と意思で動くようにする説得の仕方です。

自分で納得して行動するため、自己説得は

  • 自分で気づき、理解する
  • 体感を伴う
  • 行動の変化が発生しやすい

という特徴があります。

前提として、問題を解決できるのは本人だけです。
そのため、助言のように答えを教えるのではなく自ら考えてもらうことで、より解決に導くことができます。

理由2:相手の成長につながるから

理由1とも重なりますが、人から教えてもらったことより自分から学んだことの方がより物事は身につきやすいとされています。

7・2・1の法則」という理論があります。

7・2・1の法則はアメリカのコンサルタント会社が提唱した、人の成長を決める要素の比率です。
人が成長するために何からどのくらいの割合で学びを得るのか?を示した法則で7割を「仕事上の経験」、2割を「上司や先輩からの助言やフィードバック」、残りの1割を「研修や書籍」から人は学ぶと言われています。

この法則からわかるのは、成長には「仕事上の経験」による実体験が非常に重要ということです。

より成長を促すには、適切なフィードバックを行い、部下が仕事上の経験を最大限得られるようにサポートする必要があります。

助言しないならどうしたらいいのか?結論:対話しよう!

とはいえ、助言がしたい気持ちは相手に「ここまでの能力を身につけてほしい!」「ここまで頑張ってほしい!」という親切心や期待から来ていると思います。

成長してほしいという思いはとっても素晴らしいことです。
なので、ぜひ、対話するという方法を試してみていただきたいです。

部下を信じ、対話を重ねることで、成長を促すことができます。

Step1.現状を伝え、認識をすり合わせる

上司が期待する水準と部下の現状を本人に伝えます。

例えば、部下のコーディング能力が不足しているとしましょう。
その場合の対話の例を挙げます。

問いかけから認識の差を埋める対話例

上司😎「今回の案件のコーディングについて、自分で何点くらいできたかな〜と思いますか?」

部下😃「大体80点です!レビュー指摘も少なかったし、結構できたと思います!!」

上司😎「いいですね!たしかに、〇〇さんがよく頑張ってくれていると他メンバーからも聞いています。」

上司😎「ただ、実は〇〇さんには、後輩を指導できるくらいに実力をつけてほしいなと考えていまして...100点が自分でレビューできるレベルだとしたら、どうでしょうか?」

部下😃「あ〜...そう言われると60点くらいかも?ですね。」

上司😎「私としても、今すぐにレビューする側になるのはまだちょっと厳しいかなと見ています。しかし、〇〇さんの成長スピードなら次の案件までにはできるようになると思っています^^」

部下😃「なるほどですね^^」


ここで大事なのは、問いかけをすることで、認識の差を伝えることです。

はじめから上司が「〇〇さんには後輩指導できるくらいにはなってほしいです。現状できていないように感じます。」と言ってしまうと、事実だとしても部下側はいい気分にはならないでしょうし、場合によっては「でもがんばってるんですよ!」と反抗心が芽生える可能性もあります。

結論から言いたくなる気持ちをグッと堪えて、まずは現状を認識してもらうための問いかけからはじめましょう。

Step2.次の行動を決定してもらう

現状の認識合わせができたら、次はどうしたら改善するか?目標までにどのような行動を取ったらいいか?を考えてもらいます。
ここでも、上司は具体的にどうしたらいいかは伝えず、相手の頭の中にある考えを引き出し、相手に決定してもらいます。

次の行動を決める対話例

上司😎「ということで、後輩に指導できるくらいになるにはどうしたらいいと思いますか?」

部下😃「うーーん...そうですね...」

上司😎(多少の沈黙があっても、待つ)

部下😃「実践的にはたくさんコードを書いた方がいいですよね。」

上司😎「いいと思います!量は大事ですね。ちなみに、どのくらい書いたらいいと思いますか?」

部下😃「やっぱり、本を読んで、知識を身につけた方がいいかもしれません。」

上司😎「それもありですね。」

部下😃「おすすめの本とかあります?」

上司😎「リーダブルコードがおすすめです。私自身も先輩からお薦めされて読みましたがよかったです。」

部下😃「じゃあ、それ読みます。」


ここでのポイントはStep1同様に相手から答えを引き出すことです。多少の沈黙があるかもしれませんが、相手が考える時間でもあるので、"間"を恐れず、待つようにしましょう。

また、部下側から助言を求められた場合は、一つの選択肢として伝えることです。上司側がはじめから「リーダブルコードおすすめ!これ読んだらいいと思う!!」と伝えてしまうと部下の思考が狭まってしまいます。

自分は壁打ちの壁役と思い、相手の思考の整理を手伝う心持ちで接します。

Step3.経過を気に掛ける

部下が目標を決めたら、実際に行動をしているか気にかけて、様子を観察します。
そして、現状と理想に差がある場合は「Step1.現状を伝え、認識をすり合わせる」から繰り返します。

なお、もし部下が決めた行動をとっていなくても、そのことを非難しないようにします。
その場合、「なぜ行動ができなかったんだろう?」と理由を尋ねるようしてください。
部下の気持ちになってみれば、できなかった理由が何かしらあるはずです。

すぐ教えた方がいい内容もあります

事務的に伝えた方がよいことは対話などせず、すぐに教えるようにしてください。
例:
「給料明細で一部気になる箇所があるのですが...」→「労務担当のAさんにメールをしてください。」
「この変数名、なんとなくしっくりこないんです...」→「XXXがいいと思いますよ。」

単純におすすめしたいことがある場合

プラスアルファでやらなくても困らないけど、おすすめはしたい!とりあえず伝えたいことがある場合
例えば、おすすめの本があって、有名じゃないけど知識として頭の片隅に置いてほしいこともあるかと思います。

そのときは、1on1やフィードバックの時ではなく、Slackの雑談チャンネルや休憩のときに、おしゃべりとしてさらっと伝えると良いです。

最後に

部下を信じることも、対話した際に部下が本音で話してくれるかどうかも、お互いの信頼関係の上に成り立ちます。

信頼関係を築きつつ、対話を重ねて、相手の成長を促す方法を試してみるのはいかがでしょうか。

質問をくださった方、とてもいい質問をくださりありがとうございました!
また、勉強会に参加してくださった方、ここまで記事を読んでくださった方、お付き合いいただきありがとうございます!

ご意見、ご質問等ございましたら、ぜひコメントください!

参考文献

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?