📝

1年間のフロントエンド開発インターンで得た学び

に公開

こんにちは、株式会社TechBowlエンジニアインターンのnova27(@novablog_diary)です!

インターンに参加し始めてから約1年が経過したので、振り返りがてらアウトプットしようと思います!

インターンを始めたきっかけ

インターンは大学1年生の6月から開始しました。
大学入学時に新しくできた友人(入学前からXで繋がってはいました)が以前からTechBowlでインターンをしていたとのことで紹介してもらいました。

「入学してバイト始めようと思ってたし、Next.jsの開発経験を活かせるからめっちゃいいじゃん!」と思って、カジュアル面談を経てすぐにジョインしました。

業務内容

フルリモート&フルフレックスタイムで好きな場所・時間で仕事しています。この記事に貼っているスクショを見てわかる通り、私は夜型人間なので夜に作業してました...(会議が必要なときは日中に仕事してましたが)
学業に合わせて自由に仕事量を決めることができるので非常に助かっています。
私はここ1年間フロントエンド(Next.js)を担当していました。

企業HPのリニューアル(2024年6月~10月)

最初に任されたタスクはリブランディングに伴う企業HPのリニューアルでした。
社員デザイナーさんが作成したデザインをもとに、私ともう一人のインターン生の2人で実装作業を担当しました。

初めてのチーム開発だったので「ブランチ運用よくわかんないな...」と思いながら作業してましたが、PR作成&レビュー依頼を繰り返していたら自然と身についていきました。

後半はブラウザ固有のバグに見舞われて困ってました。意外とブラウザ間で挙動が違うんだなーということを学びました。

TechTrain Mediaの改修(2024年10月~11月)

次に任されたタスクはTechTrain Mediaの改修でした。
記事一覧ページでカテゴリ別に記事を表示するように変更するのと、記事詳細ページの下部に関連記事やナビゲーションを追加する作業を担当しました。

企業HPはイチからコードを書いたので比較的自由に実装していましたが、今回は主要サービスであるTechTrainの改修だったので、大規模な既存のコードと上手く組み合わさるようにコードを書く必要があり苦労しました。
どのファイルをどのように修正すれば良いのか把握するのが大変で、慣れないうちは修正に時間が掛かっていました。さらに複数人が同じリポジトリで開発していたのでコンフリクトが頻繁に発生して解消に苦労していました。

タスクを細かく分割してこまめにmainにマージするとコンフリクトが起こりにくいと教えて頂きました。

追加の作業として、ステージング環境のCSRでログイン判定が上手くできない問題も解決しました。
調査してみたところMediaページ自体に問題はなく、奥深くのAPI呼び出しを抽象化する処理に問題があることが発覚しました。
バグを解決するときには、処理の流れを丁寧に追って確認することが大切だと感じました。

求人票の実装(2024年11月~2025年5月)

この期間は、ほぼ一から求人票機能を実装するという大きなプロジェクトに取り組みました。
フロントエンドは業務委託の方と2人で担当し、私は主に求人票詳細ページの作成を進めました。

作業量がとても多く(かつ春休みを満喫して私の稼働時間が少なかったせいもあって...ごめんなさい)、半年ほどかけてじっくりと開発を進めました。
このタスクはデザイナーやバックエンドなど多くの方々と連携する場面が多くあり、情報共有やコミュニケーションの取り方について特に意識する必要がありました。

つい先日やっとのことで求人票機能がリリースされて、大きな達成感を感じました!

意識したこと

保守性の高いコードを書く

個人開発とは違って仕事はチーム開発なので、他の人が分かりやすく修正しやすいコードを書くようにしました。

コーディングスタイルはlinterやformatterが修正してくれますが、コンポーネントの設計や処理の詳細は自動で修正されないため、他の人のコードを参考に良いコードの書き方を学びました。

特殊な利用シーンを想像する

入力項目が未入力だった場合や想定外の手順で操作された場合でも不具合が起きないか確認するようにしました。

全てのパターンについて仕様書に書かれているわけではないため、曖昧な部分に関しては他のエンジニアに確認するようにしました。

「人間はミスをする」という前提で考える

仕事中にそこそこ大きなミスをしてしまったことをきっかけに意識するようになりました。
どれだけ気をつけていても人間はミスをしてしまうモノなので、ミスにすぐ気づいたり未然に防いだりする仕組みを構築・利用するようにしました。

確認内容をテキストに書き出すというような心がけだけでも効果があると思います。

技術的な学び

並行処理

TechTrain Media改修時に得た学びです。

記事はmicroCMSで管理されているのですが、深く考えずに直列でAPIを呼び出すようにしていたところ、ページの表示に2秒ぐらい掛かってしまうようになりました。
レビューを依頼したときに「Promise.all(Promiseを並行で待機するメソッド)を使うといいよー」と教えて頂き、アドバイスをもとに変更したところ0.5秒ぐらいまで改善され、ちょっとした工夫の重要性を感じました。

Container/Presenterパターン

TechBowlのフロントエンドコーディング規約では「Container/Presenterパターン」を使うことが定められています。
簡単に言うと、データ取得や状態管理部分(Container)とUI(Presenter)を分離する設計手法です。
TechBowlではpresentationライブラリを用意して、TechTrainやDirecTrainなどの各プロダクト中のContainerから参照できるようになっています。

