新卒研修紹介とチーム開発前にやったこと

この記事はSafie Engineers' Blog! Advent Calendar 1日目の記事です

導入

はじめまして！2024年に入社し、現在は第4開発部コアデバイスグループに所属しております山口と申します。
今回は、2024年新卒エンジニア研修の紹介をしたいと思います。

導入
新卒研修の軽い紹介
チーム紹介　
開発体制について
タスク管理について
コーディング規則
チーム開発前にやったこと
まとめ

新卒研修の軽い紹介

セーフィーの新卒研修ではチーム開発をおこなっています。チーム開発を通してチームマネジメント・開発（フロント、サーバ、デバイス、CI・CD）・運用・保守を学んでいくのが目的になります。

チーム開発では、2024年度の新卒エンジニアは7名で「社内の負」を解決するシステムについて、アイデアを出し合って開発しました。新卒エンジニアメンバーで話し合った結果、社内で用意されている「異才ランチ」という福利厚生制度に着目し、これを活性化しようという話になりました。

異才ランチを効率化するシステムについては他のテックブログで紹介があると思いますので、本記事では頭出し程度にしておきます。
また、新卒研修のトレーナーには去年の新卒の方々が担当してくださっています。

新卒エンジニアメンバーが執筆した記事については以下リンクをご参照ください！

チーム紹介　

新卒研修を始めるにあたってチーム名とロゴを作成しました。
今後会社で24卒エンジニアと認識されるより、チームとして認識してほしいこと、チームとして一体感をだしたいなどが理由です。

チーム名には悩みましたが、各メンバーの頭文字をとって

SSSTIFY（トリスティフィー）

と命名しました。
ロゴは新卒デザイナーに作成してもらいました。こちらも何度かやり取りを繰り返し、最終的に以下のようなデザインになりました。

このロゴは開発したプロダクトでも使用しています。

開発体制について

チーム開発でプロダクトをリードするプロダクトリーダーと技術まわりについてリードするテックリードといった役割もチームで選出しました。
出社する頻度もチーム内で決め様々な働き方を試してみて、自分にはどの働き方があっているかなども考えました。

リモートワークでのコミュニケーション方法について考え、我々は「Gather」を使用してみました。リモートワークの際、Gatherではマップ上で話しかけたい人の近くに移動すれば会話ができるので、現実でちょっと話を聞きに行くみたいな感覚に近いものがあって気軽に相談もできたのが良かったと思います。

下記の画像は実際に開発中に使用したGatherの画像になります。

利用ルールは下記のように定めていました。

利用ルール
- 利用する曜日：月・水・木
リモート可能な日に利用
- リモート：月
- 出社：火・金
- 自由：水・木
ログイン時間：出勤時～退勤時まで
利用範囲はSSSTIFYの7名とする
- 他者の招待は原則NG
- トレーナーさんなど参加が必要な場合は相談
カメラは常にON
マイクは基本OFF、話しかける際にON
- 雑音などを拾う可能性があるため
全体のミーティングはGoogle Meetを利用
- 個人間の話し合いではGather上で画面共有など利用可
チャットはSlackを利用し、Gatherでは使わない
- 履歴を残しておくため

我々のチーム開発ではアジャイル開発を取り入れ、スプリントごとに各領域の開発をできるようにもしました。
例えば、今スプリントでフロント開発していた人が次回スプリントではデバイスの開発をしているといった感じです。
下記のように開発に向けたチームの目標を決めていました。

チームでやりたいこと（目標）
- 型にはめたスクラムを経験してみる
  - レビューを定期的に受ける（進捗定例）
  - スプリントを２周以上回す経験をする
- 使ってもらえるプロダクトにする
  - 満足度などの定量指標を設ける
  - 自分が使いたいプロダクトを作る
- 全員が全ての技術に触れる
  - 1スプリントで二つ以上の技術を触れることが目標
  - いっぱいタスクを消化している人にどんなタスクあるか相談するのもあり
  - チケットは基本メインの技術スタックをとっても良いが、他の分野についてはレビューで寄与する
  - レビューでは動いたからOKといったものではなく、積極的に実装者やその他の関係者に質問するなど理解を深めるよう意識する

タスク管理について

タスク管理には「Backlog」を使用しました。
チーム開発ではgitのbranch名をBacklogの課題IDと紐づけることでgithub上でプルリクがマージされたらBacklog上でのチケットも完了ステータスに移行するようにし、なるべく繰り返し作業を減らすことを意識して開発に集中しやすい環境を目指しました。

githubのプルリクとBacklogのチケットが紐づいていることで、どのチケットに対するプルリクなのかも一目で判断でき履歴を追いやすいのも良かったです。