イベント

2019.11.28

【CEDEC2019】「大規模モバイルゲーム運用におけるマスタデータ管理事例」セッションレポート

  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly
  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。本記事では、9月6日に行われたセッション「大規模モバイルゲーム運用におけるマスタデータ管理事例」の内容を一部抜粋してレポートします。

セッションの冒頭では、登壇者の株式会社ディー・エヌ・エー ゲーム事業部 共通基盤部人西聖樹より、近年のモバイルゲームの大規模開発に伴い、マスタデータ入力やそれ以外の作業者などチーム内のメンバーが増加し、ワークフローも複雑化している状況が説明されました。

そのような状況の中、マスタデータを管理、入力するためのワークフロー構築は、とても重要な分野であり、世の中に公開されている情報は未だ少ないと人西は述べています。

そのような背景を踏まえて本セッションでは、まずDeNAのこれまでのブラウザゲームの時代からネイティブアプリのモバイルゲーム時代の遷移を説明しつつ、これまでに実施したマスタデータの管理およびワークフローの構築の取り組みについて紹介されました。

マスタデータとは

「マスタデータ」とは、モバイルゲームの運用において、デプロイ時点で運営側が先に用意しているアセット群のうち、文字列で表現されるデータのことを指し、ユーザー起因で内容は変化せず、運営側により変更されることがあり、ゲームのランタイムからするとRead Onlyなデータ。ユーザーごとに値が変化するデータは含めず、テキストデータで画像や3Dモデルのようなアセットも、今回の発表では含めない。

マスタデータは、ゲームの動作やゲームバランスを決定するために、あらかじめ設定をしておくパラメータを指し、多くの場合は表形式で表示できる構造になっています。

モバイルゲームの多くは、アプリ起動時に最新のマスタデータをダウンロードして、そのデータを参照しながら動作します。

クライアント側だけではなくサーバー側のプログラムも同様に、マスタデータを参照することもあり、プログラムとマスタデータを分離しておくことで、マスタデータ部分はプランナーなどの非エンジニアでも容易に変更できるように設計されているとのことです。

マスタデータの更新のみで完了する場合

アプリバージョンアップをせずにマスタデータだけ配信することが可能です。

アプリのバージョンアップは、Apple Storeなどプラットフォームの審査を通過する必要があり、時間がかかりますが、更新内容をマスタデータに切り出しておくことで、各審査を通さずに、運営側のスケジュールのみで、迅速にゲームの更新を反映することができるようになっています。

ここでは、マスタデータの一例として、「武器」マスタや「必殺技」マスタのサンプルが紹介されました。

以下の表では「武器」マスタの中に「スキルID」という列が入っており、「必殺技」マスタのIDでも、あるマスタが別のマスタへの参照を持つことは非常に多いとのこと。本セッションでは、これについてリレーションと呼んでいました。

マスタデータの一般的なワークフローとして、最初にプランナーがマスタデータを入力、その入力したマスタデータをゲームのランタイムに読み込める形式に変換します。

その後、変換したランタイムをゲームに読み込ませ、ゲーム上で手触りを確かめ、パラメータを変更希望な部分があれば、マスタデータを修正して、ランタイム形式に変換、再度ゲーム上で確認することが一般的なフローとなっています。その後、本番環境にデプロイされます。

マスタデータの役割について、ユーザーのプレイサイクルをデザインすることが重要だと説明されました。ユーザー体験の中でも、UI、画像、音楽のような目や耳で感じられるビジュアル、オーディオ以外全般のことを指すようです。

例えば、ステージクリアやレベルアップのテンポ、アイテムや必殺技、魔法の種類や性能、敵の強さの調整、会話やチュートリアルの説明などが該当します。

新イベントやステージを、アプリ本体更新なしに追加したり、プレイヤーが挫折しやすいポイントはすぐに修正が可能なので、コンシューマーよりもモバイルゲームの方が、運営を続けていく点においては、マスタデータを更新する機会が多いと人西は述べました。

DeNAにおけるこれまでのマスタデータ管理の歴史

ブラウザゲーム時代

ここからは、DeNAにおける過去のマスタデータの管理の歴史遷移について紹介されました。

