Cygamesは、8月31日開催の「CEDEC2017」にて、セッション「ユーザーを飽きさせない高頻度の更新を可能にする開発運用ノウハウ～ハイスピードな開発、リリースを実現するために～」を実施。
同社の鈴木元気氏（技術本部 クライアントサイドエンジニアリーダー）が、社内プロジェクトにおける実例を踏まえて運用フロー改善に関するノウハウや、DSLを導入することで実現したテスト効率化、コード自動生成システムなどについて語ったセッションの模様をレポートする。
▲鈴木元気氏氏。
鈴木氏はまず、ゲームにおける運用について、ゲームに対してコンテンツや機能を追加して拡張することで、「ゲームを成長させていくことが大切」だと説明。コンテンツを追加し拡張させることは、ユーザーの手にとってもらいやすくなるので良いことだとしながらも、「ちょっとしたことで離れる恐れもある」という。飽きずに楽しんでもらうためには、“ゲームの面白さ”と“定期的な更新”の「両方の要素が重要である」と鈴木氏は言う。
また、“最高のコンテンツ作り”という同社の企業理念にも触れ、デザイン、プログラム、パラメーターなど、ゲームに関する全ての面で最高のものを提供することを意識。もちろん、運用についてもそうで、「最高のコンテンツにとって、最高の運用は欠かせない要素」と考える鈴木氏。最高の運用について、鈴木氏は「想像の上をいくクオリティとスピード感でユーザーを楽しませる」、「不具合を出さず常に安定した稼働でより快適にプレイしてもらう」ことをポイントに挙げ、高頻度更新かつ不具合ゼロを目標に、運用改善に取り組んだとのこと。
また、“最高のコンテンツ作り”という同社の企業理念にも触れ、デザイン、プログラム、パラメーターなど、ゲームに関する全ての面で最高のものを提供することを意識。もちろん、運用についてもそうで、「最高のコンテンツにとって、最高の運用は欠かせない要素」と考える鈴木氏。最高の運用について、鈴木氏は「想像の上をいくクオリティとスピード感でユーザーを楽しませる」、「不具合を出さず常に安定した稼働でより快適にプレイしてもらう」ことをポイントに挙げ、高頻度更新かつ不具合ゼロを目標に、運用改善に取り組んだとのこと。
高頻度更新に関しては「ユーザーのためではあるが、高速なイテレーションでコンテンツを成長させ、開発のロスも少ない」と鈴木氏。サイクルを高速に回せすことで、作ってみたけどダメだったというロスが少なくなり、ユーザーにも開発にもメリットがあるとした。ちなみに同社タイトルの更新頻度は、「タイトルによる」（鈴木氏）が、週に2～4回程度、1日に2回実施する場合もそうで、「だからこそスピード感をもって対策をとる必要がある」そうだ。
続いて、鈴木氏は高頻度更新における課題について説明。開発できるのか？ テストできるのか？ リリースできるのか？ という3つの工程で、それぞれスピードと効率が求められる。鈴木氏によれば、開発とリリースは、課題が明確で解決策やノウハウが豊富にあるという。
“テストできるか？”という課題については、高頻度更新におけるテストで有効な手法、テストを効率化するシステムの構築を目指したそうだ。ここで鈴木氏は、あるタイトルの更新スケジュールを紹介。更新項目に対して整理した結果、更新内容は主にデザイン素材と
パラメータだった。デザイン素材の検証は、表示やアニメーション、品質の適切さを確認するため、自動検証での担保は難しい。一方、パラメーターの検証は、設定値やバランス、参照エラーの確認となり、自動で十分な検証が可能とのこと。
パラメーターについては「むしろ自動で検証すべき内容」（鈴木氏） パラメーターの検証では、参照エラーがミスをしやすいという。例としては、クエストをクリアし報酬としてもらえるアイテム、称号の獲得条件となるクエストなどで、そのクエストが存在しないとエラーが発生する。機能追加によって、マスターデータは肥大化し、それに伴ってテストケースも増える。そうなると、自動検証が必要になってくるというわけだ。
パラメーターについては「むしろ自動で検証すべき内容」（鈴木氏） パラメーターの検証では、参照エラーがミスをしやすいという。例としては、クエストをクリアし報酬としてもらえるアイテム、称号の獲得条件となるクエストなどで、そのクエストが存在しないとエラーが発生する。機能追加によって、マスターデータは肥大化し、それに伴ってテストケースも増える。そうなると、自動検証が必要になってくるというわけだ。
では、データ検証の自動化はどのように行ったのだろうか。鈴木氏によれば、参照エラー検出も含めた検証システムをDSLによるメタプログラミングで構築し、データ検証用の言語を独自設計。簡単な記述で検証を実現できるようにしたとのこと。
同社はなぜDSLを採用したのか？ その理由について鈴木氏は、データ製薬の記述の簡潔さ、制約反映のフローの適切さ、検証以外の機能拡張を挙げ、DSLによるデータ検証の方法を紹介した。
また、エラーが発生した場合、社内の連絡用ツールに、担当者やビルドパラメータ、エラー詳細へのリンクといったエラー情報が自動投稿されるという。エラー詳細は、対象ファイルやエラー内容、該当箇所がわかりやすい形で報告されるため、「担当者が問題をすばやく解決でき、チームとしてもすばやく対応できるメリットがある」と鈴木氏は語った。
▲DSL導入前、導入後のフロー解説。
DSL導入の課題として、もう1つ挙げられたのがデータ検証システムの普及について。検証が独立していると拡張漏れが出てくるほか、開発フローで自然にDSLを記載するフローが必要だった。そのため、csvデータのDB化とコード自動生成も実現したそうだ。
DB化は、起動時処理の高速化とデータの検索機能の大幅強化がメリット。また、DSLによるコード自動生成は、マスターデータDBからのデータ取得や各カラム値取得に必要なコードを全て生成できる点が強みのようだ。
▲プロジェクトのプログラム構成とコード生成の流れ。
ただ、自動生成には懸念点もある。解放期間が設定されているクエストなどの特殊なケースへの対応だ。特殊なケースの場合は、自動生成、または手動生成で対応することになるが、「特殊ケースの場合は、動作上のパフォーマンスを優先すると手動に軍配があがることもある」と鈴木氏。そこで、特殊ケースだけクラスを手動生成するといった、手動化と自動化の両方を活かす共存策をとった。
DB生成とコード生成について鈴木氏は、「超高速化と開発工数の大幅削減を実現し、検証で使用するDSLで両機能に対応した」とまとめた。
また、DSLの他タイトルへの展開について「簡単にできる」と鈴木氏。タイトルに依存するのはデータ定義（DSL）だけで、基盤部分（Rudy）についてはタイトルに依存しないため、同社内でも横展開しているとのこと。
最後に鈴木氏は、「一連の検証システムは、構築には多少手間がかかるけれど、問題を抱えていらっしゃる方にとっては良いものだと思います」と、改めてDSLの利便性の高さを説明。そして、「更新頻度を下げれば良いのではという意見もありますが、すべてはCygamesの理念でもある“最高のコンテンツ”を作るためです。そういったチャレンジをするのが我々の使命であり、これからもおもしろいゲームがどんどん出していければと思います」とメッセージを送った。
