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を併⽤用 – だんだんとコード全体が複雑化… •  なぜ？ – 急に⼊入るゲーム中の割り込み処理理 – スキル発動時のカットイン演出 – チュートリアル – ポーズボタン Cocos2d-‐xとアクションゲーム

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

Cocos2d-‐xとアクションゲーム

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

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

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

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

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

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

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

•  課⾦金金 – フクザワ (ゲーム内通貨) が付与されない – 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

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

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

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

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

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

DOVERミーティング事例 3営業週も滞留留 (しかも年年末年年始を含む)

•  QAチームで再現性を調査 – 再現性があれば⼿手順を報告 DOVERミーティング事例

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

DOVERミーティング •  継続的に実施 – お客様からの着信共有 : 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_「消滅都市」運用の一年

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

More Decks by gree_tech

Other Decks in Technology

Featured

Transcript