ページトップへ

概要

ゲームスタップ社は、最近オンライン・ゲーム(以下、ゲーム)業界の中堅企業へと急浮上している新鋭のベンチャーです。 ゲームスタップ社は創業以来、斬新なヒット・ゲームを連発し、業界から注目を浴びてきました。 ゲームスタップ社は、ゲームの面白さだけではなく、ユーザー行動分析の先駆けとしても有名です。 多くの業界の関係者は、ゲームスタップ社の影の立役者は、ユーザー行動分析を行うログ分析基盤であると、口をそろえて言っています。

ゲームスタップ社のログ分析基盤は、業界関係者の間でゲーム以上に注目の的ですが、うわさ程度の話ししか流れておらず、実はその中身についてはほどんど知られていません。 今回は、ゲームスタップ社のログ分析基盤の誕生に関する物語をご紹介します。

誕生の裏話

ゲームスタップ社は、数年前、苦労の末、新しいタイプのオンライン・シューティング・ゲームをリリースすることに成功しました。 そのゲームは、ユーザーから大好評を得て、本格的な自社ブランドのゲーム開発を進める原動力になりました。 そして後続のシリーズも成功を収めました。 しかし、その裏側ではゲームスタップ社の経営陣は、人知れず苦悩に陥っていました。

ゲームスタップ社のヒットの秘訣は、ゲームをリリース後に継続して改善を重ねることであり、ディレクターの鈴木さんの鋭い判断による様々な対応があったからです。 しかし、それが一転して課題になっていました。 事業拡大のためには、鈴木さんのような能力を持った人材が数人は欲しいところでしたが、それは人事で簡単に解決できる問題ではなかったのです。 鈴木さん自身も、会社の業績アップには喜んでいましたが、そのまま仕事を続けるには、もはや限界を感じていました。

鈴木さんは、苦悩のなかで、ふと気付いたことがありました。 ゲームのリリース後の調整の中で鈴木さんは、ログ分析から何度も発見をし、改善のアイディアを得ていました。 つまり、自分がやっていたことの8割ぐらいは、ゲームのログからユーザー行動を把握して、対策を打つということの繰り返しでした。 そこで、鈴木さんは、自分の仕事をシステム化したらどうか、という構想を経営陣に打ち明けました。 しかし、具体的な説得力のある方法や定量的な効果試算ができなかったため、見送りとなりました。

行動分析の夜明け

ゲームスタップ社は、初の自社ブランドのゲームをリリースしてから、課金ユーザーを中心に、ECサイトの分析で知られている分析手法などを見よう見まねで取り入れました。 鈴木さんのリードのもと、有料のユーザーアイテム、ゲーム内通貨などに関するクラスター分析して、様々なユーザー動向や推移などを可視化し、自社独自のKPI(Key Performance Indicators)の設定に取り組んできました。 そしてTwitterやゲーム内のチャットなどにも気を配り、できる限りの手を尽くしていました。 ゲームスタップ社は、このようなPDCAサイクルを回していくのが、最初の目標でした。

すべてが手探り状態でしたが、何とか自分たちの業績に関するKPIを設け、様々な切り口で見ていくことに成功しました。 可視化されたデータを網羅したり、集約したり、並べ替えたりしながら、目視でデータを吟味し、議論を重ねながら意思決定を行う流れができ上がりました。 さらに、業績も順調に右肩上がりを記録し、ユーザー・コミュニティも大盛況でした。 これから更にPDCAサイクルを回し、「さらに洗練されたものにしていこうじゃないか!」といった、盛り上がりになっていました。

この当時、殆どお金をかけずゲームDBから抽出したデータを、自社のPCサーバーのMySQLで管理していました。 メインの分析テーブルは、ユーザーログと呼んでおり、ユーザーのログイン、どんなアイテムを買ったか、だれを招待したかなど、主に業績分析を行うための項目ばかりでした。 もちろん、対象も課金ユーザーのみに絞っていました。 そして分析にはSQLを利用して、ジャンル毎にExcelに落とし、集計レポートやグラフなどを作成していました。

