freeeの2024年新卒研修の事例 - 社内むけショート動画プラットフォームの開発

こんにちは！24新卒でfreeeに入社したkochanです！この記事では、実際に私が経験した2024年度のエンジニア新卒研修について紹介します。これから研修を控える方や、就職先を検討中の学生の皆さんに、freeeでどのような成長機会が得られるのかをお伝えします。

私たちはまず、営業メンバーも含めた新卒全体で会計などに関する業務知識についての講義を受け、演習を行いました。

その後、エンジニア新卒研修が2.5ヶ月間あります。内容としては前半・後半の2段階構成で、実践的なスキルと即戦力になるための経験を身につけることができます。

前半研修ではWebフレームワークを自作するといった本格的な技術トレーニングや、社内サービスやインフラに関する講義を受講しました。これによって、実務で必要となる基礎技術力を習得できました。

後半研修ではさらに踏み込んでエンジニアとデザイナーが混合チームを組み、実際の社内課題を解決するプロダクト開発に挑戦しました！

後半研修チームのメンバー紹介。エンジニアのtaru, yuki, takemi, fill, kochanとデザイナーのkumachanの計6人のチームでプロダクト開発を行った — 後半研修チームのメンバー

お題では3年運用可能なプロダクトを開発するという要件もあり…（この重さを研修時点では知らないのであった…）。僕たちのチームは社内に情報を浸透させるために社内向けショート動画サービスを開発し、研修が終わった後に社内で本番運用を行いました。研修で作ったプロダクトが実際に社内で使われる経験は、新卒1年目としては非常に貴重なものでした。

記事は全部で以下のような3部構成とし、今回は後半研修でのプロダクト開発について紹介します。

後半研修でのプロダクト開発について
本番運用移行について
本番リリース後の展開について

お題

課題

チームで社内課題解決のアプリを作ってください。チームごとに別々の社内課題が複数を割り当てられるので、それぞれ課題を選んで解決してください。

条件

DesignDoc(設計ドキュメント)をちゃんと書きましょう
とりあえず3年くらいは運用できるようなイメージで考えてください

アドバイス

仕様調整・要件定義をがんばりましょう
時間は限られているのでMVPをどこにするかが大事です

2024年のfreeeの新卒研修では要件定義からインフラ構築、アプリケーション開発まで全部やりました！僕たちはYouTube Shortsの社内版が欲しいというお題を選択しました。社員数が増えている中でも社内に広く情報を届けられるようなプラットフォームを目指します。

研修全体の流れ

短い研修の期間で新規プロダクト開発の流れを一通り行います。与えられた期間はたった6週間なので以下のような予定を立てて開発を進めました。

研修当初に想定していた開発スケジュール, 6週間のガントチャートで表現しており、リサーチ・DD設計・ワイヤーフレーム・UI設計・infra設計・admin画面開発・ユーザ画面開発についての想定スケジュールが並んでいる。 — 当初想定していた開発スケジュール

課題の深掘りと仕様策定

まずは課題の起票者にインタビューをしてどんな課題感を持っているのか確認しにいきます。インタビューの録画を何度も見返しながらどんな要求・要望を持っているのかを整理しました。

また、自分たちの理解が正しいかを確認するために社内で同じ課題感を持っていそうな人たちに声をかけて要望を確認しました。インタビューを数回繰り返しながら要求・要望を整理して、どんな機能を作るとユーザーに価値が届くのかを考えました。インタビューをすると同時にSlackで社員にアンケートをとり、社内にどんな要望があるのかを調査しました。

与えられた開発期間は短いため、価値を届けるために最低限必要な機能は何かを考えました。

インタビュー結果から要求・要望を切り出し、グループングして整理してている様子カルフラ(一般的には人事担当にあたるfreee内の組織, カルチャーインフラ)、動画制作者、視聴者それぞれの役割が、どのような要求をもっているかを整理している — インタビュー結果から要求・要望を整理

要求・要望を整理した結果以下の点が重要になると考えました。

1つの動画を再生すると流れで関連する動画も見て受動的に社内の広い情報にたどり着くこと
Slackに動画を投稿することと比較して動画の一覧性が高いこと
YouTubeと比較してセキュリティレベルの高い情報が扱えること

上記の要望を満たしつつ、動画のプラットフォームとして当たり前の機能を実現できるように設計していきます。

設計

まずは、UI/UXの設計とシステムの設計を並行して進めました。

UI/UX設計

デザイナーの kumachan にコアとなるユーザー体験を設計してもらいました。YouTube Shortsのように動画を再生してから流れで関連動画を再生していき、最初は全く知りもしなかった情報にたどり着くという体験をコアに置きました。

動画を視聴した後に他の動画も見る体験をコアとしてユーザー体験を設計 Slack通知から、動画を閲覧ができ、コメントや他の動画への回遊ができることを示している — ユーザー体験の設計

コアとなるユーザー体験が決まるとそれを実現するためにどのような画面が必要かを考えていきます。複数の案を考えてぞれぞれのメリット/デメリットを比較してUIを設計していきました。

この作業を繰り返してユーザー側の動画一覧画面、動画詳細画面、ログイン画面、管理者側の動画詳細画面、動画詳細画面、動画投稿画面など複数の画面のデザインを考えました。