DeNAのブラウザゲーム開発運営の時期は、およそ2009年から2013年。開発の運営に携わるチーム人数は30名程度で、プランナーは10名程度参画していたとのことです。

技術的には、クライアント側はHTMLとCSS、JavaScript、サーバー側はLinuxとApache、MySQLというオーソドックスなWEBアプリケーションで、DeNAではPerl、他社だとPHPなどのスクリプト言語で構成されていることが多いようです。

当時のブラウザゲームのマスタデータは、Excelファイルを共有ファイルサーバーに置いて管理していたそうで、マスタデータの反映や閲覧は、ゲームごとに独自に存在する管理用のWEBアプリケーションで管理していました。

マスタ作成ワークフローについては、マスタの種類ごとにExcelファイルが存在し、ファイルサーバーで管理されていました。

また、マスタデータを運営する作業者ごとに、そのデータを確認するためのゲームサーバーが割り当てられており、そのサーバーで各自が、その時点でのリリースのバージョンがセットアップされているため、自身で作業することが可能になっています。

作業フローは、Excelファイルをファイルサーバーからダウンロード、ファイルを編集した上で保存し、管理用WEBアプリケーションを経由して、自身のゲームサーバーに反映します。

その後実際にパラメータの動作確認のため、モバイル端末のブラウザ経由でアクセスして動作確認後、再度修正が必要であれば修正します。

データに問題なければ、mysqldumpでCSV化してgit管理。最終的にFIXしたCSVのデータを本番環境にMySQLへ流し込むことで、マスタデータを本番反映していたとのこと。

管理については、運用時に追加するマスタデータの多くは、一時的に使用するものとして管理されていたとのこと。その理由としてソーシャルゲームでは、ゲーム内イベントで使うテーブルなど、特定の期間でのみ必要なマスタが継続的に発生するからだと考えられます。

共通テーブルには、アイテムマスタやキャラクターマスタなど、イベントに紐付かない共通のテーブルがありますが、同時編集に留意してマスタを追加することが重要で、その部分はメンバー間のコミュニケーションでカバーしていたと人西は話しています。

チームの人数が少ない時期は、コミュニケーションで問題なかったものの、メンバーが増えてくると伝達が漏れて、誰かが編集したデータを上書きしてしまうといった事故が発生したようです。

さらに、独自の管理画面でマスタデータを投入・閲覧していたため、テーブルを追加するたびに管理画面も実装が必要になり、エンジニアの工数が増えて、テーブルによっては個別にリレーション先のテーブルの内容も見たいというプランナーの要望もあったため、エンジニアが個別で実装していたとのこと。

マスタの入力に関する部分では、運用が長期化すればマスタデータも増加するため、、入力が必要な個所をマクロや関数でカスタマイズし、できるだけ判別しやすく減らすなど、作業内容を単純化してデータ肥大化に対応しています。

ただ一方で、ナレッジが個人に依存しすぎたため、担当者が退職などで入れ替わるたびに引き継ぎされない箇所が多く、その影響でExcel上の意図しないデータが入れ替わってしまったり、誤ったデータ入力につながったりしていたことが問題だったと人西は振り返りました。

基本的に作業の分業はリリースバージョンごとに担当しており、バージョンごとにシートが分かれていたため、他の人の作業の影響を受けることは少なかったとのこと。

ただ、リリースに向けて、現在のブランチまでをマージ後、本番環境に反映する段階で、CSVがコンフリクトすることが多いようです。

同じ個所を複数のリリースバージョンで調整していたことが発覚し、コンフリクト解消が非常に大変だったこともあるようです。

対応策として、各イベントのリリースバージョン担当者とコミュニケーションを取り、「コンフリクト部分において、どちらが正しいデータなのか?」など、直接議論をしながら正しい値を選択する作業をひたすら繰り返していました。

新規キャラクター追加に関しては、共通のキャラシートのテーブルが存在するため「どの範囲のキャラクターデータの値を本番に反映するのか」「未来のデータは反映しないので省く」といった細かな更新をプランナーが手作業で実行していたため、未来のキャラクターのデータが反映されかねない危険な作業をしていたことも明かされました。

ブラウザゲームの時代を踏まえて良かった点としては、独自の管理システムを用意していたため、エンジニアが自ら拡張することで、見やすいように成形することができたこと。

