大規模モバイルオンラインゲーム開発におけるチーム組成とワークフロー最適化

大規模モバイルオンラインゲーム開発における
チーム組成とワークフロー最適化

2
2
自己紹介
山田雅人
KLab 株式会社
KLabGames事業本部
エンジニアリング本部技術広報グループ
過去の講演
大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例
大規模モバイルオンラインゲームにおける安定運用のための仕組み
ソースコードレビューのススメ
個人情報の保護となりすまし対策～KLabのゲーム内通貨の払戻のシステムの場合～
表も裏もすべて見せます！ KLab謹製大規模オンラインゲームのリアルタイムチャットマイクロサービス

3
3
自己紹介
役割：
サーバリーダー
担当業務：
● サーバのプログラム
● サーバインフラ
● アセットビルドパイプライン
なぜここまで範囲が広いのか
発表にも関係あります

5
5
ミッション：「世界と自分をワクワクさせろ」
ビジョン：「エンターテインメントで、世界中のユーザーをひとつにつなげる」
社会に感動と喜びを提供できるような、サービス・技術を創造しています。
設立 2000年8月1日
資本金 54億5795万円（2023年10月末現在）
株式公開市場東京証券取引所･プライム市場（3656）
代表者
代表取締役社長CEO 森田英克
代表取締役副会長五十嵐洋介
所在地
本社（東京都港区、六本木ヒルズ森タワー）
大阪事業所、福岡事業所、仙台事業所
主要関連会社
株式会社BLOCKSMITH&Co.
株式会社グローバルギア
海外拠点可来软件开发（上海）有限公司（KLab China Inc.）
グループ従業員数正社員 516名(2023年6月末時点)
主力：ゲーム事業
アニメ、コミック、ゲームなど、
世界中で人気の高いIPを原作とした
モバイルオンラインゲームを
国内外に展開。
現在155の国と地域で配信
その他：
スマートフォン関連のアプリケーション、
サービス及びサーバインフラの企画、
開発、提供、新規事業開拓など
会社紹介：KLab(クラブ)株式会社

6
6
コーポレートサイト紹介
https://www.klab.com/jp/

7
7
1. はじめに
2. ワークフローとチーム組成の役割分担による問題
3. 役割分担を見直してみた(クライアント/サーバ編)
4. 役割分担を見直してみた(プランナー/エンジニア編)
5. まとめ
本日のアジェンダ

8
8
1. はじめに
5. まとめ

9
9
突然ですが
● ゲーム作りがうまくいってない
● タスクは進むが出来上がったらなんか違う
みたいなことがありませんか？
私も時々そういう場面に出会って困っています。
はじめに

10
10
そんな時に必要な人は？？
役割を越えて動いてくれるちょっとイレギュラーな存在
そんな人がいるととっても心強いです
はじめに

11
11
役割を越えて動いてくれる人を軸に
チームやワークフローを見直すとよい
本日はそんな話をします
はじめに

12
12
1. はじめに
5. まとめ

13
13
1. ゲーム作り全体を網羅した設計
2. 実態は隙間だらけ
3. セクショナリズムの実態は隙間説
4. チームやワークフローの改善の繰り返し
ワークフローとチーム組成の役割分担による問題

14
14

15
15
チームの役割やタスクはどう決めていく？
1. ゲーム全体の設計をする
2. ある程度の部品に分ける
3. 部品の依存関係を整理
4. タスク間の依存関係を考慮してフロー作成
5. 担当やチームを割り当てる
→全体を網羅できるようにしたい
ゲーム作り全体を網羅した設計

16
16
ワークフローはどう組んでいく？
企画書仕様書 UI設計素材組み込み
マスタ設計プログラム
これをベースに
一定並行したり前後したり、繰り返したり
のような工夫をする

17
17
一定並行したり前後したり
企画書仕様書
素材組み込み
マスタ設計
プログラム
UI設計

