新人さんに教える時に気をつけてること

IT会社に勤めていて、新しく新卒の人が後輩についた人向けの記事です。

最近、5年目にして同じグループに後輩ができた。社会人なりたての、新人さんなのでいろいろ教えている。教えるときに気をつけることを書いていきます。
他の人が、どんな風に後輩と仕事をしているかも、できれば知りたいです。良ければコメントがほしいです。

みんな初めはできない

なんでこれぐらいできないんだろうって思っちゃうけど、誰でも最初はできないもの。
自分もそうだったし。イライラしないで長い目でみるのがよい。

抜かれる危険性

自分が頑張って教えてきた人と、ずっと一緒にやっていけるのかはわからない。
別の仕事にとられるかもしれない。そうなると頑張って育ててきた意味がない。他のところで能力を発揮してくれるのであれば、意味はあるけど。
それでも悲しい。悲しいがこれは仕方ない。それは考えずに進めたほうがいいだろう。

指示の曖昧さをなくす

新人さんには、曖昧な指示は良くない。先輩や上司の指示で良くないのは、クイズ形式なってしまうことだと思う。指示が曖昧すぎて、正解するまで答えを教えてくれないみたいなのは、やられるとつらい。多分、そういうのは指示する側の甘えだと思う。これぐらいわかってくれと投げやりになっているのかも。
でも、そういうのが合う人もいるだろう。それは人をみて判断するけど、あんまりそういう人はいないと思う。

指示の細かさの調整

最初一度ぐらいはどの程度わかってるかわからないので、同僚に依頼するぐらいのラフさで出してみる。そのあと途中経過覗いたり、一回目のレビューの時の成果物の様子をみてどの程度まで指示が必要か判断する。

例えば、「ここの文言わかりにくいから直して」と言って、直してきたのがわかってない感じの内容だと、「ここの文言をこう直して」という風に考えなくてもできるレベルまで落としこんだ指示を出す。それの狙いはこう直すんだとわかってもらうことにある。それを繰り返していくとそのうちパターンが見えてくるようになるだろうと思っている。
実践 -> 評価 -> 実践 -> 評価 の繰り返しをしているつもり。
あと、ポイントポイントではこれは、つまりこういうことだよっていうパターン自体も教える。能力が足りていなければ、本とか紹介する。

つまり、

1. 実践させる
2. 評価する
3. 一般化したルールを伝達する

この３つを繰り返す。

仕事の手順を明確に伝える

仕事は以下みたいな方法でやってもらっている。

1. 仕事を細かいタスク落としこむ
2. スケジューリングする
3. 実行する
4. 実績と予定を見比べて、スケジュールを修正する

進め方については、自分のやり方もあるだろうけど、基本的に

• 仕事の全容を把握
• どれぐらいで終わるか予定を立てる
• 実行してみて、実績から予定を調整
• 実績は記録しておいて、次の見積もりの参考にする。

っていうルーチンができるようになるまでは指示を出したい。
繰り返すと、ちょっとずつ精度が上がってくると思う。のでやってもらっている。
だいたい初めのうちは見積もってたりよりも2,3倍おおくの時間がかかったりする。
求められてる成果物の品質にたどり着く大変さとか、隠れタスクとか最初は読めないからね。

これは多分、これぐらいかかるよ。みたいなことはあんまり言わない。
そこはできるようになってほしい部分なので、考えてもらう。実績が答えを出してくれる。

やりすぎ？

どこまで考えさせるのか、難しい。
もしかしたらマイクロマネージメントしすぎかもしれない。
それに、これは僕のエゴなのかもしれない。

だけども、大事なことは伝えていきたいとも思っている。葛藤がある。
バランスをうまく取りたい。

報告はあんまりいらない

基本的に成果物は GitHub 上で管理してるから、とくに新人さんに「できたらみせて。」とか言わなくても、いつでも進捗とか方向性確認できてるので便利。( 生煮えプルリクエストしてもらってる )
終わらないと持ってこないとかあるあるなので、そういうの防げる。

僕は在宅、新人さんは会社

課長は別にいるので、なにかあった時はそっち相談してもらう。
Slack と GitHub で淡々とやり取りして、仕事進められて快適。
たまに出社してお喋りする。

レビューの細かさ

