Recruit Tech Blog
とある新人エンジニアの日常
石井潤
はじめに
このエントリは全 9 回を予定する 18 卒新人ブログリレーの第 8 回です！
はじめまして。リクルートテクノロジーズ新卒１年目の石井潤です！
入社後の研修を経て、７月から現場に配属され、OJT を受けながら業務に取り組んでいます。
このブログのテーマ
今回のブログでは、 「新卒で入社したエンジニアが現場でどんなふうに働いているのか、どんなふうに指導を受け、学んでいるのか」 について書きます。新人エンジニアの日常のできごとを取り留めもなく書き綴るというゆるふわ系のブログです。リクルートへのインターンや就職を考えている人に多少の参考になれば嬉しいです。
本ブログの構成は以下のとおりです。各項目間にはあまり関連性がないため、どこからでもお読みいただます。
参考までに、私の技術的なバックグラウンドはこんな感じです。
- バイト・インターンでの開発経験なし
- プロダクトコードに触れたことがない（研究で多少コードを書いていたが、自分しか触らないようなコード）
ちなみに、7月以降のトレーニング・業務の内容は配属によって大きく異なります。
他の新人のキャッチアップの方法ついては、平松くんの記事『RECRUIT RED TEAMのセキュリティトレーニング：OSSへの貢献とCVE IDの取得』や西野くんの記事『新卒エンジニアが配属後３ヶ月間で学んだ事 ~ 開発・ユーザ・ビジネス の理解 ~』など各新人の記事をご覧ください。
今までやってきたこと
4 月-6 月： 新人研修
4 月：リクルートテクノロジーズ エンジニアコース新人研修
4 月は、以下の研修を受けました。
リクルートテクノロジーズ エンジニアコース新人研修の内容を公開します（2018年度版）
実際に研修を受けてどう感じたかを書きます。上記ブログの通り、実装課題、データモデリング、ISUCON、ハッカソンなど、「自分で考え、手を動かす」課題が多くありました。講師の補助のもと、実際に必要になったから習得した知識、ぶつかった壁を乗り越える経験は非常に貴重なものだと思います。また、「これをやりたい」「こうやりたい」をベースに課題を進められたので、高いモチベーションのもと楽しく研修を受けられました。3,4 人のチームでの課題も多く、各人の得意な領域を教え合い知識を補填し合うことができ、良い刺激になりました。
一方、エンジニアとしての業務経験の無い自分にとってはレベルが高く、ついていくのが大変でした（ほとんどの新人にとっては適切なレベルだったのではないかと思いますが）。しかし、必死についていくことで自分に足りていない知識が浮き彫りになり、自分が何を勉強するべきかの広範囲なインデックスが作れてよかったと思います。
5月-6 月： 新人によるプロジェクト研修
新卒エンジニア 10 人が、5 人ずつの 2 チームに別れてそれぞれプロジェクトを行いました。
私のチームは「チーム開発に慣れる」という目的のもと、「既存サービスのスマホアプリ版を React Native で作成する」というお題を与えられ、設計、実装、ユーザーヒアリングを行いました。
この研修の目的は、以下です。
- 新規プロダクト開発の基本の流れを理解・経験する
- チームで開発するうえで必要なことを学ぶ
- React-Native の技術調査
この研修での最大の学びは、周囲の人を巻き込む経験です。
何を作るかは課題として与えられましたが、具体的にどうやるかは新人が自分たちで決めるという進め方でした。
しかし、当然新人は技術、ドメイン知識、社内の環境など様々な知識が足りません。そこで、分からないことはとにかく先輩社員に相談しに行きました。例えば下記のように、わからないことがある度に知見のある先輩社員を紹介してもらい、アポイントメントを取って相談しました。
- 作ろうとしているものが本当に正しいものかを確かめるために、プロダクトオーナーに「なぜこのサービスのスマホアプリ版が必要なのか？」を聞きに行った
- 実装で分からないところ、詰まりそうなところがあればペアプロをお願いした
- 新人チームメンバーはユーザーヒアリングの経験がなかったため、ヒアリングを担当している別事業会社の社員を紹介してもらい、ヒアリング方法をインプットしてもらった
以上のようにこのプロジェクトでは、技術だけでなく周囲の社員との関わり方も学びました。
7 月-現在： 新人、現場に立つ
上記の研修が終わり、現場に配属されました。以降では、現場での業務や OJT について紹介します。
メンターがつく
7 月の現場配属以降は各新人にひとりずつメンターが付き、新人が一人前になるまでのサポートをしてくれます。
私のメンターは、iOS アプリ開発やサーバーサイド開発などをされているエンジニアのgaopinさんです。Swift に関するカンファレンス try! Swift Tokyo の運営 など、社内外問わず活躍されている方です。
私の場合、座席が隣りあっていることもあってメンターと接する機会はかなり多く、気軽に会話・質問できる環境です。また、毎週 30 分面談をして進捗や困り毎を共有しています。メンターとのやりとりは「日常エピソード」の章で紹介します。
7月-9 月：0→1 開発
7 月から 9 月まで、 海外の新規プロジェクトの MVP (Minimum Viable Product) 開発 に参加しました。7 月から 8 月にかけてアプリの初期構築をし、9 月にエンハンスを行うというスケジュールで開発が進みました。
サーバーサイドは Ruby on Rails, フロントエンドは Vue.js で開発しました。
開発チームの人数は 5 人で、私はその中の 1 人として業務に当たりました。また、開発チームのメンバーはほとんどが Rails での開発経験がなかったため、Rails 熟練者のレビュアーが 2 人いてコードの品質を担保していました。
以下は、私が実際に行った業務の内容です。
- 技術調査
- 業務系ツールの開発
- 初期リリース前の結合テスト実施
- 種々の業務系スクリプトの実装
- アプリのエンハンス開発
- デプロイ時のバグ対応
- 各種ドキュメントの英語化
基本的に私は遊撃手のような役割で、そのとき手が足りていない業務や当初予定していなかった業務などを担当していました。そのおかげで上記のような幅広い経験ができ、良かったと思っています。
10 月：タウンワークの iOS アプリ開発キャッチアップ
前述のプロジェクトが終わり、10 月からタウンワークの iOS アプリ開発チームに配属されました。
私は iOS アプリ開発が未経験だったので、最初の一ヶ月は「一人で案件の実装をこなせるようになること」を目標に定め、キャッチアップに励みました。キャッチアップのために何をすべきかはメンターが計画し、随時相談しながら進めていきました。
以下では、私がキャッチアップのために行ったこと説明します。
参考書を読む, 課題アプリを実装する
まずは入門書を読み基礎知識をつけました。次に、メンターから与えられた仕様を満たす課題アプリを実装しました。課題となるアプリは、以下の 3 つの画面を持つ Twitter クライアントアプリです。
- ログイン/タイムライン画面
- ツイート投稿画面
- お気に入り一覧画面
この課題のねらいは、以下の通りです。
- アプリをゼロから作る一通りの流れを体験する
- タウンワーク iOS アプリで多用されるテーブルビューに慣れる
- HTTP 通信や画面遷移を学ぶ
- コードレビューを通してより良い設計を学ぶ
作ったアプリはこんな感じです。
この項目が終了する段階では、調べたりアドバイスをもらったりしながら、アプリをゼロから構築できるようになっていました。
過去の開発案件を実装する
次に、実際のプロダクトのソースコードを用いた訓練として、過去に存在した開発案件を 1 から実装しました。
案件のイメージです。
この課題のねらいは、以下の通りです。
- 実際の開発の流れを一通り経験する
- 既存のソースコードへ慣れる、理解を深める
この課題の中で教わったのが ボーイスカウトルール です。ボーイスカウトのルール「来た時よりも美しく」に倣った「既存のコードに手を加える際にどこか 1 箇所でいいので改善する」という原則です。
今回は練習のため、このボーイスカウトルールをよりアグレッシブにした「既存のコードに手を加える際は、目についた範囲のソースコードはできるだけ綺麗にする」という方針のもと実装を行いました。
このルールですが、課題を終えてみて以下のような効果を感じました。
- 手を加えるソースコードの範囲が広くなり、理解が広範囲になる
- 実際に手を加えることで、理解が深くなる
- 既存のソースコードを思考停止して受け入れることなく、より良い実装は？を常に考える癖がつく
この項目が終了する段階では、コードの理解や実装に時間はかかるもののある程度独力で開発案件を実装できるようになっていました。
新規案件をペアプロで実装する
最後に、実際にチーム参加して開発案件をこなしました。過去案件の実装を行ったとはいえ、まだまだ iOS アプリ開発にもタウンワークのソースコードにも不慣れな状態です。自走できるようになるまではチームメンバーとペアになって設計・実装を行いました。ペアで作業を行うことによって、立ち上がりがスムーズになったと思います。
日常エピソード
以上が、私が入社以降受けてきた研修、行ってきた業務です。
ここからは、私がどんなふうに業務を行っているか、またどのような指導を受けているのかを、具体的なエピソードを通して紹介をしていきます。
分報の活用
会社全体としての取り組みではありませんが、私は分報を活用してメンターを始めとする同僚社員とコミュニケーションを取っています。
分報とは、日報のリアルタイム版のようなものです。 Slack に “times_[名前]” のような名前のチャンネルを作り、
- 今やっていること
- 困っていること
- 世間話
などをリアルタイムに書いていきます。リクルートテクノロジーズ の slack にはたくさんの分報チャネルがあり、下記の画像はその一部です。
分報についての詳しい説明はこちらを参照してください。
私が分報を使用している上で感じた利点は、情報を気軽に公開することで、さまざまなフィードバックを得られることです。以下でエピソードとともにいくつか紹介します。
先輩からのフィードバック
分報に独り言をつぶやくと、メンターを始めとする先輩たちが「コイツほんとに理解してんのか？」とか「間違った理解してない？」とマサカリを放ってくれます。
ある日、使用したコマンドをメモとして分報に貼りました。
するとどこからともなくマサカリが……
自分の理解を伝えました。
すると、ツッコミが来て、理解が間違っていたことを気づかせてもらいました。
そこで、ドキュメントを読み、再度理解したことを報告し、それで合っているとリアクションをもらえました。
さらに、オプションが何のためにあるのか？に話は及びます。
このやり取りを通してメンターが与えたかった教訓は「よくわかってないものは使わないように」でした。このやり取り以降は、コマンドもソースコードも、公式情報のドキュメントなどの一次情報を参照して理解してから使うようになりました。
最後に理解したことを確認して、このやり取りは終わりました。
上記のように、勘違いを気づかせてくれたり、思考停止しているときに「考えが足りてないんじゃないの？」と指摘をもらえたりします。間違いを正していかないと成長には繋がりませんが、そもそも知識の足りない自分は何が間違いなのかを分かっていません。そこをいろんな人の視点から指摘して気づかせてもらえるので、自分ひとりの場合と比べて格段に成長できると思います。
他の人の分報を見ていると、勉強になる
一方で他の社員の分報を見ると同様に技術的な議論・雑談がオープンになっており、非常に勉強になります。また、社員がカンファレンス等に参加する場合、その実況も盛んに行われています。以下はサンディエゴで開催された Agile2018 の実況です。
プルリクレビューでのやり取り
続いて、立ち上がりの時期のコードレビューを紹介します。内容というよりは、こんな雰囲気だということを感じていただければと思います。
これは Swift における定数をどう宣言するべきか、という問題に関する議論です。
このあと、メンターにこれはあるネット記事を参考にしてこの実装にしたことを伝えると、以下のような返答をもらいました。
詳細は省きますが、このやり取りを通してメンターが与えたかった教訓は、「ネット記事などを参考にするのはいいけど自分なりの見解を持つようにしよう」でした。たしかに、以前の自分はネット記事で同じ内容のものが多ければあまり深く考えずに「正しいんだろうな」と納得し、それを鵜呑みにしやすかったように思います。
以上のように、レビュアーがしっかりとレビューをしてくれるだけでなく、意図を持って成長のきっかけを与えてくれます。
入社までプロダクトコードに触れたことがないことが不安だった自分にとって、とても良いキャッチアップの機会だと思っています。
困ったときのアドバイス
困りごとを日報や分報に書くと、誰かが相談に乗ってくれたり、解決策を一緒に考えてくれます。
ある日悩みごとを日報に書いたところ、アドバイスをもらい、それによって問題が解決したエピソードを紹介します。
アドバイス 1: ペアプロ実施による立ち上がり加速
配属直後の 7 月時点で Rails はチュートリアルレベルしか 経験がなかったため実装がスムーズに進まないことが悩みでした。その旨を日報に書いたところ、
上長から、ペアプロしてもらって学びながら進めた方が立ち上がりが早いのではとの指摘をもらいました。
※ここでいう「TEPCO」とは、京橋にある「三井住友海上テプコビル」というリクルートテクノロジーズの拠点のひとつを指します
その後、リモートの Rails 熟練者のレビュアーの方に連絡を取って、ペアプロをしてもらえることになりました。
ペアプロでは、Rails でのシンプルなコントローラの書き方のように Rails らしい書き方や RSpec によるテスト駆動開発などを教わりつつ実装を進めました。このように
- Rails の基本を学べたこと
- 開発のコツが掴めたこと
- 実装で困ったときに「ペアプロ」という解決の選択肢が一つ増えたこと
など得るものが大きかったです。また、直接私のレベルを把握してもらったおかげで、以降の PR レビューや Slack でのやりとりもスムーズになったと思います。
アドバイス 2: 設計レビューによる手戻りの防止
上記と同様に「実装が遅いことを悩んでいる」とメンターに相談したところ、「短期間で実装を一気に早くすることは現実的でないので、まずは手戻りを少なくしよう」と提案してもらいました。
手戻りを少なくするために、いきなり設計・実装を始めるのではなく、設計をしそのレビューをもらってから実装に入ることになりました。
その結果、手戻りが減ったことはもちろん、しっかり設計してから実装に入るため実装中に手が止まることも少なくなったように感じます。
これらの経験から得たこととして、問題解決もそうですが、壁に当たっても相談すればよいという安心感が得られたことが大きかったと思います。
技術顧問への相談・ペアプロ
技術顧問の和田卓人(t_wada)さんがフロアにいらっしゃるときは、ペアプロ、モブプロをしていただいたり、様々な技術課題の相談をしたりしています。
この日はタウンワークの iOS アプリについて、テストを容易にするのためのアーキテクチャ移行方針を相談しました。
入社までは、和田さんは忙しくて接する機会があまりないだろうなあと思っていたのですが、予定がギチギチに埋まっているというわけでなく、気軽にお声掛けして相談できます。
技術顧問の availability が高いことによって、開発チームの相談・ペアプロへのハードルが下がっていてとても良い環境だと思いました。
アウトプット中心の学習
知識の効率的な修得のために、アウトプットを中心とした学習をしています。
自分のことばで説明する調査課題
メンターに質問をしたとき、理解度の確認のために用語や概念を自分の言葉で説明することを求められます。
そこで説明できなかった、または説明が間違っていた場合は、調査課題として文章にまとめて分報に投下することにしています。自分のことばで説明することによって、知識が整理され、理解度向上につながります。
ある日、以下のようなやり取りがありました。
メンター「デリゲートパターンって何？？」
私「ｱｯアノッｿﾉｯ…アレです」
メンター「調べて自分のことばでまとめて分報に投下して 👼」
以下を調べて投下しました。
このように、自分のことばで説明する機会を意識的に多く与えてもらっています。
登壇駆動学習
メンターおすすめの「登壇駆動学習」を 9 月からはじめました。
登壇駆動学習とは、勉強会の登壇枠に申し込み、発表することを前提として学習を行うことです。
登壇駆動学習は以下のような利点があります。
- 発表資料を作る過程で知識の整理ができる
- 締切による強制力が生まれる
- 資料があとにのこる
ある日こんな出来事がありました……
私「手っ取り早く力をつけたいです。どうすれば…」
メンター「登壇するといいよ」
私「ハハッなるほど」← 初心者が発表できるわけがないと思っている
メンター「じゃあ今から勉強会の登壇枠抑えるぞ＾＾ はよ connpass 開いて開いて」
私（えっ マジだったの？）
かくして、私の登壇駆動学習がスタートしました。
実際やってみて、想定していたこととのギャップ、また登壇駆動学習の効果について紹介します。
勘違いしていたこと
① 内容
❌ 勉強会で最新の知識やとても高度な内容を発表しなくてはならない
✅ 初心者向けの勉強会なら、最新の知識でなくても知らない人はたくさんいる
✅ LT はハードルが低いので安心して発表できる
登壇に際して、私が最初に思ったのが 「話す内容が簡単すぎて他人の時間を無駄にしてしまうのではないか…」という不安 でした。
しかし、実際に登壇してみたところ、発表後の懇親会で「知らなかった」「参考になった」との声をもらい、初心者でも貢献できる場があることを学びました。
また、LT は 5 分と短いため、話す側の負担も聞く側の負担も小さいため、初期の登壇には適していると思いました。メッセージを 1 つにフォーカスすることで内容も考えやすくなります。
② 準備
❌ 準備ができたら申し込む
✅ 申し込んでから準備する
これは私の話ですが、準備をしようしようと思っていても、なかなか着手ができません。発表申し込みをすることで、締切による強制力にドライブされ否が応でも準備を行うようになります。
感想
実際に発表してみた感想です。
まず、登壇に対するハードルが下がりました。勝手のわからない分野における、「この程度のことを発表していいのか…？」という恐れが小さくなりました。一方で、調べてまとめただけの内容を発表したので、もう少し貢献できるような内容を発表したいという意欲が出てきました。
また、自分は物事を整理するのが特に苦手なので、アウトプット駆動学習は自分の苦手を補うのに良いと思っています。
以下は私が 9 月に発表した LT の資料です。このように非常に簡単な内容でも貢献ができ嬉しかったです。
https://speakerdeck.com/i4e/rails-defei-tong-qi-chu-li-woxing-u-gem-falsexuan-bifang-nituitediao-betemita
研修や社内勉強会
以下では、業務以外で行っている社内の活動について紹介します。
Go 研修
毎月 1 回、『Effective Java』や『プログラミング言語 Go』の翻訳者である柴田芳樹さんのGo 研修を受講しています。
研修は 7 月から 12 月まで毎月 1 回、全 6 回で、各日程 9:30 から 17:00 まで丸一日使い研修をします。受講は希望制ですが、18 新卒入社したエンジニアのほとんどが受講しています。
研修の内容は、大きく分けて事前課題と研修当日のディスカッションに分かれます。
課題は、以下のような内容です。
- 『プログラミング言語 Go』の指定された章を読み、 質問票（Google スプレッドシート）に 質問をまとめること
- 『プログラミング言語 Go』の練習問題を解くこと
研修当日は、以下を行います。
- 事前にまとめてきた質問への回答、議論
- 練習問題の解答の確認、講評
課題の量が非常に多く大変ですが、その分力が付くと評判の研修です。
また、今後社内では 2018/10/30 に発売された Effective Java 第 3 版の研修も予定されています。
感想ですが、ひとつの言語をしっかりと勉強したことがなかったので、初年度に OS などの低レイヤーを含めた言語の基本を学習できてよかったです。ここで学習したことを軸にすれば多言語の仕様の理解もスムーズになることと思います。
社内勉強会への参加
週 1 または隔週水曜日の 19 時〜21 時に、教科書を読む会という社内勉強会に参加しています。
この勉強会の目的は、「エンジニアとしての基礎教養をつける」ことで、18 卒同期入社の小松くんが主催しています。主な参加メンバーは 18 卒エンジニアで、和気あいあいと勉強しています。
会が発足してから 4 ヶ月、 以下のような内容の勉強会を行いました。
- 『リーダブルコード』輪読会
- 『アジャイルサムライ』輪読会
- 秋期 情報処理推進機構の情報処理技術者試験 対策もくもく会
- 『新装版 達人プログラマー 職人から名匠への道』 輪読会
さらにこの勉強会は、会社の仕組みを使って勉強会費用の支援を受けています。この勉強会では支援費用を主に弁当の手配に使っています。
リクルートには Commune Square という勉強会コミュニティ運営のためのプラットフォームが存在し、これを利用することによってコミュニティの活動を全社的に拡大しながら会社からの活動費用サポートを受けることができます。この活動費用のサポートによって食べられるケータリングやお弁当の魅力も読書会参加者のモチベーションを維持し続ける重要な要素の一つとなっています。 ー「教科書を読む会」より引用
例えば、こんな弁当を食べています。
このように、新卒 1 年目でも気軽に勉強会を開催することができ、さらに活動費用のサポートまで得られます。
勉強会にまつわる問題として、そもそも継続させることが難しいことが挙げられますが、ハードルを低くすること、また美味しい弁当が食べられることでモチベーションが上がり勉強会は継続しています。
技術共有相談会
隔週金曜日の 17 時〜18 時 30 分に、技術共有相談会という勉強会に参加しています。
雰囲気はGoogle などの企業で行われている “TGIF” のようにざっくばらんな感じで、新入社員から執行役員までが自由に参加し、発表・議論を行っています。
所属部署を問わず、エンジニアが自分の取り組みや技術的に困っていることについて気軽に、オープンに共有・相談出来る場として隔週で実施されている会です。
これまで各部のそれぞれで勉強会などを行ってきましたが、日常の仕事の文脈に関係ある・なしを問わず、エンジニアが自分の興味関心あるテーマについて自由闊達に語る/相談する/共有することで、エンジニア間の技術を介した関係性の構築や、最新の技術動向に対する組織としての感度や視座を高めることを目的としています。 ー「技術共有相談会」より引用
18 卒同期入社の辻くんが主体となって運営をしており、毎回 80 人を越える参加者が集まる人気イベントです。
こちらの勉強会でも補助制度を活用しており、金曜の夜に軽食やお酒を飲みながらフランクに猛者たちのマサカリが飛び交う和やかな雰囲気でさまざまな技術発表が行われています。
社内ISUCONへの参加
12月7日、8日に行われた社内 ISUCON である R-ISUCON に参加してきました。
2年目の先輩、4年目の先輩とチームを組み、結果は19チーム中12位でした！
私は主にアプリ周りを担当し、ボトルネック・改善策の調査やサーバ3台を使ったシステム構成の検討をしました。
最初はスムーズに進んでいたのですが、中盤あたりから考えた施策がうまくいかず、点数が伸び悩みました… 悔しい！
次回の ISUCON でリベンジを果たすべく、過去問等を使って練習をしようと思っています。
余談ですが、スマブラをやろうとスイッチを持っていったのですが、競技に熱中してしまいプレイする暇がありませんでした（笑）
おわりに
以上、新卒で入社したエンジニアが現場でどんなふうに働いているのか、どんなふうに指導を受けているのかをお伝えしました。
リクルートテクノロジーズは、学びの場が充実していて、エンジニアにとっては非常に喜ばしい環境だと思います！
以上、現場からでした！