新卒3年目のゲームバックエンドエンジニアがこれまでに経験したこと

by COLOPL Inc.

Slide 1

Slide 1 text

Slide 2

Slide 2 text

氏名　：部署　：自己紹介齋木駿輔 2021年4月 … 新卒入社 2021年6月 … 運用タイトル配属 (2.5年弱) 2 第2バックエンドエンジニア部

Slide 3

Slide 3 text

目的ゲーム業界(特にコロプラ)に入社して数年間のイメージを持ってもらうこと目次 1. 齋木の入社時と現在を紹介 2. 運用タイトルで行う業務のサイクルを紹介 3. 業務の中で起きがちな(実際に起きた)問題と、そこから得られたことを紹介 3 概要

Slide 4

Slide 4 text

私の入社時と現在を比較 4

Slide 5

Slide 5 text

● 4年制大学学部卒 ● 情報系学科 ○ 授業でC言語 ○ 研究ではR言語を使った分析 ● 技術関連 ○ webアプリ開発アルバイトで2年くらい ○ 開発して引き渡すのみ. 運用/保守経験はなし. ○ ゲーム開発経験もほぼ0 ○ Python/Flask ○ MySQL 5 私の入社時

Slide 6

Slide 6 text

● リリースから数年の運用タイトルに在籍 ○ 開発暦 = 運用タイトル所属暦 ● イベント(後述)の開発約10本 ○ うち半数は、イベント関係バックエンドエンジニアのリード ● 技術関連 ○ PHP/Laravel ○ MySQL, Google Cloud Spanner ○ Docker, Kubernetes 6 私の現在他職種とのやりとり窓口になったりタスク調整したり...

Slide 7

Slide 7 text

運用タイトルで行う業務のサイクル 7

Slide 8

Slide 8 text

● イベントとは ○ 期間限定のゲーム内コンテンツ追加 ■ 期間限定キャラ ■ 期間限定で特別なシナリオが読める ■ 期間限定で機能が増える ● 1イベントの開発は？ ○ 私の所属タイトルの場合... ○ だいたいリリースの2〜3ヶ月前から開始 ○ バックエンドエンジニア2〜4人くらいで担当 8 大きな開発単位「イベント」

Slide 9

Slide 9 text

● ざっくりイベント開発フロー 9 大きな開発単位「イベント」企画の共有検討 (工数, 実装難度) モック開発プレイ会修正 QA リリース Quality Assurance 要はデバッグのこと ×3 3ヶ月前初回: 2ヶ月前以降1週おき 1ヶ月前

Slide 10

Slide 10 text

● ざっくりイベント開発フロー 10 大きな開発単位「イベント」 ● これを配属から10回 ≒ 1年に4回行なっている計算企画の共有検討 (工数, 実装難度) モック開発プレイ会修正 QA リリース Quality Assurance 要はデバッグのこと ×3 エンジニアが主に手を動かす範囲

Slide 11

Slide 11 text

イベント開発中に起こりがちな問題3選 11 (実際に起きた)

Slide 12

Slide 12 text

12 ① 仕様変更つらすぎ問題

Slide 13

Slide 13 text

● プレイ会を受けて仕様が変わることが大いにありえる。 ● それを繰り返して面白くしていくから自然なことだが... ● 仕様変更の工数が必要以上に高くなる時がある。 ○ DBのテーブル設計が不完全で、仕様変更のたびにデータ構造を変えないといけなくなる ○ コード実装を不完全のまま固めすぎて、仕様変更のたびに見直さないといけなくなる 13 ① 仕様変更つらすぎ問題

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● プレイ会を受けて仕様が変わることが大いにありえる。 ● それを繰り返して面白くしていくから自然なことだが... ● 仕様変更の工数が必要以上に高くなる時がある ○ DBのテーブル設計が不完全で、仕様変更のたびにデータ構造を変えないといけなくなる ○ コード実装を不完全のまま固めすぎて、仕様変更のたびに見直さないといけなくなる ● 学び ○ 実装時、仕様の目的を明らかにしよう。 ■ 仕様が変わっても、その仕様で達成したいことは大きく変わることは少ない。 ○ テーブル設計は初めにメンバーでレビューしよう。 ○ 大規模チーム開発では、より密にコミュニケーションを取ろう。 15 ① 仕様変更つらすぎ問題