YouTubeやTikTokの画面を参考にしながらコアとなるユーザー体験を実現できるUIを検討している様子 — 画面の設計

UI/UX設計の中でデザイン工数・開発工数を削減するために標準UIを使おうという意見が出ました。

しかし、ユーザーが気軽に情報を収集できるという体験を実現するためには軽やかなUIが重要という意見が出て、Admin画面だけ標準UIを使用しユーザー画面には標準UIを使わないことになりました。その際にユーザー画面の実装にMaterial UIを使うのかVanillaな状態に独自CSSを当てるのか、工数増に対して体験の向上の価値は大きいのかと議論が白熱しました。結果として、ユーザー体験のために軽やかなUIは譲れないという話になりました。

UI/UX設計が7割ほど完成した時点で手が止まってきた際にkumachanが先輩デザイナーに相談しに行ったら、「デザイナーは前提を疑え」という金言をいただきUI/UXが一度白紙に戻ったことが個人的に印象に残っています。 0から考え直した結果、要望として上がっていたSlackへの新規動画通知機能や時間を指定してサムネイルを作成する機能はプラットフォームで提供するコア機能ではないという判断ができました。

システム設計

まずはインフラを設計します。AWSに詳しいメンバーがいなかったため、勉強しながら進めました。必要そうな構成要素を並べ、何が足りないかを議論しながら作成しました。ECSやRDS、ALBといった基本的な構成要素に加えて、動画をストリーミング形式に変換する用のLambdaを用意したり署名付きCookieを利用してS3から動画を配信できるようにするなど低コストで動画配信を実現できるように工夫しました。

AWS上に展開するインフラの構成図。アプリケーションサーバにはECSを利用し、ストレージにはS3, CDNとしてCloudFrontが利用されている — インフラ構成図

インフラ構築に並行して、システムの設計も進めます。システム設計では技術の選定から始めます。

Go言語を触りたいメンバーが多かったことからGo言語を選択しました。社内でよく展開されているRuby on RailsのフロントとなるHTTP ServerとgRPCを組み合わせる構成とするか、GoのWebフレームワークのecho単体で進めるかを検討しました。期間に対して、Rails + gRPCという構成は重厚すぎるということや、フレームワークに依存する箇所を切り分ければ後から載せ替えることも容易だろうという判断からechoを選択しました（この選択が後々自分たちの首を絞めることになるのでした…）。また、3年保守可能という要件もあるため、勢いに任せて作るのではなくクリーンアーキテクチャを意識してアプリケーションの内部設計を行いました。

freee shortsのアーキテクチャを表した図。クリーンアーキテクチャを意識して、Domain, UseCase, Infraといったレイヤーを組み合わせた構成にしている。 — クリーンアーキテクチャを意識してアーキテクチャを設計

続いて、データモデリングを行います。動画、ユーザーなどの基本の要素を管理するテーブルを設計することから始めました。また、視聴履歴の管理や動画へのタグ付けができるようにテーブルを追加していき、最終的に計8つのテーブルを作ることになりました。データモデリングの際には、データを正規化して重複したデータが発生しないように意識しました。

freee shortsのDBのER図, user, comment, movie のような動画配信サイトに必要な情報がエンティティとして定義されている — データモデリング

実装

大まかなシステム設計が完了したら、UI設計と並行して実装を進めていきます。メンバーのfillがスクラムに詳しかったのでスクラムを取り入れて開発を進めました。最初にAdmin側の画面を作成して、課題の起票者に意見を聞きながら早めの軌道修正をして進めましようとしました。

しかし、課題を起票したチームが忙しくてAdmin画面が形になってきた時点と成果発表直前の2回しかミーティングを入れることができませんでした。また、最後の方になると設計時点での考慮漏れやチケットの切り忘れなどが出てきてなかなか計画どおりに進みませんでした。最後は気合と執念で完成させました。

全然下がらないどころか計画当初よりも倍以上まで上がっているバーンダウンチャート — 計画どおり行かないバーンダウンチャート

今になって振り返ると、アジャイル開発というよりもウォーターフォールに近くすでに決まったゴールに対してアジャイル風に分割していただけでアジャイルは機能していなかったのだと思います。スクラムイベントの名の下にただただチケットを消化するデスマーチ、いわゆるゾンビスクラムになってしまっていました。スクラムって難しいですね。

成果発表

なんとか成果発表までに動くものが完成しました。成果発表会では完成したショート動画プラットフォームを見せながら、体験設計やアーキテクチャなど特にこだわった部分について話しました。

完成したショート動画プラットフォームの詳細画面。動画再生、タイトルと説明の表示に加えていいねとコメント、関連動画の表示がされている。 — 完成したショート動画プラットフォームの動画詳細画面

発表もかなりウケが良く、講評でメンターから以下のような嬉しい言葉をいただきました(?)

オークスで始まり、宝塚記念で終わった今回の後半研修でしたが、そもそもこの動画プラットフォームを作るという課題の大きさに対して、よくここまでのアウトプットを出してくれたなと思いました！序盤の動き出しの速さは、まるでサイレンススズカを彷彿とさせて、最後の追い切りは、イクイノックスが目に浮かぶようなチームでした