くふうカンパニーAdvent Calendar 2019の8日目！
こんにちは、くふうカンパニーの株式会社みんなのウェディングでエンジニアをしている@Hanachanmです。
新卒です！
5月からエンジニア研修が始まり、早くも7ヶ月が経ちました。
「えっ、７ヶ月も研修って長くない？何をしているの？」と思う方もいるかも知れませんね。
2019年度新卒エンジニア研修の様子は、くふうカンパニーAdvent Calendar 2019の7日目の記事、2019年新卒エンジニア研修もそろそろ終盤です。そして2020年へをご覧ください。
簡単に研修について振り返っていきたいと思います。
研修の構成
自ら課題を発見して学べる、Railsを利用してウェブアプリケーションを正しく作れるようになるため、以下のような構成で研修が行われています。
- 課題図書（入社前4冊、入社後9冊）
- 全体研修（4月）
- RailsTutorialの写経とSQLドリル（5月）
- 座学基礎編（6月）
- パイロットプロジェクト（7月）
- 座学応用編（8月）
- OJT第1弾（9月〜）👈今ここ
より深い理解・知識の定着を促すためにインプット・アウトプットを交互に行うよう設計されています。
5月のわたし
私がプログラミングを始めたのは大学3年生の頃。周りからは「エンジニアになるって本当？大丈夫？」と心配されるくらいに経験・知識も乏しかったです。
入社前の課題図書としてプロを目指す人のためのRuby入門やRuby on Rails ガイドで勉強してはいたものの、実はRuby・Railsの機能の区別もできていなかったんですよね。
研修についていけるのか...という不安に対抗した4月最後の日報がこちら↓
まず、分からないことを認めることが第一歩と自分に言い聞かせ、研修に臨みました
座学で意識したこと
先輩エンジニアが講師となり講義形式の研修が行われました。
その時に言われたのが、「分かったら反応してください。分からなかったら分からないという反応をしてください。何か反応を示してくださいね。」ということ。
当たり前のように思えますが、これが意外と難しかったです。
講義中は純粋に分かった・分からなかっただけではなく、「一旦頭を整理したいけど聞いておかないと分からなくなるよなぁ」とか「メモが追いつかないぞ」という状態になります。そして大抵はこういう時、自分だけだしな..止まってとか言えないし..いけてる風を装おうという状態に陥ります。
同期も同じ状態に陥ったことがあるそう。。。しかも同じタイミングで。
実は自分が困っているとき、他の誰かも困っている時があると気付いた19卒メンバーは、遠慮せずにもっと質問したり・止まって欲しいことを伝えたり、自分の状態を伝えるようにしよう！となりました。
そうすることで講義の中での理解度が増し、受け身の研修ではなくなったように思います。
私たちが来年講師側になった際にも、コミュニケーションの1つとして自分の状態を伝えてもらう事を意識していきたいと思いました。
動くだけじゃダメ
パイロットプロジェクトやOJTでは Ruby on Rails を用いて開発を行います。
開発は、機能ごとにプルリクエストを作成して、19卒の誰か、かつ、技術開発部マネージャーからapproveをもらえたら、masterにマージするという流れで行います。
approveまでにはいくつかの壁があります。
解析ツール
ひとはひとにしかわからない問題に注力できるよう、解析ツールによる機械的なレビューが取り入れられています。
初めの頃は指摘がめちゃくちゃ多くて、直すのにも時間がかかっていました。
だけど自然と指摘も減り、保守しやすいクリーンなコードを書けるようになっているのかなと思っています。
1人での開発とは違い、様々な人が触るコードだからこそルールを決めて、人によって書き方がバラバラで汚いということがないようにするのも大事なんですよね。
自動テスト
みんなのウェディングでは自動テストを大事にしていて、カバレッジ90％未満はマージがブロックされています。
故に、レビューにはテストに関する内容も多くなります。
システムテストを書けばガバレッジは上がるけど、それだけだとダメなんですよね。
ユニットテストでカバーできるのでは？を考えることも必要だし、抜け漏れのない必要最小限のテストか？をチェックする必要もあります。
研修中、「自動テストの考えがなってない！」という指摘をいただいたことを思い出します..
今でもテストの書き方に悩む時もあるし、時間がかかる時もありますが、意味のあるテストを書いていれば自信を持ってリリースしたり、リファクタリングすることができます。
趣味で作っているアプリではなく、サービスの品質を保障しなければならないものだからこそ、自動テストが大事になってくるんですよね。そして将来の自分たちのためにも。
設計に関するレビュー
CIも通ったし、テストも通った。期待した動きもしてくれているから大丈夫だろう！とレビューを依頼しても通らない。ということが多々起きました。
それはもっといい設計ができそう..みたいな内容のレビューがある時です。（実際はもっと具体的です）
オブジェクト指向設計の研修もありましたが、レビューから初めて知る事も多く、こればかりは経験の有無も大きいのでは..と感じています。
そして設計のレビューをもらったプルリクはなかなか終わらない。
私たちは、実装前に設計レビューをもらっておく・ペアプロしてもらうという方法で乗り越えています！
個人開発とは違う
これらはどれも社内の開発の効率を上げる、保守性を高め、安定的に開発・運用するためのものです。
初めは動くものを作るので精一杯だったけど、OJT中に現在稼働しているサービスのソースコードに手を加えていく中で、正しく作るを意識し、もっといい設計はないのか？を考えるようになりました。
それは自分が書くコードだけではなく、既存のものに対しても言えることで、当事者意識を持ってより良くするために気付いたらプルリクチャンス！として行動していくべきだと思っています。
サポートが手厚い
研修を受けていて、ありがたいなぁと思うのが先輩方からの手厚いサポートです。
講義の担当
まず、講義は項目ごとに担当がいて、技術的な質問は各講義を受け持ってくれた先輩に聞きにいくという風になっています。（サポート期間は１年間だそうです）
もちろん他の先輩に聞いても優しく教えてくれますが、これで困ったら〇〇先輩！というのがあるだけで誰に聞けば良いんだろうと悩む事もなくなり、質問ハードルが下がっていたように思います。
レビュー
次に先輩からのコードレビューです！
19卒間でレビューをして、これで良いのか自分たちじゃ分からないなとなった時、先輩方がレビューをしてくれます。
プルリクを作った瞬間に、レビュー依頼をしなくとも、コメントをくださるすごい方もいます。
何が良いのか、何がダメなのか、なぜダメなのかがまだ分かっていない新卒にとって、様々な観点からのレビューは学びの塊です。
レビューをお願いしやすいというのは、恵まれた環境であると思います。
精神面をサポートしてくれるメンター
技術的なサポートはもちろんのこと、新卒には１人ずつメンターがついていて、定期的な1on1で精神面のサポートもしていただけます。
小さなことを相談できるだけでなく、成長のために今何をするといいのかを一緒に考えてくれたりもします。
継続することが苦手だった私もメンターに見守られ、3ヶ月毎日読書をして体系的に学ぶ 安全なWebアプリケーションの作り方を読み切ることができました！
まとめ
色々な技術を学びながらも、「エンジニアとして働くとは？」を考えさせられています。
学生の時、「お金をもらうってことは、自分の書いた全てのコードに責任が持てる、持たなきゃダメだよ」と言われた事があります。その時は無理だと思っていました。だけど、このような日々の積み重ねがコードに責任が持てるに繋がるのだと今はそう思います。
そんな気持ちも胸に、残りの研修も突っ走っていきたいと思います！