Slide 16

Slide 16 text

16 ② 安請け合いしちゃう問題

Slide 17

Slide 17 text

● 仕様共有時点で「多分できます」と言ってしまう問題 ● リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづらく悲しくなるパターン ● 追い詰められると、人はどうするか 17 ② 安請け合いしちゃう問題

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● 仕様共有時点で「多分できます」と言ってしまう問題 ● リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづらく悲しくなるパターン ● 追い詰められると、人はどうするか ○ `if (このイベント) // 本当は〜〜した方がいい ` というコードが大量発生する。 ○ 変更に弱くて汎用性がない。次に似たイベントを実装する人が同じ苦労を... 19 ② 安請け合いしちゃう問題・期限がない (学習目的の) 開発中心・数ヶ月、数年先のことは意識しない学生時代

Slide 20

Slide 20 text

● 仕様共有時点で「多分できます」と言ってしまう問題 ● リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづらく悲しくなるパターン ● 追い詰められると、人はどうするか ○ `if (このイベント) // 本当は〜〜した方がいい ` というコードが大量発生する。 ○ 変更に弱くて汎用性がない。次に似たイベントを実装する人が同じ苦労を... ● 学び ○ あらかじめ調査はしっかりしよう。 ○ 有識者に意見を求めよう。 ■ 過去前例があるか？ ■ この方針で本当にいけるか？見落としはないか？ ○ 工数見積もりは、なるべく定量的に行おう。 20 ② 安請け合いしちゃう問題

Slide 21

Slide 21 text

21 ③ お問い合わせ調査不可能問題

Slide 22

Slide 22 text

22 ③ お問い合わせ調査不可能問題 ● ユーザーさんから運営への報告や質問 ○ 「手に入れたはずのアイテムが消えてしまった」 ○ 「通信エラーでプレイできなくなった」 ○ 「この挙動をするのは仕様なのか？」 ○ etc … ● カスタマーエクスペリエンス (CX) チームが受け、開発チームに確認が必要な物は調査依頼が来るという流れユーザーさん CXチーム開発チーム(我々) 送信返信調査依頼返答

Slide 23

Slide 23 text

● リリース後、お問い合わせ着信 ● バグか...？勘違いか...？ 23 ③ お問い合わせ調査不可能問題

Slide 24

Slide 24 text

● リリース後、お問い合わせ着信 ● バグか...？勘違いか...？ ● →「「調査に必要なログが無い！！！！！」」 ● → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなくなる (つらい) 24 ③ お問い合わせ調査不可能問題

Slide 25

Slide 25 text

● リリース後、お問い合わせ着信 ● バグか...？勘違いか...？ ● →「「調査に必要なログが無い！！！！！」」 ● → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなくなる (つらい) 25 ③ お問い合わせ調査不可能問題・個人開発は完成して終わり・アルバイトも運用の経験はなし学生時代

Slide 26

Slide 26 text

● リリース後、お問い合わせ着信 ● バグか...？勘違いか...？ ● →「「調査に必要なログが無い！！！！！」」 ● → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなくなる (つらい) ● 学び ○ 遊んでくれるユーザーさん、CXチームの存在を常に意識した開発をしよう。 ○ 作って終わりじゃ無く、遊んでもらっているうちが本番。 ○ 具体的には ... ■ ユーザーデータの変動がある時は、変動前後の値を残す ■ 非エンジニアでも調査しやすい環境の整備などなど... 26 ③ お問い合わせ調査不可能問題

Slide 27

Slide 27 text

まとめ 27

Slide 28

Slide 28 text

目的ゲーム業界(特にコロプラ)に入社して数年後のイメージを持ってもらうことおさらい ● 運用タイトルでの働き方をざっくりと紹介した ● その中で起きがちな(実際に起きた)問題を紹介した 2.5年間での学びは多かった ● 実際の業務中の方が学びやすいこと ○ 広く他職種の絡むチーム開発 ○ 多数のユーザーの存在による部分 ■ (負荷分散, ノーメンテ, お問い合わせ対応 ...) ● 業務外でも身につけられること ○ 一般的なweb知識やテーブル設計/コード実装 ○ 技術や製品に関する価値観、こだわり ○ 工数計算 etc… 28 まとめ