「ゲームを快適に動かす人」と「チームを快適に動かす人」
Photo by Monaz Nazary on Unsplash
前職でご一緒した、あるゲームメーカーのテクニカルディレクターの方が、今でも強く印象に残っています。
いわゆる“手が速い人”ではありません。自分でコードを書く場面もありましたが、それ以上に目立っていたのは、
「自分がどう動くか」ではなく
「チームをどう動かせば、ゲームが一番快適に動くか」
を、常に考えていたことでした。
技術の話をしているのに、視点は一段上にある
具体的にどんなことをしていたかというと、判断の仕方がとても特徴的でした。
たとえば──
- リアルタイム処理が重い
→ 同期コストが原因ではないか
→ 非同期化した場合、プレイフィールは崩れないか
→ まずは検証用の小さな実装を用意しよう - 高解像度データで詰まる
→ 単純な最適化ではなく、IO帯域そのものがボトルネック
→ プリフェッチ層を含めて構成を見直せないか - CPU負荷が高い
→ Profilerで原因を特定
→ アルゴリズムだけでなく、描画順やメモリアロケータまで含め再検討
ここまでは、技術的にはよくある話かもしれません。
ただ、この方が一段違っていたのは、ここから先を必ず「チームの動かし方」に落としていた ことです。
「誰がやるか」まで含めて設計していた
印象的だったのは、
- この調査は、今一番コンテキストを持っている人に任せる
- この修正は手が空いている人ではなく、影響範囲を説明できる人に任せる
- ここは自分が判断だけして、手は別の人に動かしてもらう
といったように、技術判断と同時に「誰に何を任せるか」まで決めていた ことです。
さらに、
- 「この処理は、演出で逃がした方が安全だね」
- 「ここは物理精度より、体感を優先しよう」
といった判断も、とてもスピーディ。
議論が長引くことは少なく、「今の制約の中で、一番リスクが低い選択」を迷いなく選んでいました。
設計より上の層を“デザイン”していた
あとから振り返って思うのは、この方は コードや設計そのものよりも、もう一段上の層を扱っていた ということです。
それは、
- 誰が
- どの順番で
- どの粒度で動けば
- 最小のリスクで最適解に近づけるか
という 「動かし方の設計」 でした。
設計書に直接は書かれませんし、レビューコメントにも残りにくい。
でも、プロジェクト全体の安定感には、確実に効いていました。
これはゲーム開発に限った話ではない
この経験を通じて感じたのは、
これはゲーム開発に限った話ではない、ということです。
- システム開発
- 運用
- 組織づくり
- 教育
どの分野でも、
「自分が頑張る」より
「どう動けば、全体が一番スムーズか」
を考えられる人は、強いです。
しかもそれは、派手なスキルや肩書きがなくても、少しずつ身につけていける種類の強さだと思っています。
まとめ
コードを書く力はもちろん大事です。
設計を理解する力も欠かせません。
ただ、それと同時に、
- 判断をどこで止めるか
- 誰に任せるか
- 何を「やらない」と決めるか
こうした視点を持てるようになると、開発の景色は少し変わって見えてきます。あのテクニカルディレクターから、そんなことを学ばせてもらった気がしています。
おわりに
X(旧Twitter)やBlueskyを中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。
https://www.tatsu-mi-systemsolution.jp/
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social