アウモでの新卒エンジニア1年目の振り返り

こんにちは。2021年4月に新卒入社したネゴロです。

先日ノイズキャンセリング機能付きのイヤホンを購入しました。購入前は半信半疑だったのですが、実際に使ってみると本当に外界の音が遮断され、音楽への没入感が半端なく非常に感動しました。

感動のあまり家にいる時はずっとそのイヤホンをつけていたため、ある日突然モスキート音のような耳鳴りに襲われたため、現在そのイヤホンは最低限の利用にとどめています。皆様もノイキャンの使い過ぎにはお気をつけください。

さて今回は、グリー株式会社に新卒で入社し、アウモに配属されてから今までやってきたことや、業務を通して得られた学びについて振り返っていきたいと思います。

自己紹介

以前より本TechBlogでいくつか記事を投稿をしていますが、改めて自己紹介をしたいと思います。

私は慶應義塾大学環境情報学部を卒業後、グリー株式会社に新卒エンジニアとして入社しました。

学部名はいかにも情報系のようですが、実際には情報工学だけでなく経済やマーケティング、建築、デザイン、音楽などなんでも学ぶことができる学部です。そのため、実際私も大学2年の前半まではマーケティングの授業を中心に履修しており、プログラミングはほんの少し授業で触った程度でした。

そんな中、2年後半から研究室に入る時期になり、先輩に「たくさん単位が取れる研究室があるよ！」とおすすめしていただいたところにウキウキで入りました。

しかし実際そこはガチガチの情報系の研究室で、プログラミング経験がほぼ皆無だった自分は最初右も左もわからず非常に大変でした。

ただ、その研究室でプログラミングの基礎を少しずつ学び、加えて先輩に紹介していただいたベンチャー企業でエンジニアのインターン始めてから、自分の書いたコードがサービスとして形になっていく楽しさをどんどん感じるようになりました。

それから、案件請負型のベンチャー企業で業務委託として様々な技術を触らせていただいたり、デジタル素材を売買できるプラットフォームを開発している企業のベトナム・ハノイ支社で、現地のエンジニアと英語でコミュニケーションをとりながらサーバーサイドエンジニアをさせていただくなど貴重な経験を積ませていただきました。

それから就活の時期になり、ご縁があってグリー株式会社に入社しました。

自己紹介の詳細は以下をご覧いただけたら幸いです。

新卒エンジニア入社1年目でやってきたこと

グリーに入社後は、2週間の研修(ビジネスマナー等)に取り組んですぐに現場配属という流れでした。

そのため、私がアウモにジョインしたのは2021年4月の第3週目になります。

最初はSEO分析のためにGoogle検索結果をBigQueryに流す定期実行のrakeタスクを作成したり、一部の記事ページのデザインを改修するなど、取り組みやすいタスクを割り振っていただきました。タスクをこなしていく中で、システムの全体像の理解に努めました。

ここでは、アウモにジョインしてから現在に至るまでの約10ヶ月間で取り組んだ、割と大きめのタスクについてご紹介します。

サーバーレスポンス速度改善（LCP改善）

まずはRailsのサーバーレスポンス速度向上によるLCP改善の取り組みです。(詳細はこちら)

こちらはコアウェブバイタルのスコアの1つである、LCPを改善する取り組みで、私がアウモに配属されてから初めて取り組んだ大きめのタスクでした。

コアウェブバイタルとは、2020年にGoogleが発表したサイトのUXの重要指標であり、読み込みパフォーマンスを表すLCP（Largest Contentful Paint ）、インタラクティブ性を表すFID（First Input Delay ）、ページコンテンツの視覚的な安定性を表すCLS（Cumulative Layout Shift ）の3つのスコアで構成されています。

今回取り組んだのは、LCPが「不良」と判定されているaumo.jpのページを改善するというタスクでした。

このタスクを通じて、計測とボトルネック特定の重要性を感じました。

LCPを改善するにあたってまずLCPの評価に影響を与えている項目をリストアップしました。「今回改善が必要なページでは、どの項目に時間がかかっているのか」「かけられる工数と照らし合わせて、改善の実現可能性が高い項目はどれか」などを考えるのはクイズを解いている感覚で楽しかったです。

この取り組みの成果として、レスポンス時間の減少とLCPの改善が数字で目に見えて現れたことが嬉しかったです。

ユーザーバッジ機能開発

続いて新規機能開発面で取り組んだ大きめのタスクとして、ユーザーバッジ機能開発をご紹介します。(詳細はこちら)

ユーザーバッジ機能とは、アウモのアプリにて、ユーザーの口コミ投稿件数やコメント数、いいね数などに応じて、金/銀/銅のバッジが付与される機能です。

私はこの機能のサーバーサイドの実装を担当し、バックエンドAPIの設計から実装、テストまでを一貫して行いました。

こちらのタスクでは特に設計段階で学びが多かったです。バックエンドAPIでは多くのユーザーの投稿写真やコメントなどについて集計する必要がありました。設計では大量のデータに対する集計のパフォーマンスを考慮し、ElasticSearchの導入を検討するなど、ユーザー数を多く抱えるサービス特有の問題について深く考える機会になりました。

また、テストを書くなかでRspec(Railsのデファクトスタンダードであるテスティングフレームワーク)特有の書き方に慣れることができました。

上司やメンターには設計段階から頻繁に相談に乗っていただいたおかげで、無事リリースすることができました。

自動テスト導入・ウェビナー登壇

