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.
PHPStan をできる限り高速化してみる
colopl
0
250
コロプラ最新作インフラ構成について
colopl
0
53
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
1.5k
コロプラのオンボーディングを採用から語りたい
colopl
7
2k
怖くない!ゼロから始めるPHPソースコードコンパイル入門
colopl
0
210
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
3
4.4k
長期運用プロジェクトでのMySQLからTiDB移行の検証
colopl
3
1.6k
ゲームを支えるバックエンドエンジニアのリアルを公開!
colopl
1
1.3k
コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い
colopl
0
940
Other Decks in Technology
See All in Technology
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
110
一人QA時代が終わり、 QAチームが立ち上がった話
ma_cho29
0
240
Amazon EKS Auto ModeでKubernetesの運用をシンプルにする
sshota0809
0
110
コード品質向上で得られる効果と実践的取り組み
ham0215
1
200
Symfony in 2025: Scaling to 0
fabpot
2
130
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1.1k
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
190
Compose MultiplatformにおけるiOSネイティブ実装のベストプラクティス
enomotok
1
190
パスキー導入の課題と ベストプラクティス、今後の展望
ritou
7
1.1k
開発組織全体で意識するSLI/SLOを実装している話
zepprix
1
780
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
18
18k
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Optimising Largest Contentful Paint
csswizardry
34
3.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
How STYLIGHT went responsive
nonsquared
99
5.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
A better future with KSS
kneath
238
17k
Bash Introduction
62gerente
611
210k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
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 まとめ 基礎 応用 学べるうちに学んでおくと 応用や活躍に繋がりやすい 💪 学びや成長が より結果として見えやすい