Cedec2015_「消滅都市」運用の一年

Copyright © 2015 Wright Flyer Studios, Inc. All Right Reserved.
WRIGHT FLYER STUDIOS
“消滅都市” 運⽤用の⼀一年年
CEDEC 2015 (August 26, 2015)

まず最初に
ゲームの運営には何が必要なのか

•  既存のお客様を驚かせるための新機能
–  飽きが来ないような新しいゲーム性 / ⼯工夫
–  カッコいいアートワーク
•  新しいお客様にリーチする
–  各種コラボレーション
–  CMや広告など
•  安定したプログラムコード
–  メンテナンス性が⾼高く、新機能の追加しやすい
–  多くの端末をサポートしている
•  お客様の声に⽿耳を傾ける
–  迅速にサポートできる体制
ゲームの運用に何が必要か
別セッションで解説
本セッションで解説

•  消滅都市運営におけるゲーム制作
やコラボレーション施策等に関す
る解説
•  8⽉月27⽇日(⽊木) 11:20〜～12:20
•  3F 311+312
関連セッションのご紹介
お客様に驚きを提供する運営

-‐
消滅都市の事例から -‐
グリー株式会社下田翔大 /
櫻井慶子

•  多くのお客様に⻑⾧長く楽しんで頂くために
– 技術⾯面から何ができるのか
– チームの運⽤用体制として何ができるのか
– 開発チームとサポートチームのいい関わり⽅方は
•  本セッションの主な対象者
– スマートフォンネイティブゲーム開発者
– 特に、リーダー等の各パートにおける責任者
本日の内容

•  写真撮影可
– 資料料等はあとで公開します
– シャッター⾳音等、周囲の⽅方にご配慮ください
•  講演内容のSNS投稿可
– ハッシュタグは #CEDEC2015
本日の内容

•  渡部晋司
– リードエンジニア
•  経歴
– 会津⼤大学コンピュータ理理⼯工学部
– 任天堂株式会社 (2007年年〜～)
– グリー株式会社 (2012年年〜～)
•  GREE Platform事業
•  消滅都市
•  CEDEC 2014 登壇
講演者紹介

•  ⽥田⼝口　和重
–  WFS CSマネージャー
•  経歴
–  ⽴立立教⼤大学経営管理理学博⼠士課程
–  GEコンシューマー・ファイナンス
–  ベルシステム24
–  グリー
•  仙台カスタマーサービスセンター⽴立立ち上げ
•  Wright Flyer Studios CS ⽴立立ち上げ
–  延べ10年年程のCS経験
講演者紹介

ゲーム紹介

ゲーム紹介
•  現代を舞台にしたスマートフォンゲーム
–  iOS, Android, Amazon
•  2014年年5⽉月下旬にリリース
•  おかげさまで500万ダウンロード突破

現在のシステム構成

