はじめまして。

2024年4月に新卒エンジニアとして入社した和田萌花です。現在はAI事業本部オペレーションテクノロジーディビジョンにて広告事業本部向けのレポーティングシステムの開発を行っています。

この記事は新卒エンジニア向けの研修の一環として行われた、約3週間にわたるハッカソン形式のチーム開発で最優秀賞を受賞した私たちのチームでの取り組みや技術的工夫点などをまとめたものです。研修や我々のチームの全体概要とiOS、バックエンド、ML、インフラそれぞれの技術的な取り組みについて全5記事で紹介していきます。

[ 関連記事目次 ]

2024年度開発研修最優秀チームの取り組みと研修全体概要
2024年度開発研修最優秀チームの高品質サービスを支えるインフラ構成
2024年度開発研修最優秀チームの研修 – iOS編
2024年度開発研修最優秀チームの研修 – バックエンド編
2024年度開発研修最優秀チームのお手軽自動コードレビュー & 推薦システム Cookbook~

上の記事から順次公開予定です。

私はチーム開発研修にてチームリーダーのような役回りをしていたので、私からは今年の新卒エンジニア向け研修の概要と私たちLチーム全体での取り組みについて紹介します。

新卒エンジニア研修概要

今年の新卒エンジニア向け研修の全体概要を紹介します。今年のテーマは「目標設計」でした。ハッカソン形式のチーム開発研修では、新卒エンジニア7〜8人とメンター2人でチームを編成し、約3週間でSNSサービスを開発しました。機能要件・非機能要件については必須で提示されておりそれだけである程度SNSサービスの形になります。その上でチャレンジしたいチーム向けにオプションの要件もいくつか用意されており自由に追加実装することもできました。

3週間という短い期間では必須要件だけでもギリギリ作り切れるかどうか微妙なラインの要件だったかと思います。そのためオプション要件まで取り組めたチームは少なかったように思えます。

またチーム開発研修最終日に成果発表会とそれに対する表彰もあったのですが、その表彰の際に評価されるポイントは以下の三つです。

①アイディアではなく、技術や開発プロセスを重視
②設計した目標に対し、どれだけ達成できているか
③AIをいかに活用できているか

この評価ポイントからも作成したSNSサービスの機能やアイディアではなく、目標設計やエンジニアとしてのソフトスキルやエンジニアとしての技術力が重視されていることがわかります。

また、AIの活用方法に関しては自由度が高かったために、一機能としてAIを盛り込んだり、AIを活用して機能のサポートをしたり、自分たちの開発の支援に使うなどチームごとに異なる色が出たようでした。

私たちのチーム目標は「必須要件に注力し質の高いプロダクトを完成させる」ことでした。今後の配属を見据え、本来他職種がすべき責務にかけるコストを最小限に抑え、現場のエンジニアに求められるであろうサービスの品質を担保することに注力しました。具体的には後ほど紹介しますが、世の中にあるサービスをオマージュすることでデザインや企画に割く労力を最小限にしたり、実際の開発現場で採用されているアーキテクチャを取り入れたり、セキュリティ的にも強固なサービスを目指してセキュリティテストを導入するなど必須要件を確実に達成できるような取り組みをしました。

私たちLチームが作成したSNSサービス

私たちのチームが作成したSNSサービスは以下のような画面です。

デザインや企画にかける労力を最小限に抑えるために、既存のSNSサービスに似通った見た目と挙動のサービスを作成しました。

チームとして全体で取り組んだこと

進捗共有

毎朝チーム全員で朝会、夕方に各領域ごとで夕会を行い進捗共有を行いました。朝会ではチームとしての一日のゴール、昨日のやったこと、今日やることを確認しました。夕会はiOSとその他の領域に分け、一日の進捗を確認し、開発環境から本番環境に上げるGithubのPull Requestを作成して再レビューを行うタイミングとしました。

スケジュール管理

開発タスクは領域ごとに細かくチケットを切り、GitHubのタスクカンバンとissueで管理していました。基本的には3時間ほどで終わるタスク量ごとにチケットを切っていたためにレビューもしやすく、一日の進捗も見てわかる形になりました。また、チーム全体でのタスク管理のためにクリティカルパスも作成しました。クリティカルパスとは、プロジェクトの全工程を最短で完了するための重要作業経路のことであり、誰にでも分かりやすくタスク進捗と手順、ボトルネックになる可能性のある点を可視化することができます。これをmiroを使って作成することで、専門外の領域のタスクでも進捗や関連性を理解でき、チーム全体の進捗が一目で分かるため、メンターへの進捗報告も容易になりました。

知見のドキュメント化

README設計やコーディング規約についてGitHubのwikiにまとめていました。その中には環境構築手順、実装方針とその意図をまとめた設計書、コーディング規約などをまとめて、手戻りの軽減と認識の統一化を行いました。また、今回の研修ではもちろんないのですが、今後メンバーが増えた時のキャッチアップコストやオンボコストを意図的に下げる取り組みにも力を入れていました。

GitHub運用体制

スムーズな開発と属人性の解消、より質の高いサービス開発のためにGitHub開発でのルールも設定し全員で守りながら開発を進めていきました。設定したルールの主な内容は以下の3点についてです。

タスク管理
- GitHubのカンバン、issue、Milestoneを活用
- 進捗がひと目で分かるようにタグ付けやテンプレートを設定し活用した
2 Approve制
- 最低2人からApproveを貰わなければmergeできない設定
- iOS、バックエンド、インフラ、MLそれぞれの領域ごとにほぼ全てのコードを読み、一定レベルは理解しつつサービス開発することで属人性の解消もできる
mainブランチ(本番環境)の保護
- mainブランチを本番環境、developブランチを開発環境として環境構築
- mainとdevには直接pushできないように設定
- devからmainへのpushはPRを立て毎日夕会にて全員で確認後pushする