『IDOLY PRIDE』の安定運用を支える多機能管理ツール

この記事は、2024年3月7日に開催された「CyberAgent Game Conference 2024（CAGC 2024）」のセッション内容をAIによる自動文字起こしをベースに加筆修正したものになります。

はじめに

本記事では、弊社開発のスマートフォンゲーム『IDOLY PRIDE』で利用している多機能管理ツールについてご紹介します。

この多機能管理ツールは弊社開発の専用WEBツールで、「プランナー」「エンジニア」「QA」「CS」といった幅広い職種のメンバーの作業をサポートしています。各職種のメンバー向けに様々な機能を実装した結果、その機能数はなんと…驚異の50以上。

「アイドルスキルシミュレーター機能」「SQL不要の行動ログ閲覧機能」「お知らせ作成機能」「マスタデータの検証機能」etc.

本記事では、「IDOLY PRIDEのガチャがユーザーに届くまで」の流れを通して管理ツールがカバーする機能の幅広さについてご紹介します。

概要

弊社が開発・運営を行っている『IDOLY PRIDE』では、「ガチャ」「アイドル」「衣装」「ヘアスタイル」「アイドルの誕生日コンテンツ」「各種イベント」など、大きなものから小さなものまで数えると毎月100前後の施策がリリースされています。

これらの施策はチーム内の様々なセクションの作業者が協力することで成り立っており、非常に多くの人的要因が介入しています。

人的要因が増えるほど不具合が発生する可能性が高まり、不具合を検知するためのデバッグ工数も肥大化していきます。

そのような状況の中で『IDOLY PRIDE』をより長く、より楽しくプレイしてもらえるようにするためには、「作業量を抑えながら不具合を少くする」ことが重要であると考えています。

この記事では、ゲーム開発・運営に伴う人的要因を排除するために導入している「自社開発の多機能管理ツール」についてご紹介します。

「『IDOLY PRIDE』でガチャが実際にリリースされるまでのフロー」に沿って、発生し得る不具合の原因とそれらを未然に防ぐための機能についてご紹介していきますので、ぜひ最後までご覧いただければと思います。

『IDOLY PRIDE』のガチャがリリースされるまで

『IDOLY PRIDE』では毎月5~10程度のガチャが登場しています。

各ガチャがリリースされるまでに「ガチャの開催期間」「排出アイドル」「カードのスキル設計」「3Dモデル」「イラスト」の用意など、幅広い職種の作業が必ず発生します。

上記は先ほどご紹介したガチャごとに必ず発生する作業を、より具体的にフローとして示したスライドです。

「データ作成」

施策を開発環境で用意するフェーズです。下記の作業が完了すると「デバッグ」フェーズに移っていきます。

「仕様策定」：ガチャの開催日時や施策内容を決める作業。
「データ作成」：決まった仕様を実現するためのデータを作成する作業。
「デザイン作成」：ゲーム内で表示されるような画像やイラスト、3Dモデルを制作する作業。

「デバッグ」

「データ作成」フェーズで作られた内容に不具合が無いかを確認するフェーズです。

項目例）

意図した挙動になっているか？
表示画像が合っているか？
ガチャの確率が合っているか？
正しい文章で表現されているか？など

「本番リリース」

これまでのフェーズで問題が無いことを確認できたデータが、実際にプレイできる環境へとリリースされていきます。

ここまでご紹介してきた各フェーズの作業は、チーム内の様々なセクションの作業者が協力することで成り立っており、非常に多くの人的要因が介入しています。人的要因が増えるほど不具合が発生する可能性が高まり、不具合を検知するためのデバッグ工数も肥大化していくリスクが存在します。

上記は先程ご紹介した各フェーズに存在する、不安材料の例です。

「データ作成」
- データ設計
- データ作成ミス
- 仕様が複雑になることによる作業コストの肥大化など
「デバッグ」
- 一つ前の「データ作成」フェーズで発生したミスによる、デバッグ工数の肥大化など
「本番リリース」
- 作業者の操作ミスなど

これらの不安要素はスマートフォンゲームの安定運用を実現する上では、必ず解消すべき項目であると考えています。

そんな不安材料を解消するために、我々『IDOLY PRIDE』チームでは、自社開発の多機能管理ツールを導入することで不具合が発生しにくい運用環境を作っています。

