2ヶ月の新卒エンジニア研修を受けて変わったこと

新卒エンジニア研修を実施しました

こんにちは。 みんなのウェディング技術部の武田です。

6月1日より技術部に配属になり、そこから7月31日までの約2ヶ月間の新卒エンジニア研修がありました。 もう冬に突入しようとしていますが、研修の様子とともに、実際に新卒の私が感じたこと、得たものを書いていきたいと思います。

研修の目的

今回の研修の目的は「Railsを利用してウェブアプリケーションを正しく作れる」ということを目指しています。単一に正しくというと広いですが、Webアプリケーションには設計、プログラム、セキュリティ、アプリケーションの信頼性と様々な切り口があります。それらを自ら学んで行きます。

17卒の新卒エンジニアは5名います。 (個性の強いメンバーに会いたい方はぜひオフィスに遊びに来て見てください!どこかに連絡くれれば反応します。) 各々Railsには初挑戦だったり、かじっていただけ、というメンバーがほとんどです。 それぞれメンバーのこれまで大学や個人でやって来た分野は違いました。

  • Android開発(Java)
  • ゲーム、VRエンジニア
  • 機械学習(Python)
  • フロントエンド(CSS, JS)
  • 物理学(ちょっとプログラミングしたことあるぐらい)

この5人と一緒に研修を進めていく中で自分の目標として「Railsらしい、書き方を学ぶこと」を設定しました。

私は比較的Railsはやったことある、データベースもオブジェクト指向もそれなりにわかるぞ!という状態で研修に臨みました。 もちろん比較的座学の内容はすんなりと頭に入ってきて、復習だと感じましたが、学生と会社員の間には事業要件という大きな違いがありました。 事業的背景を捉えないとデータベースの設計ができないという状況を体験し、社会を生きていくのは大変だなと感じたのを覚えています。

トータルこの研修では僕は強気で攻めたのでその気持ちも伝わればと思います。

研修の流れと課題

2ヶ月間のスケジュール内容は以下のようになっています。

期間 やったこと
6/1 ~ 7/7 RailsTutorialの写経
テーブル設計
オブジェクト指向設計
セキュリティについて
CSS、SCSSについて
6/26 ~ 7/31 オリジナルアプリケーション作成

実は私はRailsでのサービス開発に携わっていたことがあり、 「私Railsチョットワカル」 状態でしたので、ひとまずは大丈夫だろうという気持ちの方が大きかったです。

Rails Tutorialの写経をメインで進めていきますが、 Tutorialで足りない部分を補うためにコードレビューもここで入ります。

テストとの出会い

Rails Tutorialも後半戦に差し掛かった頃に、 RSpecでテストコードを書いてみようということになりました。 (Rails TutorialではMini Testを写経することになっています!)

Mini TestをRSpecっぽく書く、ということを意識して書くように、という風に一言もらったのですが、 「Rspecっぽくってなんだろう…?」状態でした。

2~3日あたりは辛かったのを覚えていますが、3日後ぐらいからテスト書くことに抵抗がなくなってきました! 後半に、Mock、Stubであたふたなるのですが…笑

資料は以下を参考にしました。

  • EverydayRails
  • RSpecの入門とその一歩先へ ~RSpec 3バージョン~の写経

さて、次に追加課題にそれぞれ取り組みました。

  • erbではなくhamlに書き直してみる
  • Rails Tutorialの最後の章にある追加課題をやってみる
  • もう一周してみる

追加課題に関しては、自走に近い形なので、 各々の実装方法が見れたので面白かったポイントでした。

Rails Tutorialと平行して座学があり、 Webアプリケーションを作る上で必要なものを学びます。

テーブル設計

松久さんの講師のもと、第3正規形までのデータベースのテーブル設計を 学びました。

私は大学の研究で、分散型のデータベースの研究をしていたため、 『テーブル設計やったことある!やれる!』と思っていました。(ちょっと調子乗っていたんです!)