開発環境のデータベースにSQLを投入すれば、自身の環境を確認することが可能なので、実際にパラメータ確認の点で、ネイティブアプリと比較してイテレーションが早いこともメリットと考えられるようです。

さらに、MySQLのテーブル単位でイベントの単位に紐付けていたため、比較的管理が容易で、イベント期間が終了したら、テーブルは不要なので削除も可能、他のイベントのデータと重複することもないため、コンフリクトすることもなかったとのこと。

一方で、Excelファイルを共有サーバーで管理していたため、複数人で同時にデータを編集できないことがデメリットとして認識していたと語られました。イベントのデータは管理が容易ですが、ゲームで共通で使用するマスタは、Excelで管理する方が難しかったようです。

また、イベント単位で切られているマスタは、ブックでの管理のため比較的容易ですが、共通のマスタは同時編集不可のため、イベント専用アイテム追加などの作業中には他の人が触ることができないので、当然待ち時間が発生してしまいます。

それを回避するために、同名のExcelファイルをコピーして、一時的に入力できる運用方法でカバーしていました。

ガワネイティブ時代

この時代は技術的的にブラウザゲーム時代と同じ構成のブラウザゲームを、webviewでネイティブアプリ化しており、外側だけネイティブアプリで、中身はブラウザゲームであるため「ガワネイティブ」と呼ばれています。

この時代になると、チーム人数の規模が一気に増え、開発と運用チーム人数が100名程度、うちプランナーが50名程度という大規模なチームになりました。プランナー全員がマスタデータを編集する可能性があったため、しっかりとワークフローを考えなければならない状況だったと、人西は当時の状況を振り返りました。

ネイティブアプリ側もOpenGL APIを実行可能にすることで、中身はブラウザゲームですが、ネイティブアプリに近い、リッチなアプリゲームを開発できるようにしています。

この時期から、Excelファイルをファイルサーバーで共有して管理するのではなく、Googleスプレッドシートを使用してデータ入力するように変化していったそうです。

Googleスプレッドシートを利用すると、リアルタイムで複数人が共同編集可能になり、データの閲覧は基本的にGoogleスプレッドシート、データの反映は独自のCLIツールを開発し、それをGoogleスプレッドシートからダウンロードして、CSVに変換、MySQLにデータを投入・反映していました。

この時期のマスタ作成は、リリースバージョンごとにディレクトリを分けて、Googleスプレッドシートを管理するようになり、各ディレクトリにそのバージョンで追加変更するマスタデータのGoogleスプレッドシートだけが存在する仕組みになっていたようです。

Googleスプレッドシートに入力する内容は、基本的にマスタデータの差分のみを入力。そのため、マスタデータ全てがGoogleスプレッドシートに存在するのではなく、そのリリースバージョンで追加・変更するものだけが管理されます。

そして特定バージョンまでのマスタデータをゲーム反映したい場合、リリースバージョンごとの差分が存在するため、過去バージョンのマスタデータを独自CLIで統合し、最終的に全てのマスタデータが内包されたマスタデータを作成しています。

これにより、疑似的にバージョン管理を実現でき、Googleスプレッドシート上でマスタを入力し、Jenkins、独自CLIを使って担当リリースバージョンのゲームデータに変換して、ゲームに反映後、確認します。

実機で動作確認をして問題が発生した場合、修正後に再度Jenkinsを実行、問題なければそのままmysqldumpでCSV化して、同様にgit管理下にCSVを配備し、gitでCSVを管理しています。最終的にCSVをMySQLに流し込むことで、マスタデータの本番反映を実施していました。

企画者がリリース単位でスプレッドシートにデータを作り、Jenkinsのジョブを実行、スプレッドシートからマスタデータをダウンロードし、CSVに変換、開発環境用のデータベースに反映するのが詳細なフローになります。

反映後、企画者がゲーム上で確認して問題なければ、別のJenkinsのジョブを実行し、スプレッドシートからダウンロード、分割されたシートをマージし、CSVに変換して、githubへPullRequestとして送信されます。

そして、github上ではマスタデータのレビューを行っており、この変更で問題なければ、リポジトリにマージすることで、初めてマスタデータの変更がCSVに反映されるというフローを採用しているとのことです。