ここからは本記事の本題である多機能管理ツールについてご紹介していきます。

多機能管理ツールとは

多機能管理ツールは自社開発の専用Webツールを指しています。

「プランナー」「エンジニア」「QA」「CS」といった幅広い職種の作業をすべてサポートしています。

多くの作業が管理ツールによって完結するため、不要な人的要因を排除することができ、安定したゲームの運用を実現しています。

ここからは多機能管理ツールの導入による効果についてお話ししていきます。

上記はこれまでにご紹介してきたガチャがリリースされるまでのフローの中で、多機能管理ツールがサポートしている機能の一部を示しています。

「データ作成」
- スキル設計機能
- データ作成入力機能
「デバッグ」
- お知らせ生成機能
- 自動検証機能
「本番リリース」
- マスタタグ機能
- ログ閲覧機能

それぞれのフェーズに対し、作業をサポートしてくれる機能が存在しています。ここからは本記事の本題である多機能管理ツールの詳細について、より具体的な内容をご紹介していきます。

多機能管理ツールのシステムについて

ここからは多機能管理ツールのシステムについて説明していきます。

まず管理ツールのシステム構成について説明させていただきます。インフラにはGoogle Kubernetes Engine(以下、GKE)を使用しています。

フロントには言語にTypeScript、フレームワークにVue.jsとVuetifyを使用しています。

サーバーには言語にGo、フレームワークにEchoを使用しています。

アイドルスキルシミュレーター機能

続いて多機能管理ツールの具体的な機能について説明していきます。ここではどういう機能があって、どのようにシステムが動いているのか、ということについて説明していけたらと考えています。

まず一つ目が、アイドルスキルシミュレーター機能になります。こちらは先ほどお見せしたフローだと、序盤のデータ作成にあたる機能になっています。

具体的に、アイドルスキルシミュレーター機能がどういう機能なのかということについて説明していければと考えています。こちらは一言で言うと、ゲームバランスを左右するスキル設計を補助してくれる機能となっています。

デッキの編成やアクセサリーの組み合わせを実行して、勝敗などの結果をスプレッドシートに出力できるようにする機能となっています。

「安定してスコアが取れるか？」「他のカードが強くなりすぎていないか？」など、次のガチャで出すカードの効果を決める際に重要な役割を果たしています。

こちらのアイドルスキルシミュレーター機能なのですが、100万から500万通りでライブが実行されるので、高いマシンスペックが要求されます。そのため、IDOLY PRIDEではこちらのシミュレーターの実行を管理ツール上でやるのではなく、GKEのJobを呼び出して高スペックのノードプールに配置して実行しています。

アイドルスキルシミュレーター機能の画面構成がこちらになります。スキルの設計者が画面にJSON形式で入力し、実行ボタンを押すとシミュレーションが開始されます。そして、シミュレーションが終了すると実行結果をスプレッドシートにエクスポートすることが可能になります。

その他にも「現在シミュレーションが実行中かどうか」などのステータスも確認することが可能になっています。

アイドルスキルシミュレーター機能のシステム構成がこちらになります。先ほど説明した通り、高いマシンスペックが要求されるので、組み合わせをJSONで渡してJobで実行しています。

マスタデータのエクスポート・インポート機能

次に、マスタデータのエクスポート/インポート機能について説明していきます。こちらは先ほどお見せしたフローだと、序盤のデータ作成にあたる機能になっています。

こちらがどういう機能なのかというと、ガチャなどの静的なデータであるマスタデータをスプレッドシートで入出力できるようにする機能となっています。

2つの機能があり、DBの情報を読み取ってスプレッドシートに反映するエクスポート機能と、スプレッドシートからSQLに変換しマスタデータをDBに入れるインポート機能の2つがあります。

スプレッドシートをインターフェースにすることによって、誰でも簡単に正しいマスタデータを入力できるようになっています。こちらはGoogleワークスペースAPIを通して実現しています。

こちらがスプレッドシートの例になっています。インポート時にはこのセルを読み取ってSQLに変換して、DBに投入されます。エクスポート時には既存のデータをDBから取得して、スプレッドシートのセルに出力できるようになっています。

