エンジニア

ゲームスタジオのテックリードとして2年間取り組み意識したこと

投稿日:2021年11月11日 更新日:

エンジニアリング&デザインマネジメント室(通称EDMO・エドモ)の吉谷です。ワンダープラネットでは2021年9月に、技術とデザイン領域を全社横断的にリードするEDMOという部署が立ち上がり、この度、自分はこちらの部署に異動となりました。

それまで自分は東京オフィスにおけるゲームスタジオのテックリードを2年間担当してきたのですが、異動を機に現在は別の方に役割を引き継いでいます。

今回は、自分がテックリードとして、その期間考えてきたことや取り組んできたことを振り返りながら知見を共有できたらと思います。

テックリードとは

テックリードとはエンジニアチームにおける技術をリードする人・ポジションです。場合によってはリードエンジニアと呼ばれることもあるようです。技術選定やアーキテクチャ・設計、コード品質、開発効率などを担保することで、エンジニアチームの成果を技術的な側面から最大化するような働きをします。

ちなみに今回の記事では、タイトルの通り「スタジオ」テックリードということで、複数のプロジェクトやエンジニアチームの技術を横断的に見るという役割の意も含んでいます。

なぜテックリードというポジションが求められたか

そもそもですが、自分が担当するまでワンダープラネットではテックリードと呼ばれるポジションはありませんでした。それまでは、スタジオ単位のエンジニアチーム全体は、開発グループ長という役割の人が統括をしており、その元でプロジェクトごとにリードエンジニアや開発リーダーと呼ばれる人が各プロジェクトのエンジニア代表を務めるという形でした。

しかしながら、次のような課題が存在していたのです。

1. 開発グループ長は組織マネジメントで手一杯

スタジオのエンジニア全員の長である開発グループ長の役務は組織的なマネジメントがメインです。そのため、勤怠管理や体制構築、面談、評価、育成施策などで時間やマインドがかなり割かれてしまいます。つまり、技術的な要素に注力しにくいという課題がありました。

2. 複数のプロジェクトで技術連携がうまくいきにくかった

各プロジェクトのリードエンジニアが、集まる共有会や定例などはありましたが、その場での情報共有や進捗共有にとどまるケースが多い状態でした。そのため、アーキテクチャの統一や開発基盤の構築・利用などが推進されにくかったと言えます。

3. 技術志向のエンジニアのキャリアパスがモヤっとしていた

以前までのエンジニアのキャリアパスは、各プロジェクトのリードエンジニアやプロジェクトマネージャの経験を積んだのち、開発グループ長になるというものが主でした。つまり、より技術的な要素を極めていきたい人でも、キャリアをアップするためには、いわゆる「組織マネジメント」的な要素が強く求められてしまうというギャップがありました。(だたしテックリードも技術をマネージするのでマネジメントスキルは必要だと思っています)

上記の潜在的な組織課題や、当時スタジオ内で新規のプロジェクトが複数始まるという事情もあり、何度かプロジェクトのリードエンジニアを担当してきた自分がパイロット導入的にスタジオのテックリードに任命されました。これにより、組織的な課題やマネジメントは開発グループ長、技術的な課題やマネジメントはスタジオテックリードと、責務を分け各々の領域に集中する体制となりました。

責務の定義

さて、任命されたのは良いのですが、社内で初めてのことですし、テックリードという言葉も聞き慣れなかったため、まず役割や責務の定義をするところからはじめました。これには、この新設ポジションを仕掛けた弊社VPoEと会話しながら、以下のような方針をざっくり定義しました。

テックリードは

  • 技術ビジョンを描く人
  • 技術に関係する全般を担保・説明責任を持つ人

さらに、少し時間が立ってからですが、最終的にはRACIを定義しました。組織マネジメント的な部分とも関わりがありますが、開発グループ長と分担し、より技術の部分に責務を持つ感じです。以下に概要を紹介します。