18
18
繰り返したり

19
19
ゲーム作りに対して
「タスクの漏れがないように」設計したい
ワークフロー

20
20
チームの編成
● 職種別(コンポーネントチーム)
● 機能別(フィーチャーチーム)
→使い分けたり多重所属したり
チームはどう編成する？

21
21
コンポーネントチームとは
プランナー
チーム
アーティスト
チーム
エンジニア
チーム
職種のチームに所属

22
22
フィーチャーチームとは
機能Aチーム
機能Bチーム
機能のチームに所属

23
23
エンジニア
チーム
アーティスト
チーム
プランナー
チーム
多重所属とは
機能Aチーム
機能Bチーム
機能のチームに所属
職種のチームに所属

24
24
ゲーム作りに対して
「担当範囲が漏れないように」設計したい
チーム組成

25
25
● タスクの漏れがないように設計したい
● 担当範囲が漏れないように設計したい
→二つの側面から漏れのないようにしたい
漏れのないチームとワークフロー

26
26
チームとワークフローの構築

27
27
チームとワークフローは設計したが
いざ開発を進めてみると、理想通りにはいかなかったりする
● すべてをタスク化する → タスク化漏れが発生
● すべてに担当者をつける → 担当不明な領域が出てくる
事前にすべてを網羅できるわけではない
実態は隙間だらけ

28
28
満遍なく担当者をつけられたらよいが…
全体に対して網羅性が
完璧な状態
ゲーム開発全体でやること

29
29
実際はこう
目に見えない隙間
誰がやるかわからない
広大な領域
謎の距離感

30
30
4. チームやワークフローの改善を繰り返す

31
31
ゲーム作りを進めているとセクショナリズムを見かける
セクショナリズムは「隙間」が生んでいるのでは？
セクショナリズムの実態は隙間説

32
32
たとえばこんなセクショナリズム
● 機能間連携のお見合い
● これは私の担当じゃないからやりたくない

33
33
機能間連携のお見合い

34
34
機能間連携のお見合い
機能Aチーム
機能Bチーム

35
35
A機能とB機能の機能間連携
機能Aチーム
機能Bチーム
連携機能

36
36
相手が進めてくれないと進まない
機能Aチーム
機能Bチーム
連携機能
相手が進めてくれないと
進まない
相手が進めてくれないと
進まない

37
37
担当範囲が決まらない
機能Aチーム
機能Bチーム
連携機能
どちらが
どこまでやるか
決まらない

38
38
機能間の隙間が問題
機能Aチーム
機能Bチーム
連携機能ここの隙間が
問題になっている

39
39
これは私の担当じゃないから
やりたくない

40
40
これは私の担当じゃないからやりたくない
機能Aチーム
テストしたら異常系が
作られていないみたいです
テスター

41
41
異常系は仕様書に書いていなかった
機能Aチーム
え、異常系なんて
仕様書に書いてなかった

42
42
仕様書に書くつもりもなかった
機能Aチーム
そんな細かい異常系なんて
仕様書に書かないよ

43
43
これは私の担当じゃないからやりたくない
機能Aチーム
・・・・
(私の仕事じゃないよね)
・・・・

44
44
周りには誰の仕事かは関係ない
機能Aチーム
・・・・
・・・・
どっちでもいいから
早くしてー！
テスター

45
45
仕様書の異常系が隙間タスク
異
常
系
異常系って
誰の仕事？
異常系って
誰の仕事？
仕様
ここの隙間が
問題になっている

46
46
セクショナリズムは「隙間」が生んでいる
セクショナリズム
隙間が原因のもの

47
47
チームとワークフローの構築

48
48
チームやワークフローの改善の繰り返し
隙間セクショナリズム
チームや
ワークフローが
うまく動いていない
隙間を退治してセクショナリズムを解決して
チームやワークフローを改善したい