最後にこちらがマスタデータのエクスポート/インポート機能のシステム図になっています。 IDOLY PRIDEではGoogle Driveでマスタデータのスプレッドシートを保存して管理しています。エクスポート時にはGoogle Driveにスプレッドシートの保存を行って、インポート時にはGoogle Driveからスプレッドシートを取得するというような流れになっています。

お知らせ作成機能

次に、お知らせ作成機能について説明していきます。こちらは先ほどお見せしたフローだと真ん中のデバッグにあたる機能となっています。お知らせを作るにあたって意図しないミスを防ぐために様々な工夫をしているので、そこを重点的に話していけたらと考えています。

まず、お知らせ作成機能について簡単に説明させていただきます。

お知らせとはユーザーにガチャの内容を訴求するための情報としてゲーム内で表示するHTMLを指しています。 IDOLY PRIDEではこちらを管理ツールから作成することが可能になっています。

ここからはお知らせの作成にあたって、どのような機能があるのかということについて説明していきます。まずは、入力プレビュー機能です。

こちらはお知らせを実機に反映する前に管理ツール上でどのように表示されるかというのを確認できる機能となっています。プレビューを確認しながら編集することができるので、意図しないレイアウトだったり誤字脱字にすぐに気づけるようになっています。

次にカスタムタグ、及び属性について話していきます。HTMLの入力を簡略化するために、IDOLY PRIDEでは専用のカスタムタグと属性を導入しています。

具体的にどういうことなのかというと、例えばカードのイラストの参照の際に使われる、s-imageという属性があります。本来imgタグのsrc属性には、画像のURLをすべて記述する必要があると思うのですが、こちらのs-imageはアセット名を入力するだけで、内部で自動的にURLに変換されるようになっています。

続いてスキル詳細の参照の際に使われる、s-cardと呼ばれるカスタムタグについて説明していきます。

IDOLY PRIDEではアイドルピックアップスキル、セット衣装などを訴求情報として出しているのですが、こちらをs-cardタグを使うだけで、自動で右のようなHTMLが生成されるようになっています。

最後にお知らせ機能のシステム構成について紹介します。アイドルの画像のアセットはGoogle Driveで管理しているので、CronJobで定期的にrcloneを行い、Google Cloud Storageにアップロードしています。最終的に管理ツールから配信用のGoogle Cloud Storageにアップロードがされると、Cloud Load BalancerとCloud CDNを経由してユーザーはお知らせを閲覧することが可能になっています。

マスタデータの検証機能

次にマスタデータの検証機能について説明していきます。こちらは先ほどお見せしたフローだと、真ん中のデバッグにあたる機能になっています。

まずマスタデータの検証機能について、簡単に説明させていただきます。

一言で言うと、ゲームの仕様に沿わないマスタデータを検出して画面上に表示する機能となっています。例えば、入力必須なカラムにデータが入力されていない場合に、実際に実機に反映する前にそれを検知して、画面上に表示することが可能になっています。

これにより、即座にミスを検知できるので実機テストの工数を抑えることが可能になっています。また入力必須、最大値、最小値のような汎用的なものから、特定のレベルでは入力必須というようなオリジナルなルールもテーブルごとに設定可能となっています。こちらのルールに関してはエンジニアが1テーブルごとにロジックを書いています。

次にマスタデータ検証機能の画面構成について説明していきます。

画像の例だとCardテーブルのNameカラムにデータが入力されていないレコードが存在するので、「必須です」というようなメッセージが表示されています。また、全てのテーブルを一括で検証したり、個別でテーブルを選んで検証することも可能になっています。

最後に、マスタデータ検証機能のフローについて簡単に説明させていただきます。 IDOLY PRIDEでは、スプレッドシートでの投入後に検証を行うフローにしています。こちらの理由としては、投入時に検証を行って弾いてしまうと、例えばテーブルの外部キーの依存関係を考慮しながらインポートをする必要があるので、プランナーのインポート作業のスピードを落としてしまうというようなデメリットがあるからです。そのため、IDOLY PRIDEではインポート後に検証を行うフローにしています。

マスタタグ機能

次に、マスタタグ機能について説明していきます。こちらは先ほどお見せしたフローだと、最後の本番リリースにあたる機能になっています。

まず、マスタタグ機能について簡単に説明させていただきます。一言で言うと、マスタデータをバイナリファイルにまとめて、タグをつけてAPIサーバーに反映させることができる機能です。このバイナリファイルをマスタタグと弊社では呼んでいます。