Accountability Responsibility
技術ビジョン・技術戦略の策定
技術選定/利用技術のマネジメント
技術課題マネジメント
技術キャッチアップ
開発品質とスピードの担保/改善
セキュリティ/非機能要件の担保
技術関係の権利マネジメント(ライセンス・特許)
App Store関連のアカウントマネジメント
技術勉強会
体制・組織課題マネジメント
採用
目標管理・評価
育成計画

全般的にResponsibility(実行責任)に○がついていますが、この通り自分自身で手を動かして実行を担うところもありましたし、実際には他エンジニアメンバーに委任するケースもありました。また、Accountability(説明責任)に○がついていないところは、開発グループ長がその責務を持っています(今回はテックリードが関係する部分の抜粋で開発グループ長は他にも複数の責務があります)。

やったこと・意識したこと

次に、実際に取り組んだことについて、そのときのモチベーションや意識したことなども踏まえて紹介していきます。

スタジオの技術ビジョン・戦略の策定

着任後、まず最初にスタジオの「技術」をどのようにしたいのかを表す技術ビジョンを考えました。つまり、スタジオのエンジニアチームとして1年後や数年後にどのような技術獲得をして、どんな技術的課題を解決したいかということです。これらを1, 3, 5年のスパンで決めてマイルストーンに落とし込みました(ただし当時は、3, 5年のマイルストーンは抽象度が高い感じにはなりました)。

なぜ技術ビジョン策定を最優先にしたかというと、よりエレガントな開発を遂行するためには、中長期的な視点が不可欠だと思ったからです。緊急度と重要度のマトリックスで言うところの、重要だが緊急でない領域にどうアプローチするかを予め考えたとも言えます。

この技術ビジョンの策定に際して、 意識したポイントとしては以下の二点です。

  • スタジオの技術的強みは何で、それをどのように強めていくのか
  • 事業面とどう方向性を合わせるか

場合によっては、大きく方針を切ることもあり得えますが、最終的にはエンドユーザーやプロジェクトメンバーに届ける価値が最大化できるようなビジョンが良いのだと思います。

また、その技術ビジョンをどのようして実現するのかの戦略も同時に策定しました。方針レベルの紹介例になってしまいますが、以下のような感じです。

  • 今まで培ってきたUnityやRails・AWSなどの要素技術をさらに積極的に獲得する
  • チーム全体で設計やアーキテクチャに対する理解を高める
  • ライブラリ化や基盤化をより推進する

エンジニアキックオフ・マイルストーンの定期確認

上記の技術ビジョンや技術戦略の策定後、エンジニアメンバー全員に集まってもらいキックオフ・説明会を行いました。正直、当時は手探りだったので簡易的な資料と説明でしたし、どれだけメンバーに伝わったかは不明ですが、とにかくチームが向かうべき方向性を示して共感してもらうことが重要だと思いました。

また、半年ごとに現状の技術課題やマイルストーンとの差分をチェックし、次の課題やアクションをどうするのかの再定義を繰り返しました。これらは各プロジェクトのサーバー・クライアントリードエンジニアに、協力してもらいながらNextアクションを決定し次の目標が決まり次第、再度全エンジニアメンバーに共有のキックオフを行いました。

技術課題マネジメントと技術課題会の実施

次に始めたのが技術課題マネジメントという取り組みです。これは各プロジェクトやスタジオ全体で「技術的な課題」と認識されるものを起票し、それらの解決のためのアクションを議論し決定するという活動です。主に取り扱うこととしては以下のような内容です。

  • プロジェクト横断的な技術トピック
    • 開発基盤の問題や改修計画
    • 各種ライブラリやフレームワークのアップデート情報や調査
  • 技術戦略を遂行する上での重点課題
    • 未獲得の技術調査や導入検証に関する計画・マイルストーン策定
  • その他、勉強会や業界の技術的トピックの更新
    • AndroidやiOSの更新やストアの要件変更のキャッチアップ
    • 社内勉強会の開催
    • 社外勉強会や重要カンファレンスへの参加計画

この技術課題を議論するMtgは週次〜隔週のペースで、各プロジェクトのリードエンジニアに参加してもらいました。