しかし、マスタデータが肥大化することが別の問題として発生しました。運用が長期化するとマスタデータが増えるため、作業に支障をきたしていたとのこと。

この問題の対応については、GoogleスプレッドシートのVLOOKUPや入力規則を利用して、なるべく編集箇所や入力できる値を絞り、自動でマスタデータが生成される仕組みを作って解決しています。

当時は、リリースバージョンごとにディレクトリを分け、Googleスプレッドシートを管理していたため、シートが独立していました。疑似的にバージョン管理の仕組みを導入することで、他のリリースバージョンの影響を一定切り分けることが可能になったとのことです。

しかし、それまでのバージョンのマスタデータを統合する際、以前のバージョンのマスタデータを他の人がまだ編集中の場合に問題が発生することが判明しました。

イベントAとBが並行で開発を進めている際、どちらも編集中の状態の場合、ゲームにそのまま投入するとエラーが発生してしまいます。

それ以降のバージョンでマスタデータを入力している人のデータが、全てエラーを含むデータになってしまうため、実際にゲームで確認したところ、自分が編集していない箇所でエラーが発生してしまい、原因が分からない混乱を招くことがあったようです。

これはリリースバージョンが異なる中で、影響範囲が切り分けられていない部分があることが原因です。

その問題を防ぐために、リリースバージョンごとにシートを独立して分けていましたが、さらに個人で作業するためのディレクトリを切り、マスタデータを編集し、その後にイベントや自分の担当したリリースバージョンに確定したデータを反映していた状況でした。

またブラウザゲームの時代と異なり、この時期にはJenkinsを活用することで、作業を自動化して入力作業以外の処理を、基本的にJenkinsの任せることが実現できたとのことです。

ガワネイティブ時代を振り返ると、Googleスプレッドシートを関数や入力規則で拡張することで、データ入力が一定自動化することができたため、特定環境にデータを挿入することや、PullRequestを送る部分については、かなり自動化を進めることができ、Jenkinsで機械的にマスタの誤りや不整合をチェックできるようになったと、人西は述べました。

ただ、Googleスプレッドシートのデータ量の増加と運用に伴って、マスタデータが増加していく一方で、シートのデータ量も増加したことが課題点として挙げられました。

さらにシートの関数機能を多用していたため、シート自体を展開、編集する処理がどんどん重くなっていったようです。

また、複数の運用開発ではリリースバージョンも複数存在するため、並行開発が進んでいく中で、疑似的にバージョン管理はできていましたが、マスタデータの変更の影響を、完全には切り分けられていないことも課題だったようです。

さらに、リリースバージョンまでのマスタデータを統合してゲームデータにする段階で、そのマスタが編集中の場合があり、エラーが発生することもあったとのこと。

マスタデータがどんどん増大していくので、それにともない線形的にマスタデータのビルド時間が長期化していく課題も発生しました。

運営が長期化すれば、マスタデータ自体も増加するため、GoogleスプレッドシートのAPIを利用してマスタデータをダウンロードする際に、APIのレスポンス速度、あるいはネットワーク通信を挟むため、通信速度がボトルネックになる課題も同時に発生しています。

ネイティブアプリ時代(現在)

現在のネイティブアプリ開発では、チーム人数としては約70名程度とやや減少傾向にあり、うちプランナーは30名程度の規模となりました。特徴として、この頃の時期からUnityを利用したゲーム開発が進んでいたようです。

マスタデータ管理については、Googleスプレッドシートを使用、Jenkins上でシートのマスタデータをゲームデータに、ゲーム側ではjson読み込みを活用しています。

バージョン管理では、gitおよびGithubを利用することで管理していました。ビルド時間が長期化する課題については、キャッシングの仕組みを導入することで、一定ビルド時間を減らすことに成功しています。

また、ネイティブアプリ化にともない、アセットデータをクライアント側に配信する概念が生まれ、後述する新たな課題が発生したとのこと。

マスタデータのワークフローの概要は、ガワネイティブ時代と同様、ディレクトリごとにリリースバージョンを作り、ディレクトリ内にさらに作業者ごとのディレクトリが存在している仕組みです。