ゲームスタップ社の経営陣は、課金ユーザーのデータ分析を通して、不都合な真実に気づき始めました。 それは売り上げが極少数の優良課金ユーザーに偏っていたことでした。 ここで数字を出すことはできませんが、なぜか低迷している課金ユーザー層が圧倒的に多いなかで、優良課金ユーザーが会社の業績のほとんどを占めている状態でした。 賛否両論がありましたが、「この状態は長期的には望ましくない」という結論に達しました。 そして低迷している課金ユーザー層から優良課金ユーザー層を育て上げようというテーマが急浮上しました。 この優良課金ユーザーとは、単純に言うと、無理のないある金額の範囲内の課金ユーザーのことでした。

さらに、ユーザーの9割以上を占る無料で遊ぶ非課金ユーザーの中から、お金を払って遊んでくれる課金ユーザーを増やせれば、大きな増益効果が得られる見込みがありました。

SQLデータベースの限界

ゲームスタップ社は、様々な方向を模索した末、2つの方策を模索することにしました。 一つ目は、低迷している課金ユーザー層から、経済的に独立している若年層を対象に優良課金ユーザーに育て上げることです。 対象ユーザーのデータを抽出するときに年齢の信憑性の問題が議論になりましたが、普通の日本人の感覚から見て生年月日を偽る確率は低いことから、そのまま信用することにしました。 そして、2つ目に、非課金ユーザーを課金ユーザーへ少しでも多く誘導できる方法を発見することです。 これは非課金ユーザーが、課金ユーザーとなる行動パターンを発見して、より課金ユーザーが増えるようにゲームをチューニングすることです。 ゲームを初心者のプレイヤーでも楽しめ、更に高いレベルを目指して意欲的にチャレンジすることができるようにすることです。

鈴木さんは、様々な仮説を立てて、ユーザーの行動の分析に当たりましたが、そのなかでも、徐々に次のような分析に焦点を当てて行きました。

  • 新規参加者数と離脱者数を比較する。
  • ユーザー毎のステージの進み具合とゲーム・オーバー回数を集計し、新規参加から離脱するまでの行動パターンを比較する。

当時、従来の課金ユーザーの業績分析に必要な項目に加え、さらに新しい情報を得るために項目の追加が必要だったこと、ゲームのデータベースに余計な負荷を掛けたくなかったこと、レコード数か大幅に増えることが見込まれたいたことなどでユーザー行動分析に関するログは、全件ファイルに記録することにしました。

しかし、効果が明確でないものに投資額を制限されたことから、自社にサーバーを設置することを諦め、クラウド環境に構築することになりました。 この方法であれば、サーバーとソフトの初期投資を必要とせず、一度投資したサーバーの能力に縛られることなく、簡単に能力アップが可能となり、不要となれば解約することができます。 これは従来の方法と比べ、ゲームをヒットに導く責任者である鈴木さんにとって、最適な選択でした。

鈴木さんのスタッフは、次の図のように、大量のログ・ファイルを蓄積するストレージの見直しに着手しました。 これまでのストレージは、前もって必要な容量を購入する必要がありました。 しかし、今回のログは、膨大な量が予測され、最初から最大量で見積もると、ストレージの料金だけで計画を断念する事態に陥る懸念がありました。 ところが、オブジェクト・ストレージは、データを保存した分だけの課金であり、容量無制限に利用できることから、今回の目的や予算的状況に合っていました。 (ご参考: コンフィグレーション・ガイド 5.1 オブジェクト・ストレージを利用するには?5.9 Linuxにマウントするには?)

そして、次に鈴木さんのスタッフが、見直したものが、分析用のMySQLサーバーです。 当初、オフィスの片隅にあるPCサーバーにLinuxとMySQLをインストールして利用していました。 しかし、データ量が増えた事から、もう少し処理能力の高いサーバーが必要となりました。 性能の高いサーバーのハードウェア費だけではなく、オフィスの環境に性能が高く消費電力の大きなサーバーを設置するには、電源や空調の点で適していないことが判明しました。 土日や深夜など、オフィスの空調が停止して温度が上昇することで故障の原因となる懸念や、パソコン用に設計されたオフィスの電源設備では、配電設備に増強が必要となり、相応の投資が必要となることも判ってきました。 このような見積もり一式を役員会に提示したところ、投資は却下となりました。 そこで、クラウドの環境上に、分析用のMySQLサーバーを構築することを決めました。 このサーバーは、SoftLayerの物理サーバー(ベアメタル・サーバー)を利用することで、能力的に不足が発生した場合、更に上のスペックのサーバーに乗り換えることができるため、過去の投資に縛られない環境となりました。 (ご参考: コンフィグレーション・ガイド 1.3 物理サーバーを起動するには?3.5 サーバーの RAM や CPU のスペックを変更するには?)