技術課題マネジメントは、実施してとても良かったと感じているのですが、反面、一番難しいと感じたことでもあります。この話は、後日別の記事で紹介できたらと思っています。

アーキテクチャや開発基盤・標準の主導

複数のプロジェクトで共有できそうな、設計概念や開発基盤、利用ライブラリ・技術スタックなどを統一・統合できるような動きをしました。以前、このエンジニアブログでゲーム開発プロジェクトのアーキテクチャへの取り組みを紹介しましたが、それもこの一環です。その他、とにかく各々のプロジェクトの技術情報を積極的にキャッチアップすることに努め、車輪の再発明や同じ議論が起きないように情報を流しまくりました。また、スタジオの標準技術や標準ライブラリなどを定める取り組みもしました。

技術的課題の発見と方針の策定

プロジェクトの開発フェーズ中盤ぐらいで、クライアントのアーキテクチャにとある問題が露呈してきたのですが、それらの解決を図りました。当該の部分を放置して進むと、コードの複雑性が高くなり、運用で改修コストが上がると判断したためです。

この時はすでにいくつか量産が始まっていたこともあり、20ページぐらいの資料を作りメンバーを集めて改修の理由と方針を説明しました。このような技術的な問題点を取り上げて、解決指針を示すのはテックリードの重要な役割だと思っています。

ちなみに、一番最初の設計で正しい選択をしていれば、このようなことも無かったわけなのですが、開発が進むことでわかる事実も多くあると思います。大事なのは変更を恐れず、的確な方針を示して、最小のコストでチームと開発をよりよい未来に導くことです。このときはメンバーに対して、「前の方針は間違いだったスマン」と正直に言いました。

設計レビュー・コードレビューの実施

テックリードとして、プロジェクトの技術やコードの品質を担保するこということは一番意識していたことです。つまり、リリースした機能に不具合がでてしまったり、パフォーマンスが劣化してしまったり、セキュリティやライセンスがまずかったり、その他、開発・技術マターで余計なコストがかかってしまうことが起きないように常に注意を払っていました。万が一このような事態が起きてしまったら、説明責任が果たせるようにとも心構えていました。

ということで、大きい機能群の実装開始前には必ずクライアント-サーバー含めて、クラス図やER図、シーケンス図などの設計レビュー会を担当者に開いてもらい自分も参加しました。弊社はドキュメント管理ツールにesaを利用しているのですが、こちらがPlantUMLを直接かけるので、そのフォーマットでやることが多かったです。結果として、認識齟齬による大幅な手戻りや作り直し、パフォーマンス的な問題などを事前にかなり防げたと思います。

ただし、実装のレビューまで自分がやるとさすがにキャパオーバーなので、懸念ポイントがある場合や基盤的な重要部分などのみに絞り、バランスを取るようにしていました。

他スタジオとの連携窓口

割と雑務的なところですが、スタジオエンジニアの代表者として、他スタジオとの技術情報共有や連携の窓口として立ちました。とりあえず、スタジオの技術的な取り合わせは自分に集約してもらえばよいというスタンスです。

他にも、Apple Developer Programの証明書の更新作業など、スタジオや全社でこれ誰がやるの?誰が決めるの?というものも担当していました。

組織マネジメントとの連携

テックリードは技術的な要素の担当が主ですが、これらは人や組織に関係してくる部分もあります。例えば、技術的な育成(メンタリングやティーチング)だったり、エンジニアの採用だったりです。

そのため、一部メンバーの1on1を担当したり、採用における技術的な基準の策定や質問を担当したりもしました。

テックリードとして活動してどうだっか

テックリードを担当して大変だったことも多かったですが、その分成果も残せたのではないかと感じています。何が変わったかを主観も少し入りますが紹介します。

プロジェクト間の連携や思想が統一できた

自身が複数のプロジェクトのハブになりつつ、双方の整合性を保つようにレビューや技術導入の意思決定を進められたのではないかと思っています。