内容としては、第3正規形まで軽く復習したのちに、実際の要件に合わせて設計をしました。 歌舞伎座(このときオフィスは銀座でした!)の作品リストと、それに関わった演者のリストを作成します。 その後の要件として、作品、演者それぞれにユーザーがレビューできるようにしたいというものでした。

実際に取り組んでみて、難しいと思ったのは設計をする前に、どんな要件があるのか?ということを聞き出すということでした。 例えば、演舞は1日2度ある場合があるが、それぞれに対してレビューができるようにするのか?などです。 設計には確実に正解というものがないので、いかに要件把握やヒアリングをしっかり行っていくかが大切だと感じました。 これはOJTのRails移行でも重要なポイントです。

わかった気になる、オブジェクト指向設計

1syoさんの講師のもとオブジェクト指向設計について学びました。 特に今回はオブジェクト指向設計の基本とRailsでの応用パターンを学んでいきました。

普段はC#を書いている僕ですが、結構オブジェクト指向(以下OOP)は大丈夫だろうという気持ちでした。(強気なので) 初めてOOPを意識して書いた大学3年のときはかなりしんどかったのを覚えています。ほんとにはじめはちんぷんかんぷんです。

基礎的なクラスを使うとこう便利にかけるという話から始まり、RailsにはModel, View, Controllerとあるけど、意識してないとFat(肥大化)するぜ。 だからちゃんと分けてあげような!という内容でした。(ざっくりしすぎ!)

例えばデバイスごとに通知したいという実装があったときに分岐を使って書くと次デバイスが増えたときに困るから 基底クラスを作ってそれを継承すればいいやん!です。

この研修を通して、OOPがいきなり書けるようにはなりませんが、 OOPを意識するきっかけにはなったと思います。

実際にOJTのRailsでの開発ではこの時の研修内容で出てきたパターンを使っていくつも実装しています。 すごい!

この他にも工藤さんのセキュリティ研修や、平岡さんのSCSS入門など、盛りだくさんの 研修でしたが、今回は肥大な内容になってしまうので割愛します。 (気になった方はぜひオフィスに遊びに来てください!)

オリジナルアプリケーション作成

研修の終盤からはRails Tutorialの復習と自走するということを目的として、 自分たちで考えたアプリケーションをRailsで開発するフェーズがありました。

その中のアイディアとして社内用フリマや、シャンプーの口コミサービスなどがあり、 各々が1人1アイデア開発しました。

開発においては制限は特に設けられていませんでした。 サービスを載せるためのサーバーはPaasのHerokuを使ってサービス開発側に注力するのもあり、 IaasであるAWSのEC2を使ってインフラ側を学んでいるメンバーもいました。

ちなみに僕はHondana!というチームで本を管理できるアプリケーションを途中までですが、開発しました。検証用としてAWSが使えたので、Ansibleを書いて構築し、そこでアプリケーションを動かしました。

CIは静的コード解析としてSideCIを利用し、 テストコード用としてCircleCIを利用しました。

開発フローを自分で初めから構築できたのは良かったと思います。

開発フロー

以下はみんなのウェディングの現場で行われている開発とほぼ同じ流れです。 サービス開発するトレーニングとして、研修ではこれと同じ流れを作ってから 研修を進めて行きます。僕が一番不安だったポイントはここでした。 開発フローを知らない(やったことない)ので一度は一からデプロイまでの流れを構築したかったので 既存を使わないという部分は最高に良かったです! サービスではCircleCIを使いますが、今回のRailsTutorialではWerckerでテストを走らせます。オリジナルアプリケーション開発では僕もですが、CircleCIを使ったりしました。

TDD(テスト駆動開発)に近い形を取っていて、実装前にある程度テストを書いてテストを失敗させ、 そこから実装していきます。Railsでは逆パターンが多いけどメソッドとかはまずテスト失敗させることが多いですね。

TDDについてはここを参考にしました。

振り返りを行う

一週間の終わりに振り返りを行います。 これも開発フローの一貫で、来週の開発速度や密度を高めるために決められた曜日にチームメンバーが集って以下のような振り返りをしていきます。

  • 良かった点
  • もやもやした点
  • 来週へのトライ