また、それぞれのディレクトリの内部に、そのバージョンで追加変更するマスタデータのスプレッドシートが存在しており、マスタを追加変更する際は、対応する名称の空間に自身のシートを作成し、マスタデータを書き込みます。

変更後に、マスタデータ書き込みが終わった段階で、作業者のローカルPC上でゲームの変更確認を実行しています。現在ではこのように「データを入力」「ローカルにダウンロード」「変更を加え動作確認する」という作業フローを繰り返しているそうです。

そして、パラメータに問題なければ、Jenkinsを実行します。この作業は追加変更したデータを差分として見られるようなPullRequestを、自分の担当のブランチに対して投げるJenkinsのジョブになります。GitHub上でPullRequestが投げられるので、GitHub上でマスタデータの変更を作業者、あるいはレビューの担当者が内容を確認してマージしていきます。

各バージョンがリリースされるまでは、ブランチ上では別々の差分ファイルとして管理されていました。同じキャラテーブルでも、別々の差分ファイルとして管理されています。それをゲームのランタイム側で、データを読むタイミングでマイグレーションしたデータを作成しています。

この処理では、同キャラテーブルでも差分ファイルだけが増加していくため、リリース後のデータ枠で全て結合して管理していきます。実機確認の際は、特定のブランチのgit管理下にあるデータをゲームサーバーに読み込ませて利用していました。

ここでの取り組みについて、スプレッドシートでデータが複雑化しない工夫は、ガワネイティブ時代と同様に実施し、同時作業や他の人と並行作業する際は、同じバージョン内で分業できるように設計されているとのことです。

一方で、差分で表現するリスクとして、別ファイルで同じ行を変更していた場合に、どちらが正しい行と判断するかという点がありましたが、運用とコミュニケーションでカバーすることで解決していました。

ここで人西は「検知する仕組みくらいはあっても良かったのかな、と思っています」と話しました。

マイグレーションのデータの統合のフローが、ガワネイティブ時代からかなり改善されており、スプレッドシート上のデータをマイグレーションするのではなく、それぞれのバージョンのgit管理下でデータ統合するため、スクリプトなどでマスタデータ、テスト済みのものを取り込むことが可能になっています。

さらに、プログラムコードと一緒にgitのブランチに取り込むことも可能になったため、マスタデータとプログラムコードが乖離する問題も解決したようです。ただ、マスタデータを変更してから、実際にゲームで動作確認するまでに時間がかかる課題は残ったようです。

また実機で確認する際は、マスタデータをmBaaSにあげて確認する必要があります。Unity開発のゲームでは、アセットバンドルの仕組みを利用して、マスタデータおよびそれ以外のリソース、3Dデータや画像を配信していたのですが、その際にアセットバンドルをビルドする必要があり、その処理に時間がかかること。さらにゲーム上で動作確認するまで、時間が必要になる課題もあったとのこと。

作業フロー

続いて、実際の作業のフローが詳しく説明されました。

フローの最初では、各個人でイベント用の環境を持っているため、mBaaSサーバーとビルド、UnityEditorを用意し、Excelで特定のバージョンのデータを作成します。

作成したデータをスプレッドシートに投入、特定のバージョンのシートに入力したデータをダウンロード、必要なアセットを作成し

ます。この部分はJenkinsのジョブでまとまっているので、プランナーが容易にアセットが作成できる仕組みを採用しています。

スプレッドシートのダウンロードには、独自のCLIを利用してゲームデータに変換しています。この際に、特定のバージョンのシートのみをダウンロードしてゲームデータに変換しています。

理由は、直前のバージョンまではgitのレポジトリに全て入っている前提でgit管理しているためで、これまでのデータと今回のリリースバージョンで追加されたデータとなります。

ゲームデータに変換後、ビルドしたゲームデータとUnityEditorを利用して動作確認をします。動作確認で問題がなければ、ブランチに対してPullRequestを送って取り込みます。リリース後に、今回のブランチでの追加のデータ群を、これまでの場所に取り込んでいます。

例えば、リリース前にA、B、Cというブランチを並行で開発したと仮定し、これまでのデータ群、リリースした全マスタデータとブランチAでの追加分、ブランチBでの追加分のデータ、ブランチCでの追加分のデータのように、それぞれブランチA、B、Cの差分のみを管理している仕組みです。

