こんにちは！ エンジニアの井上こと @a_know です。GitHub では a-know という ID で活動しています。34歳、社会人11年目です。いつのまにやら、立派な中堅どころとなってしまいました。

先日、約2ヶ月に渡って行われた2016年度の新卒エンジニアの受け入れが終わり、全員が配属先となるプロダクト開発チームへと巣立って行きました。私はこの数ヶ月、今年度新卒エンジニアの受け入れ責任者として立ちまわっていたため、それぞれが配属先で活躍している様子を見て、今はまるで親鳥のようなきもちです。(\( ⁰⊖⁰)/) .｡oO(がんばるのよ...!)

今年は5人もの新入社員がフィードフォースエンジニアチームの仲間に加わってくれました。みんなとても優秀な若者ばかりで、嬉しく、頼もしい限りです。......ちなみに、彼らが入社する前の時点で、エンジニアチームは総勢 20人という規模でした。おわかりでしょうか、彼らの入社のインパクトの大きさが...。。

ということで今回は、「新卒受け入れに関する何かしらの知見を共有できれば」という思いも込めて、2016年度新卒エンジニアの受け入れの記録をこの技術ブログに残したいと思います。

※ フィードフォースにおける「新卒社員研修」は大まかに分けて、「前半：総合職＋エンジニア職での合同研修」と「後半：職種ごとに分かれての職種別研修」という2部構成で実施しました。
この記事では、特に「エンジニア職」における「後半：職種ごとに分かれての職種別研修」について、お伝えしたいと思います。

2016年度新卒入社の経緯

昨年の秋ごろでしょうか、「どうやら来年は5人も新卒が入ってくるようだ」との噂が私の耳に入ってきました。ここ3年のエンジニアチームへの新卒社員入社の実績は、

• 2013年度：2人
• 2014年度：1人
• 2015年度：0人

という状況だったこともあり、今まではその受け入れも「入社後すぐに配属先を決定（本配属）」「配属先での OJT 形式」、という形で実施していました。

そんななかでの、5人入社の情報。私は当初、いち社員としてしばらく様子を見ていたのですが、だんだんと「どうやらこのままいくと、2016年度も今までと同じような受け入れをすることになりそうだぞ」という雰囲気が漂ってきていました。

これについて、私は「このままじゃ絶対にヤバイ！」と直感的に思ったため、早々と「新卒エンジニア受け入れ責任者」に立候補しました。これは、最初こそ危機感が先に立ってのことでした。ですが「会社の未来を作ることになる新卒エンジニアの受け入れ」に責任を持って取り組めることはそうそう無いし、そのことにやりがいもすごく感じましたので、責任の重さも当然ありましたがどこかワクワクもしながらあれこれと考え始めました。
（ちなみに受入期間中の私の業務ですが、1日の業務時間のうちの5割 〜 7割を新卒受け入れ業務に充てていました。自分の開発チームでの仕事は、正直なところ、コードレビューの実施やスクラムマスターとしての立ち回りが主となっていました。が、それくらい集中してコミットができる体制はやはり必要だったと感じています）

まず考えたこと

立候補はしたものの、当時の私には特に具体的なアイデアがあるわけではありませんでした。
ただ、2014年度に唯一一人だけ入社したエンジニアの受け入れをしたのがたまたま私であったこともあり、それを通じて「こういうことをしてあげる必要があるんじゃないかなぁ」みたいなイメージのようなものも頭のなかにはありました。

それは、断片的ではありますが挙げてみると、下記のようなことでした。

• エンジニアチームの全員で受け入れる感じにしたかった
  • 今までのやり方だと、新卒エンジニアに関わることのできる人が少なかった
• 配属に関して、配属される新卒エンジニアにも主体的になってほしいなと思った
  • やっぱり自分から「このチームに行きたい！」と考えるほうが、よりモチベーションに繋がる
