こんにちは！GaudiyでBackendエンジニアをしているtakaです！
今回は、UnityエンジニアとしてCasual Gameチームで活躍されているkazuyaさんが、私が所属しているフィーチャーチームに異動して、1ヶ月半ほどBackend領域を学ぶための武者修行をしたお話です。
Backendの知識はまったくなかったkazuyaさんが、独り立ちするまでにどのようなサポートをしたのか、そのコツを含めてご紹介します！
- 1. UnityからBackendに転生することになった背景
- 2. Gaudiyの開発体制とスタイル
- 3. Backendの立ち上がりサポート
- 4. チーム開発に入る上で意識したこと
- 5. ぶつかった問題と乗り越え方
- 6. 成果（Before / After）
- 7. まとめ
1. UnityからBackendに転生することになった背景
kazuyaさんの所属するCasual Gameチームは、Unityでゲームをつくり、Web上で動作するゲームを開発するチームです。
当時、Unityに強いエンジニアは数名いるものの、BackendやFrontendを絡めた開発をできる人が1人しかいなかったので、機能開発でやれる幅が狭まったり、アジリティが上がりづらいという課題がありました。
そんななか、ある日、Casual Gameチームのリーダー haseyan と僕が雑談をしてた時のこと。
Casual Gameチームの課題感を聞いたなかで「UnityエンジニアがどこかのチームでBackend領域に挑戦すれば、Casual Gameチームの底上げになって、今以上に良いサービスを提供できそうだよね」という結論に至り、検討し始めることになりました。
それからUnityエンジニアであるkazuyaさんに相談した結果、本人も乗り気だったので、最終的には
haseyan「takaさんのチームでいける？」
僕「いけるよ！」
というコミュニケーションでアサインが決まりました笑
チーム間での調整は多少ありましたが、挑戦に対して積極的にサポートするのがGaudiyらしいかなと思います。
2. Gaudiyの開発体制とスタイル
僕が所属するチームは、Gaudiy Fanlinkというファンコミュニティのプラットフォームサービスを開発する、Feature Teamの一つです。
＜開発組織の体制図＞
Feature Teamは機能開発を行い、ユーザーに価値を提供することを目的としたチームです。
フルサイクルエンジニアリングをベースとし、設計・開発・運用・QAなどのサービスライフサイクルを1つの開発チームがすべて担当するため、幅広く開発できることが重要と考えています。
3. Backendの立ち上がりサポート
kazuyaさんは、つよつよUnityエンジニアなのですが、Backendについては技術スタック自体触ったことがない状態だったので、システム構成の説明とペアプロから重点的に始めました。その後、徐々に1人でタスクをこなしていただくように進めていきました。
3-1. Backendのシステム構成の説明
まずはGaudiyで利用しているアーキテクチャと技術スタックについて説明しました。
アーキテクチャの中で、特にgRPCやmicroサービスについての経験がなかったので、厚めに Why? という部分を説明することを意識しました。
3-2. ペアプロ
オンボーディングは、基本的に時間をかけて、齟齬が起きないようにペアで時間をとって進めました。
まずは簡単なタスクを切り出して、PRを出すまでVsCodeのLiveShareを利用してペアプロをしていました。ペアプロをするなかで、Backend開発を行う上で必要なprortobufの書き方やGoの開発におけるポイントの指導を行いました。
4. チーム開発に入る上で意識したこと
オンボーディングを一通り実施した後は、タスクを切り出して徐々に慣れていただくようにしました。この「タスクを切り出す」という部分で特に気をつけていたことを紹介したいと思います。
4-1. 成果を出しやすいタスクから渡す
まずタスクを進めていただくなかで、成果を出しやすいところから渡すという部分を意識していました。
成果の出づらいまたは勉強用のタスクはモチベーションが上がりづらく、チームにとっても本人にとってもよくないので、下記のような流れでチーム内の信頼構築ができるようなサポートを意識してました。
業務の中で成果を出していただく
→Slackでやっていただいたことをチームメンバーに共有
→何をしているのか認知してもらう
4-2. 似たようなタスクで反復を促す
また似たようなタスクを反復することで、Goを書くことに慣れていただくよう、タスクの割り振りをしました。
チームでは新規機能の開発が多かったので、CRUDを中心にドメイン理解をしながら慣れていただきつつ、チームに貢献いただいたと思います。
4-3. Blockerになりづらいタスクで幅を広げる
それから慣れてきた頃に、幅を広げるためのタスクをつくっていきました。タスク管理を行う上では、フロー効率で動いているチーム内でBlockerになりづらい、優先度が低いタスクを洗い出して割り振りを行いました。
その上で優先度の低いタスクの仕様など、意思決定のみ優先度を上げて、開発への貢献と挑戦を両立させるように意識しました。
そうすることでチームのタスク消化としてもかなり貢献いただき、スケジュールとして余裕があったわけではありませんでしたが、お互いに気持ちよく開発を進めることができたと思っています。
5. ぶつかった問題と乗り越え方
順調に開発を進められたように書いていましたが、別領域からの挑戦をしていただくなかで、躓いた部分もありました。
一例を出すと、テストコードの考え方や書き方についてです。CRUDを作っていただく分には問題ありませんでしたが、途中からビジネスロジックを組む際に、テストケースで何を網羅すればいいのか？現実に近いケースを実現するためのデータとは何なのか？などに詰まっていることに気づきました。
上記の問題がわかったのは、ペアプロで進めていたからです。kazuyaさんと会話すると、「そもそもUnityではあまりテストコードを書かずに、Debuggerを使うようにしていた」と聞いたので、テストを書く目的、特に保守性について伝えなければならないと考えました。
その問題がわかった後は、テストについての考え方がわかる『テスト駆動開発』を読むことをおすすめしました。
ただ内容が濃いのとページ数も多いので、簡潔にまとめられた記事をシェアしたり、私が認識している考え方を伝えたりしました。kazuyaさんは早速週末に読んでくれたようで、次の週からテストコードのペアプロがスムーズに進みました。
6. 成果（Before / After）
転生前のkazuyaさんは、Backendの技術スタック自体触ったことがなく、開発以前に、自力でキャッチアップするのも難しい状態でした。
そこから約1ヶ月半チーム帯同して、最終的には、反復したタスクについては雑な依頼の仕方でも仕上げていただけるようになりました。チーム内で開発リソースで困る場面もありましたが、kazuyaさんに頼らせていただいた部分もあり、最終的にスケジュールを組む際にも余裕が出たと思います。
kazuyaさんからも一言いただいたので紹介します！
普段ゲーム開発をしていますが、ノリで手を挙げてバックエンド開発を経験しました。アサイン前はUnity外の社内コードに触れたことがなく、他チームが何をどう開発しているのか見えていない状態でしたが、会社のプロダクトへの理解が深まったのはもちろんのこと、最終的にはサポートを受けながらBackendのContextを理解して開発をすることができたので、Goを書くのが毎日楽しみでした。Gaudiyでは別領域にもチャレンジできる環境・雰囲気があるのがとてもよかったです。
7. まとめ
UnityエンジニアからBackend領域に挑戦した内容を振り返りながら紹介させていただきましたが、いかがでしょうか？プロジェクトを進める上でタスクの割り振りについての考え方など参考になれば嬉しいです！
Gaudiyでは手を挙げれば、大変ですがやりたいことに挑戦できる環境なので、メンバーの挑戦をサポートできるように、またチームの開発生産性を最大化しつつ良いものを作っていきたいと思います！
もし興味を持たれたらお気軽にお声がけください！