49
49
隙間について考えてみる
事前に隙間を全部埋めるのは無理
事後に埋めて行く考え方

50
50
今の状況
広大な領域
謎の距離感
ゲーム開発全体でやること目に見えない隙間

51
51
ここまでは目指さない
全体に対して網羅性が
完璧な状態

52
52
今の状況
広大な領域
謎の距離感
ゲーム開発全体でやること目に見えない隙間

53
53
こうなってほしい
歩み寄る
誰のものかわからない
タスクを拾う
ゲーム開発全体でやることお互い隙間を埋める

54
54
問題となっている隙間
担当者やタスク間に見えない隙間
担当者やタスク間に想定外の距離感
誰がやるかわからない広大な領域

55
55
役割を越える動きが必要
→これらを解決するには、役割を越える動きが必要
担当者やタスク間に見えない隙間
担当者やタスク間に想定外の距離感
誰がやるかわからない広大な領域
お互いに隙間を埋めてもらう
歩み寄ってもらう
誰のものかわからないタスクを拾う

56
56
役割を越える動きが必要
役割を越える動きをしてもらうためには
何らかの形で役割分担を見直す必要がある

57
57
1. はじめに
2. チーム組成とワークフローの構築
5. まとめ

58
58
サーバ負荷を解決したい
すごい負荷
解決してください
クライアントサーバ
偉い人
サーバエンジニア

59
59
サーバの台数増と性能改善
台数を増やす
性能を改善

60
60
サーバだけでは限界
台数を増やす
性能を改善
サーバだけで
対応は
限界

61
61
実はサーバだけではないサーバ負荷
台数
×
性能
アプリ数
×
通信回数

62
62
トータルで解決すればよい
台数
×
性能
アプリ数
×
通信回数
増強
削減
トータルで負荷を解決すればよい

63
63
わかったこと：
負荷を解決したい≠サーバを増強したい
解決方法：
アプリとサーバ両方の観点から負荷を解決
真の課題と解決策

64
64
クライアントも含めて解決してみる
クライアントエンジニア
新しいAPI作ったので
対応お願いします
依頼
対応しました
再試験どうぞ

65
65
何度も繰り返すとしんどい
依頼
毎回このやり取りは
しんどい
新しいAPI作ったので
対応お願いします
対応しました
再試験どうぞ

66
66
ちょっと出しゃばってみた
どっちも対応して
おいたんで
見てください
チェックだけします

67
67
大成功
台数
×
性能
アプリ数
×
通信回数
大量アクセス対応に成功
増強
削減

68
68
1. 役割分担の硬直化は品質の硬直につながる
2. 役割の再設計に力を入れよ
3. 役割の再設計にフォローが必要
4. チームとワークフローからの逸脱もアリ
この事例から得られたこと

69
69
1. 役割分担の硬直化は品質の硬直につながる

70
70
クライアントとサーバのエンジニアの境界は
→クライアントとサーバの間
(当たり前)
役割分担の硬直化は品質の硬直につながる

71
71
役割の境界
クライアントとサーバの
境界線担当範囲の境界線

72
72
決められた役割の範囲内で活動
クライアントのことは
干渉しないよ
サーバのことは
干渉しないよ
お互いに干渉しなくなる

73
73
決められた役割の範囲内で活動
サーバ負荷は
サーバで考える
サーバ負荷のことは
よくわからない
協力がなくなることも

74
74
サーバとクライアントを合わせた負荷対策という
品質を得られない状態
→より良い状態が目指せるのにストップしている
→品質が硬直状態にある
役割分担の硬直化は品質の硬直につながる

75
75
1. 役割の硬直は品質の硬直につながる

76
76
サーバエンジニア：
クライアントの一部まで担当
→アプリとサーバまとめて負荷対策ができる
→硬直状態から脱却できる
→全体最適化
役割の再設計をすると

77
77
基本の考え方
ここの詳細を固める