そのため、クライアント、サーバー、インフラの基本的な思想の統一や、共通基盤の利用や標準化をかなり進められました。新しいプロジェクトが始まったとしても、現在の続きから議論や改善を初められますし、プロジェクトのメンバー同士がシャッフルしても、ほほ問題が起きないレベルだと思います。

難易度が高いチャレンジを推進できた

正直、結構キツかったところもありますが、新しい技術のキャッチアップや大きめの技術課題解決への取りくみを実行できました。例えば、クリーンアーキテクチャの考え方の導入、Unityのモダンな技術の導入(Addressable Asset SystemやURP、ShaderGpraphなど)、複数の新しい開発基盤の構築やリファクタリング、Docker/ECSでの運用などです。

つまり、「今までこうしてたから、この仕組みでいいよね」というところから、どうやったら以前からあった課題を解決できるかや、よりエレガントに扱うことができるかなどを技術ビジョンに従って目指せました。リリーススケジュールもタイトで、かなり厳しかったですがメンバーの協力もあり、何とか達成できました。

反省点

テックリードの責務はどのようなものか?ということを自分なりに考えベストを尽くしてきたつもりですが、今考えるとあまりよくなかったなということももちろんあります。それらを簡単に紹介します。

技術ビジョンの策定に関して

技術ビジョンや戦略を定めるフェーズですが、もう少しいろいろな人(スタジオ長やプロデューサー、各リードエンジニアなど)と会話するべきでした。自分自身が、スタジオやプロダクト自体に所属している時間が長かったため、事業理解や技術理解をしていたので、結果大きなズレはなかったとは言えます。しかし、このあたりは本来いろいろな視点を取り入れるべきだったかなと思います。(ただしビジョンの策定や意識決定は誰か一人がやるべきです)。

技術課題への取り組みに関して

技術課題への取り組みはとても難しかったです。起票された課題の整理方法から、会議体の参加メンバーの変更など、やり方が2年の間で紆余曲折しました。

なにより、プロジェクトのスケジュール管理外のトピックも扱う可能性があり、どのように工数を確保するかなど常に悩んでいました。

このあたりは先ほど触れたとおり別の記事で詳しく紹介します。

プロセス、任せ方や関わり方

どれが自分の設計レビューやコードレビューが必要なのかの決まりはなかったので都度判断やメンバーからの申し出でレビュー会に参加したり、Pull Reqeustのレビュアーに設定してもらったりしました。できる限り各プロジェクトの情報をキャッチアップするように努めていましたが、漏れが出る可能性のあるやり方だったかもしれません。

反面、自分がでしゃばりすぎたかもという点もあります。もちろんテックリードは単なる管理者ではないので自分自身で調査したり設計をしたり、コーディングしたりすることは必要だと思っています。工数的なスケジュール的な観点もありましたが、もう少しメンバーに頼ったり、資料作成や設計、基盤開発などを委任してもよかったように思います。

まとめ

テックリードというポジションの存在意義は大きいと感じています。テックリードはアーキテクチャの主導や、設計・コードレビューを通して品質や開発速度を担保するなどの責務を基本としますが、ただそれでだけでなく、チームやプロジェクトの技術をどのように高めていくかの「ビジョン」を示すことのできる重要な役割でもあります。このビジョンがあることで、プロジェクト間やエンジニア個人間に連携やシナジーが生まれ、いままで為せなかった大きい技術的チャレンジにも挑むことができます。

そのようなことから、テックリードは「描いたビジョンを如何にメンバーに共感してもらい一緒に目指すか」ということに意識を向けることがとても重要なのではないかと思います。

なお、東京スタジオ後任のテックリードはリードとサブリードの2人体制なのですが、各技術領域の専門性も申し分ない上、横目で見てプロセスなどもより洗練されていました。これから東京スタジオの技術やエンジニアチームがどうなっていくかとても楽しみです。

採用情報

ワンダープラネットでは、一緒に働く仲間を幅広い職種で募集しております。

-エンジニア
-, , , ,

© WonderPlanet Inc.