2021年11月の1カ月間株式会社サイバーエージェントさんでフロントエンドエンジニアとしてインターンをしてました。今更感はありますが、やったことや学んだことや感想など自分用のメモとしてまとめておきます。<h2 id="h1388d7e348">採用まで</h2>インターン採用までの流れとしては、ES選考 → 一次面接 → 二次面接 → 参加という感じでした。面接では自分が書いたESを基に非常に雰囲気良く会話形式で進んでいきました。二次面接の終わりに「インターン参加していただきます」と言われたので少し驚きました。その後、配属先のメンターの方との面談を経て実際に11月から実務へ移るという形になりました。私が配属されたのは<a href="https://dokusho-ojikan.jp/" target="_blank" rel="noopener noreferrer nofollow">Amebaマンガ</a>という事業でした。<h2 id="h2220f0ef7d">やったこと</h2>端的にいうと、Webフロントエンドのパフォーマンス改善を行いました。<a href="https://developers.cyberagent.co.jp/blog/archives/30577/" target="_blank" rel="noopener noreferrer nofollow">CLS改善をした結果事業成果がグンと上がった話</a>こちらの記事にもある「SpeedCurveを垣間見る会」にも参加させていただきました。指標を見る→課題を見つける→考察&amp;改善方法を検証する→タスク化→実装とリリース→指標を見るというフローを経験できました。その中で、今回僕が行なったのは大まかに分けて<ul><li>マイページのCLS改善</li><li>Reactにおける再レンダリング対策</li></ul>です。それぞれ簡単に解説しようかと思います。<h3 id="hfed09d2cbb">マイページのCLS改善</h3>CLSとはGoogleの提唱する<a href="https://developers-jp.googleblog.com/2020/05/web-vitals.html" target="_blank" rel="noopener noreferrer nofollow">Core Web Vitals</a> の1つです。よくある体験としては、「送信ボタン」みたいなものをタップしようとしたら広告が入り込んできて広告をタップしちゃうみたいなことです。今回マイページにおいてCLSが起こってしまっていた原因は、データのローディング中とロード後で要素の大きさが変わるためでした。そこで、ロード後に来るであろう要素を先にスケルトンという形で用意しておく、というものです。スケルトンについては<a href="https://engineering.linecorp.com/ja/blog/front-end-otoshidama/" target="_blank" rel="noopener noreferrer nofollow">こちらの記事</a>が分かりやすいかと思います。実際にCLSの数値が改善されており嬉しかったのを覚えています。<h3 id="h3404c5c538">Reactにおける再レンダリング対策</h3>whyDidYouRenderというライブラリで不要に再レンダリングが起こってしまっている箇所を修正しました。ここではなぜ不要に再レンダリングが起こってしまっているかの調査から原因を特定し、解決策を考え実装し、なぜその解決策で上手くいったのかというところまで体験できたので非常に楽しかったです。これについては別記事で詳しく述べたいと思います。<a href="https://10shin.net/blogs/s263wet-7" target="_blank" rel="noopener noreferrer nofollow">→書きました</a><h2 id="h447d69583c">学んだこと</h2>今までのインターンや個人開発では小さめのプロダクトが多かったので、初めて大規模な開発に携わったため学ぶことが非常に多かったです。また、技術的な学びだけでなくマインド面での気づきが多かったように思います。<h3 id="h5db61149aa">大規模開発における設計や実装と開発フロー</h3>単に設計と言ってもその時点のベストプラクティスとか最新でモダンな技術を取り入れたら良いいいわけではなく、URL共存しなきゃいけないとか人材の確保の容易さとかのビジネス要件も考慮する必要があるというのは新たな発見でした。そのときのリーダーの思想によって設計が変わったりすることがあったり全ソースコードまで目が通せなかったりというのは大規模開発ならではだと思いました。また、commitメッセージがテンプレート化されていたり、commit時にlinterが走ったり多くのコメントがあったり、変数名に規則性があったりと大規模開発をする上で整備されると望ましい部分についても学ぶことができました。<h3 id="hf72e369568">なぜそうなるかまで考えて実装する</h3><h3 id="hcf83e1357e"></h3>memo化すれば再レンダリングさせなくできる、でそのままタスクは終了することは出来ますが、それが何故なのか原因は何かまで掘り下げることでその部分の修正だけでなくもっと抽象的に全体の修正に応用ができ、結果的に全体でみると近道でさえあるという良い経験ができました。このように思考しながら実装することで未知の問題に当たったときの引き出しも増えると思うのでこの考え方は大事にしたいと思います。<h3 id="h529054f8d5">Webパフォーマンスについて</h3>Webパフォーマンスについてどのような態度で向き合うか理解が深まりました。数値を見たときにそれが何故その数値になっているか考察するという点が重要だなのだと学びました。LCPの数値悪くなっていたが、例え数値が悪くなっていたとしてもクーポン訴求が起因だった場合、事業的優先度を踏まえると現状は難しいので原因把握に留めておく、とか、再レンダリング修正の実装が長期的に見て徐々にメモリ利用減少に繋がっているのではないか、みたいな事例を「SpeedCurveを垣間見る会」で経験できたので良かったです。<h3 id="hde9197008c">マインド面</h3>自分から積極的に人と関わり前に出て何かに参加することはビジネス職、エンジニア職関わらず大事なのだと学びました。今までもなんとなくそういう人って評価されるよねという実感こそあったのですが、なぜそのような人が評価されるのか、チームや会社にとってプラスになるのかまで少しだけ理解できた気がします。例えばある部署で良い知見を得たときにそれを全社向けに発信できる人がいるとプラスになるし、人と積極的に関わりを持っているとある問題を解決するときにこの問題なら他部署の〇〇さんが詳しいから聞けるかもみたいなこともできるなと思いました。粛々とタスクをこなすだけでは人と人から生まれるシナジー効果が薄れるという点でもっと能動的に人を巻き込んで行動することの重要性を学びました。<h2 id="h1cb1ed03f9">待遇や環境や感想</h2>時給は1500円でした。交通費も実費で出ました。コロナ禍ということもあり、出社は週3だったのですが、もれなく出社日には美味しいランチへ連れて行っていただきました。渋谷の美味しいランチは制覇した気でいます()また、本当にいい人、いい方が多いという印象を持ちました。とにかく雰囲気が良く、質問すればタスクに関係ないことでも気さくに答えてくださったり、業務外のことでも優しく話しかけてくださったため参加前に不安だった気持ちは1日目にはなくなっていました。また、どうすれば私が1つでも多く学びを多く持ち帰れるか、という視点でタスクを振ってくださったり、毎週メンターさんと人事の方とミーティングが組まれており、そこで自分に足りない点やアドバイスをくれたりなどとにかく素晴らしい体験となりました。偉そうなことは言えませんが、参加するか迷っている方がいたら絶対に参加した方が良いと思います！