【CEDEC2015】開発・サポートから振り返る『消滅都市』の運営…動作速度UPとサポート強化で長く楽しめるゲームに

グリー<3632>Wright Flyer Studiosは、8月26日、「CEDEC 2015」で、「『消滅都市』運用の一年」と題するセッションを行った。今回、消滅都市チームのリードエンジニアである渡部晋司氏と、お客様サポートチーム マネージャーである田口和重氏が登壇した。

サービス開始から1年半の月日が経過した『消滅都市』だが、多くのユーザーに長く楽しんでもらうために技術的な面から何を行ったか、チームの運用体制から何ができるか、そして開発チームとサポートチームのいい関わり方のために何が必要なのかをテーマに公演を行った。

 
(1)開発体制について

まず、渡部氏（写真）が登壇し、『消滅都市』の紹介を行った。『消滅都市』は、ドラマ×アクション×RPGのコンセプトで企画・開発されたゲームアプリで、2014年5月にリリースされた。現在、累計500万ダウンロードを突破しており、App StoreやGoogle Playの売上ランキングでも上位に入る人気タイトルとなっている。

その後、クライアントと開発環境、サーバといった現在のシステム構成をそれぞれ紹介していった。以下のスライドのとおりとなっている。
 
開発体制は、ローンチまで17名で開発を行った。開発期間は、プロトタイプで1ヶ月、その後、サービス開始まで半年を要した。開発まで7カ月だった。上層部からは半年でリリースするように指示がでていたため、チームメンバーの時間を無駄に広告することがないよう、並列でムダのない作業を心がけたという。この時は、運用のことは考えず、半年後のローンチを目指していたという。
 
何とかローンチしたが、運用直後は運用のワークフローが存在しておらず、2014年夏までに開発の運用ワークフローが確立したそうだ。またリリース直後は短期間で無理して開発したため、不具合が多く、システムの安定化に努めていたとのこと。

2014年秋ごろにランキング機能を導入するとともに、ソースコードを大きく作り直した。同年冬から開発チームの増員を行っていった。テレビCMも放映も開始するとともに、開発チームも17名から50名まで増員した。サポートチームはリリース直後に発足したが、同じ時期に変更も行ったそうだ。
 

(2)サポート体制

続いて、田口氏が登壇し、カスタマーサポート体制を紹介した。カスタマーサポートは、現在では多くの業種で取り入れられており、同社も例外ではない。以前は苦情受付を行う業務という位置づけだったが、今日では顧客の声を聞いてマーケティングに活かしていく会社が増えているという。

具体的な業務内容だが、夜間を除く365日、顧客からの仕様や不具合、課金障害への問い合わせメールに対応するほか、通報のあったチート行為の調査、オークションサイトでのRMTの調査などがメインの業務になっているという。アプリ内に問い合わせフォームがあり、簡単に問い合わせを行うことができる。

CS対応の流れは、問い合わせフォームからメールでお問い合わせがくる。外注している一次対応チームが仕様書などの資料に基づいて対応し、不具合などの情報は、CSコーディネーターがとりまとめて開発チームにフィードバックや修正依頼などを行っているという。
 
また、通常のお問い合わせ以外にも、Twitterアカウントを使った対応にも力を入れている。フォロワー5万人を超えている。ゲーム内の宣伝やイベント告知なども行うほか、顧客からのサポート窓口としての役割も果たしているそうだ。Twitterは、ゲーム内キャラクター「ギーク」になりきって投稿を行っている。
 
ゲーム内に不具合や障害が発生した場合、ギークがキャラクターになりきって告知していく。顧客からの問い合わせには個別対応できるものはやるが、できないものは問い合わせフォームに誘導しているとのこと。
 
公式Twitterアカウントは、カスタマーサポートと相互連携することで障害や問題の早期発見が可能にしているだけでなく、顧客との間に入ってクッション的な役割を果たしている。この意味で、Twitterアカウントが顧客満足度に寄与している。


 
続いて渡部氏が再度登壇し、多くのユーザーに遊んでもらうために技術的な取り組みを紹介した。