淡々と成果物をレビューする。レビューはあまり妥協していないので、やられている方はもしかしたら辛いかもしれない。
定期的に今のやり方でつらくないか本人に確認している。その結果でレビューの細かさを調整する。
辛い時にはつらいと言ってもらえる関係性を築いておく。

同じことを指摘する

なんどか同じ指摘をすることがある。つらいけど、頑張って同じように指摘してる。前も言ったでしょ的なことはあまり言わないようにしている。一度でできるようになったらすごい。でも面倒なので、一度指摘した時のコメントのURLを貼ったりもしている。

機械的に指摘したい

なるべく、自動的にチェックする仕組み(CIとか) を作りたい。機械的にできることは機械に任せたい。

できるようになるまでは、ちょっと窮屈だけどセルフチェックシートを作って、簡単な指摘は無いように、レビューのする前に自分でチェックしてからレビュー依頼かけてもらうようにもしてる。

ゲーミフィケーションしてもいいかもしれない。

なんでこの仕事が必要なのかきちんと説明する

最初のうちは、仕事をこなすことに夢中になってしまう。
手段ばかりに気を取られて、目的を見失う。そうするとなんでこんな内容なんだろう？っていう成果物が出て来る。こうふうに直して、という指摘する手間がまた一つ増えてしまう。
だから今やってる仕事がどういうことに繋がるのかわかったうえでやってもらう。
目的は手段を最適化させる。

例えばドキュメントを書く仕事とか

例えばドキュメントを書く仕事なんかがあった場合、当たり前なんだけど、読んで欲しい人がいるからドキュメントを書いてる。
だから、どんな人がどんな状況で読むのか想定しながら、ドキュメントを書く必要がある。
それを忘れて、ただドキュメントを書くと、ちぐはぐな内容になる。

時系列がおかしかったり、必要な情報がなかったり。

たまに僕も目的を伝え忘れて反省する時がある。そこは丁寧にやっていきたい。

一度にたくさん教えない

なにか「こうだよ」って教えるときは、一度にあまりたくさん教えないようにしている。
いっぺんにたくさん言われてもわからない。消化できたかなって思ったら新しいこと教える。

型を教える

書いてて気づいたのは、僕は型を教えているんだと思う。
型をうまくできるようになったら、それを基本に自分なりに発展させてほしいと思う。

あとこの会社じゃなくても、他のところでも活躍できるようなことをなるべく教えたい。

仕事の型

実践して実績を集める -> パターン化する -> 展開する

というのが僕の考える仕事の型。
まずは仕事を進める。たいだいの人はこの段階で終わってしまう。最初はこれだけでも精一杯だけど。
次に実績をふりかってみて、パターンがないか確認する。パターンを見つけたら、ドキュメントにしたり発表したりして、他の人(未来の自分)が使えるように記録を残す。

パターンを見つけるところが大変だと思う。ここは頭の良さがかかっていると思う。
あと実績をふりかえれるように記録を残しておくことも忘れない。
だから Slack とか GitHub 使って、自然と記録を残せるようにしている。

先輩と後輩の認知コストのちがい

極端に優秀な後輩でもないかぎり、お互いの関係性上認知コストの違いがでてくる。

後輩が認知コストを多く払うことの方が多いと思う。

それは後輩の方が先輩の意見を理解する機会が多いということ。逆に先輩は後輩からの意見について必死になって頭をつかうことは少ない。

先輩からすると、それは楽で気持ちがいいことなんだけど、それに乗じて好き勝手にはやらない。あくまでも真摯に対応する。

教えることでのメリット

ここまで書いてきたど、自分のメンタルもいろいろある。

あまりにも自分がわかりきってることを人に教えることは時間の無駄のように思える。
でも、なんとか自分にとってのメリットを絞り出したい。

ノウハウを言語化する練習

自分の頭の中にあるモノを言語化するのはなかなか難しい。
人に理解できるモデルに直さないといけないから。
一度モデルができあがると、いろんな場面ですぐに言語化できるで便利ではある。

ちゃんと教えるために勉強する

実際に教えようとすると、自分の曖昧さに気付く時がある。
こういう時には勉強する動機になる。

やれる人を増やす

ノウハウを自分だけに閉じ込めておくのは、スケールしない。
一人でやれることは少ない。一人でできないことをやるために、会社はある。
人に伝えて、やれる人を増やすのは大事なことだ。
そうすると、もしかすると、自分のやりたいことができるようになるかもしれない。