後輩が自走できるようにサポートするぞー

この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。

note.com

信頼する

まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。

対話

自分の期待を共有する

「自走できるようになってね?」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、ということを伝える方が手っ取り早いので好き。

いいなと思ったことをフィードバックする

いいなと思ったところは、みんなの前でいいね・ありがとうって伝える。そういうのが好きじゃない人の場合は、ダイレクトメッセージで伝えたりする。

それとは別に、本人が気づいていない良いところを1on1で細かく伝えたりもする。リモート会議でみんながシーンとしてるときに意見出してくれてその後に他の人にも聞いてくれたのありがとうとか、コードの名前に気をつけてくれてるのいいと思うとか、ドキュメントを分かりやすく書いてくれてありがとうとか。

自分の行動の中で何が良かったのか、って言ってもらわないと分からない場合は多いよね。だからそういうのは言葉にして伝える。自信と道標になるかなと思って。

良くなるといいなと思ったことをフィードバックする

もうひとつは、ネガティブフィードバック。「あの行動は、話を聞いていないように見えたよ」とか「今回のタスク、ちょっと手戻りが多かったね。次同じようなのが来たらどうしようか?」みたいなの。「あなたは話を聞いていませんよね?」みたいな主観的な決めつけじゃなくて「どう見えたか」とか、「手戻りが多かったよね」っていう事実とかを中心にする。

信頼が前提にあるから「もっと話をちゃんと聞くように!」じゃなくて「どうしたらそう見えない行動を取れるか」とか「どういう仕組みにしたら手戻りを減らせるか」みたいな話ができる。

フィードバックはあったかいうちにする

どちらもできるだけはやく伝えたい。特に、ネガティブフィードバックは評価時期に伝えるのだと遅すぎる。そこまでの間に良くなってて評価も上がるのが一番いい。だって、後輩をサポートするときって「後輩の評価があがること」が僕のゴールだから「評価時期だから言うけどここ良くないよ」みたいなの意味ない。

迷ってることはそのまま伝える

サポートしてるときは結構悩むことがある。先輩だからある程度しっかりしてるほうがいいのはそうだけど、完璧じゃなきゃいけない、みたいなのはちょっと邪魔。

例えば「話を聞いてるよって伝えるにはどうしたらいいんだろう?分からん。これ質問で引き出そうとしてるとかじゃなくて、本当にどうしたらいいかよく分かってないんだよね」みたいに相談したりする。「じゃあ、こういう風にやってみるのはどうでしょうか?」って教えてもらえたりして「おーいいね。それやってみよう!」ってなったりする。

話を聞く

自分の意見を伝えたら、次は相手の気持ちを知りたい。これ、順番が逆だとあんまり話したい気持ちにならないかなと思うので、先に自分の気持ちを伝えるようにしてる。

相手の考えが自分と違ったとしても「相手がそう考えている」ということは否定することじゃないので「そう思ってるんだね。教えてくれてありがとう」って言う。「そっかー」ってよく言う。その次に使う接続詞は順接にする。「そう思ったんですね。でも・・・」じゃなくて「そう思ったんですね、じゃあ・・・」にする。

イメージとしては、横に並んで一緒に目的地を見てる感じ。「今こっちに向かってるよね、じゃあ、あのゴールに向かうには次にどうしたらいいと思う?一緒に考えよう」みたいなの。

だいたいここまでが、お互いの考えを共有するためにやってること。実際は、これを「行動」の中でやってる。

行動

やって見せる

最初は、やって見せる。何が正解かも分からない状態で「自分で考えてやって(でも、僕の期待には応えてね)」みたいなの、さっきも言ったけどめんどくさい。「最初は僕がやるから、次は自分でもできるようになるつもりで見ててね」

タスクに対して「こういう場合は、こんな風に考えるよ」って考えを伝えて「だからこんな風にコードを書いて、でドキュメントにはこういうことを書くよ、その理由は・・・」みたいに。

「この仕様だと何種類かに読み取れるよね?そういうときは『Aさんの時間をいただくのもったいないから、たぶんこれだろうしこれで実装しよう』じゃなくて『Aさんーこれ教えてくれー』って教えてもらう方が結局良いものができるんだよ」みたいに。

んで「ふむ。時間をいただくのが申し訳ない?それわかる。じゃ、申し訳なくならないような仕組みをチームで考えてみようかー」とかも。

一緒にやる

次は、一緒にやる。ペアプロのナビゲーターみたいな感じ。「そうそう、そこは仕様書確認してみようか」「おーその名前付けいいね!」「そこは、こういう風にやったほうが良いと思うー」「ちょっと興味があるだけなんだけど、そこどう考えてそれにしたの?・・・なるほど」「お、悩む?そういう場合はAとBがあるよ。試してみる?」とか。

やったのを見る

その次は、やったのを見せてもらう。ここでまた気づくことが出てくるので、そしたらその部分はまたやって見せたり、一緒にやったりして、徐々に一人でできるようになっていく。

任せる

そういうことを繰り返して、どんどんできることを増やしていきつつ、もう安心だなと思う部分は完全に任せていく。とはいっても、チームのレビューとかがあるから、まぁその後輩とチームに任せるって感じではあるか。

心持ち

失敗の機会を与える

失敗しながらが一番成長できると思うので、小さくいっぱい失敗してもらえるような仕組みにする。プルリクエストのレビューよりもペアプロで拾う。週次の30分の共有よりも日次の5分の共有で伝えるとか。

失敗、というか、自分の期待と違う場所に向かった場合は「何がそうさせてるのか」を知る良い機会。怒られるかもしれない、という気持ちだったり、知らないということが恥ずかしくて聞けないとか、目的を勘違いしてたとか。それが分かれば、次はそうならないような仕掛けを一緒に考える。

ちなみに、失敗は、自己申告しなくても勝手に見つかるような仕組みにしておく。自分から「これ失敗かもしれません・・・」って言いづらいから。

最短距離を求めない

質問の仕方とか、確認の方法とか、目的地にたどり着くのに最短の道を選んでなくていい。「自分だったらこの道をいくから君もここを通るべきだ」みたいなの。それよりも自分で考えてやってみることに価値がある。「その道行くの?いいね。行ってみよう!」「わー!目的地についてよかった!」でいいかなと。その後で「こういう道もあったよ」くらい。

最後は拾っとく

任せるし、失敗から学んだらいい、とはいえ、プロジェクトとかを失敗させてしまうとめんどくさいことになる。なので、その辺りは拾っておく。今のスキルではこぼれ落ちてしまう部分がどうしてもあるからね。

もし、その拾ったものを伝えて理解できるんだったら伝えるし、まだ伝えてもわかんないかなと思うのは別に伝えない。そのときがきたら伝えればいいかなと思って。

目的を共有する

これ最初に書けばよかった。「何をするか」っていうタスクじゃなくて「何を達成したいか」っていう目的を共有する。「そのためにチームのみんなでベストを尽くしてほしいんだよね。どうする?」みたいなの。

タスクよりもプロジェクト、プロジェクトよりもサービス、サービスのためにチーム、その視点を全部見せておく。と言っても、プロジェクトぐらいまでしか見えてない人もいるかもだけど別にいい。いつか、どっかで言ってたことが役に立てばいいかなくらいで。

どこまでやるの?

こんな話をしてたら「そんなことしてる時間ない」みたいに言われるときあるけど「僕は、それをやらない方がめんどくさいってだけだよ」という気持ち。

こんなとこかな。こういう風にしてたら、勝手に自走してくれる。