78
78
基本の考え方
ここの詳細を固める
これに固執しすぎるのも
良くない

79
79
全体最適化の鍵
新しい担当範囲の境界線
アプリとサーバまとめて
負荷対策できる
こちらに労力を割く

80
80
境界線の詳細よりも誰がやるか
新しい担当範囲の境界線
だれが負荷対策をするか
にフォーカスする
境界線の詳細よりも
「移動」に着目

81
81
この事例の正解
サーバエンジニアのカバー範囲

82
82
真の適材適所はメンバー構成や状況によって異なる
この時のKLabの正解はこれだった
真の適材適所とは流動的

83
83

84
84
役割を越える動きをする人は貴重
誰もが役割を越えた動きをできるわけではない
負担が増えすぎないよう、周囲の理解とサポートが必要
役割の再設計にフォローが必要

85
85
新たな範囲は負担増
新しい範囲
の業務範囲
従来の範囲
新たな範囲は
負担増

86
86
周囲の理解とサポートが必要
新しい範囲
の業務範囲
従来の範囲負担軽減
元担当者の
支援
自動化などで
負担減

87
87
どちらの理解とサポートも必要
1. 新たな担当範囲→クライアントエンジニア
2. 従来の担当範囲→サーバエンジニア
周囲の理解とサポートが必要

88
88

89
89
常識的なチーム組成やワークフローにとらわれず
役割を再設計したことが良かった
チームとワークフローからの逸脱もアリ

90
90
ほとんどの場合において
常識的なチーム組成やワークフローは良い答え
常識的なチームとワークフロー≠悪

91
91
常識通りにチームやワークフローを設計して
そのあと疑ってみるという姿勢が良い
常識を疑うという姿勢

92
92
仮説と検証の上で勝利を確信したら実際に動かす
それまでにある程度の失敗や調整の積み重ねは必要
慎重かつ大胆に実施

93
93
先の事例でも、少しずつ逸脱しながら
調整を繰り返し積み重ねた結果、フローの改善ができた
新しいAPI用意しました → 実装します
（毎回はしんどい…）
こちらで対応しました → チェックします
少しずつ調整しながら一歩ずつ進めていく

94
94
1. はじめに
5. まとめ

95
95
ショップ機能の考慮漏れを防ぎたい
クライアント/サーバエンジニア
仕様書/UI設計
考慮漏れ発覚
・表示内容が足りない
・メッセージ表示が足りない
・時間経過が考慮されていない
etc…
企画書仕様書 UI設計マスタ設計プログラム素材組み込み
仕様書作成に手戻り

96
96
当時の状況
企画書仕様書 UI設計マスタ設計プロ
リソース効率重視で常に仕事がある状態
同じチームの人が同じ仕事をしているとは限らない
ほげ機能
ショップ機能

97
97
当時の状況
エンジニア
デザイナ
プランナー
自分の役割を果たすことに集中
お互いの都合まで考えられていないことがある

98
98
うまくいかない理由
1. 仕様書やUI設計書作りがゴールになっている
2. ゲームが作り終わるのがゴールになっていない
→ゴールに必要な情報はエンジニアが持っていた

99
99
クライアントサーバ編と実は同じでは？
エンジニアの分業の境界線を
ずらした件と同じじゃない？

100
100
役割を越える動きで解決
共同作成
考慮漏れが解決した・・・だけじゃない！

101
101
プラスアルファの価値を創出できた
さらにあったらいいなな便利機能まで盛り込めた
1. 複数種類×複数個まとめ買い
2. イベントとの連動の自動化

102
102
複数種類×複数個まとめ買い
1種類×複数個のまとめ買い
↓
複数種類×複数個のまとめ買い
単体を複数にするデータ設計はエンジニアの分野
→仕様の段階から盛り込むことができた

103
103
イベントとの連動の自動化
イベントごとに毎回手動で作成するマスタデータ
自動でスケルトンが生成される
→純粋に商品だけ準備すればOK
→仕様書にスケルトン作成を行う旨が記載された

