こんにちは。エンジニアの高詰です。
LIFULLでは新卒入社2年目のエンジニアを対象にしたSET研修が開催されます。 SET研修は2年目の若手エンジニアが中心となりプロダクトをスクラッチから自分の手で開発することでWebエンジニアとしてステップアップすることを目的としています。
この記事では、研修での取り組みや研修中に直面した問題や学びについて紹介します。
SET研修とは
SET(Sophomore Engineers Training)は新卒2年目のエンジニア3〜4人チームでAWSや外部サービスを利用し、16営業日内に1つのプロダクトを作る研修です。期間及び予算は決まっていますが、それ以外はすべてチーム内で決める必要があります。
研修中のサポートは先輩エンジニアがメンターとなり開発相談やコードレビューを行います。他にも社内に数人いるベテランのスペシャリストエンジニアにいつでも相談できるようになっています。 SETは下記を目的として毎年行われています。
- プロダクトを作る全段階を経験することでwebサービスの全体像を把握し、エンジニアとしての引き出しを増やす
- 業務では携わる機会がなかった分野に触れて幅広い能力を身につける
- 自分の苦手分野を正しく認識し、スキルセットのバランスを整える
- サポートメンバーのフォローを受けつつ、プロのエンジニアとしての知識を効率よく得る
研修の全体の流れは下記になっています。また、第一実装期間および第二実装期間は通常業務から外してもらえるので開発に集中できます。
- 個人の目標設定
- 作成するサービスの検討
- サービスの全体設計
- 第一実装期間（8営業日）
- 第二実装期間（8営業日）
- 研修成果の社内発表
個人の目標設定
SET研修ではまず最初にメンバーそれぞれが研修を通して覚えたいことの目標を決めます。研修の目的に書いてある通り、通常業務では携わる機会がない分野や苦手な分野を中心に目標を設定することが推奨されています。
私の場合、通常バックエンドエンジニアとして既存のHOME'Sのプロダクトの改修や機能追加をメイン業務として行なっているので、個人目標には開発のベースとなる技術選定やインフラ部分に力を入れるような以下の項目を目標として設定しました。
- 技術選定及びインフラ設計の経験を積む
- デプロイの設定ができる
- サーバーの仕組みと設定が理解できる
- ミドルウェアを正しく実装できる
作成するサービスの検討
私たちのチームは交換日記サービスを選びました。
このテーマを選んだ理由としてはCRUDが満たせること、認証機能が必要であること、設計が複雑すぎないこと、メンバー全員の目標を満たせるテーマだったことです。
チームメンバーが3人いたので開発はそれぞれの個人目標を考慮し、インフラ及びサーバー担当、インフラ及びアプリケーション担当、アプリケーション担当の3つに分けました。私はインフラ及びサーバーを担当したので、開発期間前からサービス全体の設計の検討を行なっていました。
サービスの設計および実装
アプリケーション
今回開発したアプリケーションはMVC2パターンを採用しており、Expressを使用したモノリシックアーキテクチャで動作しています。
URLのルーティングに関してはDHH流のルーティングを参考にし、Controllerもそれに合わせて設計しました。
ModelはActiveRecordの考え方を参考にして開発しています。
View周りはPreactを採用しています。
今回はフロントエンド部分の開発を個人目標に入れているメンバーはいなかったので、View周りの設計やライブラリは最小限に抑えて他部分の開発により多くのリソースを割けるように調整しました。
データベースへのアクセスはTypeORMを利用することで型安全なデータ操作できるようにし、認証・認可には AWS Cognitoを活用してユーザー管理と認証を実装しました。また頻繁に必要になるデータはRedisを使ってアクセスすることでレスポンス速度を上げるように心がけてプロダクトを作りました。
インフラ
サポートチームへ相談する際もgithub上でのコードを確認してもらうだけで済んだので効率よく開発を進めることができました。
設計面ではウェブサーバとアプリケーションサーバを分けることで、ウェブサーバのキャッシュ機能やプロキシ機能を使って効率よくリクエストをさばき、アプリケーションサーバに不要な負荷がかからないように注意しました。
静的ファイルはS3を使ってクライアントに返すことで高速化も図っています。
AWS CloudFrontを使う案もありましたが、時間の関係で今回は実装していません。
アプリケーションはDockerを使って開発していますが、勉強のためあえて便利なECSは使っていません。
ログ周りやインスタンスが落ちた際の設定、セキュアな環境変数の渡し方などの工夫が必要なEC2を用いてデプロイしました。
EC2で実行されているDockerが何らかの原因で止まってしまった時に再実行できるような設定や、CodeDeployなどのAWSサービスに対応できるように設定したAMIを作成し、インスタンスが落ちてしまった際も自動で早く立ち上がるための工夫もしています。
デプロイ
研修期間が短いので効率よく開発サイクルを回せるようにAWSのCode Pipelineを用いて自動デプロイを実現しました。
EC2を使っているためデプロイは以下の手順で進行します。
- 研修用に立ち上げたリポジトリにmainへのpushを検知すると自動的にコードをビルド
- ビルドに問題がなければECRへDockerイメージをプッシュ
- EC2インスタンスを新しく立ち上げ、Dockerイメージ及びAWS Secret Manager環境変数を取得し、イメージを実行
- Blue/Greenデプロイで旧インスタンスと新インスタンスを入れ替える
- 上記手順に何か問題があった場合はデプロイ開始前のバージョンに切り戻す
デプロイ結果はSlackに通知が届くように設定したので、研修中はコードの実装に集中できるようなりました。
実装期間中のプロジェクト進行
実装期間前にひとり一人が担当する実装箇所や設計のすり合わせを行うことでスムーズに研修開始時と同時に開発を始めることができました。
実装期間中は毎日チームメンバーで10分ほどの朝礼を行いました。
前日の進捗及び当日やることについて報告を行うことで、何か困っているメンバーがいないかを確認し、期間中に終わらなさそうなものがあれば優先順位の変更を行い、メンバー全員の目標を満たしつつ最低限動くものを提出できるようにタスク調整しました。
また、第一実装期間と第二実装期間の間にメンバー内で振り返り会を行うことで開発中に起こった問題点を洗い出し、改善策を一緒に考えることで第二実装期間のタスクマネジメントをより良い方法で行えたと思います。
実装期間を終えての反省点
個人的な反省点は大まかに以下の3つです。
- 要件定義や画面構成の認識合わせが足りていなかった点があったので、詳細なところまで文章化するべきだった
- 何を決めるにしても明確な数字を出すべきだった
- タスク見積もりが甘く、思ったより時間がかかることが多かった
①に対しては口頭で話し合っていても各自のイメージが違っている可能性を考慮していなかったことです。
忘れることや記憶違い、認識違いが発生していたので実装開始前のサービスの検討のフェーズでメモだけではなく詳細にプロダクトのイメージを文章化すれば避けられた問題だと思いました。
②については①の問題と関わってくるのですが、何か依頼する際には明確な数字を示さなかったことが原因でチーム内で問題が起きました。
「多め」や「なるはや」などの曖昧な言葉の解釈は人によって違うので、定量や日時を明確にした上で進めるべきでした。
③に関してはお互いに初めて使うツールや設計で開発したので、開発期間で実際手を動かしてみると想定した以上に時間がかかることが多発しました。
タスク分割が大きいということに気づけないまま実装期間に進んでしまったので、極端に負担がかかり過ぎているメンバーが生じたり、期間内に終わらせることができないことが途中で発覚するなどの問題が起きました。
この問題についてはプロダクトマネジメントを経験しないとわからない部分だと思うので今回は大変貴重な勉強機会でした。
研修で問題点に気がつけたことで本業務ではもっと精度が高いスケジュールの見積もりができるようになると思います。
学び
本業務ではあまり携わる機会のなかったAWSの各種サービスを活用し、インフラ構築やデプロイフローの設計を経験することができました。
これによりWEBシステム全体の管理や運用、プロジェクト進行の経験と知識を身につけることができました。
また、普段の業務ではどれだけ整備された環境で開発しているのかを体感することができました。
結果としては最初に目標で設定していたことは研修を通してすべて達成できました。
開発のベースとなる部分の設計と実装を担っていたので、他のメンバーの実装に支障が出ないように速度と正確さを求められるポジションだったと感じました。
特に技術選定に関しては最後まで悩むことが多く、自身のアプリケーションの特性を深く理解した上で各技術のメリット・デメリットを考慮し、選択する必要があることを痛感しました。どんな技術を選んでもデメリットは必ずついてくるものなので、与えるインパクトを十分に理解した上で許容するのか、対策を考えるかなどのアクションが必要になってくると思います。
AIが発達し、自動でコードを生成してくれる今ではエンジニアは自分が作っているアプリケーションが持ちうるリスクを想定し、考慮した上で対処方法の設計できるかが大切なんだろうなと思った次第です。
終わりに
この記事ではSET研修で取り組んだことや反省点と学びについて振り返りました。
周りについて行くことに必死だった1年目が終わり、ようやく自分が好きなことや興味があることが明確になってきた2年目のタイミングでSET研修に参加できたのは大変貴重な経験でした。
メンターとサポートチームに幾度も助けられながら大幅に成長できた２週間超でした。個人的には設計や実装に悩む時間を思う存分に楽しめたのでSETに参加して本当に良かったです。
一人前のエンジニアとして活躍できるようにこれからもインプットとアウトプットを重ねてスキルアップしていきたいです。
最後になりますが、LIFULLでは一緒に働く仲間を募集しております。よろしければぜひこちらのページもご覧ください。