PresenterはバックエンドAPIのデータ構造に依存しないため再利用性が高まります。
またstorybookを導入しているため、先にデザインだけ実装して確認し、それが完了したらバックエンドとの通信部分を実装するという流れで作業できた点も良かったです。(今回は先にバックエンドAPIが実装されていたのであまり恩恵は感じませんでしたが、バックエンドの実装を待たずにUIを先に作れるといったメリットもあるそうです)

TechBowlではPresenterから更にpages(ロジックを含まない、ページデザインのみ)やwidgetに分割して管理しています。Presenter/Containerパターンと似ている設計手法であるAtomic Designよりもシンプルさを保ちながら、必要なコンポーネントを探しやすいディレクトリ構造になっています。
超巨大なプロダクトを扱っているわけではないので、Atomic Designほどの細分化は必要ないのだろうと思います。

求人票のOGP画像自動生成

求人票詳細ページ実装の一環として、OGP画像自動生成機能も作りました。
完成イメージだけ渡されて「どうやって実装するかは自分で調べてみて」と言われ、情報収集から実装までを自力でやり切りました。

OGP画像は各求人票の情報に合わせて自動で生成されています。

TechTrainはVercelでサービス提供しているので、OGP画像APIの提供にはVercelのEdge Runtimeを利用しています。
内部的には@vercel/ogというライブラリを用いています。他にはnode-canvasで生成する方法も見つかりましたが、@vercel/ogはJSX(html/css)でレイアウトを作成できるのでより直感的だと感じ、採用しました。

通常のhtml/cssよりも制限が多いため、公式ドキュメントとにらめっこしながら試行錯誤しました。
特に画像とフォントの扱いには苦労しました。リモートリソースをfetchする形で実装していたところ読み込み時間が長くなってしまったためローカル読み込みに変更しようとしたのですが、公式のサンプルコードを真似ても上手く動作せず、上司にアドバイスを貰って実装しました。

貰ったアドバイス

与えられたタスクをしっかりこなせていると褒めて頂きましたが、一方でもっと成長できるように幾つかアドバイスを頂きました。

エンジニアとしてのこだわりを持つ

ここでの「こだわり」は、UIやコードで「○○の方がいいだろう」と自分なり考えて実装することです。
上司にすぐに意見を仰ぐのではなく、自分なりに考えることが重要です。
仕様書に書かれていないような細かい部分に関しても、ユーザーや社内の開発者のためにどのようにすべきか考えて実装すると、より良いサービスを作ることができます。

先回りする

実装するうえで確認が必要なことを「事前に」確認して仕様を詰めることです。
私はタスクを与えられたら取り敢えずコードを書いて、疑問点が出てから随時確認することが多かったです。
しかし確認するごとに返信を待って作業が止まる時間ができてしまうので、そうではなく実装前に事前確認することでスムーズに仕事が進むとのことでした。

ドメイン知識をつける

技術的な知識だけではなく業界や会社特有の知識を身に着けることです。
私は会社の事業内容に関する理解が不十分で、求人票という新しい機能を実装するときに何が何のための実装なのかあまり理解できていませんでした。
ドメインモデル図を参照したり、よくわからない部分を聞いたりして業務フローについて学ぶことで、機能を実装する際の参考になりました。

感想

このインターンを通じて、とにかくやりがいを感じました。
個人開発と違って非常に多くのユーザーに利用して頂けるため「こんなにも多くの人が使っているサービスを作ってるんだぞ!えっへん」と思いながら開発していました。
また、機能を実装したり不具合を修正したりした時に社員の方々に褒められて嬉しかったです。
好きなことをしてお金が貰える点も良かったです...(小声)

風通しの良い会社で働きやすかったです。
バイト経験ゼロで最初は緊張していましたが、コミュニケーションが軽い感じでリラックスして仕事できました。
slackのtimes文化や月1の1on1など、気軽に相談できる環境が整っていました。

「15分悩んだら質問しよう」みたいな文化もあります。
以前オフィスで仕事をしたとき(普段はフルリモートですが、東京に用事があったついでに寄りました)、「ここ上手くいかないんですよね...」「あーこうしたら動くかもー」「おーできたー!やったー!」という会話が地味に楽しかったです(笑)

反省点

まずは、稼働時間がバラバラだったことです。
フルフレックスで仕事量を自分で調整できるのですが、マイペースに進めすぎて少しの作業に長期間掛かるようなときがありました。
社会人になったら納期に追われるようになると思うので、今後は計画を立てて作業完了までの見通しを持つようにしたいと思いました。
(このインターン体験記も個人的に期限を決めて書いています。すでに期限を超過していますが...)

また、アドバイス頂いた「こだわりの発揮」や「先回り」をあまり実践できていませんでした。
今後は、仕様書に書かれていないことも事前に考慮して実装を進めたいと思います。

まとめ

刺激が多くて1年があっという間に感じました。
次はフロントエンドだけでなくインフラ分野にも挑戦する予定です。AWSとTerraformを使いこなします!
これからも成長し続けられるように頑張りたいと思います💪

TechTrainテックブログ

Discussion