•  C++11
•  Cocos2d-‐‑‒x (http://jp.cocos.com/)
– Ver3.0 RC (ロンチ時の最新版)
– いくつかの独⾃自改造
– 最新コードから必要なバグ修正の取り込み
•  LWF (https://github.com/gree/lwf)
•  Cricket Audio (http://www.crickettechnology.com/)
システム構成 (クライアント)

•  UI作成システム (LayoutLoader)
– PhotoshopのファイルからUIデザインを設計
•  ステージエディタ
– ゲーム専⽤用のステージ作成ツール(内製)
•  データ変換ツール (MasterTool)
– Excelファイルからゲーム⽤用データを⽣生成
•  Jenkins
– デプロイやデータ変換等を⾃自動化
システム構成 (開発環境)

•  php 5.4
•  silex + MagicSpice (https://github.com/gree/MagicSpice)
•  cascade (https://github.com/gree/cascade)
•  MySQL
– memcache等は無し
•  GameLib
– 内製の課⾦金金/ID基盤システム
•  オンプレミス環境
システム構成 (サーバ)

チームの構成と開発期間

開発体制 (ロンチまで)
プロデューサー
1名
ディレクター
1名
PM
1名
クライアント
プログラマー
4名
サーバー
プログラマー
3名
アート
4名
テクニカル
アート
1名
合計17名
ゲーム
デザイナー
2名

スケジュール
2013年年
10⽉月
2014年年
11⽉月 12⽉月 1⽉月 2⽉月 3⽉月 4⽉月 5⽉月
プロト開発
α開発
-‐‑‒ 主要機能完成 -‐‑‒
β開発
-‐‑‒ ひととおり
完成 -‐‑‒
社内公開
改善
QA
G
O
A
L
計7ヶ⽉月
アジャイルQA
(逐次動作チェック)

•  半年年後のロンチは必達⽬目標
– 限られた⼈人数と期間でできるモノを作る
– 並⾏行行作業に重点を置いた開発スタイル
– 未来(運⽤用)のことは何も考えない
•  なんとかロンチは無事間に合う
– 当時は運⽤用ワークフローすら存在しない状態
スケジュール

•  2014年年 5⽉月 : ロンチ
•  〜～2014年年夏頃
–  開発運⽤用ワークフローの確⽴立立
–  システム安定化
•  2014年年秋頃
–  初の⼤大規模機能追加リリース (ランキング)
–  ゲームコードの⼤大規模な作り直し (後で詳述)
•  2014年年冬頃〜～
–  CM放送開始
–  開発チーム規模を徐々に拡⼤大 (現在50名弱)
–  サポート体制の変更更 (後で詳述)
運用開始後
CSチームの参加

お客様の声に⽿耳を傾けるために
-‐‑‒ 消滅都市のCSチームの構成 -‐‑‒

•  ⼀一般的には
– 「Customer Satisfaction」の略略
– 「お客様満⾜足度度」「消費者満⾜足」とも
そもそもCSとは？
※出典：⽇日本経済新聞社「顧客満⾜足CSの知識識」
•  導⼊入している業種は
– ⼩小売業やサービス業といった、お客様と⽇日々対
峙している業種から、⾃自動⾞車車や家電、⾷食料料品や
⽇日⽤用雑貨などの製造業に⾄至るまで広く浸透

•  お客様からのメール対応
– 仕様
– 不不具合
– 課⾦金金障害
•  チート、RMT対策
– 不不正利利⽤用者への調査・対処
消滅都市におけるCSチームの役割

消滅都市への問合せ方法
ゲーム内のメニュー画⾯面
より
「問合せフォーム」を
選ぶことが出来ます

消滅都市の基本的なCS対応の流れ
CS⼀一次対応
専⾨門部隊
CSコーディネー
ター
開発
CS⼀一次
ü  お客様への回答
ü  コーディネータ
への調査依頼
CS⼀一次
ü  各種簡易易調査
ü  要望取り纏め
ü  開発への修正
依頼
CS⼀一次
ü  修正対応
ü  要望事項のアッ
プデート対応
ü  仕様書の作成

コミュニティマネジメントへの取り組み
•  通常のお問い合わせ以外の導線強化
•  公式 Twitter アカウント
– フォロワー 5万⼈人弱
– 宣伝、イベント告知
– お客様からのサポート窓⼝口としての役割も

消滅都市公式Twi+erアカウント

公式
Twi+erアカウントの役割
サーバ障害が発⽣生した際な
どに、情報を周知
Twitter宛の質問を
問合せフォームへ誘導

公式Twi+erアカウント
•  全体的に良良好な運営
– Twitter/CSの相互連携による障害の早期発⾒見見
– 話しかけやすいキャラクター性
– CSとお客さまのとの間でクッション的な役割
•  お客様満⾜足度度の向上に寄与
– 詳細は後述

多くのお客様に遊んでいただくために
-‐‑‒ 端末の動作速度度の改善 -‐‑‒

動作速度の改善

•  消滅都市はアクションゲーム
– ぬるぬる動く状態で遊んでいただきたい
•  スマートフォンは種類が多い
– すべての端末で完璧を⽬目指すのは難しい
– 開発チーム内で動作保証ポリシーを決める
•  とは、⾔言え…
– 開発 : 多くある端末の中の1台
– お客様 : 私が持ってる唯⼀一の1台

•  動作速度度の改善⽅方法
– 銀の弾丸は…なかなか無い
– アプリごとに原因は違う
•  調査⽤用のツール
– Xcode
•  フレームデバッガ機能
•  Instruments
– Adreno Proﬁler
– PerfHUD ES

•  Android ハードウエアスケーラ
– (ほぼ？) ノーコストで引き伸ばしが可能
– ⾼高解像度度端末で効果⼤大
•  特にタブレット向け
• FPS37→60弱まで改善した端末も
– API呼び出しによりバッファサイズを変更更
•  SDK : setFixedSize
•  NDK : ANativeWindow_̲setBuﬀerGeometry

•  Android ハードウエアスケーラ
– Cocos2d-‐‑‒xの改造が⼀一部必要
– 改造⽅方法 (コードは省省略略)
•  JNI経由で物理理サイズとバッファサイズ両⽅方渡す
•  GLViewProtocol::_̲screenSizeの意味を変える
•  タッチ位置座標の計算⽅方法を変更更
– 物理理ピクセル数依存の計算に注意
•  getFrameSizeの意味が変わる
•  消滅都市のスワイプ判定はDPIで計算

•  2015年年3⽉月アップデートを実施
– 新たに 10種程度度のAndroid端末を動作対象
•  商業⾯面で⾒見見ても⼤大きな効果
– 告知は Twitter でつぶやいただけ
– 1ヶ⽉月で延べ約10,000ダウンロード

Cocos2d-‐‑‒xを使った
アクションゲームの効率率率的な書き⽅方
-‐‑‒ コードの安定性を維持するために -‐‑‒

•  消滅都市
– グリー社内で初のCocos2d-‐‑‒xゲーム
•  社内にノウハウが少ない
– Cocos2d-‐‑‒xを使った「良良い設計」とは…？
•  Cocos2d-‐‑‒xの便便利利な機能 “runAction”
– これを使って書いていくのが”Cocos流流”
– 消滅都市でもたくさん使っていました
– 普通のゲームではupdateで少しずつ更更新
Cocos2d-‐xとアクションゲーム

•  アクションゲームの部分でも多⽤用
– 通常のupdate処理理 + runActionを併⽤用
– だんだんとコード全体が複雑化…
•  なぜ？
– 急に⼊入るゲーム中の割り込み処理理
– スキル発動時のカットイン演出
– チュートリアル
– ポーズボタン

•  割り込み対応 (ロンチ時)
– ノードに対してpause関数を使⽤用して⽌止める
•  問題が頻発
– 2回pauseしたあと1回resume
– 動き出すタイミングでない状態での開始
•  その場しのぎのパッチで乗り切切る
– だんだんとコードがカオス化
– QAで発覚するバグが頻発 (リリース遅延)
– 「俺、ゲーム部分触りたくない」と⾔言われる

•  2014年年秋にゲーム部分の全作り直し
– ほぼ「消滅都市２」に
– updateループによって動く設計に変更更
•  ⽌止める場合はupdate呼び出さない
•  いわゆる「普通のゲーム」の作り⽅方
– runActionを使⽤用しないように
•  引き続きゲーム画⾯面以外では使⽤用

•  とは⾔言えrunActionは便便利利！
– update駆動で停⽌止再開系コードはスッキリ
– 軌道計算等の記述が⾯面倒に…
•  裏裏ワザ
– update駆動にしつつActionを使⽤用する構造
– いいとこ取りできる

アクションの開始コード
pAction->startWithTarget(pSprite);
pAction->retain();
毎フレーム実行するコード
pAction->step(delta);
if (pAction->isDone()) {
pAction->release();
pAction->stop();
}

•  QA (デバッグ)
– 2週間程度度でバトル部分の全体⾒見見直し
– 導⼊入前後でゲーム感に変化がないよう注視
•  効果
– ポーズ / 再開周りのコードの⾒見見通しがよく
– 問題発⽣生によるリリース順延回数が減った

•  多くのお客様に遊んでいただくために
– 多くの端末に対応させる
•  ⻑⾧長く運⽤用できるように
– ゲームエンジンの特性を知る
– 不不吉な前兆があれば勇気をもって取り除く
安定したコード

問い合わせワークフローの改善
-‐‑‒ お客様の声がすぐに届くように -‐‑‒

•  問い合わせ数
– 数百件 / ⽇日
– グリー社内でも最⼤大規模
•  基本的には当⽇日中対応
– 休⽇日も含む
– 夜間問い合わせは翌⽇日
消滅都市のお問い合わせ状況

•  課⾦金金
– フクザワ (ゲーム内通貨) が付与されない
– AppStore, GooglePlay等で決済されない
•  仕様
– ガチャの確率率率
– 進化・強化
– クエスト難易易度度
消滅都市の問い合わせ種別

•  不不具合、データ復復旧
– 強制終了了/動作不不良良
– ログインができない　
– アプリを消してしまったため復復旧して欲しい
•  ご意⾒見見
– 難易易度度
– 操作性
– アイテム出現率率率
消滅都市の問い合わせ種別

問合せ種別毎の割合
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
6⽉月 7⽉月 8⽉月 9⽉月 10⽉月11⽉月12⽉月 1⽉月 2⽉月 3⽉月 4⽉月 5⽉月 6⽉月
2014年年 2015年年
課⾦金金仕様不不具合、データ復復旧ご意⾒見見

全て完璧に対応することは難しい
•  お客様ごとにニーズが違う
– 不不満に思われる部分も⼈人それぞれ
– 要望として挙げられる項⽬目も⼈人それぞれ
•  多くのお客様に⾔言われる部分
•  ごく⼀一部のお客様に⾔言われる部分
•  それでも最⼤大限対応していきたい
– そのためにいったいなにができるのか？

多くのお客様に満足いただくために
•  CSチームだけでやれること
– それぞれのお客様に丁寧に対応する
– メールのテンプレートを運⽤用を⾒見見直す
– カスタマーセンターを⻑⾧長時間稼動する
•  それだけでは完全な解決は難しい

•  消滅都市チームでは何をやったか
– 開発とCS⼀一緒に課題を解決
•  やってきた取り組み
– 管理理ツール改修
– コミュニケーション強化
– 滞留留するサポート案件の精査

管理ツール
•  管理理ツールとは
– 消滅都市のほぼ全ての情報が操作 / 閲覧可能
– Webブラウザ経由で操作
•  機能
– 現在のユーザー状態の閲覧
– データの書き換え
– ⾏行行動ログの閲覧
– マスターデータ(強さパラメータ等)の参照
– そのほか

管理ツール

管理ツール
•  初期の管理理ツール
– 必要最低限の状態でリリース
– お客様の⽬目に触れない部分なので、全体的に適当
•  ログの検索索がまったくできない状態
– アイテム⼊入⼿手経路路
– タマシイの合成履履歴
– クエストのプレイ記録

管理ツール
•  各種お問い合わせに対応できない！
– CS側だけではログの調査が不不可
•  開発へのエスカレーションが増える
– 開発側でないとログの調査ができない
– 結果的に開発側もより負担が増える
– 回答が遅くなりお客様満⾜足度度の低下
•  お互いが独⽴立立して仕事ができるよう
– ログの検索索機能を管理理ツールに追加
– ログ⾃自体はあったが検索索ができなかった

イメージ
⾏行行動パターン毎に
履履歴が⾒見見れるよう
になった
時系列列で

•  CSチームだけでも各種調査がしやすくなった
•  しかし突発的な案件の対処能⼒力力が不不⼗十分…

コミュニケーション強化
現在稼動中のプロダ
クトの中⼼心で稼動
突発的な障害、開発
への優先案件対応の
アプローチが容易易と
なる

事例
•  タマシイの進化機能
– 特定の素材を集めるとより強いタマシイに進化

事例
•  タマシイの進化設定誤り障害
– データ誤りの影響で同⼀一タマシイに進化
•  つまり → 進化しても何も起こらない
•  しかもレベルは最⼤大 (99) から最低 (1) になる
– お客様問い合わせで発覚
•  緊急対応
– 開発チーム側の席で迅速にデータ修正
– サーバへのデプロイ
– 影響範囲の洗い出し / お客様への補填

事例
•  再発防⽌止策
– お客様に2度度とご迷惑をかけないよう
– 技術⾯面から何ができるのかを考える
•  Excelデータの変換ツールを更更新
– 同⼀一タマシイに進化する場合にエラー
•  Jenkinsが停⽌止する
– ⼈人間に怒怒られるよりも機械に怒怒られたい

•  緊急度度が⾼高い案件に対処できるようになった
•  しかし優先度度が低いものは放置されがちに…

•  緊急性の低いものサポート案件
– 特定端末のみで発⽣生
– 問題の再現ができない
– 報告数が極端に少ない (1〜～2件)
•  滞留留しがちだった
– お客様への返答の遅れ
– 不不正確な回答
– 半ば放置状態に近いものも
•  なぜこのようなことが起こるのか？
滞留するサポート案件

滞留するサポート案件の解決
•  開発チームの意⾒見見
– 開発 (新規イベント / 機能) を優先したい
– ⾃自分たちに問題があることは認識識
– 問題を再現できない
– 修正するためのリソースがない
– 昔すぎてよく覚えていない
– 担当者が異異動
•  悪い意味でお客様から遠い
– 意識識が希薄化

滞留するサポート案件
•  CSチームの意⾒見見
– 早く調査して欲しい
– 早く直して欲しい
– 早く仕様書を早く出して欲しい
•  ⾃自分たちだけではどうにもできない
– お客様には返答をしなければならない

結局のところ
開発を優先したい
開発側のミスはわかっている
再現できない
⼈人がいない
早く調査して欲しい
早く直して欲しい
早く仕様書を早く出して欲しい
開発
CS
コストの話
に帰結する

コストを勘案して
体系的なプロジェクトマネジメント⼿手
法ではなくてもいいので、多少粗っぽ
くても、コストをかけず効率率率よく改善
を⾏行行いたい。。。

コストを勘案して
そこではじめたのが・・・

その名も
DOVERミーティング

突然、DOVERとは何だという話ですが
•  名前の由来…
–  ドーバー海峡を渡るぐらい難しい
–  チームみんなで渡りきっていこう
出典：h+ps://commons.wikimedia.org/wiki/File:Straits_of_Dover_engraving_by_William_Miller_aLer_Turner.jpg

開発マネージャ
QA
企画
CS
コミュニティーマネジメント担当
開発担当

•  CSチームとして重要なこと
– 障害事案を開発進捗ツールに乗せてもらうこと
– CSがその進捗状況を追えること
– 開発に修正の確約を取り付けること
– 修正バージョンを共有してもらうこと
– 開発に問題を放置した場合の影響範囲を知って
もらう事

•  開発チームとして重要なこと
– 必ずDOVER担当者を1名つかせる
•  繁忙期でも常時⽤用意する
•  サポート担当は開発チームのバッファではない
– 不不具合の修正状況を毎週共有する
– 同⼀一⼈人物がやり続けないようにする
– 新しく配属されたメンバーはまずここから
•  チームの実情が⾒見見えてくる
•  コード全体を⾒見見渡せる → 今後の開発にも役⽴立立つ

そのためのフロー
CSコーディネー
ター
QA
開発
DOVER担当
CS⼀一次
ü  障害案件の精査
ü  これまでの問合
せ状況の提⽰示
ü  障害継続時の影
響を提⽰示
CS⼀一次
ü  障害事象再現
ü  障害範囲の特
定（全体or個
別）
CS⼀一次
ü  修正可否判断
ü  修正時期判断
ü  修正の優先順
位を決定
ü  修正
障害案件
障害案件

•  「アヤメ」のスキルが連続発動可
– 効果 : 敵の攻撃を完全に無効化
– 連続発動できないことが仕様
•  公式 Twitter に報告される
– 優先度度低めになっていた
–  → 初期のDOVER議題に
DOVERミーティング事例

3営業週も滞留留
(しかも年年末年年始を含む)

•  QAチームで再現性を調査
– 再現性があれば⼿手順を報告

•  開発チームが修正
– 修正バージョンをミーティングで共有
•  QAチームが修正を再確認

•  継続的に実施
– お客様からの着信共有 : 2〜～10件 / 週
– QAの再現確認共有 : 2〜～5件 / 週
– 開発の修正共有 : 2〜～3件 / 週
– Twitterからの意⾒見見共有 : 1〜～2件 / 週

効果として
•  開発へのエスカレーション解決率率率70%
–  DOVER開始以前は、滞留留案件が最⻑⾧長で1ヶ⽉月以上
放置されていた
•  開発へのエスカレーション解決率率率99％
– 基本的に週をまたいで案件が放置されることが
なくなった

お客様満⾜足度度
-‐‑‒ サポートチームと開発チームが協⼒力力した結果どうなったのか -‐‑‒

お客様満足度
•  お客様満⾜足度度調査
– お問合せ頂いた全ての⽅方にアンケート
– お問い合わせ返答内容も含めて満⾜足度度を調査
•  満⾜足度度回答項⽬目
–  ⾮非常に満⾜足
–  満⾜足
–  どちらかというと満⾜足
–  どちらかというと不不満
–  不不満
–  ⾮非常に不不満
上位2項目（Top2Box）を

選択していただくことが目標

お客様満足度の推移
50.0%
55.0%
60.0%
65.0%
70.0%
75.0%
80.0%
85.0%
9⽉月 10⽉月 11⽉月 12⽉月 1⽉月 2⽉月 3⽉月 4⽉月 5⽉月 6⽉月 7⽉月
Top2Box
2014年年 2015年年
管理理ツー
ル改修
DOVER
開始
コミュニ
ケーショ
ン強化
公式Twitterフォロワー
フォローしていないお客様
公式Twitter閲覧者

まとめ

•  多くのお客様に⻑⾧長く遊んでいただくために
•  技術⾯面から
– ときには思い切切った決断も必要
– 対応端末を増やせば Win-‐‑‒Win
– 障害の再発防⽌止に積極的な取り組みを
•  サポート⾯面から
– 開発チームとの繋がりを強化すべき
まとめ

•  責任範囲の垣根を超えて
– お客様のために何ができるのか
– 温もりのある運営チームに
•  チーム全体で考える
– 多くの⽅方に遊んでいただけるよう
– ⻑⾧長く安⼼心して遊んでいただけるよう
– Reach Next Level ! (新しいレベルに到達させよう！)
まとめ

WRIGHT FLYER STUDIOS
ご清聴ありがとうございました

Cedec2015_「消滅都市」運用の一年

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Cedec2015_「消滅都市」運用の一年

Similar to Cedec2015_「消滅都市」運用の一年 (20)

More from gree_tech

More from gree_tech (20)

Cedec2015_「消滅都市」運用の一年