自分でやりすぎちゃう上司になっていませんか?

仕事の中で、

「こういうトラブルが起きています、どうしましょう?」

と相談を受ける上司は多いのではないでしょうか。

 

その際、どういう対応をしていますか?

 

「じゃあ、こうしたらいいんじゃないかな?」

と自分の考えを伝えますか?

 

さて今日は、マネジメントの研修で恐らく最初の方に教えられることを書きます。

 

「じゃあ、こうしたらいいんじゃないかな?」

これはいわゆるティーチングです。

課題に対し答えを教えに行っている状態です。

 

ティーチングが必ずしも悪ではないですが、この状態が日常化するとどうなるか。

 

部下は自ら解決法を考えることを止め、上司に答えを求めに行くようになります。

すると当然、経験値が溜まるのは上司だけ。

メンバーはいつまで経っても、上司と同じ経験値が溜まらずに昇格できません。

 

それではどうするのか。

その際に今回の主題、「ティーチングではなくコーチング」になります。

 

ティーチングとコーチング、似ている言葉ですが違いが分かるでしょうか?

一見、どちらも「教える」ことに変わりがないように感じませんか?

 

ja.wikipedia.org

 

コーチングの考え方からすると、

「こういうトラブルが起きています、どうしましょう?」 

 に対しては、

「じゃあ、まず何をしたらいいと思う?」

といった問いかけをすることが多いです。

それにより、部下が自分だったらどうするか考える機会を作り、1つ上の視座から物事が考えられるチャンスになります。

その結果部下が出した結論を放置するのではなく、もし考えの方向性が大きくズレていたらアドバイスしましょう。

 

ここでも状況によりますが、「コケないように完全サポート」よりは、多少コケてもいいので自分自身で決めさせて、自分自身で行動させるのも重要と考えています。

人間は成功した時より、失敗したことの方が記憶に残りますし、自分の考えや行動の何が足りなかったのか反省する機会が増えます。

コーチングの結果、もし失敗しそうでもグッと見守る勇気も大切かもしれません。

(もちろん、他人に迷惑を過剰にかけてしまったり、人命に関わるような場合は全力サポートが必要ですが)

 

つまりティーチングは直接的な支援で、コーチングは間接的な支援です。

我々が原始時代の人間だとして、子どもが「お腹が空いた」と訴えた時に

  • 獣や魚を狩猟して子どもに与えるのが直接的な支援
  • 狩りのやり方や釣り竿の作り方を子どもに教えて自分で採れるようにするのが間接的な支援

です。

 

直接的な支援のみを続けていくとどうなるのか。

自然界の鳥に例えるなら、巣でくちばしを開いて訴えるだけの雛がそのまま大きくなっていき、親が死ぬと自分で狩りに行けないので餓死します。

 

いわゆる上司はスーパープレイヤー上がりが多いです。

営業ならスーパー営業マン、エンジニアならスーパーエンジニア。

そういった人たちが上司になってすぐは、どうしても「自分が解決した方が楽だし早い」となって、部下の考えるチャンス・成長するチャンスを奪いがちです。

そこでグッと抑えて、「部下に任せて、失敗した時は自分が責任を取る」ぐらいの覚悟が必要とされるでしょう。

自ら機会を創り出せるか

「自ら機会を創り出し、機会によって自らを変えよ」

リクルート創業者江副浩正氏の言葉で、長らく同社の社訓であった言葉です。

現在は公式の社訓としては無くなっていますが、今なお各所で語り継がれている言葉のようです。

 

私が初めて聞いたのは3年ぐらい前で、当時は「なるほどなー」ぐらいの印象でした。

しかしここ数年マネジメント業務に携わらせていただく中で、この言葉を知ってか知らずか、体現できている人ほど成長・貢献できているなと感じます。

 

誰かが機会を創ってくれる、誰かがチャンスを与えてくれる、誰かが行動のアドバイスをくれる、誰かが進めてくれる…