過去の差分に対しての変更や削除も、このような差分のみを適用するパッチで実行されるので、これまでのデータ群を直接変更することがないようにしていました。

共通スプレッドシート上で企画側がデータを作成し、Jenkins上のジョブを実行していくのですが、その際に一通りマスタデータを作成するために必要な処理をしてくれるようです。

gitリポジトリを最新の状態に更新し、シートからダウンロードし、リリースされている分とマージして、ランタイム向けにデータを変換します。マスタデータをスクリプトで機械的に異なる値が入力されていないかをチェック。アセットバンドル後、gitのリポジトリにコミットして、PullRequestsを出力しています。

もし、この時点でエラーがあればJenkins上で内容を確認して、修正して解決。それから変更したマスタのデータがgitのPullRequestに出力されているので、それを他のプランナーでレビューしてマージ、最終的にgitのレポジトリまで反映するという仕組みを採用しています。

ここまで説明されたように、ネイティブアプリでマスタデータを運用した際のメリットとしては、スプレッドシートのデータを直接、差分ごとに統合しないため、ガワネイティブ時代の課題を一定解消することができたと人西は述べました。

gitのリポジトリに入っている、これまでのデータ群が正しければ、その後は自身のブランチのみ変更の影響範囲を受けるので、作業影響の切り分けが容易にできるようになったとのことです。

一方で、ビルド完了までは、マスタデータの変更をゲーム上で確認できないことは課題だったようで、ゲームデータ変換をJenkinsのジョブに任せていたため、ジョブの実行時間が肥大化していき、マスタデータを入力後にゲーム上で確認するまでのイテレーションが遅くなっていました。

これは、マスタデータを追加したことによる、アセットの用意やテストなどに時間が必要となってしまった部分です。

課題のまとめ

大きな課題感として「並行で開発する環境に対応しきれていない部分がある」と人西は述べました。

複数のイベントを並行で開発する際でも、イベント間で編集の影響範囲が切り分けられておらず、このために、前段のイベント開発でシートを編集中だと、後続のイベントも影響を受けてしまいます。

編集中のデータをゲームに反映すると、アプリクラッシュが発生したり、前段のイベントがエラーになる値を入力していると、作業中では後続も影響を受けてエラーが続発することがあったようです。

例えば、3月1週目にリリースするイベントに対して、あるプランナーがパラメータを入力していたとします。さらに並行して3月2週目にリリースするイベントを、別のプランナーが作業している状況を考えます。

その場合、1週目のプランナーがボスパラメータを編集中のため、実際にゲームに反映するとゲームが落ちる可能性のある「誤ったデータ」となります。

3月2週目にリリースするイベントの担当者が、別のパラメータを編集中の場合、実際にはゲームは動作せず、自分が編集した箇所以外でクラッシュすることも判明しています。実はボスパラメータを3月1週目のプランナーが編集していたため、ゲーム上で動作しない現象が発生していました。

もう一点、実機確認までに時間がかかる問題では、マスタデータをゲームデータに変換するところがJenkins頼みになっていることが原因でした。

Jenkinsは他の人が実行中に作業できないため、当然待ち時間が発生します。作業者が増えるほど、ビルドの待ち時間も増えるので、入力したマスタデータを実機で確認できるまで、かなりの時間が必要になることが課題となっています。

最後に「差分が見にくい」といった課題も明かされました。

DeNAではマスタデータを入力後、正しい値が入力されているのか、修正不可な内容を編集していないか確認するために、GitHub上でレビューを実施しているとのことですが、この差分の確認がしづらい課題もあり、ゲームデータに変換後のデータをGitHub上で確認しています。

そのため、ゲームが読み込む形式のjsonやCSVのフォーマットテキストで差分を確認しますが、その際には行単位で差分が表示されるため、非常に人間の目に優しくない(セルが細かくて目が疲れるなど)課題も発生しています。

共通基盤システム Oyakata

先述した課題を解決するために、DeNAでは共通でマスタデータを管理するための、共通基盤システムOyakataを開発・活用しています。このシステムは以下の4つの機能を備えていることが紹介されました。

・バージョン管理機能
・変更データをOyakata上でレビューできる機能
・CIを経由しなくてもゲームデータに変換できる機能
・入力されたデータの検証機能