• 技術についてのレクチャーは、その時点の私の中になんとなくある、「Rails での Web アプリケーション開発のよさげな勉強方法」をベースにするしかないかなと思った
  • 自分自身も入社から 2年たち、Rails での Web アプリケーション開発を学ぶときの「歩きやすいルート」みたいなものが見えてきていた
  • とはいえ 1 から 10 まで教えるのは違う気もする
  • そもそも「教える」というのも違う気がする
• 今回の受け入れを通じて、既存社員にも刺激を与えたい（受けたい）なと思った

これらをうまくカバーできるような内容にすれば、その過程で大変なことはいろいろあっても最終的には「やってよかった」とみんなが思えるものになりそうだなと、比較的楽観的に考えていました。

やろうと決めたこと

上記を踏まえ、以下の様なことをやってみよう、と考えました。

1. 「指導先輩」という仕組みの導入
2. ローテーション配属の実施・研修の最後に本配属面談を実施
3. 技術研修（座学・実習）の実施

それぞれについて、書いてみます。

「指導先輩」という仕組みの導入

主に「エンジニア全員で受け入れる感じにしたかった」という点についての打ち手になります。
今までは、「新人受け入れというのはごく一部の人（配属先の受け入れ担当者）が考えればいい」みたいなところがあったと思っていて、その状態から抜け出したいと思っていました。なにより「今後も同程度の規模で新卒採用を継続していく」というのが会社の方針でもあったので、それも踏まえて、「新卒社員は会社全体で受け入れるもの」という文化というか雰囲気を醸造したい（しなければ）という思いがありました。

「指導先輩」は、「若手で」「数年後にはフィードフォースを背負って立つような人になってほしい（もらわないと困る）」ような人を、CTO とも相談の上、指名させてもらいました。一人の新卒社員に対して一人の先輩を指名し、計5名です。「人に何かを教える」には、その人自身も同等以上に知っていなければ教えられないものです。そんな動きを求められる「指導先輩」を経験することで、その先輩になる側もきっと多くのことを学べるとも考えました。

指導先輩には、指導後輩とのふりかえり（KPT）も毎日実施してもらました。それにより日々得た学びを定着させるお手伝いをすると同時に、毎日何かしらの改善を積み重ねていけるような働きかけもお願いしました。

ローテーション配属の実施・研修の最後に本配属面談を実施

「配属に関して、新卒エンジニアにも主体的になってほしい」ということに関する打ち手です。

「ローテーション配属」、つまり、フィードフォース内の5つのプロダクトチームに、週替りで仮配属してもらう取り組みです。

なぜこのような取り組みをすることにしたかですが、「配属に関して、新卒エンジニアにも主体的になってほしい」という思いは上述の通りありました。一方で、

• 各プロダクトチームがどんなチーム（開発方法・利用ツール・雰囲気 etc.）か
• 各チームに対して、自分がどう思うか（このチームに行きたい！ or このチームはやだな... etc.）
• これらを勘案して、自分はどのプロダクトチームに行きたいのか

......なんて、入社したばかりの新卒社員にはわからないはず。だからこその、この取組でした。

ローテーション配属を実施することで各チームの状況と雰囲気を自分の目と体で知り、さらに研修の最後に本配属面談を行うことで、新卒エンジニア側の気持ち・希望も考慮できるように心がけてみました。
（もちろん「その希望がどれくらい通るか」は、そのときのチーム状況や各人の適正なども考慮することになるとは思っていたし、そのことは本人達にも何度となく伝えました。が、配属決定時に「なぜこの配属先か」「このチームでどんな活躍を期待するか」といったメッセージは、CTO からしっかりと伝えてもらうようにもしました）

ローテーション配属による良い影響の狙いは、新卒エンジニア側についてだけではありません。ローテーション配属先の受け入れに関しては、基本的に「指導先輩」に主導してもらうにしても、ある程度は他の社員の助けを借りる瞬間が絶対に出てくるだろうと思っていました。
それによって、「エンジニア全員で受け入れる感じにしたかった」の範囲を広げられるだろう、とも考えていました。基本的に全てのエンジニアが業務において、新卒エンジニアと自然と関わるような仕組みにしたかったので、ローテーション配属という仕組みは打って付けだろうと思いました。

