ユーザを飽きさせない高頻度の更新を可能にする開発運用ノウハウ ～ハイスピードな開発、リリースを実現するために～
講演者
鈴木 元気 さん（株式会社Cygames）
講演内容
実際に運用しているプロジェクトにおいての改善方法を講演されました。
ゲームにおける運用
機能やリソースを追加し続けて、ゲームを成長させていくことが大切である。
では、これを実現するために何を行えば良いのか？
遊んでもらうため
- ゲーム自体の面白さ
- 定期的な更新
この両方がとても重要なことである。
また、最高の運用は最高のコンテンツに欠かせない要素である。
最高の運用とは？
ユーザーを楽しませることが重要→想像の上を行くクオリティとスピード感が必要
不具合を出さず、安定稼動を常に心がけ、より快適な環境を提供する
↓
高頻度更新かつ不具合ゼロを目標に開発を行っている。
コンテンツを成長させていくためには、
企画→開発→更新→反響の繰り返しをロスの無くすように高頻度で行う必要がある。
課題
- そもそも開発できるのか？
- テストできるのか？
- リリースできるのか？
そもそも開発できるのか？
開発用のツールを準備し、拡張しやすい設計で作る。
リリースできるのか？
ビルドの高速化と転送の高速化の整備を行う。
テストできるのか？
高頻度更新におけるテストの有効な手法を見つける必要がある。
不具合を出さないためにテストが重要である。
では、テストの効率化を行うためには？
デザインデータの検証
- 表示が正常か
- アニメーションは適切か
- 品質は適切か
っといって自動検証で担保することが難しいもののため、手動＆目視で行う
パラメータの検証
- パラメータの不備がないか
- バランスが崩れていないか
- データ間での参照が正しいか
こちらは自動検証でも十分な検証が可能である。
実際にエラーの大半はデータの参照ミスだった。
また、機能追加に伴いマスターデータが肥大化していくため、それに伴ったテストケースが増える。
そのため自動検証の仕組みが必要となった。
検証を行うためにDSLを用いたメタプログラミングで構築を行った。
DSL（ドメイン固有言語）で構築
特定の問題を解決することに特化した言語である。
今回はデータ検証に特化して作成を行っていた。
今回はRubyを使用した。
なぜExcelではないのか？
- データ制約の記述が簡潔
- 制約反映のフローが適切
- 検証以外の機能拡張が可能
検証と運用
検証時にエラーが出た際、社内連絡用ツールに自動投稿を行うようにしている。
投稿内容には、担当者、パラメータ、詳細を表示し分かりやすくしている。
導入前
Excelで入力（この時点でVBAを使用した入力規則などの基本的なチェックだけを行っている。）
↓
ビルド＆反映
↓
テスト
最後のテスト段階でエラーが検出されると、ビルドのやり直しが発生してしまい、ビルド時間が非常に無駄となっていた。
また、入力規則に関しても個人環境だけでのチェックだったので制約が反映されないことなどもあった。
導入後
Excelで入力（この時点でVBAを使用した入力規則などの基本的なチェックだけを行っている。）
↓
DSLで検証→エラー検出時に報告を行い、以降の処理を行わない。
↓
ビルド＆反映
↓
テスト
エラー検出タイミングを早い段階で仕込むことで効率よくチェックでき、
また、制約チェックなども共通の箇所で行うため反映漏れがなくなる。
懸念事項
検証自体が独立しているため、機能追加などを行った際に拡張漏れがでてくる可能性がある。
開発フロー自体に自然な形でDSLを記載するフローが必要となってくる。
対策
DSLを使用してcsvデータのDB化とコードの自動生成を行うように対応し、
検証項目の拡張もできるようにしている。
DB化のメリット
起動時の処理が高速化された。
起動時に行っていた、CSVデータの展開処理が不要となりデータ検索機能が大幅に強化された。
コードの自動生成
CSVデータから自動的にそのデータを管理するためのコードを生成する。
生成するコードは３種類あり、
データクラス
データ管理クラス
統合管理クラス
の３種類を自動生成している。
１．DSLに定義されている情報を下に、データクラスを生成する
２．データ管理クラスに主キーを元にデータの単体取得と複数取得処理を生成
３．データ管理クラスへのアクセサを統合管理クラスに追加する
自動生成の問題点と対策
特殊なケースに対する対応が出来ない。
- 手動で生成する
特殊なケースに対応したものや特殊な検索に対応したものを記述
パフォーマンスを追及したものを記述可能
- 自動で生成
共通部分の構築は強い
この両方のいいとこ取りをするためにデータ管理クラスをpartial化して対応を行っている。
まとめ
全体として起動の高速化と開発工数の大幅削減に成功することが出来た。
データ検証システムを普及させるために、DB生成やコードの自動生成などを用意して
使う機会を増やしている。
また、１タイトル内で完結させるには非常に惜しい機能だったので、
他タイトルでも使用できるように検証システム自体も容易に実装している。
システムの共通部分
- 基礎部分（Ruby）
- DSL用構文定義
- データ検証機能
- データ報告機能
- DB生成機能
- コードの自動生成機能
タイトル依存
DSLのデータ構造やデータ制約
感想
更新を効率的に行うために機械的な部分をより簡単に対応できるようにしていたりと
参考になりそうな部分が非常に多くありました。