Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新卒3年目の ゲームバックエンドエンジニアが これまでに経験したこと
Search
COLOPL Inc.
October 31, 2023
Technology
1
1.5k
新卒3年目の ゲームバックエンドエンジニアが これまでに経験したこと
COLOPL Inc.
October 31, 2023
Tweet
Share
More Decks by COLOPL Inc.
See All by COLOPL Inc.
コロプラ最新作インフラ構成について
colopl
0
36
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
910
コロプラのオンボーディングを採用から語りたい
colopl
7
1.8k
怖くない!ゼロから始めるPHPソースコードコンパイル入門
colopl
0
130
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
3
4k
長期運用プロジェクトでのMySQLからTiDB移行の検証
colopl
3
1.6k
ゲームを支えるバックエンドエンジニアのリアルを公開!
colopl
1
1.2k
コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い
colopl
0
890
大規模タイトルを ノーメンテで運用するコツ
colopl
1
1.4k
Other Decks in Technology
See All in Technology
あれは良かった、あれは苦労したB2B2C型SaaSの新規開発におけるCloud Spanner
hirohito1108
2
780
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
130
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
7.1k
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
1
1.3k
The Future of SEO: The Impact of AI on Search
badams
0
240
N=1から解き明かすAWS ソリューションアーキテクトの魅力
kiiwami
0
140
RSNA2024振り返り
nanachi
0
620
深層学習と古典的画像アルゴリズムを組み合わせた類似画像検索内製化
shutotakahashi
1
260
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
270
Windows の新しい管理者保護モード
murachiakira
0
170
開発組織のための セキュアコーディング研修の始め方
flatt_security
3
2.7k
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
The Cult of Friendly URLs
andyhume
78
6.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
KATA
mclloyd
29
14k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Practical Orchestrator
shlominoach
186
10k
A designer walks into a library…
pauljervisheath
205
24k
How to train your dragon (web standard)
notwaldorf
91
5.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Building Your Own Lightsaber
phodgson
104
6.2k
Transcript
新卒3年目の ゲームバックエンドエンジニアが これまでに経験したこと
氏名 : 部署 : 自己紹介 齋木 駿輔 2021年4月 … 新卒入社
2021年6月 … 運用タイトル配属 (2.5年弱) 2 第2バックエンドエンジニア部
目的 ゲーム業界(特にコロプラ)に入社して数年間のイメージを持ってもらうこと 目次 1. 齋木の入社時と現在を紹介 2. 運用タイトルで行う業務のサイクルを紹介 3. 業務の中で起きがちな(実際に起きた)問題と、そこから得られたことを紹介 3
概要
私の入社時と 現在を比較 4
• 4年制大学 学部卒 • 情報系学科 ◦ 授業でC言語 ◦ 研究ではR言語を使った分析 •
技術関連 ◦ webアプリ開発 アルバイトで2年くらい ◦ 開発して引き渡すのみ. 運用/保守経験はなし. ◦ ゲーム開発経験もほぼ0 ◦ Python/Flask ◦ MySQL 5 私の入社時
• リリースから数年の運用タイトルに在籍 ◦ 開発暦 = 運用タイトル所属暦 • イベント(後述)の開発約10本 ◦ うち半数は、イベント関係バックエンドエンジニアのリード
• 技術関連 ◦ PHP/Laravel ◦ MySQL, Google Cloud Spanner ◦ Docker, Kubernetes 6 私の現在 他職種とのやりとり窓口になったり タスク調整したり...
運用タイトルで 行う業務のサイクル 7
• イベントとは ◦ 期間限定のゲーム内コンテンツ追加 ▪ 期間限定キャラ ▪ 期間限定で特別なシナリオが読める ▪ 期間限定で機能が増える
• 1イベントの開発は? ◦ 私の所属タイトルの場合... ◦ だいたいリリースの2〜3ヶ月前から開始 ◦ バックエンドエンジニア2〜4人くらいで担当 8 大きな開発単位「イベント」
• ざっくりイベント開発フロー 9 大きな開発単位「イベント」 企画の共有 検討 (工数, 実装難度) モック開発 プレイ会
修正 QA リリース Quality Assurance 要はデバッグのこと ×3 3ヶ月前 初回: 2ヶ月前 以降1週おき 1ヶ月前
• ざっくりイベント開発フロー 10 大きな開発単位「イベント」 • これを配属から10回 ≒ 1年に4回行なっている計算 企画の共有 検討
(工数, 実装難度) モック開発 プレイ会 修正 QA リリース Quality Assurance 要はデバッグのこと ×3 エンジニアが主に 手を動かす範囲
イベント開発中に 起こりがちな問題3選 11 (実際に起きた)
12 ① 仕様変更つらすぎ問題
• プレイ会を受けて仕様が変わることが大いにありえる。 • それを繰り返して面白くしていくから自然なことだが... • 仕様変更の工数が必要以上に高くなる時がある。 ◦ DBのテーブル設計が不完全で、仕様変更のたびにデータ構造を変えないといけなくなる ◦ コード実装を不完全のまま固めすぎて、仕様変更のたびに見直さないといけなくなる
13 ① 仕様変更つらすぎ問題
• プレイ会を受けて仕様が変わることが大いにありえる。 • それを繰り返して面白くしていくから自然なことだが... • 仕様変更の工数が必要以上に高くなる時がある。 ◦ DBのテーブル設計が不完全で、仕様変更のたびにデータ構造を変えないといけなくなる ◦ コード実装を不完全のまま固めすぎて、仕様変更のたびに見直さないといけなくなる
14 ① 仕様変更つらすぎ問題 ・個人/少人数開発で、仕様変更自体頻繁にない ・期限がなく、作り直しのインパクト少ない 学生時代
• プレイ会を受けて仕様が変わることが大いにありえる。 • それを繰り返して面白くしていくから自然なことだが... • 仕様変更の工数が必要以上に高くなる時がある ◦ DBのテーブル設計が不完全で、仕様変更のたびにデータ構造を変えないといけなくなる ◦ コード実装を不完全のまま固めすぎて、仕様変更のたびに見直さないといけなくなる
• 学び ◦ 実装時、仕様の目的を明らかにしよう。 ▪ 仕様が変わっても、その仕様で達成したいことは大きく変わることは少ない。 ◦ テーブル設計 は初めにメンバーでレビューしよう。 ◦ 大規模チーム開発では、より密にコミュニケーションを取ろう。 15 ① 仕様変更つらすぎ問題
16 ② 安請け合いしちゃう問題
• 仕様共有時点で「多分できます」と言ってしまう問題 • リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづ らく悲しくなるパターン •
追い詰められると、人はどうするか 17 ② 安請け合いしちゃう問題
• 仕様共有時点で「多分できます」と言ってしまう問題 • リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづ らく悲しくなるパターン •
追い詰められると、人はどうするか ◦ `if (このイベント) // 本当は〜〜した方がいい ` というコードが大量発生する。 ◦ 変更に弱くて汎用性がない。次に似たイベントを実装する人が同じ苦労を... 18 ② 安請け合いしちゃう問題
• 仕様共有時点で「多分できます」と言ってしまう問題 • リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづ らく悲しくなるパターン •
追い詰められると、人はどうするか ◦ `if (このイベント) // 本当は〜〜した方がいい ` というコードが大量発生する。 ◦ 変更に弱くて汎用性がない。次に似たイベントを実装する人が同じ苦労を... 19 ② 安請け合いしちゃう問題 ・期限がない (学習目的の) 開発中心 ・数ヶ月、数年先のことは意識しない 学生時代
• 仕様共有時点で「多分できます」と言ってしまう問題 • リスク or 工数 (or 両方)がデカすぎることが後から判明し、仕様調整もしづ らく悲しくなるパターン •
追い詰められると、人はどうするか ◦ `if (このイベント) // 本当は〜〜した方がいい ` というコードが大量発生する。 ◦ 変更に弱くて汎用性がない。次に似たイベントを実装する人が同じ苦労を... • 学び ◦ あらかじめ調査はしっかりしよう。 ◦ 有識者に意見を求めよう。 ▪ 過去前例があるか? ▪ この方針で本当にいけるか?見落としはないか? ◦ 工数見積もりは、なるべく定量的に行おう。 20 ② 安請け合いしちゃう問題
21 ③ お問い合わせ調査不可能問題
22 ③ お問い合わせ調査不可能問題 • ユーザーさんから運営への報告や質問 ◦ 「手に入れたはずのアイテムが消えてしまった」 ◦ 「通信エラーでプレイできなくなった」 ◦
「この挙動をするのは仕様なのか?」 ◦ etc … • カスタマーエクスペリエンス (CX) チームが受け、 開発チームに確認が必要な物は調査依頼が来るという流れ ユーザーさん CXチーム 開発チーム(我々) 送信 返信 調査依頼 返答
• リリース後、お問い合わせ着信 • バグか...?勘違いか...? 23 ③ お問い合わせ調査不可能問題
• リリース後、お問い合わせ着信 • バグか...?勘違いか...? • →「「調査に必要なログが無い!!!!!」」 • → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなく なる
(つらい) 24 ③ お問い合わせ調査不可能問題
• リリース後、お問い合わせ着信 • バグか...?勘違いか...? • →「「調査に必要なログが無い!!!!!」」 • → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなく なる
(つらい) 25 ③ お問い合わせ調査不可能問題 ・個人開発は完成して終わり ・アルバイトも運用の経験はなし 学生時代
• リリース後、お問い合わせ着信 • バグか...?勘違いか...? • →「「調査に必要なログが無い!!!!!」」 • → ヒアリングを繰り返し、状況証拠をかき集めてなんとか調査するしかなく なる
(つらい) • 学び ◦ 遊んでくれるユーザーさん、CXチームの存在を常に意識した開発をしよう。 ◦ 作って終わりじゃ無く、遊んでもらっているうちが本番。 ◦ 具体的には ... ▪ ユーザーデータの変動がある時は、変動前後の値を残す ▪ 非エンジニアでも調査しやすい環境の整備 などなど... 26 ③ お問い合わせ調査不可能問題
まとめ 27
目的 ゲーム業界(特にコロプラ)に入社して数年後のイメージを持ってもらうこと おさらい • 運用タイトルでの働き方をざっくりと紹介した • その中で起きがちな(実際に起きた)問題を紹介した 2.5年間での学びは多かった • 実際の業務中の方が学びやすいこと
◦ 広く他職種の絡むチーム開発 ◦ 多数のユーザーの存在による部分 ▪ (負荷分散, ノーメンテ, お問い合わせ対応 ...) • 業務外でも身につけられること ◦ 一般的なweb知識やテーブル設計/コード実装 ◦ 技術や製品に関する価値観、こだわり ◦ 工数計算 etc… 28 まとめ
目的 ゲーム業界(特にコロプラ)に入社して数年後のイメージを持ってもらうこと おさらい • 運用タイトルでの働き方をざっくりと紹介した • その中で起きがちな(実際に起きた)問題を紹介した 2.5年間での学びは多かった • 実際の業務中の方が学びやすいこと
◦ 広く他職種の絡むチーム開発 ◦ 多数のユーザーの存在による部分 ▪ (負荷分散, ノーメンテ, お問い合わせ対応 ...) • 業務外でも身につけられること ◦ 一般的なweb知識やテーブル設計/コード実装 ◦ 技術や製品に関する価値観、こだわり ◦ 工数計算 etc… 29 まとめ 基礎 応用 学べるうちに学んでおくと 応用や活躍に繋がりやすい 💪 学びや成長が より結果として見えやすい