この3つをあげて、チーム内で共有して、開発効率を上げたり、コミュニケーションを取る場として設けられています。 新たなインプットや他のメンバーのやり方を共有できる場として、会話が弾むこの時間は結構私としては好きです。 メンバーが何をやっているかはGithubを見ればある程度わかりますが、仕事の進め方というのはあまり知りません。

振り返りの様子

研修全体としての取り組み

開発を進めていく中でエラーや実装でつまる部分がありました。 詰まった部分や気になった点はその都度、

を参考にしてプログラムを書いていきます。 常にDocumentを見るという習慣もつきました。

エラーで問題がわからない時は

  • とにかくエラー文をよく読む
  • エラーログをよく読む
  • それでもわからない場合はエラー文でググる(Stack Overflow等)
  • もしくはslackのtech_qaチャンネルがあるのでそこで質問する

公式ドキュメントを見ることがどれだけ解決方法として最短か、という部分を実感できた研修でもありました。

基礎的な質問でも全力で回答してくれる

新卒が何気無く思ったことは気軽に聞けたり教えてもらったりできたのはいいなと思いました。

Github上では頻繁に会話が行われていますが、オフィス内で直接会話して解決することも多々あります。 このころはまだ初期なので会話もぎこちなくどこか硬いようです。

時間を割いて、ペアプロをしたり、議論したりできる場があるので、 新卒側からするとすごくありがたいです。

同期からのレビュー

先輩にレビューをもらうことがほとんどですが、それと同じぐらいレビューをもらったのが同期メンバーです。 初めは遠慮がちだったレビューですが、時間が経つごとに、コードに対して厳しくレビューをもらうようになりました。

現在のOJTでもトライとして、同期内で10分レビューをするという意見がでていて試しています。 これは私たちの成長と、実装からコードレビューまでの速度を速め、精度を上げていこうという目的で始まりました。

同期間の助け合い

基本的に僕たちは支え合ってコードを書いています。笑 よくある例を見てみましょう。

  • Gitが絡まったー!
  • レビューが多すぎ辛い!
  • 謎のエラーが出るんだけど!
  • 実装は正しいはずなんだけど動かない!
  • テストがうまく書けないからペアプロしてほしい!
  • こんな実装をしたのだけどもっとシュッと書ける方法知らない?

時系列に並べてみました。 後半にかけて少しずつレベルが上がって来ているのが実感できますね! 自然と質問が難しくなって自分達の成長も感じられたいい場面でした。

そういえばこんな会話もありました

何気ない会話ですが、結構いい効果を生んでいると思っていました。 この後に自然と会話が生まれるので、自分の意見が言いやすかったり、質問しやすかったりするんだろうと思います。 温泉に行きたいなぁという会話から生まれたSlackのポストです。

ラフに声を掛けれるので、プロジェクトを円滑に進めやすかったです。

最後に

今回は新卒エンジニア研修について書きました。 現在はOJTの一環として新卒メンバーは2つのチームに分かれて、以前から使っているPerlで書かれたアプリケーションからRuby on Railsへの移行を着々と進めています。

また、同期メンバーの櫻井Ruby on Rails を使ったサービス開発と組織(ブラケット × みんなのウェディング) で登壇しました。同じくエンジニア研修を受けた仲間がどう感じたのかを見られる発表でした。(僕も後ろで聞いていました!) 記事の中にはスライドへのリンクもありますので、ぜひチェックしてみてください!

今回のエンジニア研修を終えて、

  • テストを書くことに前向きになった
  • 正しくアプリケーションを作る意識が芽生えた

この2つは確実に芽生えました。

今後はRails本体も読み、どう使っていけばいいのか、どういう仕組みで動いているのかをRails移行で実践しながら学んでいきます。 そして18卒を始め、新たに入ってくるメンバーへのサポート、ピリッとしたコードレビューを17卒ができるように頑張りたいと思います。

みんなのウェディングでは、一緒に働く仲間を募集しています。 興味のある方は、Wantedly からご連絡ください。または 武田 に直接ご連絡いただいても大丈夫です。