こんにちは、4月に入社しました広告技術部のyamaYuです。今回は21卒新卒ブログの第三弾ということで、私が入社して広告技術部に配属されてからどんなことをやってきたかを紹介します。第一弾、第二弾の記事は ↓ から読めますのでこちらも是非見てみてください!
Gunosyに入る前は何をしていたのか
はじめに私自身のバックグラウンドについて少し書いておきます。
CS系の学科の修士卒で、自然言語処理の研究をしていました。 深層学習を使ってニュースの見出しを自動生成する研究で、Pythonで深層学習のモデルやテキスト処理を実装したり、 Bashで実験用のスクリプトを書いたりしていました。
プログラミング自体は大学から始め、授業でCとJavaを習い、 他社のアルバイトで1年ほどJavaによる業務用Webアプリケーションの開発をしていました。
後ほど入社してから触れてきた技術について述べますが、Gunosyで開発されているプロダクトの多くで採用されているGo言語を含めほぼ全てが未経験でした。
広告技術部とは
私の所属する広告技術部では広告配信システムの管理画面やAPIの開発・保守を担当します。 下図は広告技術部で扱うプロダクトの一つであるGunosyAdsの概要をざっくり図示したものになります。 プロダクトの詳細についてはここでは触れませんが大まかなイメージだけ掴んでいただければ幸いです。
- 広告主側で広告を作成し、管理画面から入稿。
- アプリからのリクエストに応じ、ユーザ情報等をもとに広告を選定・配信。
- アプリに広告を表示。
これまで触ってきた技術
開発に携わる中で多くの技術を触ってきました。ここではその一部を紹介します。
Go
Gunosyで開発されているプロダクトの多くがバックエンドにGoを採用しています。 広告配信APIもその一つです。広告の配信においては複数の処理を非同期に実行することが多く、並行処理を簡潔に書くことができるGoの良さが生きています。シンプルな言語仕様やgo fmtなどにより新卒エンジニアでもきれいなコードを書きやすいところが気に入っています。
Kubernetes
コンテナ化されたアプリケーションのデプロイとスケーリングに伴う手作業を自動化できるオープンソースコンテナプラットフォームです。 こちらは技術研修でも扱います。
広告配信APIではKubernetes上でCanary Deployを実現する仕組みやニュース速報によるリクエストの増加を処理するためのスケーリングの仕組みを導入しています。システムの可用性が売上に直結する広告配信において非常に重要な構成要素となっています。
Terraform
HashiCorp社が提供するマルチクラウド上のコンピュータやネットワークをコード化し、構築を自動化するツールです。GunosyではAWSなどのインフラの管理をTerraformで行っています。
AWSなどのインフラはTerraformでコード化されており、Terraformの文法さえ学べば、新卒でも管理しているインフラの設定を容易に把握できるようになっています。また設定の変更はPRを通して行われるため些細な変更でも、背景を履歴に残すことができるという利点があります。入社までIaCを経験したことがなく、AWSはマネジメントコンソールやCLIから操作するものと思っていた私には衝撃的でした。
その他
上で紹介した以外にも多くの技術に触れてきました。 管理画面はRuby on Rails + TypeScriptで書かれており、ログ収集にFluentd、CI/CDにCircleCI、ワークフローエンジンにDigdag、モニタリングにDatadog、BIにRedashなどが使われています。 割愛しますが他にも色々あります。
どんな感じで仕事をしてくのか
4月に入社するとすぐにチームに配属されます。 配属先は選考中/後の面談で相談しつつ決めたので、どのようなことをやるかは事前にある程度把握できていきました。 私は選考の際にサーバサイドの開発をやりたいと希望していたので望み通りの配属になっています。
基本的にチームごとのOJTがメインになりますが、5月の下旬くらいまではビジネス/エンジニア共通の研修やUdemyによる技術研修を並行して進めていきます。 また有志による社内勉強会があり、AWSやKubernetes、アルゴリズムなどを業務時間内で学ぶことができます。
その頃の1日の流れとしては出勤→チームごとの朝会→新卒研修→昼休憩→OJT/技術研修/勉強会→退勤といったイメージです。
OJT
私はGoやAWSなどの経験が浅く、また最初はプロダクト特有のことを何もわからないので、はじめは比較的簡単なタスクを振ってもらい、それをこなしつつ徐々にプロジェクトの全体像をつかんでいきました。
入社から1週間ほどして少し慣れてきたタイミングでモブプログラミングを経験しました。 実際にコードを書くドライバーと問題解決のサポートをするナビゲーターに分かれて共同でコードを書いていきます。 リモートワーク1で行うためエディタ・画面共有をしながらの作業になります。 私とメンター、テックリードの3人で交代でドライバーを担当しながら開発を進めていきました。 実装の方針を共有しつつ進めるため一人でコーディングするのとは異なった難しさがありますが、リモートワーク下においても分からないことをシュッと2相談できたり、先輩社員の作業を見てコードの書き方や編集操作を学んだりできる良さがあります。
ある程度一人で作業を進められるようになってくると、大きめの粒度のタスクを任されます。 実装の方針など自分で決めることが増えるので一層面白くなってきます。 ただ新米なので相変わらずわからないことは無限にあります。 そういった場合はSlackのチャットや通話を活用し、メンターなどと相談しつつ進めます。 私はSlackのtimesチャンネル3を作業ログやタスク管理にも使っており、相談の際の進捗の共有や問題点の言語化にも役立てています。
コードレビュー
コードレビューもアサインされます。 自分のタスクだけでも精一杯という状況下で他のチームメンバーが担当しているタスクの背景と変更内容を理解しないといけないので大変です。 初めは時間がかかってしまったり、表面的な指摘しかできなかったりしますが、読みやすいコードやレビューしやすいPRの書き方を学べます。 また数をこなすことで徐々に断片的な理解がプロジェクトの全体像の理解へと繋がっていくので面白いです。
1on1
私のチームでは、定期的にメンター、テックリード、マネージャーとの1on1があります。 業務内で困っていることや今後やってみたいことを相談したり、全く業務とは関係ない雑談4をしたりします。 今やっているタスクで詰まっているとか、興味のある技術を学べるタスクを割り振ってもらえないかとか、どのアニメが面白いかなどを気軽に話せる場になっています。 直近のハイライトとしては、Ruby on Railsを勉強したい旨を相談したところそのタスクを割り振ってもらえたこと、ウマ娘の2期が良いとメンターと共感したことの2点が挙げられます。
これから
入社してから半年間多くのことを吸収してきましたが、学ぶべきことはまだまだ無限にありそうです。
現在、既存システムをKubernetesへ移行する作業を担当していますが、相変わらずわからないことだらけです。 このタスクを終えた後にエンジニアとしてどのくらい成長しているだろうということを考えるととてもワクワクします。 今後の展望としてはエンジニアリングはもちろんのこと、ビジネス方面の理解も一層深めていければと考えています。
以上新卒ブログ第三弾でした!次回もぜひご期待ください!