2021年、初めて後輩を持ちました

この記事はTECHPLAY女子部のアドベントカレンダー 11日目の記事です。
https://adventar.org/calendars/6337

初めて後輩を持ちました

今年で入社3年目になり、初めて後輩新人プログラマの教育を任されました。
結論、自分の仕事をしながら後輩を育てるのはめっっちゃ大変！
でもその分、とても学びは多いです。
何が大変で、何が学びになったのか？をここに記録しておきます。

大変だったこと

タイムマネジメントが大変

自分の作業もしつつ後輩育成の諸々もやるということは、単純に必要な時間が増えるのでいかに作業効率を上げるか・時間をうまく使うかが超重要。
上司がタイムマネジメントしっかり出来てる人なので（多分）すごいな〜っていつも思ってましたが、これは後輩教育でかなり身につくスキルなのでは？と感じています。
大前提として、『後輩育成にはしっかり時間を使うべき』と思っています。
後輩育成に使う時間を減らそうという話ではありません。しっかり時間を使うべきだからこそタイムマネジメント力が必要って話です！

自分のタスクだけをこなす場合はやるべきことの全体像・量を見て、ある程度優先順位を決めて着手するので、スケジュールが乱されることはそこまで多くならないと思います。
ただ、新人の子は右も左も分からないので、作業していて分からないことを質問してきます。というか分からなければすぐ質問するようこちらからも言ってあるんですが。
なので、後輩に作業を振ってその間に自分のタスクをしていると、大体途中でチャットが飛んできます。
この場合は自分の作業と後輩が困ってることの優先順位付けをして対応します。
仕事に割り込みはつきものですが、新人教育では”必ず”割込みが発生すると思っていいんじゃないんでしょうか。

リモートワークで教えるのめっちゃ大変

マジでこれ。
リモートだと教える方も、教えられる方も大変ですね。
教える方で特に困るのは環境構築でハマった時です。
これ何か良い方法があれば教えて欲しい・・・。
隣にいればなんとなく状態見て触ってみてアタリつけることが可能ですが、ビデオ通話でそれをやるのは結構労力がいるので、もう質問しまくって状況を整理して、そこからアタリをつけて解決の糸口を探る感じになってます。
※環境構築手順書はあるんですが、その通りにやってる「はず」なのにエラーになるというやつですね。私も新人の頃はそもそもIDEの設定とかcomposerのこととかよく分かってなくてそういうハマり方してました。

あと、教えられる側はやっぱりリモートだと質問しづらいみたいです。
姿が見えないから今忙しいかどうかが判断しづらいし、チャットの履歴だけ見ると忙しそう・・・ってなるみたいです。
「忙しい時は忙しいってちゃんと言うから、遠慮せずに聞いてね」というのは口を酸っぱくして伝えています。
バーチャルオフィスを使ってみたりしたんですが、私もちょいちょい席外してたりするので（あと常に声かけられるかもって緊張状態は嫌だw）、結局のところは「気軽にチャット送ってね」が一番良いのかなぁと思ってます。
いやいや！バーチャルオフィスこう使えば良いよ！みたいなのあればご教示ください・・・。

学んだこと

大変だったことをつらつらと書いたけど、実際学びの方がめちゃくちゃ多いです。マジで後輩に感謝。

「いつでも遠慮せず質問して良いよ！忙しい時は忙しいって言うから！」を何回も伝えるのが大事

とにかく「何回も伝える」がポイントです。
ちゃんと頻繁に報連相してきてくれるようになるまでは3日に1回くらい言わないと、ついつい聞きづらいと思ってしまうものです。私がそうだったし。
リモートワークだと尚更、チャットで私に新しいタスクが降ってくるのを見てるから、聞きづらさは倍増してるかなと思います。
後は「質問して”良いよ”」とか、「私も無理な時は隠さず無理って言うよ」ってことを伝えること。
組織で仕事するにあたって心理的安全性が何より大事だと思っているので、正直に自分の状態を伝えて良いんだよというメッセージは欠かさず送っています。

質問に対して、すぐに全部答えない方が良い

これはテクニック系ですねw
後輩の質問と上司の質問は違うので、わかりやすく回答を伝えるというよりは「こうだから、私はこうだと思う。多分ね！」みたいに余裕を持たせるというか、考え方とか方向性だけ示して、あとは後輩が考えて答えを出してもらうって方が学びになるかなと思ってます。（私にとっても）
あと、何でも答えを教えちゃうとクレクレになる可能性が高まるとも思うので。
これは通常よりも問題解決に時間かかるから、ちょっと我慢が必要です。
でも、「答えを書かずに考え方だけ伝える」ってなかなか難しくて、自分の思考のプロセスが強制的に可視化されるから結構勉強になりますよ！

開発環境の理解が深まる

環境構築の手伝いしてると「何のためにこれをする」とかを逐一説明してあげる必要があるので、自分自身も開発環境の理解の手助けになりました。
恥ずかしながら今まで深く理解できていなかったプロダクトの基盤処理とか、composer周りとか。

プリンシプル・オブ・プログラミングからの学びが深まった

この本、普通に読んでも学びが多い良本なんですが、後輩育成でかなり使えたし自分自身も学びになりました。
ちなみに社内LT会で軽く紹介したのでスライド載せときますw

この本、『プログラミングにおける原則』がたくさん書いてあるので、必然的にコードレビューの指針となるものがたくさん載っています。
【KISS】【DRY】【YAGNI】【名前重要】
このあたりがコードレビューするにあたってよく話したかな。
自分が今までなんとなくやってた事が綺麗に言語化されているので、後輩に伝える時にそれを活用できるのが最強にメリットです。
それを人に伝えることで自分の中でも腹落ちするので、自分の学びにもなる。言語化する力って大事なんやね。

車輪の再発明をさせよう

『車輪の再発明』、すでに作られたものを再び一から作ることは普通は避けるべきとされているし私もそう思うけれど、学習目的では非常に意味のあるものだと思います。（実はこれもプリンシプル・オブ・プログラミングに書いてある）
既に開発されているものをまず自身の力で開発し、出来たら開発済のプロダクトコードと自分のコードを照らし合わせる。
そうすると自分に無かった視点がよく見えるし、ああこうやって書けば良いのか！とか、これより私の書き方のほうが良くない？とか、いろんな学びや気づきがあります。
これは超重要な経験だと思っています。
仕事では結局他人と一緒に開発していくのだから、他人のコードを読めなければならないし、他人に読んでもらうことを意識してコードを書く必要があります。
だから、自分のコードと人のコードを見比べる経験は必須だと思います。
それはペアプロとかでもできるし、車輪の再発明でも経験できるので、新人プログラマには積極的にそういった経験をさせて行った方がいいんじゃないかなって思ってます。

ペアプロ（的なの）はめっちゃやるべき！

すみません、ちゃんとしたペアプロはやってないです。
が、ソースを見ながら一緒に修正するペアプロ”的なやつ”をちょくちょくやっています。
これは修正に時間がかかるけど意思疎通がしやすく齟齬が生じにくいので、結果的にはコードレビューの時間も減ってコミュニケーションも取れて、互いに学ぶところもあるのでかなりお得な気がしています。
リモートワークだと特に、文章でのやりとりだけでは認識に齟齬が生じやすいので画面共有しながらやるってとても大事です。
これは忙しくてもしっかり時間作って継続していきたいですね。

まとめ

後輩育成は超大変。だけど、超学びがある！
後輩ありがとう！来年もよろしく！
タイムマネジメント力伸ばすぞ！