続いてご紹介するのは、GraphQL自動テスト環境構築の取り組みと、その内容についてグリーグループ広告メディア事業3社合同ウェビナーに登壇したことです。(GraphQL自動テスト環境構築の詳細はこちら。登壇の詳細はこちら。)

サービスの品質保証と変更容易性の観点から、日頃から自動テスト環境を構築したいと思っていました。そこで合同ウェビナーの登壇に合わせて、登壇ネタのために１週間程度工数をいただき、GraphQLの自動テスト環境の構築に取り組みました。

アウモでは一部サービスのバックエンドAPIにGraphQLを用いています。

この取り組みではGraphQLを（ある程度）網羅的にテストできるgraphql-autotestというgemを導入し、GithubActionでCI環境を構築するところまでを行いました。

graphql-autotestのおかげで少ないコードでGraphQLのtypeを網羅的にテストできるようになり、またGithubActionで特定のブランチにプッシュすると自動的にテストが走る環境を構築し大変勉強になりました。

またgraphql-autotestの導入にあたって、gemのソースコードを読み込みました。そのおかげで自分も知らなかったRubyの書き方を学ぶことができ、OSSのソースコードリーディングから得られるものの大きさを感じました。

登壇ではこれらの取り組みの内容について話しました。

自分にとっては初めての登壇で、非常に緊張しましたが、資料の作り方や伝わりやすい発表の仕方の工夫など、登壇を経験しなければ得られなかった学びが多くありました。

コーポレートサイトのWordpress・AWSへの移行

普段は主にサーバーサイドをRails(Ruby)、フロントエンドをVue(JS)で開発しているのですが、こちらの取り組みでは、コーポレートサイトのWordpressへの移行とAWSインフラ構築を行いました。

アウモのコーポレートサイトはこちらです。

こちらのコーポレートサイトは元々静的サイトとして運用されており、html/js/cssをgulpでビルドして、デプロイはAWS S3に配布するというような開発フローでした。

コーポレートサイトでのプレスリリースの頻度が増えるにつれ、CMSで投稿を管理したいというニーズが高まり、Wordpressへの移行が決まりました。同時にインフラ面も見直し、Auto Scaling × ECS × EFSでスケーリング可能な構成にしました。

こちらの取り組みを通じて、静的サイトをどのようなステップでWordpressに移行していけば良いのかを学ぶことができました。またインフラ面に関して、本TechBlogのAWS構成とほとんど同じですが、1から構築するという経験を通じて座学では得られない学びを得ました。aumo.jpなど主要サービスでも似たようなAWSの構成になっているため、このインフラ構築で得た学びはその後の業務にも活きています。

コーポレートサイトをWordpressに移行することで、以前までプレスリリース等を出す際に発生したエンジニア工数を削減でき、またWordpressのCMS機能(下書きや装飾、予約投稿など)により利便性が向上しました。

新卒エンジニア入社1年目で学んだこと

フロントエンド・インフラの知識

私は学生時代からAPI開発等サーバーサイド中心の業務を行なってきました。そのためフロントエンド・インフラは少し触ったことがある程度で、業務レベルでガッツリ取り組んだことはありませんでした。

アウモは事業ごとに担当のエンジニアがおり、サーバーサイド・フロントエンド・インフラはそのエンジニアが一貫して触ることができます。

私もアウモにジョインしてから、業務でフロントエンド・インフラを触り、自分の技術の幅を広げることができたと感じています。

今後は技術の幅を広げることに加え、一つの技術をさらに深めていくことにも注力したいと考えています。

ユーザー規模が多いサービスならではの開発視点

アウモでは多くのユーザーに利用いただいているサービスを開発するため、ちょっとしたイケてないコードでもDBへの負荷が増大してしまうなど、ユーザー規模が多いサービスならではの難しさを感じました。

また、巨大テーブルに対して頻繁にリクエストが発生する、かつ、リアルタイムでのレスポンスが求めらえる場合は、そもそもMySQL等のRDBへのリクエストをやめ、ElasticSearchに任せるなど、負荷を意識した技術選定の視野が広がりました

パフォーマンス向上といっても、N+1を解消したりテーブルにインデックスを貼るといった割とすぐに対応できるものから、すでに大量のデータが格納された巨大テーブルを再構成するというような時間をかけて取り組まなければならないものなど、いくつものやるべきことが分かり、今後もそれらに愚直に向き合っていきたいです。

ビジネス側とのコミュニケーション

アウモでは事業ごとにビジネス側とエンジニア側が密に連携して、開発を進めていきます。

そのため、エンジニアは要件にある機能をただ開発するだけでなく、要件の背景にある目的を把握して開発できるためビジネス側の視点を持つことができると感じています。

また、ビジネス側とエンジニア側が密に連携していると、開発中に生じる様々な課題に対しての解決速度も速いです。

サービスに求められる要件を素早く開発してリリースするためには、純粋な技術力に加え、ビジネス側と密にコミュニケーションをとっていく重要性を学びました。

最後に

ここまで私のアウモでの新卒エンジニア1年目の振り返りに付き合っていただきありがとうございました。

振り返ると、ここで紹介していないタスクも含め思った以上にいろんなことを経験したと実感しました。(振り返りって大事ですね)。また、私のような新卒エンジニアでも初めからスムーズに業務が遂行できたのは、アウモのエンジニアチームがとても気楽に質問できる環境だからだと思います。

今後も事業やチームに貢献できるよう引き続き精進していきます。