Oyakataは、モバイルゲームの運用に特化したマスタデータの管理用ツールで、ゲーム内マスタデータを一元管理し、ゲームデータに変換やデータチェックする機能まで備えています。大きな特徴として、バージョン管理機能、ブランチ機能、コミット機能を備えて、細かいバージョン管理をすることが可能とのこと。

管理できるレベルに関しては、gitと同レベルのバージョン管理機能を備え、これまで述べた説明通り、DeNA社内でこれまで発生した課題を解決するための機能を備えています。

また、複数のリリースバージョンを同時並行で作業していても、他の案件から影響を受けない構造にしたい目的も実現しているようです。

特に、作業するプランナーが50名を超える規模に拡大した開発現場では、単純にチーム内のコミュニケーションやワークフローレベルの改善だけでは、影響範囲の切り分けが難しくなり、システムでのサポートが必要だという課題を感じたそうです。

また、同リリースバージョンの中でも複数人で作業を可能にしたい、という要望を叶えることも目的のひとつになっています。

さらに、プランナーのデータ入力、ゲーム側の確認のイテレーションはできるだけ迅速にしたい要望もあり、これまで使用してきたJenkinsやスプレッドシートの組み合わせだけでは実現できなかったため、内製のマスタデータ管理システムを開発することになった経緯が説明されました。

Oyakataでは、その独自のシステム上でマスタデータを作成します。Jenkins上でゲームデータに変換するのではなく、作業者のローカルPC上でゲームデータに変換するという仕組みになっています。

ゲームデータを用いて実際のゲーム、UnityEditor上や実機で確認することを繰り返し、正しいパラメータに調整していきます。

その後、Oyakata上でPullRequestを送ります。GitHub上でのPullRequestではなく、OyakataがPullRequestの機能を備えており、PullRequestを送れる仕組みです。Oyakata上でPullRequestがOKであれば、マージ、開発ブランチに内包します。

この時点では、Oyakataのシステム内部のみでマスタデータが反映されている状態なので、続いてgitに登録することが必要になります。この部分では、ゲームデータを定期的にOyakataに登録されているマスタデータをデータに変換して、gitに登録するという仕組みを採用しています。

プランナーはOyakataを使用すると、Excelもしくはアプリケーションで編集する場合もあれば、マスタデータによっては、スプレッドシートなどの他のツールで編集したほうが効率が良い場合もあります。

例として、マップデータでエディターを用意し、マップをビジュアルで参照しながらマスタを設定したい場合、マスタの種類や目的に合わせて、適切な編集ツールを使うことができます。その後、マスタデータを入力して、Oyakata上で保存します。

続いてゲームサーバーに配信しなければいけないため、OyakataのDownloaderと呼ばれるCLIツールを使うことでゲームサーバーにデプロイすることが可能です。そしてサーバーからマスタデータを実機に配信することで、リリースやQA時、デバック時などもゲームデータの反映を行っています。

Oyakataを利用するメリットは、マスタデータ入力のためのワークフローを簡単に構築することができ、さらに運用スタートしてからの並行開発にも対応しているため、複数の開発が並行で進んでも現場が混乱しないワークフローが構築可能なことです。

また、バージョン管理の仕組みでは、各個人を切り分けて作業可能で、Jenkinsに依存しないマスタデータの変換の仕組みも備えているため、マスタデータを入力してから実機確認するまでの時間を短縮するワークフローが構築できるのも強みと言えます。

さらに、Oyakata上でマスタデータの差分を表示・レビューする機能も備えており、差分表示はGitHubのように行レベルでの表示ではなく、行と列がある形式のデータに合わせた見やすい差分の表示になっているので、意図せず誤った変更についても、レビュー段階でチェックできる仕組みを構築可能と人西は述べました。

また、Oyakataには共同で編集できるメリットもあることが明かされました。

CSVファイルとgitでマスタデータを管理する方法では、CSVファイルをレビューする場合、編集差分がgit上では非常に目視しにくいが難点になります。

CSVファイルを直接編集するワークフローでは、関数機能などCSVに保存することはできません。スプレッドシートからダウンロードし、ゲームデータに変換するツールを用意する必要があります。