ユーザーログは、独自にログライターを開発し、テキスト形式で書きこみを行いました。 項目数は増えたものの、従来のログライターとさほど変わらなかったために非常に短時間で開発できました。 ところが、ユーザー行動分析のため膨大な量のログが出力されるようになり、これらを全てMySQLへ取り込むには、想定を遥かに上回る強力なサーバーの処理能力が必要であることが判ってきました。 この構築費用は、非常に高額なものであることが分かり、ゲームの業績に対して、釣り合いの取れない投資金額となることが判りました。 適正な投資金額の範囲に抑えるため、ありとあらゆる手を使うというありさまでした。 とりあえず、grepやawkなどのコマンドを利用して、無駄なレコードをフィルターしたり、sortコマンドを使ってデータをソートしたり、必要なレコードとカラムだけを抜き出しては、MySQLにアップロードしてSQLで集計をする。 そしてExcelに取り込んで可視化し、それを人間が見て判断するいうものでした。 このような苦労の中で、鈴木さんチームの職人芸により、このシステムは社内から、秘密兵器とも呼ばれるほど好評を得ていました。

このような苦労の末、後続ゲームの成功とともに、会社が事業拡大に乗り出そうとするなか、鈴木さんは、既存のログ分析基盤では、それを支え切れないと実感していました。

NonSQLによるブレークスルー

既存のログ分析手法では、MySQLで分析を行う前の段階で、手作業でデータを加工する工程が最大のボトルネックとなっていました。 その原因は、分かっていたが簡単に修正できるものではありませんでした。 データを取る箇所や項目は鈴木さんが指示していたもののデータの中身はアプリに依存していて、イベントによっては取得できないものがあったり、データの最終的な使い道に関する考慮が十分でないものもありました。

このような状況の中で、ログの容量がどんどん増えてゆき、手慣れた作業でも処理時間が伸びていきました。 そして、膨大なログを全てMySQLに読み込ませて様々な集計処理を行なうには、高いスペックのサーバーや大容量の高速ストレージ装置が必要でした。 しかも、バッチ処理には長時間を要することから、これまでの処理方式を踏襲するのでは、必要なレベルの分析ができないことに、鈴木さんは苛立ちを感じていました。

鈴木さんは、「ゼロから、抜本的に変えないと問題解決にはならない。 何か秘策はないのだろうか?」 と自問自答を繰り返す日々が続きました。 「妻と子供を除いてはすべてを変えよう」この言葉は、韓国のグローバル企業であるSAMSUNGの会長の言葉ですが、ゲームスタップ社の経営陣や鈴木さんは冗談交じりで、この言葉を何度も口にしていました。 このログ分析処理能力の向上は、会社の業績拡大の為に解決しなければならない課題でした。 鈴木さんは、既存のログ分析基盤の強みと弱みを徹底分析し、新しいログ分析基盤の構想を固めました。 そのおおよその構想は、次のようなものでした。

鈴木さんのスタッフによる、MySQLを利用するログ分析方法の弱点は以下のようなものでした。

  • 統計的な処理は、サンプリングして母集団を推定することが一般的であるが、ゲームの行動ログは、簡単な数値的なデータだけではないため、サンプリング手法の適用が難しい。
  • ゲームサーバーが出力するログの生成速度は、高性能なサーバーを使ったとしても、MySQLへのローディング速度では到底追い着かない。
  • ログの個々のレコードは、ユーザーのアクションといった、それ自体に有意的な価値は少なく、全件をMySQLに保存する価値はない。
  • このログの個々の有意性の低さに比較して、データ量に相応するCPU数のサーバーや高速ディスク装置は、たいへん高額であり、ログをまるごと取込むことは、コストや時間の点から現実的ではない。
  • 行動パターンごとに集計するといった処理は、MySQLでは苦手な処理であり、このような集計処理は、ローディング前に完了させておきたい。

