凹んでいるやつを蹴るな
今回ブログ記事のタイトルはジャック・ウェルチ氏（元ゼネラル・エレクトリック社のCEO）のFreakonomics podcastでのインタビューから引用しました。
WELCH: The worst one, I think that I could think of off hand — I had a number of experiences in my life and while I was running it that were uncomfortable. I blew up a factory.(snip)I expected I might get fired. I drove down in my Volkswagen from Pittsfield. I met Charlie, it turns out he was a Ph.D. Chemical Engineer from M.I.T. So, he took me through the Socratic method. You know, “Why it happened? What would you do differently? Why did you do that? Why didn’t you do this?” And he was coaching me, and it was — couldn’t be nicer. And I learned from that, never kick anybody when they’re down. Kick them when they start to swell and instead of grow, and whack ’em when that happens.
ウェルチ氏：（工場を管理する中で）いろいろ苦い経験があるが、思いつく中で一番ひどい例は、工場で爆発事故を起こしてしまったことだ。（中略）クビになると思った。ピッツフィールドからフォルクスワーゲンを運転して、チャーリー（注：当時のウェルチの上司）に会いに行った。チャーリーはMIT出身で化学の博士号を持っていたからなのか、ソクラテス式で質問してきた。「なぜ起きたのか？次に同じことを起こさないためにどうするか？なぜそうしたのか？なぜ、こうしなかったのか？」と。チャーリーは私をコーチングしてくれた。とても親切だった。彼から凹んでいるやつを蹴るなということを学んだ。成長を止めてしまって、調子に乗っているようなやつを蹴れ。（作者の意訳）
つまり、誰かがミスをしたときに批判したり非難してはいけない、ということですね。当人は既に自分が犯したミスを分かっているので、その傷に塩を塗る必要はなくて、代わりに、そこから何かを学んで糧にしてもらうべき、ということです。
自分の過去の経験から、この言葉に関係するものをミスした側と、それを部下が犯した際の上司の視点から書いてみたいと思います。
視点1: ミスをした側
自分がソフトウェア・エンジニアとして働き始めた新人の頃、仕事を進めるのがとても苦手でした。新人なので、タスクも1つぐらいしかもっておらず、時間もたっぷりあったのにも関わらず、なかなか進まなかったのです。
もちろんサボっていたわけではなく、ちゃんとそのタスクに取り掛かってはいたのですが、新人だったため、コードベースはもちろん、システムの全容やビジネス観点など何も分かっていない状態でした。ドキュメントなども少なく、前任者からの引継ぎもほとんどなかったので、とても苦労していました。
毎週、進捗を確認する定例会議があり、自分の上司に加えて、上司の上司も参加していました。当然、自分は何も進められていないので「特に進捗はありません」と言うのを毎週繰り返していました。その上司の上司は当然ながら不満を持っており、ある日それが爆発して、
なんでこんなに時間がかかるんだ？まだやっているのが信じられない。毎日何をやっているんだ？毎日の作業報告をメールにして送れ。
と言われました。
新人の自分は完全に怖気づいてしまい、不安なり、元々仕事を進められていなかったのが、パフォーマンスが更に悪化しました。
今思うと、そのときに自分に必要だったのは誰かと相談してコーチングしてもらうことだったんだろうと思います。もちろん、自ら行動を起こして聞きに行くこともするべきなのでしょうが、周りや上司がそういう機会を作ってくれることもあれば、もう少し良い結果になっていたかもしれません。
視点2: 上司として
こちらは最近の出来事で、自分がマネージャーとして数年経った頃の話です。
自分のチームのメンバー（仮にAさんとします）が任されていたプロジェクトがなかなかうまく進められず、苦労していました。Aさんはソフトウェア・エンジニアとしては数年の経験があったのですが、任されていたプロジェクトでは言語やフレームワークに関してはあまり経験がない状態でした。同じチームに、より経験豊富なエンジニアがいて、コードレビューなどでいろいろとフィードバックをたくさんしてくれていました。しかし、Aさんは自身でなかなかうまくいっていないことを認識していて、コードレビューのフィードバックに対しても、ものすごく敏感になっていました。コードレビューやフィードバックの内容が無駄に厳しいとか、言葉が強すぎるとか、そういうものではなく、いずれも建設的で丁寧なフィードバックだったのですが、数も多く、Aさんの中では不安がどんどん溜まっていっているようでした。実際に自分と週次で行う1-on-1でも、いつも不安な様子でした。いわゆる「インポスター症候群」に陥っている状態でした。
そのときに自分が上司として取れる行動は次の2つでした。
ハードモードのフィードバック：Aさんに対して、仕事がうまく行っていないことを伝え、もっと頑張ってもらう必要があることを伝える。
ソフトモードのフィードバック：Aさんに対して、仕事はできており、ちゃんと成長していることを伝える。
ジャック・ウェルチの言葉からも1はあまり良くなさそうだな、と考えていました。1の選択肢を取っていたら、Aさんを一層プレッシャーを与えてしまい、インポスター症候群が悪化して、パフォーマンスが更に悪化し、最悪の場合は退職してしまう可能性もあり得ると思いました。
自分は2の選択肢を取り、Aさんに対して、大きな問題はなく、コードレビューやフィードバックは、Aさんを成長させるためのものであることを伝えました。Aさんも納得してくれて、そのフィードバックに真摯に向き合ってくれるようになりました。
結果として、Aさんはプロジェクトをうまく進めることができるようになり、インポスター症候群から抜け出し、その後、大きく成長しました。
2つの経験から、フィードバックを与えるときには、どのように与えるか、ということを意識することがとても大切だと感じています。凹んでいるやつを蹴るのはとても簡単です。自分のストレスを発散できるし、一瞬は自分も楽になるかもしれません。しかし、相手にとっては良いことは何もなく、長い目で見れば、自分にとっても良いことではないと思います。
凹んでいるやつを蹴らないようにしましょう。
この記事が気に入ったらサポートをしてみませんか？