公式Twitterアカウントに寄せられる意見として、自分の使っている端末で遊べないので対応してほしいというものが多いという。『消滅都市』はアクションゲームなので、フレームレートの高い状態で遊んでもらいたいと考えている。しかし、スマートフォンは、種類が多く、全ての端末で完璧な動作を実現するのは難しい。
 
開発チームでは動作ポリシーを決めており、スペックやOSのバージョンによって対応できないと判断している。とはいえ、開発チームにとっては対応できない端末は数ある端末のひとつだが、顧客にとっては唯一の端末で動かないと捉えがちだ。そのため、対応端末を増やすための取り組みは継続的に行っているという。

動作速度の改善は確実にうまくいく方法はなく、アプリごとに原因を探っている作業が必要になる。調査ツールは、XcodeのフレームデバッガツールやInstruments、Adreno Profiler1やPerfHUD ESを活用し、日々、無駄な処理を調べているという。
 
銀の弾丸はなかなかないが、一箇所だけ2Dのゲームであれば多くのゲームアプリに適応できる方法があるとのこと。「使っている会社が多いかもしれないが」と前置きして、Androidのハードウェアスケーラを紹介した。ノーコストで画像の引き伸ばしができるツールだ。
 
開発チームでは、アプリ向けのイラスト素材はiPhone5で表示させることを前提にして開発しているという。2Dのゲームでは高解像度のレンダリングを行っても、さほど綺麗さが上がらない。Androidのハードウェアスケーラで小さくレンダリングして画面全体に大きく引き伸ばしているという。この仕組みはタブレットなど高解像度端末には効果的で、フレームレートが37しか出なかった端末でもこれによって60台に改善した事例もあったそうだ。これによって動作対象端末を広げることができた。

対応端末の拡大をTwitterを介して告知したところ、顧客から御礼のメッセージをもらい、「やってよかった」と思ったという。さらに2015年3月に対応端末を拡大するアップデートを行った。新たに10種類の端末に対応したが、告知はツイッターでつぶやいただけにもかからず、1ヶ月でのべ1万ダウンロードが獲得できたとのこと。CPIを500円と想定すると、広告費換算で500万円ほどの効果となった。
 
また本作は「Cocos2d-x」を使って開発した初のアプリケーションとなる。社内にノウハウがなく、「良い設計」をわからない状態だった。「とにかく動けばいいと無我夢中で開発してリリースしてしまった」と述懐した。そのなかで「Cocos2d-x」にある"runAction"という機能を多用していたが、アップデートを繰り返していくうちにコードが複雑なものになってしまったという。
 
その理由は、ゲーム中に入る割込演出や、スキル発動時のカットイン演出、チュートリアル時に止める処理、ポーズボタンの処理などで複雑になっていたことだった。この結果、ポーズ中、本来、動き出すタイミングではないのに勝手に再開するといった不具合が発生していった。開発チームではその都度、その場しのぎの対応を繰り返していたが、QAで発覚するバグが頻発し、リリースの遅延の原因となったという。
 
2014年の秋には、このままいくのは限界ということでゲームの部分を作り直した。事実上『消滅都市2』と内部的には呼ぶほど書き換えた。updateのループによって動く設計に変更した。いわゆる「普通の作り方にした」。"runAction"は極力使用しないようにし、ガチャや合成などアクションゲーム画面以外で使用することにした。

updateを使うことで停止再開系のコードがスッキリしたものの、起動計算などの記述が面倒になるという問題もあった。そこでupdateを駆動しつつ、runActionを併用する構造として、両者のいいとこ取りを狙った。動かし方は違うが内部の処理は全く違うものにした。
 
デバッグの期間は2週間。人数をかけて短期集中でテストしたという。導入前後はゲーム感に変化がないよう注視するものだったが、ポーズ/再開周りのコードの見通しが良くなったほか、問題が発生したことによるリリース順延回数が減るという効果があった。

