新卒エンジニア研修の取り組みやカリキュラム
昨年夏頃から会社で開発部の研修担当になり、カリキュラムの全面見直し、開発研修の位置付けや運用方法などを考え、そして実践を今現在やっています。最近、開発研修やWEBエンジニアの教育についての記事が増えてきたなと感じたので私のブログでも書こうと思います。
背景
私の会社では新卒エンジニアが5年ぶりに入社しました。(ちなみに5年前の新卒エンジニアが私です。
つまり5年間、新卒エンジニアの開発研修をしてなかった事になります。
開発研修を担当するにあたり、まずは5年前の開発研修を確認しました。
- サーバを一からセットアップ → AWSなどのクラウドがある今必要性を感じない
- サーバサイド(Apache+PHP+MySQL)がメイン → サーバサイドだけでは今は通用しない
- フロントエンドはHTMLで簡単なフォームを作るくらい → 今はCSS、JSは触れるくらいじゃないと
- カリキュラムは社内Wikiで管理 → Markdown使いたいし課題などが管理しづらい
ということで案の定、現在のWEBエンジニアとしては物足りない、そしてメンテナンス性が低いものでした。
また、最近感じている事として以下の要素もWEBエンジニアで重要度が増しています。
- 周りとのコミュニケーション
- コスト・進捗管理
- 要は技術以外の部分
アジャイルの普及もあり、単に設計・実装するだけではWEBエンジニアとしてはもう通用しないため、ここも開発研修に取り入れる必要がありました。
そのため、開発研修の全面的な改修をしていきました。
プロジェクトとのニーズの違いと開発研修の目的
改修にあたり、一番考えたのが開発研修後のプロジェクトアサイン。いざ新卒エンジニアをプロジェクトにアサインすると、よく担当のWEBエンジニアからこういう声を聞きます。
- 必要な事を全然教えられてないじゃん
- 技術の水準が低すぎる
- プロジェクトやっても成長してくれないよ
- 教えるのコストかかるんだけど etc
開発研修を終了しただけではまだ一人前のWEBエンジニアとは言えないため、こういう声がでるのは仕方のない事だと感じてます。(高望みしすぎだし面倒見てくれよとも思いますが)
そのため、私は開発研修が終わった段階では以下のWEBエンジニアになっている事を目的としました。
- 業務や技術領域の変化に対応出来る
- 基本的な所を幅広く底上げすることで変化に対応させる
- 成長段階で特定の技術に拘らないようにする
- 主体的に継続的に技術を取得出来る
- 分からなかったら自分で調べて成長させる
- 新しい技術を取り入れる姿勢を身に付けて成長させる
- 技術以外(見積、コミュニケーションなど)も一定の水準に満たす
- 自分でタスクやコストを管理する事で自発性を高める
- プロジェクトで自ら他職種とコミュニケーションが出来るようにする
この目的はid:ryopekoさんがデブサミ2014で発表した新卒エンジニア研修の目的そのままです。自走するエンジニアというのは名言だと思いました。
私が思うに、どう頑張っても開発研修だけでは即戦力になるWEBエンジニアを育てるのは無理です。むしろプロジェクトを通して成長する方が重要だと思います。そのため、開発研修ではプロジェクトで自発的に成長するための土台作りをし、プロジェクトアサイン後にさらに成長させようと考えました。
また、開発研修が終わった後は基本的に研修担当のプロジェクトにアサインするようにしました。要はOJTまで含めて開発研修という形です。実装フロー、タスク・コスト管理、コミュニケーションの仕方などは、開発研修より他職種の方達と絡めるプロジェクトで経験した方が分かり易く、また新卒エンジニアをずっと見た人がOJTをやった方が何かと互いにやりやすいかなと思ったからです。
カリキュラムの改修
カリキュラムはほぼ一から改修しました。詳細はGitHubにて公開しています。
私が改修したポイントとしては以下です。
- フロントエンド、サーバサイドを幅広くやらす
- 新卒エンジニアに全体的な基礎知識を身に付けさせる
- 新卒エンジニアに興味のある分野を見つけさせる
- 課題図書を要所要所で読ませる
- 内容によっては下手に社内で教えるより専門家の本に任せた方が分かり易い
- 新卒エンジニアに技術書を読む文化を体験してもらう
- 研修担当のコスト削減
- 課題毎に工数を見積もってもらう
- 新卒エンジニアにコスト意識を持ってもらう
- 研修担当は速く課題を終わらせる事が目的ではないときちんとフォローする
- 課題やソースなど全てGitHubにて管理
- Markdownで書き易い
- どこからでも閲覧、編集が可能
- 研修の進捗が管理し易い
新卒エンジニア視点から見ると、なるべく幅広く基礎知識を身に付けさせ、また課題図書や工数見積など、WEBエンジニアの文化を体験して自発的に成長できる土台を作るようにしてみました。
カリキュラムや課題に関しては全てGitHubで管理するようにしました。研修担当からすると、普段使い慣れているGitHubの方がやりやすいですし、研修担当以外のWEBエンジニアもメンテナンスしやすく、コストも抑えられました。
開発研修の進め方
開発研修の進め方は以下の流れでやりました。
■事前準備(研修担当)
- 新卒エンジニア1人毎にGitHubのアカウントと研修用のGitHubリポジトリを作成
- 課題は上記リポジトリのIssueで全て管理
- Chatworkで開発研修用チャットを作成
- メンバーは必要最低限にする
- 関係ないメンバーを入れると余計なレビューやコメントが入って課題のゴールがぶれる
■開発研修
- 課題着手前に工数を時間単位で見積(新卒エンジニア)
- 課題を進める(新卒エンジニア)
- 調査系、または実装系でGitを学ぶ前まではIssueのコメント
- Gitを学んだ後の実装系はPRを送る
- 課題が終わったらChatworkで研修担当にTo(新卒エンジニア)
- レビューをしFBがあればコメント、問題なければクローズ or マージ(研修担当)
- レビュー中は次の課題をやり、前課題のFBがあればそちらを後でやる(新卒エンジニア)
- 基本的にはMarkdownで全て書いてもらう(新卒エンジニア)
実際やってみて、全てGitHubでやって良かったなととても感じました。
- レビューがとてもしやすい
- コードの差分
- Markdownの見やすさ
- 実際のプロジェクトと同じように出来る
- どこからでも確認、レビューが出来る
- 開発研修を通して新卒エンジニアがGit、GitHub、ブランチ運用に慣れる
- contributionsなどで状況がデータ・グラフ化されて把握し易い
また、研修用のGitHubリポジトリはあえてpublicにしました。この背景として、GitHubではたまにPRやIssueでリテラシーの低いコメントやネタ画像をちょくちょく見かけます(OpenTouryoProjectのこのPRとかはまさにリテラシーの低い例です)。人によってはこれは不快に感じますし、仕事としてやる以上無駄なコストです。恥ずかしくないWEBエンジニアになるためにも、リテラシーを意識させるためにあえてpublicにし、そこに関してもきちんと学ばさせる事が出来ました。
ただ、publicにしているため公開してはいけない情報(サーバ情報、社内特有の情報など)は書かないように意識させるのと、研修担当も入念にチェックする必要があります。そこはちょっと想定外のコストでしたが、リテラシーの意識を高めさせれた事を考えれば安いコストかなと思います。
工数見積のデータ化
今回、工数見積を新卒エンジニアにやってもらいましたが、その見積時間と実稼働時間をデータ化しました。このデータはGoogleドライブのスプレッドシートで管理し、研修担当が閲覧、編集出来るようにしています。
データ化すると現状の進み具合や成長具合等が分かり易くなりますし、この後に説明する振り返りレビューでも資料として貴重なものなりました。
振り返りレビュー
開発研修中、振り返りレビューというプチ面談のようなものを設けました。これもid:ryopekoさんの話を聞いてとても良さそうと思ったため取り入れてみました。
■概要
- 週1で開催
- 1人30分〜1時間
- 研修担当と1on1で対面で行う
- ミーティングルームなど周りに人がいない状況でやる
- 研修担当が複数人いる場合は交代制
- 振り返りレビューの内容もデータ化して研修担当内で共有
- 今回はRedmineのチケットで管理
- これも閲覧出来るメンバーは必要最低限に
- 振り返りレビュー後は研修担当を集めてレビュー内容を共有
- 開発研修の理解度、改善点などを共有してどう開発研修を進めるか考える
■振り返りレビューの内容
- 今週の開発研修の振り返り
- 課題のIssue、PRを1個1個確認
- ちゃんと理解しているか「この単語の意味分かる?」など聞いて確認
- こういったコマンドもある、load averageの適正値など、現場で学んだ知識を共有
- 工数見積のデータを見せてきちんと出来ていると自信を付けさせる
- 研修担当から見た新卒エンジニアの良かった点
- どんなに細かい事でも良い点を共有
- 開発研修以外の事でも拾う(遅刻していない、元気がよいなど
- 良い所はどんどん伸びるよう工夫する
- 研修担当から見た新卒エンジニアの改善点
- これも細かい事でも改善点を共有(細か過ぎると逆にうざいので適度に
- 新卒エンジニアが納得してないようであればちゃんとなぜ改善しなければいけないのか説明
- 言葉だけではなくデータ化したものを見せる
- 言葉で説明するにも具体例などを引き合いに出して説明する
- 漠然とした説明はほぼ納得しないので(当たり前)ちゃんと研修担当は考える
- 一気に改善させずゆっくり長い目で改善
- 今までの振り返りレビューの改善点の見直し
- 改善出来たかどうか確認する
- 改善出来なかった場合は理由を聞いてみる
- 改善されるまで何度も振り返って徐々に良くする
- 新卒エンジニアからの今週の良かった事、質問、疑問点など
- どういった所が成長し、どういった所が悪かったか自分で考えさせフォローする
- 開発研修以外の不安な事や疑問な事も拾ってあげる
- 開発研修をもっとこうした方がよいなどの研修担当への逆レビューもしてもらう
- 雑談
- 会社慣れた?とか1人暮らし大丈夫?みたいな
- 雑談の中でも色々聞けてこういう子なんだなーと理解しやすくなる
- 研修担当は雑談を入れる事で場を和ませる
この振り返りレビューも実践してとても良かったです。
- 振り返る事で新卒エンジニアがきちんと理解しているかの確認が出来る
- 新卒エンジニア自身の復習にもなる
- 良い点をや改善点を明確にする事で新卒エンジニアの成長のきっかけになる
- 新卒エンジニアから開発研修の改善点をタイムリーに聞けるので開発研修を改善し易い
- 開発研修以外の事も定期的に相談出来る環境が作れた
新卒エンジニアは開発研修の進み具合や理解度、自分が本当にWEBエンジニアとしてやっていけるかなど心配事が多く、また社会人生活もなかなか慣れないなど最初は不安な事が多いです。そういった事を少しずつ解決していき、そこから成長するきっかけを作る意味ではこの振り返りレビューはとても価値のあるものでした。1on1で気軽に話せる環境はとても重要です。
改善点・反省点
順調かと思った開発研修ですが、もちろん改善・反省すべき点がありました。
- 基本研修が終わってから開発研修をすべき
- ここで言う基本研修はビジネスマナーや全職種で必要な事を教える研修の事
- 今回の研修は午前:基本研修、午後:開発研修という形でいつの間にか決められてしまった
- 基本研修でまだ学んでない事(工数見積、ツール等)を開発研修側で教えるケースが多々あった
- 新卒エンジニアからしても同じ事を2度学ぶ無駄が発生した
- 開発研修だけではなく会社全体の研修も把握する事でより良い研修になるはず
- Git、GitHubを早い段階で学ばせるべき
- 想定よりも研修担当のコストがかかる
- 当初は最大でも1日の1/3くらいのコストになると想定
- 実際は工数管理、振り返りレビューなどもあり1/3以上かかっていた
- 新卒エンジニアの質問になるべくタイムリーに答えたいため、自分のメインプロジェクトに集中しにくい状況だった
- 開発研修中は研修担当はプロジェクトから外れる、もしくはレビュワーを増やす等するべき
- 社員との交流の機会が少なかった
- 開発研修中は研修担当以外のWEBエンジニアは研修内容を見ないよう制限した
- メンバーが多くなると余計なレビューやコメントなどで開発研修がぶれる
- ただそれによって新卒エンジニアと他WEBエンジニアの交流機会を減らしてしまった
- 新卒エンジニアの休憩時間が社員と合わない
- 基本研修で時間割が決まっていた事もあり、休憩時間を固定せざるえなかった
- 定期的に新卒含めたランチ会など開いて交流の場を設ける事で機会を増やした
- 開発研修中は研修担当以外のWEBエンジニアは研修内容を見ないよう制限した
社員との交流に関しては振り返りレビューで新卒エンジニアからもあがりましたし、私もどうしようかなーと悩んでいた事でした。早くキャッチアップし改善すればもっと楽しい感じに出来たかなと一番反省しています。そういうキャッチアップをする機会としても振り返りレビューと会社・職種間との調整はするべきですね。
まとめ
開発研修の準備にはそれなりの期間を費やしてしまいましたが、私自身は上手く改善でき開発研修の土台が少なくとも出来たと手応えを感じています。また、新卒エンジニアや研修担当からもGitHubのコードレビューや振り返りレビューでの会話などが楽しいと聞けたので良い開発研修になったかなと思います。(本音かどうかは分からないですがw
もし開発研修を行う機会があれば、以下の3つを取り入れる事をオススメします。やりやすさ、楽しさが新卒エンジニア、研修担当共々とても良くなると思います。
- GitHubでやる
- データ化出来る事はデータ化する
- 振り返りレビューを取り入れる
この記事が研修担当の方々の参考になれれば幸いです。