一方で、この期間中は各チームからのアウトプットのスピードが鈍化するのも目に見えていました。そのためその点については、予め私が CTO などに直談判し、許可を得ておきました。
（新卒社員を受け入れるっていうことはそれぐらい大変なことなんだということを、ひたすら力説しました）

技術研修（座学・実習）の実施

私自身がフィードフォースに入社してからこれまでに取り組んだ Rails 関連の自学習教材（Ruby, Rails 未経験だったため...）のうちのひとつに、「パーフェクト Ruby on Rails」がありました。
この書籍は自分としてもとてもわかりやすいと感じると同時に、現在のフィードフォースでの開発業務に対するカバー範囲の広さ（Web アプリケーションの基礎から Rails アプリの構築、Infrastructure as Code まで）もあり、これはとても良い教材になると思っていました。

一方で、2014年度の新卒エンジニアと接してきたなかで「"Rails がよしなにやってくれているところ" についての認識不足」と「それによるベテランエンジニアとの齟齬の発生」は無視できないくらいにはあるな、とも感じていました。なので、Rails による Web アプリケーション構築技術の習得も大事ですが、その前提となる知識を埋めることこそ研修で実施すべきと考えました。

上記を踏まえ、以下の3点の教材を用いて座学と実習を組み合わせて約2ヶ月間取り組むことで、Web アプリケーション開発の土台を作るところから試みました。

• ゼロから始めるデータベース操作 を用いた DB 基礎
• Web を支える技術を用いた Web 基礎
• パーフェクト Ruby on Rails を用いた Rails 開発基礎・Infrastructure as Code 基礎（Chef / serverspec）

これらの本をベースにしつつ、「こういう順番で進めたほうがよりタメになるはず」という考えをベースにカリキュラムも作成しました。
例えば「パーフェクト Ruby on Rails」では特別 TDD をベースとした開発を徹底して書かれているわけではありませんでしたが、弊社での開発は基本的に TDD であるため、そのあたりをアレンジしたりしました。

このカリキュラムをもとにレクチャーする講師は私だったわけですが、終始心がけていたことがあり、それが「できるだけ教えないこと」でした。
その代わり、「本にはこう書いてあるけど、なんでそうなるの？（なると思う？）」「なんでこの1行でこの動きをするの？」「このコードはどういう挙動を期待して書いてるの？」など、様々な角度から疑問を投げかけまくりました。

その結果としてすぐに回答が返ってくるものもあれば、そこで初めて「自分はそれについてよくわかっていなかった」ことに気づき、あれこれ調べてくれたりした...ということもありました。当人たちは大変だったと思いますが、「講師が教える」よりもこの方法の方がきっと何倍も、身についたのではないかと思っています。

今後も、「ここ、井上さんから突っ込まれそうだな」という発想からスタートしてもまずは構わない ので、目にするあれこれに疑問・興味を持って欲しいなと思っています。

工夫したこと

以上のようなことをやろうと決め、実際に進めていったのですが、いくつかの工夫も心がけました。
そのうちの一部をご紹介します。

受け入れに関して考えていることは全て、とにかく Qiita:Team にアウトプットしながら準備をした

「新卒エンジニアの受け入れ研修」なんてもう、フィードフォース史上初めての試みだった上に、井上のおぼろげなイメージしか拠り所がありませんでした。そのため、「それはマズいんじゃないの？」みたいな意見は常に欲していました。

なので、「こうしようと思う」というのは思いついた時点でまず Qiita:Team に書いて公開し、いつでもフィードバックを受けられる状態を保ちながら準備を進めていました。

こうしていたことで、他の社員にもなんとなく「こういうことをやるんだよね」っていう最低限のイメージの共有は行いながら進められていたように感じています。