104
104
1. 職種間の役割分担も常識を疑おう！
2. 再設計時には動き出しの早さを意識する

105
105
クライアント/サーバ編ではエンジニア間での役割の再設計
プランナー/エンジニア編では職種間での役割の再設計
→どちらも効果が高い
→プラスアルファの価値が出ている
職種間の役割分担も常識を疑おう！

106
106
職種間で信頼感関係の築き方が異なる
→職種間での信頼関係の構築には時間がかかる
→時間をかけてお互いの境界線を探った
職種間の役割分担も常識を疑おう！

107
107
動き出しの早さは効率の良さ
1. 自分が必要なものは前の工程に取りに行く
2. 次の工程に必要なものを切り出して先に作る
再設計時には動き出しの早さを意識する

108
108
前の工程に取りに行く
共同作成＝取りに行く
必要なものは自分で取りに行く
→動き出しの早さ

109
109
次の工程に必要なものを先に渡す
切り出して先に作る
仕様書を完璧に作るのではなく
マスタ設計に必要ものだけ
企画書仕様書
素材組み込み
マスタ設計
プログラム
UI設計

110
110
次の工程に必要なものを先に渡す
仮のUI設計に必要な情報は
仕様書ではなく
企画書に入れておく
企画書仕様書
素材組み込み
マスタ設計
プログラム
UI設計

111
111
動き出しの早さは効率の良さ
1. 自分が必要なものは前の工程に取りに行く
2. 次の工程に必要なものを切り出して先に作る
再設計時には動き出しの早さを意識する
● 考慮漏れ防止
● プラスアルファの価値の創出
を実現できた

112
112
1. はじめに
5. まとめ

113
113
まとめ
1. 本日のおさらい
2. セクショナリズムの問題は解決したか？
3. おわりに

114
114
本日のおさらい
チーム組成とワークフローの構築
1. チームやワークフローを設計しても隙間がある
2. 隙間は役割の再設計で埋める

115
115
役割分担を見直してみた(クライアント/サーバ編)
1. 境界の詳細を詰めるより、誰がやるかにフォーカス
2. 役割の再設計は慎重かつ大胆に

116
116
役割分担を見直してみた(プランナー/エンジニア編)
1. 職種間の役割分担も常識を疑おう！
2. 動き出しの早さに注目して再設計

117
117
1. 機能間連携のお見合い
2. これは私の担当じゃないからやりたくない
これは解決できたか？
セクショナリズムの問題

118
118
プランナー/エンジニア編のチームは
1. メンバーレベルの行動で問題を解決できている
2. 良い意味でマネージャーの仕事は減った
→結果的に権限移譲になった
解決できた

120
120
3行まとめ
1. チームとワークフローは継続的な改善が必要
2. そのために役割を越える動きが必要
3. 役割を越える動きは小さな一歩の試行錯誤から

121
121
1. 作業体験してみよう
● ちょっとした隣のチームのお手伝いから
2. 複数のチームに所属してみよう
● 最初はやっていることを見るだけから始めてよい
3. いろんなことにチャレンジ
● 通常業務以外の何か
→役割を越える動きのヒントがあります
明日からできること

122
122
役割を越える動きがとっても大切だと思うので
みんなで見つけて育んでみませんか？
より楽しくゲームを作るための私の気づきでした
この考え方が皆さんの考えるヒントになれば幸いです。
最後に一言

大規模モバイルオンラインゲーム開発におけるチーム組成とワークフロー最適化

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 大規模モバイルオンラインゲーム開発におけるチーム組成とワークフロー最適化

Similar to 大規模モバイルオンラインゲーム開発におけるチーム組成とワークフロー最適化 (20)

More from KLab Inc. / Tech

More from KLab Inc. / Tech (20)

Recently uploaded

Recently uploaded (15)