こういう考えだと、「その時」が来るまで時間を無下にしてしまいます。

そしてその間、『自ら機会を創り出している人たち』はどんどん成長し、距離を離されるばかりです。

 

この言葉についてはもっと語りたいことがいろいろあるのですが、語りだしたご本人の真意を把握していないのでそこを把握した上で語りたいと思います。

書籍をポチったので、また1ヶ月以内を目処に書ければと思います。

人・組織に対するマネジメントを学ぶこと、発信すること

先日、都内某所で行われたLT会に参加しました。

「良いチームとは」等のテーマに対し、数人がLTで語っていました。

 

内容自体も良かったのですが、何より弊社内であまりこういった機会がないことに少し課題感を感じる機会になりました。

 

エンジニアであればプログラミングに関するLT大会、営業であれば営業トーク共有等、職種に直結する技術の共有・議論の場は多々設けられています。しかし、人や組織に関する知識は属人化しており、直属の上司部下間で伝聞されるのが主のように思います。

そしてマネジメント力強化、となると「社外の研修」という選択肢になりがちかと思います。

研修を否定するつもりは毛頭ないですが、そもそもマネージャーで横の情報共有がしっかりできていないこと、結構あるのではないでしょうか。

 

そういった知識を発信・共有するLT会をやっている企業は少ないように思うので、やれないか模索中です。

 

また、以前ブログで書いたように、LT会のような機会は聴衆のためだけでなく、何より発信者自身のレベルアップに繋がります。

rfdnxbrow.hatenablog.com

 

上司から部下に口頭で伝える場合、基本的には1対1となります。

それがLT会になれば数十人を前に発言するので下手なことは言えないという意識があり、入念に下調べや練習をすることで、今まで言語化できていなかった情報が言語化できたり、理解が深まって自分自身の中でも腹落ちできることが増えてきます。

 

また、マネジメントも専門知識になります。先人があらゆる苦労をしてきて、成功法則や考え方を本やネットで言語化されているので、それを吸収することでより早い成長が臨めます。

エンジニア的に言うと「車輪の再発明」ばかりしていてはもったいないと思います。

 

もちろんあらゆる知識を頭に詰め込んだからといって完ぺきにできるわけではなく経験することで実感になり、さらに次のステップへ進んでいきますが、自身の言動の向上スピードを上げるには、知識を吸収し、それをアウトプットする場が必要になるかと思います。

そういった場を自ら作り参画することによって、今より成長できると感じています。

将来どうなりたいのか分からない時

仕事で個人の目標を立てる時、『1年後や3年後、さらにその先どうなりたいのか?』と聞かれると迷うこと多いですよね。

そういった相談をもらった時、いきなり答えを導き出そうとしてもうまくいかないと思います。

 

もしそういった状況の場合、事実ベースで答えられることから質問をすることが多いです。

エンジニアに話をすることが多いので例に取ると、

  • 最初にプログラミングを始めたきっかけは何か
  • 今も何故続けているのか
  • この職種を選んだ理由は何か
  • プログラミングをやっていてやりがいを感じる瞬間は何か
  • 仕事をやっていてやりがいを感じる瞬間は何か

といったことを聞いています。

人によって異なりますが、書いたコードが想定通り動いた時とか、使ってもらって喜んでもらえた時とか、様々な答えが出てきます。

そして、根源的な楽しさや嬉しさを感じる瞬間と、延長線上に置ける役割や仕事内容を出すことで3年後のビジョン等を置いてもらうようにしています。

 

他にも周囲の同職種で憧れを抱ける人物を置いてみるとか、やり方はいろいろあるかと思います。

 

逆に、仕事をしていてやりがいを感じる瞬間が0%という場合は、その仕事で大きく成長することは難しいかもしれません。

いろいろな人に話を聞いてアドバイスをもらい、それでもビジョンが見えない場合は、職種や会社を変えることになるかもしれません。

