見出し画像

新人エンジニアさんにプログラミングを教えるときのNGとGOOD

こちらはTECH PLAY女子部 Advent Calendar 20189日目の記事です。

新人エンジニア留美さんが私のチームにジョインして、私がトレーナーとしてプログラミングを教えることになりました。
そういうときにやらないように気を付けたいことと、やってみようと思っていることをまとめます。

全ての判断基準は、留美さんがいかに早く自己解決力を身につけて、プログラミングの楽しさを知り、その手でシステム・アプリをもりもり作って、チームの戦力となってくれるかです(そして私をラクにしてくれるか)。

やってはいけないこと

NG1. エラーを未然に防ぐ

「ああ、そう書いちゃうとシンタックスエラー or ビルドエラー or SQLが通らないよ」と思っても、なるべく途中で修正しないで進めます。
エラーにならないやり方を教えるより、エラーを起こしてエラーメッセージを読み解く力を身に着けるほうが自立のためには役に立ちます。と、同時にエラーへの過剰な恐怖心を抱かないようにしたいためです。エラーは友達(と思えばつらくない)。

NG2. 「ちなみに」すぎる

技術者あるあるですが、私は説明しているうちに「ちなみにね」と言って話がついついマニアックな方向に広がりすぎてしまうことがあります。なので、「ちなみに」は1回までとします。でないと終わらん。
もし留美さんが、まれにいるちなみに好きの新人さんだったら、別の機会を設けて思いっきりちなみます。

NG3. 好きって言わない

トレーニング中に、留美さんが「こんなこと聞いたらバカだと思われるんじゃないか」「忙しそうなのに手間をかけさせては申し訳ないな」と思ってしまったら私の負けです。
「留美さんから質問もらうのってわくわくする」「あなたとトレーニングする時間は私も楽しい」という気持ちを、留美さんにもチームメンバーにもちゃんと言葉で表現しましょう。好きっていってくれなきゃわかんない。

NG4. 正解を求める

教えなきゃとおもうあまり「どうすればいいと思いますか」「A,B答えはどっち」と試験官のような問いかけをしないようにします。正解を聞かれてばっかりだと正解を見つけるため、留美さんは私の顔色を窺って答えを出そうとしてしまうでしょう。そんな能力はいらん。

そんなつもりはなくても「間違えてはいけない」という恐怖心を植え付けてしまうと、この先よいことはありません。

NG5. 予定をキャンセルする

緊急でない限り「今日は自分の仕事を進めたいから」という理由でトレーニングの時間をキャンセルしないようにします。
それは留美さんのトレーニングがその業務より優先度が低いと示すことになり、そんな価値観が定着すると、人を育てられるチームにはならないでしょう。
もし「いやそれ当たり前でしょ。自分が新人の時もそうだったし」と思ってしまったら、私でその悪しき価値観を断ち切ります。人の成長を支援することを良しとするトレーニングを受けた留美さんは、次に自分がトレイナーになったときに、当たり前のように後輩を大切に育ててくれるでしょう。

それに、人に教えることほど自分を成長させてくれる早道はないですよね。OJTは人のためならず。

NG6. 予定を延長する

キャンセルもそうですが、事前に決めた時間を延長しないでスパッと終わることも大事です。
新たなことを教わる留美さんはきっと私の数倍集中力を使います。はっきり言って疲れます。
絶対1時間で終わるとわかっているから集中できるんです。なので、時間が来たら名残り惜しくても今日はトレーニング終了です。

これは時間管理の大切さを伝えるよいきっかけにもなります。全ての人にとって時間は有限のリソースです。

やってみるといいこと

GOOD1. ペアプロ

ここで大事なのは成果物ではなく、私ががいつも何気なくやっている、IDEの使い方、ショートカットの使い方、どんなキーワードでググるか、といったノウハウです。最初のうちって、条件付きブレークポイントが設定できるなんてことも目からうろこだったりします。

できればこれをチームメンバー一人ずつとやって、個々のノウハウを留美さんを介してまとめちゃえるといいなあ。そしてそれを私に教えてほしい。

GOOD2. 一回全部消す

最初の課題となるプログラムが完成したら、一回全部消して留美さんに最初から作り直してもらいましょう。
記憶の定着の意味もありますが、一から全部自分で作ることでより深い達成感が得られると思うのです。

GOOD3. 早めにプロダクトへのコミット&リリースの機会を設ける

まだ業務としてユーザーにシステムを提供した経験のない留美さんには、小さなことでいいいので、早めに自分が直接書いた機能をユーザーに提供する機会をつくります。そしてユーザーからのフィードバックをもらいましょう。私も自分が最初にリリースしたものって今でも覚えています。
最初にOSSにコントリビュートするドキドキ感に似ていると思います。

同時にチームの開発プロセスを学ぶ機会にもなります。

GOOD4. キリの悪いとことで終わる

定期的にやるトレーニングなら、あえてキリの悪いところで終わらせます。
例えばコンパイルエラーで終わるとか。そうすることで、次回のトレーニングの最初の5分の立ち上がりが早くなります。何からすればいいのかが明らかなので。

GOOD5. 不運の輪を体験してみる

不運の輪とはSRE(Site Reliability Engineering)用語で「過去のインシデントをロールプレイングで追体験する」というトレーニングです。
人間必ずどこかで大きな障害にぶつかります。そのときにあたふたしないで対応できるよう、トレーニングとして障害とそのリカバリを体験してみます。
例えば、チームのテストデータベースで、以下のSQLを実行しようとして

DELETE
FROM
    Users
WHERE
    UserNo = 1234

うっかりWHERE文の前までをコピペミスした体で実行してみる、とか。

もちろん復旧の手立ては用意しておいてください。

GOOD6. TECH PLAY女子部のもくもく会に誘ってあげる

チームに入りたての留美さんから見ると、チームのメンバーはみんな「超できる人」ばっかりです(実際どうかはともかく)。
場合によっては必要以上に自分ができない気がして焦ってしまうかもしれません。
そんなときにもくもく会に来て、同じようなチャレンジをしている同志がいることを確認できるのは思った以上に励みになります。

ぜひ連れてきてあげてください。


この記事が気に入ったらサポートをしてみませんか?