分析基盤チームの高田です。
私のチームでは、各種ゲームのデータを集積するデータ分析システムの開発・運用を行なっています。
この記事では、モバイルオンラインゲームのクリティカルなポイントのひとつである仮想通貨の管理について、開発・運用という立場から気をつけていることを紹介したいと思います。
仮想通貨の扱いは、最終的には、法律・会計上の要請から決まってくるものだったりします。このため、開発者が単独で決められることは決して多くないです。しかし、ゲームの運用チームと会計部門の間に入ってルール作りを進めていくのは、経験上開発チーム主導で行なう方がうまくいくように思います。
重要なのは、「さまざまなユースケースを先に想定し、ルールを決めさせる」「システムの都合と、各部門の要件を整理する」というあたりです。要するに、「こういうケースがありえるんですが、この場合会計部門としてはどういうデータが必要ですか?」「運用チームはこのデータが見れれば問題ないでしょうか?」というのをどんどん聞いていくことが一番重要な仕事になります。
注意事項:
ここで仮想通貨と呼ぶのは、(1)ユーザーが対価を支払って購入し、(2)アイテムとの交換、行動力回復、ガチャなどに使用できるもののことです。
「仮想通貨」と呼ぶとあまりなじみがないかもしれませんが、モバイルオンラインゲームでは、特別なアイテム(「石」「ジェム」など)を販売し、ユーザーはそれらを使用することで体力回復やガチャなどの機能を使用するという仕組みをとるものが多いです。これらのアイテムも仮想通貨と呼ばれます。なお、この記事では、iOS、Googleのネイティブアプリの事例を想定しています。
日本では、利用者保護の観点から、仮想通貨の扱いは資金決済法という法律で厳しく制限されています。また、モバイルオンラインゲームの売上は仮想通貨の発行時ではなく、消費時に計上することが多いため、仮想通貨の発行・消費ログは会計上も重要な数値となります。
KLabの場合、各ゲームのログを、共通のデータ分析システムに集約し、そこから会計部門、運用チーム、分析者などに各種データを提供するという形をとっています(図参照)。仮想通貨に関するデータも、このデータ分析システムに集約されます。私のチームが担当しているのは、このデータ分析システムの開発・運用の部分です。
仮想通貨の管理は、以下のような理由で運用難易度の高いシステムになりがちです。
詳細はあとで紹介しますが、細かい要件がたくさんあり、「こんなに考えることがたくさんあると思わなかった」というくらい複雑になっていきます。
また、多くの関係者が存在するため、うまく調整ができなければ悲惨な事故にもつながりかねません。発生しうる事故の具体例をあげてみましょう。取りまとめるチームからすると、悪夢のような状況です。
こうした事故を防ぐためには、各方面からの要望を整理し、ルールを決めて運用していくことが重要です。
仮想通貨の仕様は各ゲームごとにかなり異なります。新規ゲームのリリース時などによく問題になるポイントを以下にあげてみます。リリース前にこの種のチェックポイントを確認していき、とにかく考慮漏れや想定外の事態を発生させないことが重要です。開発段階で関係者を集めてレビューすることが望ましいでしょう。
多くのゲームでは、仮想通貨相当のアイテム(「石」「ジェム」)を無償でも付与します。こうした事例では、有償で発行した仮想通貨と無償で発行したものを区別し、仮想通貨として管理するのは有償発行のものに限定するといったポリシーを採用する場合も多いでしょう。会計上売上として計上されるのは、有償発行のものに限定されますし、本来仮想通貨として管理すべきものは、ユーザーが対価を支払って購入したものに限定されるからです。
無償発行のものと有償発行の仮想通貨の両方がある場合、消費される順序をルールとして定めなければなりません。代表的なものは、以下の3パターンでしょう。ゲーム内でどのパターンを利用するのかは関係者間でよく確認しておきましょう。
海外向けに提供している場合など、価格は日本円で統一されているとはかぎりません。また、iOSの場合、価格の設定にはApple Tierという独自の単位が使用されます。いずれにしても、どのような単位を使用して集計するのか、各チームで合意しておかなければなりません。
仮想通貨は一種類とはかぎりません。ガチャチケットなどを販売する場合、そちらも仮想通貨として扱わなければならない可能性もあります。
iOS端末からAndroid端末に変更した際など、異なるプラットフォーム間でユーザーデータを引き継ぐことがあります。引き継ぎに関しては、ゲームのシステム上のルールとして、仮想通貨も引き継ぐことを認める場合と、引き継ぎを認めない場合があります。仮想通貨の引き継ぎを許容する場合、消費された仮想通貨がどのプラットフォームで発行されたものかを取得する必要が生じるかもしれません。
時間の定義も問題になることがあります。海外向けに提供しているゲームの場合、タイムゾーンに気をつけなければならないのはもちろんですし、国内限定でも、取引日時を「ユーザーが端末上で操作した日時」とするのか「サーバー上でDBにレコードが作成された日時」とするのかが問題になることがあります。端末上の時間に合わせていると、過去の取引データが遅れて送信されてくることがあるからです。
例えば以下のようなケースを考えてみてください。
ここで再送されたデータを10/01のログとして集計しようとすると、集計から漏れてしまいます。
障害時などに、通常の購入処理とは異なる形でユーザーに仮想通貨を付与することがあります。また運用中、購入処理などのデバッグが必要になる場面も想定されます。こうしたユースケースでは、デバッグのためにテスト用の仮想通貨を発行することがありえます。
こうしたイレギュラーなデータがログから漏れないよう、あらかじめ付与方法などについてもルールを決めておくことが必要です。
以下、KLabで仮想通貨管理のために集計しているログを参考のためにあげてみます。データの詳細はゲームごとの仕様によっても異なりますが、原則的には全ゲームで統一のフォーマットを使用して集計しています。
仮想通貨の発行ログです。発行した個数や販売した仮想通貨商品(仮想通貨セット)のIDなどを集計します。モバイルゲームでは、App Store、Google Playストアなどのプラットフォームを通じて、仮想通貨をセット販売するので、セット単位で集計することになります。
項目 | 詳細 |
---|---|
集計するタイミング | デイリー |
集計内容 | ユーザーID、発行額、価格、通貨(JPY/USDなど)、日時、仮想通貨商品ID、プラットフォーム、仮想通貨の種類 |
消費用途別の仮想通貨消費ログです。発行した仮想通貨が、いつ、何の目的で、いくつ消費されたのかを集計します。
項目 | 詳細 |
---|---|
集計するタイミング | デイリー |
集計内容 | ユーザーID、消費額、日時、仮想通貨の種類、消費用途 |
用途別の消費ログと似ていますが、発行時の仮想通貨商品ID(仮想通貨セット)別に消費を追ったものです。なぜこれが必要かというと、仮想通貨1個あたりの金額がセットごとに異なる場合があるからです。多くの場合、まとめ買いの方が得になるように商品価格が設定されています。また、途中で値段の変更を行なった場合などにも、この種のログが必要になります。
項目 | 詳細 |
---|---|
集計するタイミング | デイリー |
集計内容 | ユーザーID、消費額、日時、仮想通貨の種類、仮想通貨商品ID、発行時プラットフォーム |
ここまでのログが正確に集計できていれば、そこから未使用の残高を計算することもできるはずです。基本的には、残高は、発行額合計 - 消費額合計になるはずです。
KLabでは、チェックのために、月に1回の頻度で、未使用仮想通貨の残高と上記のログから計算した残高を付き合わせています。
項目 | 詳細 |
---|---|
集計するタイミング | マンスリー |
集計内容 | 仮想通貨個数、日時、仮想通貨の種類、発行時プラットフォーム |
以上、モバイルオンラインゲームの仮想通貨管理に関して、KLabで気をつけていることを紹介してきました。仮想通貨の扱いは、健全なゲームの運営やユーザーの利益保護という観点からきわめて重要なポイントになってきます。参考になれば幸いです。
KG SDKでは、KLabのノウハウを活かし、仮想通貨管理ライブラリやKPIレポートへの対応も行なっています。KG SDKの概要についてはこちら を、お問い合わせにつきましてはこちら をご覧下さい。
KLabのゲーム開発・運用で培われた技術や挑戦とそのノウハウを発信します。
合わせて読みたい
KLabのゲーム開発・運用で培われた技術や挑戦とそのノウハウを発信します。