自分のためにも、世の中に発信すること

今回も、過去何度かに渡って書いている『アウトプットの重要性』に関する記事です。

 

関連する過去記事はこのあたり。

rfdnxbrow.hatenablog.com

rfdnxbrow.hatenablog.com

 

これら記事の中で、学習定着率向上のためにアウトプットは重要、ということを伝えてきました。

読み直しているとアウトプットの定義が曖昧だったので、改めてこの記事で統一したいと思います。

 

ここで言うアウトプットとは、

  • 自分なりの解釈を加え、コミュニケーションが起きる何かしらの手段で発信していること

とします。

 

例えば自分なりの解釈を入れないケースを考えてみます。

ネットで拾ったニュース記事を、ただ横流しSNS等に展開している行為があるかと思います。この行為は全然否定しないですし、全く行動しないより何倍も素晴らしいですが、ここに「自分なりの解釈」を入れるだけで結果が変わってきます。

例えば使っているサービスの新バージョンがリリースされたとしましょう。

その場合、自分なりの解釈を加えて「この点が良い」「こう活用できそう」と加えることで、まず発信者本人の中で考えの整理ができます。また、その情報を見た知人も、発信者の見解があると無いとではレスポンスの数や質も変わってくるでしょう。

 

次に、コミュニケーションが起きる何かしらの手段を使わないケースを考えてみます。

自分の読んだ本のレビューを、日記に書き留める習慣を付けている人がいたとします。

この場合も、本を読むことや日記の習慣自体は素晴らしいのですが、それをブログのような場で発信するように変えたとしたらいかがでしょうか。

すると発信者本人は「誤字脱字はないか」「この書き方で問題がないか」「他の人が読んだ時に誤解を招かないか」「こんなこと書いて炎上しないか」「もっと説得力高められる裏付けデータはないか」等、いろいろ考えて、調べながら発信することになると思います。

個人的にはその適度な緊張感があるからこそ、発信直前に理解度の上昇と、発信後のコミュニケーションによっても更なる理解度の上昇が生まれると感じています。

 

まさにこのブログも、世の中の貢献とかアピールというより、自分自身の理解促進のために書いているようなところがあります。

 

ちょうどこのテーマで書こうと思い、裏付けデータでいろいろググっていたら見つけた記事。

globis.jp

・教えようとすれば、自分であいまいな部分を再確認・再学習しなければならない。
・教えようとすれば、事前に整理・体系化しなければならない。
・教えようとすれば、相手にかっこいいところをみせようと練習を重ねる。
・教えようとすれば、短絡的な答えではなく、「考え方・プロセス」を示さなくてはならない。
・教えようとすれば、相手にどう伝えるのがわかりやすいかをあれこれ想像しなければならない。
・教えようとすれば、目の前の相手の言葉を傾聴し、相手の反応に敏感にならなければならない。
・教えようとすれば、根気がいる。
・教えようとすれば、熱意がいる。
・そして相手が、知り、わかり、できるようになり、教えられるようになれば、とてもうれしい。

言いたいことは割とここに集約されています。

 

インターネットが世の中に普及し始めて約20年、それまでは世の中に発信しようと思うとテレビやラジオ、新聞、集会等、それなりのお金や労力が必要でした。

それが今となっては誰でもタダ同然にPCやスマホでできる時代。アウトプットのハードルが下がったことで昔より成長しやすくなった今、いち早く成長するために、世の中に向けて発信してみませんか。

アウトプット目標達成のコツ

アウトプットは重要、というお話を前回、前々回と続けてきました。

rfdnxbrow.hatenablog.com

rfdnxbrow.hatenablog.com

 

ですが、なかなかアウトプット目標を達成するのは難しいですよね。

目標を立てたはいいけれど思うように進まなかったり、全く着手できなかったり、習慣づけできず終わってしまうことが多いかと思います。

 

そうなった時に、「自分の意志が弱いから」と片付けていませんか?

