はじめに
こんにちは！ テクノロジー戦略本部24年新卒の高橋です。 2023年の10月から出社メインで、開発2部にて内定者インターンを経験していました。 先輩エンジニアの方々や同期のインターン生と共に、日々切磋琢磨しながら働いていました。 内定者インターンでのカリキュラムの内容やそこで学べたことを共有したかったので、執筆に至りました。 少しでも、バイセルを志望する新卒就活生の参考になればと考えています。
内定時点での自分の経験
大学3年秋に、授業でプログラミングを学んだことがきっかけで、プログラミングの世界に足を踏み入れました。 専攻が化学だったので、それまでは触れたことがありませんでした。 それからプログラミングを学びたい気持ちが強くなり、大学を１年間休学する決断をしました。 その後4~5ヶ月の独学を経て、バイセルとは異なる受託開発企業でエンジニアインターン生として働いていました。 インターン先の案件では、以下のような技術に触れていました。
- フロントエンド
- React系、Vue系のライブラリおよびフレームワーク
- バックエンド
- Golang、HeadlessCMSなど
- インフラ
- AWS
内定者インターンの全体像
内定者インターンは大きく分けて、２つのフェーズに分かれています。
- カリキュラム期間
- 実務
学業などで忙しい学生でも、入社後しっかりサポートが受けられますので、ご安心ください。
1. カリキュラム期間
テクノロジー戦略本部では、内定者は実務へ入る前にカリキュラムをこなす期間が設けられています。 開発１部、２部および３部はそれぞれ指定された技術スタックで、指定された要件を満たすタスク管理アプリケーションの開発をします。 チームのメンターの方から、GitHubのPR上でコードレビューをもらいながら、完成へと近づけていきます。 完成後、マネージャーとメンターに対しての成果物の発表が終われば、実務に入れます。 また、1〜3ヶ月間が想定されていますが、指定の技術スタックの経験があまりなくてもカリキュラムはその人に合わせて長めに取れるので、ご安心ください。
2. 実務
カリキュラム修了後、配属されたチームで小さなタスクから開発を始めます。 実力次第で、大きなタスクを任せてもらえることもあり、ここからはその人次第となっております。
現在、私は配属後のチームで開発をしていますが、この記事では、カリキュラムの内容やそこで学べたことに焦点を絞って、お話いたします。
カリキュラムについて
カリキュラムの具体的な流れ
メンターと相談しながら決めたカリキュラムの具体的な流れを以下に示しました。
各実装フェーズ初期に、Jiraを用いてタスクを分解しました。
私のカリキュラム期間での働き方
私のカリキュラム期間（10月11日〜12月11日）での働き方は以下のようになっておりました。 学生は学業と両立が可能なように、柔軟に稼働時間を選択できる体制が整っています。
1週間のうち、火・木・金曜日の3日間、オフィスに出社し、勤務していました。
カリキュラムの技術スタック
指定された主な技術スタック（配属後に使用する技術）は以下になります。 （※ 言語やフレームワークを変えるなど、大幅な変更は配属後の技術に触れるという目的から逸れてしまうので許されませんが、軽量のライブラリを追加するといった程度は許容されています）
- フロントエンド
- Next.js
- TypeScript
- React Hook Form
- zod
- MUI
- Apollo Client
- GraphQL Code Generator
- バックエンド
- Golang
- gqlgen
- Gorm
- データベース
- PostgreSQL
- インフラ
- GCP
上記以外に挑戦したい技術があれば、積極的に採用できます。 私は、保守性や開発生産性を考慮し、以下の技術も採用いたしました。
- Storybook、Chromatic（コンポーネント管理およびVRT）
- Jest、Testing-LibraryおよびStorybookのPlay Function(インタラクションテスト) 1)
- PlayWright（E2Eテスト）
- Sentry（エラー監視）
- Terraform（IaC）
- GitHub Actions（CI/CD）
最低限満たすべき機能要件
本カリキュラムで開発するタスク管理アプリケーションでは、以下の機能要件が求められました。
- タスクおよびそれに紐づくラベルの作成・更新・削除
- タスク名およびタスク説明文による文字検索
- 優先度および終了日での並び替え
- ステータスおよびラベルによる絞り込み
成果物
私が作成したタスク管理アプリケーションを以下に示します。
アーキテクチャ
私がタスク管理アプリケーションを開発で用いたアーキテクチャを以下に示しました。
フロントエンド(Atomic Design)
タスク管理アプリケーションは使い回せるコンポーネントが多くあることやコンポーネントの粒度や責務の定義が自分の中で負担にならないことを想定して、Atomic Designを採用しました。Compositionパターンを使ったり、Apollo ClientやRHFの処理をCostom Hooksで切り出したりして、再利用性やテストのしやすさを常に考えていました。
バックエンド（記事 2), 3) を参考に作成したアーキテクチャ）
バックエンドの処理の流れとしましては、gqlgenで生成させたGraphQL Resolverから、ビジネスロジックを定義しているService層を呼び出しています。その後、DB操作のためにrepository層が呼ばれるという形です。ビジネスロジックからDB操作を隠蔽するために、repository層で依存性を逆転させています。DBやO/Rマッパなどのアプリケーションのコアではない部分を切り離し、変更に強い設計を目指しました。さらに、タスク管理アプリケーションはDB操作が肝だったので、Daoから実体を注入できるような作りにしました。また、今回は使いませんでしたが、後からRouterやLogのライブラリを追加できるようにしました。
インフラ
開発環境では、docker-composeでNext.jsのサーバー、GolangのサーバーおよびPostgreSQLのDBサーバーが起動するようになっています。本番環境では、まずユーザーがフロントエンドのURLへアクセスした際、Cloud DNSで名前解決がされます。ドメインに紐づくIPアドレスはCloud Load Balancingに紐づいています。また、Cloud Load BalancingはIP制限のため、Cloud Armorで保護されています。その後、Cloud Runで起動しているNext.jsサーバーへたどり着くという流れになっています。Next.jsサーバーをCloud Runでホスティングしている理由としては、ページをSSR(サーバーサイドレンダリング)することでOGP対応を実現したかったからです。Golangのサーバーへのアクセスも同じような仕組みになっています。DBにはCloud SQLを採用し、Golangのサーバーと通信させています。
CI/CD
フロントエンド、バックエンド、インフラそれぞれで各ディレクトリへpushされた際にCI/CDが動きます。フロントエンド、バックエンドへそれぞれ、LinterやFormatterのような一般的な開発では必須のものを先に作りました。また、PR作成時にCloud Runへデプロイされ、タグ付きリビジョンのPreview環境を用意し、マージされたタイミングで本番環境のリビジョンへトラフィックを移すというCI/CDパイプライン4)も構築しました。開発初期にCI/CDパイプラインを構築する経験は今までなかったため、開発途中で本番環境での動作確認ができ、恩恵を受けることができました。
インターンを通したコミュニケーション
同期とのコミュニケーション
毎日14時から30分間のミーティングが設けられており、稼働している同期にわからないことの相談や雑談ができます。 自分を含めWeb系エンジニアは様々なバックグラウンドを持った人が多いので、「プログラミングをやり始めたきっかけは？」「なんで、バイセルを選んだの？」など、共有や相談以外にもこういった会話までざっくばらんに話していました。 そういった中で、同期同士の距離が少しずつ縮まったことを考えると、非常に貴重な時間だなと感じました。
先輩とのコミュニケーション
メンターの方が週1で30分の1on1ミーティングを開催してくださります。カリキュラムでわからないことや悩んでいること以外に、「将来どのような方向性で働いていきたい」「バイセルではどのようなことがしたい」など、現役エンジニア目線での回答が聞けて、参考になりました。 また、直接コミュニケーションができない場面でも、SlackやGatherで質問すると迅速に対応してくださるので、非常に働きやすい環境だなと思いました。
カリキュラムを終えて
学べたこと
技術的な部分ではCustom Hooksを用いてUIとロジックを分離すること、GolangでのDIの仕方、Composite Actionを用いたActionへの切り出しなど、様々なことを学べました。
ですが、個人的には技術的な部分よりも非技術的なところがすごく学びになったので、そちらに焦点を絞ってお話できればと考えています。
非技術的なところで学べたところに関しては、自分の強みと弱みを明確に把握できたことです。
自分の強みは、新しい技術に対しての好奇心が高いことやすぐに環境に馴染める対応力だと、カリキュラムを通して感じました。カリキュラムでも触ったことのない技術が出てきた際に、インターネットで調査し、その技術の概要や使い方を自らキャッチアップできる力があるとわかりました。環境に馴染む対応力に関しては、バイセルで働くのは初めてだったのですが、メンターの方やチームのメンバーと気軽に話せたり、打ち解ける速さは結構早かったことが挙げられます。
また、自分の弱みは開発工数の見積もりが甘いことや、１人で考え込んでしまう時間が長いことだと気づけました。開発工数の見積もりの甘さに関しては、見積もった時間と実際に掛かった時間の差分が大きいところから、自分の中でタスクに対しての解像度が高くないまま、着手してしまっていることに気づけました。さらに、自分の力で解決しようとし過ぎて、「気づいたら時間を大量に消化してしまっていた」なんてことが多々ありました。
配属後、どう活かせているか
配属後、上記の弱みに対して、メンターの方と話し合いながら、対策を講じました。
- 開発工数の見積もりの甘さ
- 仕様周りに対して、徹底的にチームメンバーと認識合わせを行う。
- １人で考え込んでしまう時間が長い
- 一定時間（15分から30分）考えた時点でわからなければ、timesチャンネル（なんでも呟けるチャンネル）に投げたり、Gatherで先輩エンジニアのところにいく。
上記を遂行することで、配属先のチームでは積極性が高く評価される場面や報連相の質と速度が向上していると自分でも実感する場面が多々あり、先輩方のマネジメントコストの低下が計れているのではないかと感じています。
まとめ
最後まで読んでいただき、ありがとうございます。
新卒の私が内定者インターンで学んだことについて紹介させていただきました。
現在は、Portalチームで働いています。
Portalは、Cosmos（総合リユースプラットフォーム、プロダクト群）の利用者が業務を開始する前に各サービスの利用状況や業務実績のダッシュボードを確認できる、いわば「玄関」的な役割を果たしているプロダクトです。ですので、Portalに訪れればすべての情報が揃っている状態にすることが、Cosmosにおける責務とされています。
また、実際に利用するユーザーからのニーズに応えたり、新規機能の提案など、事業部と掛け合いながらこれから成長するプロダクトとなっています。ですので、技術で利用者の課題を解決する力、自ら主体的に動ける力、事業部に提案する力など様々なものが求められています。
それでも、悩んでいるときや困ったときには先輩方がすぐにフォローしてくれ、難しいタスクにもチャレンジさせてくれる環境を提供してくれているので、成長を求めるエンジニアには適した環境だと感じています。
バイセルでは、新卒エンジニアを募集しておりますので、少しでも興味のある方はぜひご応募ください。
recruit.buysell-technologies.com
参考記事
1) https://zenn.dev/silverbirder/articles/c3de04c9e6dd58
2) https://kaminashi-developer.hatenablog.jp/entry/2020/10/14/093000
3) https://zenn.dev/hsaki/books/golang-graphql
4) https://blog.g-gen.co.jp/entry/deploy-preview-using-cloud-run-tagged-revision
