チーフエンジニアとして一年間、仕事してみた話

こんにちは！ゲーム事業部、技術部所属の須藤（@p_chin）です！o(｀ω´ )o

来年4月で新卒入社してもう7年が経ちます...年を感じます。

先日入った謎のベトナム料理店で『大学生かと思った』と言われたのでまだ大丈夫かもしれませんが、年をとった大学生も世には存在するので安心できません。

この記事はTech KAYAC Advent Calendar 2019の22日目の記事となります。

前置き

自分は現在運用中のモバイルゲームプロジェクトにて、チーフエンジニアという役割でお仕事してます。

元々このプロジェクトが開発中の頃はバトル部分メインで全体のリードプログラマをしていたのですが、開発終盤にかけてエンジニアの人数も増えてきてリリース直前あたりからは協業先との技術的な窓口だったり、エンジニアメンバーのマネジメントの様な仕事も担当する様になりました。

なんか固そうな話題なのですが、ちょうど社内でも評価の時期で自己評価についても振り返ったりしてたので今年のAdventCalenderは人生の記録もかねてこの話題にしようと思います。

この役割になった経緯

今年の初めあたりにQA期間にて、バグがなかなか収束しなかった状況からエンジニア観点でやり方を改善して欲しいと依頼を受けたのが発端です。

今まで社内の企画職が担当してた協業先との打ち合わせなどにも頻繁に参加する様になり、チーム内の技術的な窓口になりました。

それから無事に4月頃にリリース出来たのですが、それくらいの時期にエンジニアが多すぎてタスク管理仕切れずうまく仕事を回せていない感触に違和感を感じ始めていて自分1人で全員マネジメントするのが難しくなってきました。（当時はクライアントだけで14名のエンジニアがいました。）

他チームのエンジニアにもやり方の相談した結果『これはセクション毎にチームを分割してリーダーを立ててセクション単位で自分が管理できる様にしないといけないな〜』と悩んでた頃に丁度、協業先のPMの方に『もう少しマネジメントの比重を増やしてチーフエンジニアをやらないか？もちろん今後のキャリアをどう考えてるか次第だけど..』と誘われて、ものは試しにやってみようという気持ちで始めてみました。

チーフエンジニアとしてやってた事はこんな感じ

自分が今年やっていた仕事についてざっくり箇条書きした所、チーフエンジニアについてググった内容とだいたい合ってそうでした。

ちなみに自分はクライアント側の出身でサーバー側のアプリやインフラにはあまり詳しくなかったので、サーバー側の諸々の事に関してはサーバー側のリードエンジニアに基本的にお願いしていました。

エンジニアのプレイングマネージャ的な立ち位置なのかなと勝手に思ってます。

チーム内エンジニアリソースの管理

1on1を実施して、各々のやりたい事をヒアリングしつつ、適材適所でタスクのアサインをしてました。

今アウトゲームやってるがインゲームも担当してみたい、shaderハマってるのでshader書く仕事ください...などの要望がメンバーから出てくるので、その仕事を担当してもらったり。

タスクの偏りや、残業の多いメンバーがいたら別のメンバーをヘルプに付けたり..などの調整もしていました。

技術的な課題の洗い出し＋管理

協業先から依頼されたものや、社内で起案された問題を時にはディレクターなどにも相談して優先順位つけて整理してます。

技術的負債への対策や、他職能などから依頼されてる業務効率化に関する課題など...様々です。 platformやOS側の仕様変更に伴う対応なども良く含まれています。最近だとiOS13βが出たのでその対応とかですね。

QAが必要な修正内容が多いので、QAチームやアップデート開発を管理してるPMなどと修正を入れるアプリバージョンについて相談します。デバッグ機能など本番の製品に含まれない開発内容の場合は例外ですが。

P(プロデューサー)/D(ディレクター)/PM(プロジェクトマネージャ)との連携

開発コストやチームマネジメントの課題などの観点について主に自分の立場では関与していて、『稼働が多すぎたり体調壊しがちなメンバーが居ないか』、『異動/退職するメンバーが抜けた後の体制どうするか』、『(プロジェクト全体に関する重要な情報があった場合に)全体への伝え方をどうするか』『このコストが高すぎるのでなんとかしたい』...などについて話したりもします。

自分は今までリードエンジニアとしてエンジニア組織内のみにしか関与していなかったのですが、お金含めたコストのお話も多かったりするので個人的には新しい視点があって面白いです。

普通にエンジニアとして開発に参加

開発メンバーからの『機能追加時の設計相談』や『github上でのpull-requestのレビュー』などは日常的にしています。割とマネジメントを始める際には確実にコードを読み書きする時間が減ってしまうのが自身のキャリア的にも不安だったのですが、設計やコードレビューのレイヤーなら問題なくこなせてました。

最近久々に大きめの新規機能実装の仕事が来て、詳しい書き方は割と忘れてましたが設計に関してはコードレビューなどで『読んでた』経験と設計の相談などにも関与していた『擬似コードレベルの設計』なら日常的に行なっていたのでそこに関しては昔からは最低限劣化しない品質の仕事ができていた気がします。

とはいえ、基本的には『長い時間を使いがっつりコードを書く』や『締め切りの厳しい実装』のタスクは持たない様にしてるのでちょっとしたバグを直したりデバッグ機能を追加したりなどでコードを書く機会が多い一年でした。

やってみてどうだったか？

結論としてはこの後もこの役割を一生続けるつもりはないですが学びが多くあったのでやって良かったです。初めての役割で失敗も多く、反省も多いのですが少しづつうまくてやれてる感触はあります。

最初はまだ20代だしコード書く機会が減るとエンジニアとしての成長も止まってしまうなという気持ちもありましたが、自分は元々ゲームが面白くない失敗をしたらゲームデザインに興味を持ったし、プロジェクトが炎上してたらタスクマネジメントなどと、プログラム以外でもゲーム制作に関する事なら、自分にも手を出せる範囲の物事には全て興味があったので、チーフエンジニアの役割にもポジティブに取り組めていました。

今回チーフエンジニアをやってみて得た経験はエンジニアの普段の仕事にも活かせそうでした

他社との応対をして交渉や合意形成の取り方を学んだ

エンジニアとして課題や試したい事を見つけた時に正当な理由を説明して正式にタスクとして取り組むまでの段取りを組むのに慣れた
もちろん勝手に動くもの作って『どう？、これ入れたら良くならない？』とディレクターなどに見せるやり方も好きです！が、それが通用しにくい場合もあるので手段として使えます

お金の話を聞いてお金の流れを学んだ(元々自分がお金に関してとても疎かったので気づきが多かっただけかもですが...)

あらゆるコストについて意識する様になった(QA費、アセットの外注費、人件費など)のでそれ前提の提案なども考える様になった
業務改善した場合に実際のコスト感を意識できる様になったのでコスパ観点での優先順位を組み立てられるし、他職種へ改善の効果を前より説明しやすくなった気がする

個人ではなく職能の垣根を超えたチーム全体の集団としてモノを見れる様になった

集団に対してどの様に情報を伝えれば良いか、集団は情報を伝えるとどの様に反応するかの事例を多く見れた
製品やプロジェクト全体レベルでの課題からエンジニアの仕事を見つけられる様になった
例
- 企画がボトルネックになってるので企画の雑務を減らす
- アートがアセット作成してゲームに表示されるまでのワークフローに無駄が多いので減らす
- 今後この機能は多く拡張する機会があるけどコードが汚いのでリファクタリングのコストを払う...など