最後に、多くのユーザーに遊んでもらうために多くの端末に対応させることが必要で、ゲームエンジンの特性を知ること、不吉な前兆があれば勇気を持って取り除く必要があるとまとめて技術面のパートを締めくくった。


 
田口氏が再び登壇し、サポートの事例を紹介した。サポートに寄せられる問い合わせは、1日あたり数百件あるという。問い合わせ内容は、ゲーム内通貨「フクザワ」が付与されない、App StoreとGoogle Playで決済されないといった課金に関する問い合わせのほか、ガチャの確率や進化・強化に関するもの、クエストの難易度、不具合に関する問い合わせが多いという。
 
顧客によってニーズが違うため、全てに対応するのは無理だが、CSチームだけで対応するのは難しいため、開発チームと一体となって取り組むことにしたという。具体的な取り組みとして、管理ツールの改善、コミュニケーションの強化、滞留するサポート案件の精査などを行った。

管理ツールは、ユーザー状態やデータの書き換え、行動ログの閲覧、マスターデータの参照などができるもので、ブラウザで閲覧できる。ただ、短期間でリリースしたため、リリース当初は必要最低限の機能しか持っていなかった。ログの検索ができない状態で、問い合わせにも十分対応できなかったという。

例えば、CSチームでは、アイテム入手経路やタマシイの合成履歴、クエストのプレイ記録などログの調査が不可能のため、開発にいちいち依頼していた。そのため、回答が遅れて、満足度が低下するという状態となった。た開発側の負担も増えた。CSが自分で調査できるようにログ検索ができる機能を追加した。
 
またコミュニケーションを強化するため、CSチームが現在稼働中のプロダクトの中心で業務を行うようにした。あえて近くに席を設置し、開発とのコミュニケーションができるようにした。近くに席を置くことで、緊急対応の不具合にも短時間で対応できるようになった。
 
例えば、進化設定に誤りがあり、進化しても何も発生せず、レベルが最大99から1になる問題があった。問い合わせベースで発覚した。早急に対応が必要ということで、通常の手順を踏まず、あえて口頭ベースで対応を依頼し、数時間で対応が完了したという。

これはデータの設定ミスが原因だったが、「気をつける」だけでは第2、第3のミスが発生するおそれがあるため、再発防止策も導入した。Excelのデータから変換して、ゲームのなかで読み込むデータを生成しているが、システムのアップデートを行い、同一のタマシイに進化する場合、Jenkinsが停止し、アラートを出すようにしたという。

また、滞留するサポート案件の精査も行った。問い合わせが増える中、優先度の低い案件が放置されがちだったことが判明した。開発チームの意見としては、イベントや新機能の開発を優先したい、問題が再現できない、修正するためのリソースがない、昔過ぎて覚えてないなどがあった。

そこで十分に対応できないのは、コストの問題がある。多少荒っぽくてもコストを掛けずに効率的に取り組むため、「Doverミーティング」を主催した。CSと開発マネージャー、企画、QA、コミュニティーマネジメントの各担当者担当が同席して、一堂に会して問題を話し合っているという。
 
CSチームとして障害事案を開発進捗ツールに乗せてもらうこと、修正の確約を取り付けること、進捗状況を終えること、問題を放置した場合の影響範囲を知ってもらうことなどが狙い。また開発チームには担当者をつけてもらい、バッファではないため、同一人物がやり続けないようにしているという。また新しく配属されたメンバーはここから対応している。

実施される案件数は以下のスライドのとおり。
 
これを実施したことで、開発へのエスカレーションでの解決率が70％だったが、Doverミーティング実施後、99％に改善した。「この規模のアプリでの解決率は、グリーの社内でも例がない」。また、問い合わせのあった顧客にアンケートを行っているが、「非常に満足」「満足」と答えた割合が50％台から70％弱に上昇したという。管理ツールの改修やコミュニケーションの強化、Doverの開始といった施策の効果が出ている。
 
最後に、渡部氏は、「今回のCECECのテーマにもなっているが、チーム全体でお客様のことを考えて運用して、"Reach Next Level"（新しいレベルへの到達）を目指していきたい」と述べてセッションを締めた。


   

CEDEC2015関連記事