前提、IDOLY PRIDEではマスタデータを直接DBを呼び出して取得するのではなく、APIサーバーの起動時に、指定されたタグのバイナリファイルをまとめてメモリに載せることで、APIサーバー上でのマスタを管理しています。管理ツールでマスタタグ作成から反映までできるので、エンジニアでなくても簡単にマスタデータをリリースできるようになっています。

また、メリットとしてはタグで管理することによって、ロールバックが容易になるというメリットがあります。

例えば20231001のタグに不備があった場合に、20230930に戻すということが可能になっています。

次にマスタタグの配信フローについて説明させていただきます。まず青色の枠線にAPIサーバーが立っていると考えてください、そしてこのAPIサーバーは20230930のマスタタグを参照しています。次に管理ツール上でマスタタグを作成します。

作成ボタンを押すと20231001というマスタタグが作成されて、Google Cloud Storageにアップロードされます。

次に管理ツールからマスタタグの反映ボタンを押します。すると緑色の枠線に表示したように、新しく20231001を参照したAPIサーバーが立ち上がります。

最後にAPIサーバーが規定の台数まで立ち上がると、反映準備完了のステータスになります。切り替えボタンを押すことで緑色のサーバーのみになり、無事に反映完了となります。 IDOLY PRIDEではいわゆるBlueGreenデプロイを採用しており、ユーザーによってマスタデータの差異がない反映フローを実現しています。

行動ログ閲覧機能

次にユーザーの行動ログ閲覧機能について説明していきます。こちらは先ほどお見せしたフローだと、最後の本番リリース後に使う機能となっています。

まずユーザーの行動ログ閲覧機能について、簡単に説明させていただきます。行動ログとは、ユーザーの操作によって更新されたデータをまとめたログとなっています。例えば、いつユーザーがアイテムを消費したかなどが挙げられます。

主にこちらは不具合の原因調査等で使用しています。システム構成としてはログはGoogle CloudのBigQueryに格納しています。

BigQueryを使ったことがある方なら分かると思うのですが、実際にSQLを叩かないと検索することはできません。しかし、IDOLY PRIDEでは管理ツール上でフォームを入力するだけで、裏側でBigQueryAPIを叩いて、実行結果を画面に表示できるようになっています。これにより、SQLを使わずに誰でも管理ツールからログを閲覧することが可能になっています。

次に行動ログ閲覧の具体的な機能について、2つ紹介させていただきます。

まず1つがシンプルクエリと呼ばれるものです。こちらはとても簡易的にログ名と時間、ユーザーIDで絞れるようにするクエリです。

2つ目にカスタムクエリと呼ばれるものがあります。こちらは先ほどのシンプルクエリに加えて、任意の要素で絞ることができます。例でいうと、is_giftがtrue、つまりギフト経由での受け取りだったかどうか、ということが検索条件に含めることができます。

続いて行動ログ閲覧機能の画面構成について、説明させていただきます。実際にSQLを書かずにフォームを入力するのみで検索できるようになっています。

また、先ほど紹介したカスタムクエリは事前にDBにテンプレートを用意して、そこから選ぶ形にして、あえて制限を設ける形にしています。こちらの理由としては、BigQueryの仕様上、検索条件を自由に設定できてしまうと、意図しないスキャンが走ってしまう危険性があるので、エンジニア側でSQLのテンプレートを事前に用意する形にしています。

最後に、行動ログ閲覧機能のシステム構成になります。先ほどお話した通り、内部でSQLを実行することで、BigQueryの実行結果を、管理ツール上に表示させています。カスタムクエリに関しては、テンプレート情報をDBから取得する形になっています。

まとめ

最後にまとめになります。

IDOLY PRIDEでは、自社開発の多機能管理ツールを導入しています。「プランナー」「エンジニア」「QA」「CS」などの幅広い職種の作業をサポートしています。

様々な機能を豊富に揃えることで人為的要素を排除し、作業量と不具合を抑えられるようにしています。ご視聴ありがとうございました。

『IDOLY PRIDE』の安定運用を支える多機能管理ツール

『IDOLY PRIDE』の安定運用を支える多機能管理ツール

はじめに

概要