研修の進め方は考えるが、それに固執しすぎないようにした

上述の通り、カリキュラムまで作成して研修に臨みました。ですが「新卒エンジニアが理解できたところ・できなかったところとその理由」などは、私の目の前でどんどんと移り変わっていきました。そんななかで、予め準備したカリキュラム通り進めることに意味は無いとも思っていました。
このような状況に、「なんだ、これ、実際の開発現場と似てるじゃん！」と思えたため、

• 研修途中に 1on1 を実施し「もっとこういうふうに学びたい」という意見を吸い上げたり
• 「いまの進め方のいいところ・イマイチだと思うところ」「それらを踏まえて、こうしたらいいのではと思うところ」の意見交換を付箋を使用して実施したり
  • 「今回は研修の進め方だったけど、開発の進め方だって迷ったらこういう風に話しあえばいいし、そもそも "アジャイル" ってきっとこういうこと」という話もできた

といった工夫を合間合間で実施しました。

↑意見交換のようす。

その結果として、私だけでは思いつかなかったような、それでいて今年の新卒エンジニアにピッタリな進め方を決められた、と思っています。
また「研修は必ずしも与えられるだけのものじゃなく、自分たちでも作っていけるものなんだ」ということを（おそらく来年の受け入れ・研修を考えていくことになる）今年の新卒エンジニア自身に思ってもらえたのも、大きな収穫だと考えています。

やってみてどうだったか？

研修カリキュラムを全て終えた翌営業日、研修のふりかえりとして下記の2つの取り組みを行いました。

• ローテーション配属についてのふりかえりを、YWT 形式で
  • 指導先輩5名＋新卒エンジニア 5名＋井上
• 技術研修についてのふりかえりを、YWT 形式で
  • 新卒エンジニア 5名＋井上

YWT とは「やったこと」「わかったこと」「つぎにやること」の組み合わせのことで、以前このブログでも題材にしています → 中長期のふりかえりとしてYWT(やった,わかった,つぎにやる)を試してみました

ここでは、その場で挙がった事柄の一部をご紹介します。きっと、来年度の受け入れではこれらの気付きが十分反映された受け入れをすることができるだろうと思っています。

ローテーション配属について

• 指導先輩のみならず、配属先のエンジニア全員で協力できた
• 各チームがどんな状況・雰囲気なのかがよくわかった
  • とはいえ、「ローテーション配属というやり方しかないか」というと、もっといいやり方はありそうな気もする！
• 配属先での環境構築作業が、意外と鬼門！
• 1日のうち、半日が技術研修・のこり半日でローテーション配属、という進め方について
  • 1日をメリハリ付けて過ごすことができた一方、
  • まとまった仕事を依頼しにくいなどの弊害もあった！

技術研修について

• Rails は得意な方だったけど、井上からのツッコミでより深いところまで知ることができた
• 「パーフェクト Ruby on Rails」も良かったけど、来年は「Rails チュートリアル」でもいいかも！
• 技術研修の講師役は日々の予習が大変！
• エディタやシェル周りについても色々教えて欲しかった！

その他・進め方などについて

• 指導先輩同士の横軸での情報共有が難しかった
• 研修として何をやるかを、研修を受ける自分たちで考えることができてとても良かった
  • 講師側としても、ともすると「より意味のある研修にしなくては」と背負い込みがちだけど、その思い込みをまず外すのも大事
• 技術研修での習得状況についての共有が、ローテーション配属先と満足に行えていなかった

まとめ

2016年度の新卒エンジニアの、主に技術的な面での受け入れについて、実際にやったことをまとめて書かせて頂きました。
取り組みを考えるにあたっては、昨年末にペパボさんで開催された「師弟登壇」というイベントの資料を大変参考にさせて頂きました。ありがとうございました！
この記録自体は「師弟登壇」と関連はないのですが、来年度以降、同じように新卒エンジニアを（大勢を・初めて）受け入れるといった会社・チームの何かしらの参考になれば幸いです。