確かに重要な要素ですが、ケースや状況によって対処法は変わるのでは、と考えています。

ケース1 高い目標を数カ月後達成見込みで立てたが、数ヶ月経っても全く進まない

いつまでに何をする、が決まっていないと第一歩が踏まれることなく終わりやすいです。

1ヶ月目はここまでやる、2ヶ月目はここまでやる、と引くと良いです。

その際、バッファがないとギリギリ未達とかになるので気を付けましょう。

ケース2 習慣目標を立てて、三日坊主で終わる

習慣の難易度が高すぎると続かないです。

例えば「毎日ブログ書く」だと、何かしらの事情により達成できない日が出てしまうと、それを期に「1度も2度も同じ」とズルズルと未達が増え、習慣化できず終わる傾向が多いように感じます。

とはいえ、簡単すぎると自身の成長に繋がる目標になりません。

適度な負荷をかけつつ、未達になりそうな時にギリギリでリカバーできるぐらいがベストかと思います。

この記事も、「週2ブログ更新」という目標を立てて、現在土曜の23:30というギリギリ時刻に書いていますw

ケース3 目標を立てて少し進んだが、当初の想定ほど進んでいない

ケース1と違い、マイルストーンを立てたけどうまく進んでいないパターンです。

私の考える対処法として2つで、

です。

1つ目の習慣目標との合わせ技は特にオススメです。

例えば長期目標で「フロントエンド技術を身につけ、3ヶ月後までにWebサイトを作って公開する」と立てたとします。

そこで例えば、「毎週3日以上、20時〜22時勉強時間を確保する」を立てることで、勉強時間が確保できるはずです。

 

今回の記事はここまでです。

 

 

最後に。

このブログを週2更新続けてきましたが、来週から週1に減らしたいと思います。

負担が大きいとかやる気がなくなった等ではなく、週2アウトプットを続けてきたことでだいぶ自身の考えが整理でき、アウトプットへの抵抗感がなくなってきたためです。

当初の狙いがだいぶ達成できてきたので減らし、今後は週1でブログとqiita1記事ずつ更新してみたいと思います。

会社での役割が変わり、今まで以上にエンジニアとして手を動かすことが減りそうなので、業務外で技術向上のアウトプットをしたいと思います。

 

引き続き、よろしくお願いします。

アウトプットがなぜ重要なのか?

前回の最後で「実際アウトプットする習慣を付ける方法について書く」と宣言しましたが、その前に挟みたい内容ができたので前言撤回。

 

今回の記事は、『アウトプットが重要なのは学習定着率が高いから』という前回の内容に対する補足です。まずは前回記事をご覧ください。

rfdnxbrow.hatenablog.com

 

成長のためにはインプット・アウトプットが重要。

じゃあ、とにかくインプット量を増やせば良いのでしょうか?

 

答えはNOでしょう。

私は新卒の時にアウトプットを軽視しており、『2週間ごとに10冊本を読む』という、インプット量爆上げ目標を掲げていました。

しかし開始2ヶ月弱で、金銭的にも行動的にも破綻しました。読むことが目的になってしまっており、今となっては本の内容はおろか、本のタイトルすら2,3冊しか思い出せませんw

 

そもそも成長とは、知識や経験を元に、今までできなかったことができるようになったり、精度が上がってアウトプットの量や質が再現性をもって向上することと考えています。

一時的に覚えても数日数ヶ月経った時に何も思い出せなかったら成長とは言えないですし、新しいことを覚えたら別の知識が抜けてしまってはアウトプットの量や質が向上しないでしょうから、成長したとは言い難いでしょう。

 

インプットした知識に対して学習定着率をかけたものが力になっていくので、

インプット量×学習定着率という掛け算においてインプット量をどんどん増やしても、学習定着率が低い方法だと目の粗いザルのようにほとんど残らないでしょう。

 

アウトプットすること、オススメです。