一方、最終的なレポートやユーザー側での統計的な処理には、MySQLは表計算ソフトとの相性も良く、手軽に利用できるため、たいへん便利で強みであることは誰もが良く知るところでした。

このことから、上記の課題をMySQLに取込む前の処理として、MapReduceの処理によって解決することにました。 このMapReduceの処理とは、膨大なログ・データの中から必要なキー項目を抜き出して、KVSに格納するためのキーを作り出し、そのキーによって関連づけられる項目に対して集計するなどの処理を行なうものです。 この処理を導入することで、大量にある価値の低い情報から、少量の価値の高い情報へと変換することができます。 例えるならば、金の鉱脈から掘り出された金鉱石から金を取り出す作業に似ています。 金鉱石を精錬することで、金の濃度を高めていき、最後には純粋な金を得ることができるように、膨大なログの中から、MapReduceという手法によって情報を精錬して、価値のある情報へ変換していくものです。

このMapReduceを実施可能なオープンソースのソフトウェアは、多くの種類があり、Hadoopのパッケージとして、Apache Hadoop, Cloudera そして、MapReduceのジョブを実行可能なKVSとして、MongoDB, Riak, Apache CouchDBなどがあり、いずれも、無償でLinuxのサーバーで実行可能です。 最終的にどんなソフトを使い、どのようにキー項目を選択して集計するかと言った具体的な手法は、ゲームスタップ社のトップシークレットとされ、公開されませんでした。 しかし、次のような概要構成は開示されていました。

この新しい方式のログ分析基盤は、既存ゲームの分析に適用することで、次のようなことが分かってきました。

  • 低迷しているユーザー層は、新規参加者数と離脱者数がほぼ同じだった。 絶えず、多くの新規ユーザーが入り、課金ユーザーまでになってくれたが、ほぼ同じぐらいの離脱者が発生していた。 ある程度は楽しんでくれるが、ほとんどは長続きしない。 だから業績的には常に低迷しているように見えていた。
  • 新規参加から離脱するまでゲーム内のユーザーの行動にかなりの類似性が見つかった。 特にある難易度の高いステージで悪戦苦闘したユーザーが離脱する実態が明らかになった。
  • イベントによるアイテムの購入増加効果やプレイ時間を短時間で分析できるようになったことで、これまで鈴木さんの感性に頼っていたイベントのチューニングが容易になった。

鈴木さんは、まず、大量の離脱者を発生させているステージのレベルをチューニングすることにしました。 特に酷いステージから、段階的にチューニングしながら、繰り替えしPDCAサイクルを回して行きました。 なかなか確信に至らない箇所は、A/Bテストの手法も取り入れました。 その緻密な努力は、僅か数か月で成果を上げました。 非課金ユーザーから課金ユーザーに移行する割合が増加し、課金ユーザーの客単価の引き上げにも成功することで、優良ユーザーが増えていきました。

優良ユーザー層も、なぜか元気な対戦相手が増えたことにより、喜んでくれてユーザー・コミュニティもさらに活発になりました。 当初から懸念していたような、優良ユーザー層の機嫌を損なうようなことは起きなかったわけです。

ゲームスタップ社の経営陣は、このような結果を目の当りにし、この戦略を最重要なポジションにおくことにしました。 そして、鈴木さんは事業部長に昇進して、他のタイトルにも展開するべく日夜奮闘しています。

エピローグ

この物語は、フィクションであり人物名や会社名は架空のものですが、筆者らが、多くのゲーム関係者とゲームのログ分析について実際に様々な試みをやってきた経験、そして、途方もないデータ量を処理した経験に基づいています。 ゲームのログは、他の業種では類をみないほどのダイナミックさがあり、「一項目一項目が人間の行動と結びついているという面で、そこからなんらかの因果関係を持ったパターンが見つかる可能性がとても高い」というのが多数の業界関係者の見方です。 そして、「一つ一つのゲーム毎のログ項目の構成や意味は、それぞれ異なっていて、汎用的な分析手法を確立することは非常に困難だ」とも言われております。 しかし、現在、クラウドの伸縮自在な計算パワーや、様々なソフトウェアによって、実現できる基盤が確立されてきています。