今年4月に新しいエンジニアの方が入社して約4ヶ月が過ぎた。新人の方は入社当時でHTML・CSS・JSの基礎知識はもっていたものの実務未経験だったので、他のエンジニアとも分担してベイジのコーディングを教えていった。今回はこの4ヶ月の進め方と振り返りをいくつかまとめたので、いまベイジを検討しているエンジニアの方やエンジニアの育て方で悩んでいる方の参考になればと思う。まず、おおまかな進め方は以下の通りだ。
- 入社～2ヶ月目：案件ではない課題のコーディング
- 2～3ヶ月目：ペアプロのような状態で案件の下層展開
- 3～4ヶ月目：一人で下層展開
フェーズ1：実案件とは関係のないコーディング課題
入社してからだいたい2ヶ月目くらいまでは案件とは関係のない課題を出して、コーディングしてもらった。やはりいきなり実案件のコーディングとなると納期の関係も出てくるし、心理的なハードルも高く、教える側としてもインプットしてもらいたいことが上手く伝わらないのも多々あるからだ。具体的に言うと、過去案件で作成済みのサイトを見てそれを再現してもらうというものだ。ソースコードは答えになってしまうので見ないようにしてもらう。また、この段階ではただ書きっぱなしにするのではなく、1日30分でもエンジニアの誰かが時間を取るようにしてフィードバックする。こうすることで徐々にベイジ流のコーディングをインプットしてもらう。
フェーズ2：ペアプロで実案件の下層展開
入社して2～3ヶ月目、課題が終わったらいよいよ実際の案件のコーディングに入る。とは言っても、いきなり「これやってください」と仕事を依頼するのではなくほとんどペアプログラミングで先輩エンジニアと二人一組のような状態で下層ページの展開をしていく。今回は私がベースコーディングをした案件で下層展開をお願いしたため、コードの内容が頭に入っていて教える側の負荷をだいぶ軽くすることができた。
フェーズ3：一人で下層展開
そして下層展開に慣れてきたらほとんど一人でページを展開していく（時期にして3ヶ月目以降）。ここは突然ある日を境に一人になるのではなく、徐々に質問やサポートをする機会が減ってきて自然と独り立ちするような感じだ。
「何ヶ月目～」といった時期を書いてはいるものの、ちゃんと理解していないのに次のフェーズに進んでも意味がなく、レベル感に合わせて早めたり遅めたり都度調整は必要だ。ここ4ヶ月、このやり方で運用してみて気づいたことがいくつかあったので、振り返りたい。
質問は基本すぐしてもらう
最初のうちは結構つきっきりで教えることになるので、正直な話、教える側の自分は仕事が思うように進まなくて悩んだ。でも毎日教えていくうちに質問をいっぱいしてもらった方が成長するのが早いことに気づいた。たしかに質問されることで答える時間を作らなければならないし、集中力も途切れてしまうから教える側のパフォーマンスは間違いなく落ちる。だが、トータルで見てみると新人エンジニアのスキルアップは早くなっていて、それは最終的に教える側のエンジニアにも還元され、チーム全体で見ると有益なはずだ。目先のことだけでなく長期的な目線で物事を考えるのが大事だということに気付かされた。そういうことで、質問はどんどんしてもらうことにした。
コードレビューは大事
これは私自身が入社したときにやってもらっていたことを思い返して気づいたのだが、新人エンジニアの制作物（ソースコード）には必ずフィードバックをすべきだ。これもまた、教える側は「質問に答える」よりも多くの時間を割く必要があるが、レビューをするとしないとでは成長スピードにかなり大きな差が出る。私が教えてもらう側のころは正直「うっとうしい」と思うくらいフィードバックをもらっていたが、改めて振り返るとそれがあってこそ今の自分があると思える。私も「ちょっとしつこい」くらいを指標にフィードバックしていけたらと思っている。
実はここまで教える体制が整ってきたのも最近のことで、このシステムは発展途上。より多くの先輩エンジニアが教える側にまわって、誰かに教える負荷が集中しないように分担するといった課題もまだまだ積み残っている。教える機会は今後も増えていくだろうから、その度に良い方法を探りつつ確立していきたいと思う。
