DevLOVE現場甲子園2015『西日本大会』

2. おまえだれやねん
うつみ けいすけ
KLab (Osaka) Developer
刺青だらけのエンジニア
Golang,PHP,C#(Unity)
CrystalFantasiaのServerリーダー
PHPカンファレンス関西
関西ゲーム勉強会
Kansai Users' Group of Golang(KUG2)
Team Ku’s

3. Agenda
質問タイム
クリファンの紹介
使っている技術の紹介
ゲーム開発現場について
技術ではどうにもならなくてやってみたこと
サービスの新規開発で気をつけたいこと

4. 質問タイム

5. 実行端末
モバイル端末
据え置き機

6. 実行端末
モバイル端末
据え置き機

7. ジャンル
スマホ
コンシューマ

8. ジャンル
スマホ
コンシューマ

9. 収益型
コンテンツ課金型
広告収益型

10. 収益型
コンテンツ課金型
広告収益型

11. CrystalFantasiaのご紹介
完全自社開発オリジナルタイトル
2014/11/12より配信開始
140万DL(2015/01時点
iOS/Androidにて提供
Unityを使った爽快アクションゲーム

13. 2015/06/30 15:00
∼永眠∼

14. CrystalFantasiaのご紹介
よくあるHTTPベースのAPI＋Unityのゲーム
開発チーム：20~30人
プランナー：4∼6人
クリエイティブ：6人∼10人
サウンドエンジニア：1人
クライアントエンジニア：8人

15. ＿人人人人人人人人人人人人人＿
＞ サーバーエンジニア：1人 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

16. 使っているた技術の紹介

17. Client情報管轄
CIツール
Webサーバー
使っているた技術の紹介

18. 使っているた技術の紹介
PHPフレームワークは(ほぼ)自作
DietCakeをベースに構築
300行にも満たない超軽量フレームワーク
何もしてくれない。でもそれがいい

19. 使っているた技術の紹介
バックエンドのスクリプトも基本PHPベースで実装
遅くても気にしない。
アプリの実装資産を使う方が安心・安全
python/golangの方が得意かも？って思っても気にしない

20. 使っているた技術の紹介
効率的なキャッシュ利用
OPcache
オペレーションコードのキャッシュ
APCu
設定データの保持
memcache
リトライ制御用のレスポンスキャッシュ
redis
その他ゲーム内データキャッシュ

21. 使っているた技術の紹介
インテグレーション(CI:チープなインテグレーション
jenkinsではビルドするだけ
リソースのパイプラインは自前実装
sed芸とかもありました
ChatWork通知もふんだんに活用

22. 使っているた技術の紹介
サーバー
DSAS(自社運営のホスティングサービス)
KLabの誇る変態最高峰のインフラチーム
Blogもよろしくお願いします
パフォーマンス
Webサーバー6台
DB/memcached/redisサーバー（master/slave各1台)
処理能力：3500Request/Sec
平均レスポンス時間：28ms *ベンチマーク数値

23. と、その前に

24. 技術っぽい出だしだけど

25. ＿人人人人人人人人人人＿
＞ それも、ここまで ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y￣

26. 高度な技術話は他の人に任せて

27. 少人数(1人)でも立派にチームとして、
開発チーム全体と渡り合い、
回していくお話をしましょう。

28. ゲーム開発現場について

29. ゲーム開発の特徴
結局はサービスなのでそんなに変わらない
大きく違うところ
コンテンツ更新頻度が高い
利便性ではなく楽しさを提供する

30. ゲーム開発の特徴
コンテンツの更新頻度
ガチャのキャラ追加
イベントの追加（クリスマスとか
機能追加とは比べ物にならない頻度で更新されていく

31. ゲーム開発の特徴
利便性ではなく楽しさ
エンターテイメントサービスである
最大の敵は競合よりもユーザーの退屈/飽き

32. 自社サービス提供で気をつけるポイント
デプロイするものはプログラムだけじゃない
設定データ
お知らせ
詫び石
クリエイティブ素材
サーバーアプリケーション
クライアントアプリケーション

33. 設定データ
一番更新頻度が高い
週に2~3回なんてザラにある
開発環境で何度も修正してバランス調整

34. お知らせ/侘び石
サービス提供ではユーザー満足度を左右する大事なもの
メンテナンス予定
バージョンアップ予定
イベント告知
詫び石
ユーザー神の怒りを沈める供物
配りすぎると運営大打撃

35. クリエイティブ素材
サービスの中で一番収益性の高いコンテンツ
かっこいい！かわいい！つよい！欲しい！
ユーザーに刺さるのはコンテンツがメイン
でも制作コスト高め
ダウンロードが多いとユーザーストレスの原因に
日本では月末のジレンマがある

36. サーバーアプリケーション
PHPなのでデプロイは楽
キャッシュクリアのタイミングだけがシビア
できるだけ全サーバーで同時に切り替わる工夫
頻度はそんなに高くないので、できるだけ設定データでい
ろんなことができるように設計/構築することが楽するため
の第一歩

37. クライアントアプリケーション
一番更新頻度は低い
その分一番神経使う
Apple様審査コワイヨー
多少のことはサーバーで対処できるように設計するのも大事
容量問題（最近やっと両方100MBになったね
公開からの浸透待ち

38. サービス提供するエンジニアとして
提供サービスのコンテンツの収益モデルを意識する
各チームがどういうお仕事してるか知る
コンテンツ提供の品質を担保する

39. 技術ではどうにもならなくて
やってみたこと

40. 一人でも他チームと同じように動くために
いろんなサービス/ツールを「使わない」最低限にする
他のチームを正しく頼る/きちんと分業する
僕のクローンを量産する
コンテキストスイッチの削減

41. サービス/ツールを「使わない」最低限にする
ツールで解決できるかもね
今発生している課題に対して最適？
多機能過ぎて浮ついた使い方にならない？
結局中のコード読んでツールの障害対応、したことない？
最適なものはやはり自前実装に限る

42. 他のチームを正しく頼る/きちんと分業する
正しく頼るためにはお互いの仕事を知る必要がある
依頼などの方針インターフェイスを予め決めておく
人に寄り添った対応ではリソースが膨大に消費される

43. クローンを量産
日々依頼されることは管理画面だけで完結できるようにする
細かいタスクほどクローン(ツール)化すれば成果が出やすい
一度依頼されたルーチンタスクはクローン(ツール)がやってく
れる

44. コンテキストスイッチの削減
一人なので、何をやるにしてもコンテキストスイッチが発生
頭切り替えのオーバーヘッド
切り替え＝タバコ…本数増える…
それでも大量発生するので、そのタイミングで最大の成果を
出すためにフルコミットする

45. 開発/運用ツールの充実
CMS(管理画面)の作り方
収益コンテンツ制作の高速化
イテレーションスピードアップツール
夢や理想なんて捨てちまえ

46. CMSの作り方
CMSはエンジニアも全員使うようにつくる
オペレーションが複雑/煩雑にならないように
フロントアプリと同じプロジェクトとして扱う

47. オペレーションが複雑/煩雑にならないように
やりたいこと１つに付き
１画面
１インプット
１クリック
オペレーション数が増えれば増えるほど操作ミスなどの問題発生す
る原因になる
利用者の自由をなくす
利用者に理解を求めない

48. フロントアプリと同じプロジェクトとして扱う
同じ言語で実装する
フロントで利用するモデルをCMS用に拡張して実装する
ゲーム内で起こらないことはCMSでも発生させない。

49. よくある
UPDATE player SET level = level + 10
WHERE player_id = 123;
Playerのレベル上げて

50. よくある
UPDATE player SET level = level + 10
WHERE player_id = 123;
Playerのレベル上げて

51. よくある
Playerのレベル上げて
$player = Player::getById(123);
$nowLevel = $player->getLevel();
$newLevel = $nowLevel + 10;
$addExp = Exp::getNeedExp($newLevel) - $player->exp;
$player->addExp($addExp);

52. イテレーションスピードアップツール
完全社内制作のクリエイティブ素材なので最適なツールなど
ない
クリエイティブ素材なのでエンジニアでは正当性確認できな
い
作ったものは自身でその場で一人で確認できる環境を
PCとスマホ実機では全く同じようにはいかない

53. 夢や理想なんて捨てちまえ
必要最低限でいい。必要になったら追加しよう。
運用ツールはサービスとともに成長するもの
いきなり大掛かりなものを作り始めると後戻りできない
理想を語っていても使ってもらえない仕組みは無価値
小さなツールをたくさんつくろう
開発に２日以上かかるのは課題分解ミスってる可能性

54. 責任分界点を明確に
担当範囲が曖昧だと、責任感も曖昧になる
作ったものには責任を
各チーム、ユーザーに届けるまで面倒を最後までみる
責任が持てる環境をつくる

55. 責任が持てる環境をつくる
担当者が単一でユーザーへ正しいデータを提供できるように
エンジニアが寝ていても安心して更新作業ができる
メンバーが全員安心してユーザーに正しいデータを提供でき
る環境を整備するのもエンジニアの責任
あたりまえのことをあたりまえに

56. 情報は必ず集約する
サービスの通知などは必ず一つに集約
サービスの性質で深夜の通知も気にしなければならない
CMSと情報ツールだけでおおよその状況がわからなければな
らない
エラーとか障害は絵文字や画像を使ってインパクト重視
分散すればするほど、誰も見なくなる

57. サービスの新規開発で
気をつけたいこと

58. フェーズを意識した開発を
プロトフェーズ
本実装/制作フェーズ
運用フェーズ

59. プロトフェーズ
捨てる前提でつくる
バッドノウハウを蓄積する期間
コード品質なんかよりイテレーション速度が重要
各チームがどんな作業発生するかを見ておく
収益コンテンツの特性と、コスト感を把握しておく

60. 本実装/制作フェーズ
初期でイテレーションスピードアップツールをつくる
仕様と収益コンテンツを見て再度整理する
大きな仕様変更がプロト最後であった時は要注意
運用フェーズを意識した開発運用をするようにする
この時からすでに運用リハーサルだと思う

61. 運用フェーズ
開発環境のミスやエラーには気を使う
開発環境で起きた問題はいつか本番でも必ず起こる
誰が何に困ってるかを調べる
属人化してる作業がないか？

62. 障害が起こってしまったら
しゃーない
次を防ぐ
障害はチャンス

63. しゃーない
いくらデバッグしても出るものは出る
しゃーない。しゃーない。
責めない
きちんと包み隠さず報告できる空気をつくる

64. 次を防ぐ
きっちりヒアリングして原因を探る
ダブルチェックします！は対策じゃない
なにかしらのツールや、通知系のチェッカーをつくる

65. 障害はチャンス
月に３回起こる障害の一つを潰せたら…？
社内評価も上がって
月に１杯ビール飲む時間ができる
年で12杯もお得!!!!
やっぱり障害はないほうがいいに決まってる

66. 最後に

67. 最後に
サービス提供するなら、きちんと収益を見据えましょう
とは言ってもエンターテイメントなので収益だけじゃダメ
所属するチームのプランナーが考えた最高のゲームをそのま
まの温度感でユーザーに届けられるエンジニアになる
技術だけに頼らずにチームを大切に
一人はやっぱり寂しい

68. ご清聴
ありがとうございました。