また、Googleスプレッドシート自体にはバージョン管理の仕組みがないため、バージョン管理の仕組みもディレクトリごとに分類する必要があるとのことです。

Oyakataには、エディター・コンバーター・バリデーターの3種のコンポーネントが実装されており、各特徴が紹介されました。

エディター

エディターは、マスタデータを一覧で表示できる機能で、WEBアプリケーションとして提供しており、特徴としてレコード数の多いテーブルを複数に分割して管理することができます。

この機能があることで、マスタデータの運用が長期化・肥大化した際に、マスタデータのレコードごとにテーブルを分割して管理できるため、編集時に重いExcelファイルを開いて作業する手間が必要なくなります。

また編集の履歴機能では、gitと同様のコミット単位でのバージョン管理を提供しており、編集差分を確認することも可能で、ブランチの差分も表示可能。イベントをリリースする際、開発側での変更部分を一覧で表示することも可能なようです。

同様にこのエディターでマスタデータを編集する機能も実装されているそうです。これはマスタデータのレコードをWEB上のアプリケーションとExcelアプリケーションとしてローカルPC上で作成、変更、削除できる機能で、編集データはOyakata上でゲームデータに変換することが可能とのこと。Oyakata上にもGitHubと同様のレビュー申請やレビュー機能を備えているので、変更内容を表形式に合わせた見やすい差分表示にすることもできると人西は紹介しました。

コンバーター

コンバーターは、Oyakataで管理しているマスタデータをゲームのデータに変換する機能で、こちらもCLIとして提供。

ゲームごとにマスタデータを読み込む形式に差異があるため、Oyakataはjson形式とCSV形式でゲームのフォーマットに合わせた出力に対応しています。このCLIツールはマルチプラットホーム対応で、プランナーもWindows・Mac上でダブルクリックするだけで実行可能とのこと。

さらに、マスタデータの実機確認をする際に、Jenkins上でゲームデータを変換せず、マスタデータを自分のローカルPC上にダウンロードしてゲームデータを変換、UnityEditorで確認するフローを作ることが可能。

バリデーター

バリデーターは、マスタデータが正しいかチェックする機能で、こちらもCLIツールとして提供。マスタ間のリレーションチェックや、ゲームタイトルごとに独自で禁止事項を精査し、DSLによって、テーブルごとに設定することができます。

これまでの仕組みと違う部分は、ブランチ管理をサポートすることにより、完全に他の作業者の影響を受けなくなっている点。マスタデータの作成時も、ブランチ管理の仕組みを完全にサポートすることで、プランナーにも提供することが可能になっているとのことです。

また、ゲームデータの変換をローカルPC上で実行することにより、課題であるJenkinsの待ち時間を短縮することができたとのこと。さらに、マスタデータの表形式に特化した差分表示が可能なため、見やすい表示を実現しています。

Oyakataは、実際に新規開発プロジェクトで導入して利用中とのことですが、主にエンジニアが機能開発に必要な仮のマスタデータを入力したり、プランナーが用意された機能開発においてデータを追加・調整するために活用していると、人西は述べました。

このようにOyakataのシステムにはメリットが感じながら、実際にプロジェクトで活用して判明した課題もあるとのこと。それは運用ではなく、新規開発に適したワークフローではなかったという部分だそうです。

新規開発時では、特にデータを大量に作成する量産フローがあるため、正しいマスタデータを入力できる仕組みと比較すると、大量のデータを効率的に入力できる仕組みが重要で、その部分に関して考慮できていなかったと省みたとのことです。

本セッションでは、これまでスプレッドシートで対応しにくかった、並行開発時の各個人の作業影響範囲の切り分けや、Jenkinsに依存した管理や順番待ちの時間、jsonやCSVの目視確認のしづらさなど、各種課題を解決するために、マスタデータ管理の共通基盤システム「Oyakata」が開発され、それを活用することで、新たな仕組みが社内に生まれ始めていることが、明らかになりました。

最後に、ゲームの新規開発時の課題対処について、今後もこの共通基盤システムを活用しながら、開発現場を通して「マスタデータはどのようにあるべきなのか?」といった定義を探っていきたいと考えている、と登壇した人西はセッションを締め括りました。

取材・文・撮影:細谷亮介

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!