最近、解析を行う案件が増えて SQL や R を書く機会が多くなってきました。僕自身サーバーサイドエンジニアという立場での仕事が多かったので、解析の仕事では未知の部分がまだまだ多いです。その仕事の中で感じた、技術以前に解決すべき課題について書いていこうと思います。
使用している技術
gumi ではログの保存に主に BigQuery を使っています。（参考：gumi での BigQuery 活用事例 (GCP NEXT 2016)）BigQuery を使うようになって多くの技術的課題が改善していますが、それについては別の記事に説明を譲ります。
以下の文章ではなんの前触れもなく BigQuery について触れている箇所がありますが、それは gumi で使用しているためです。
何がうまくいかないのか
ゲームを運営するにあたり、かなり早い段階から解析を運営に活かそうという動きがあり、ゲームのソースコードは丁寧にログを残す設計になっています。しかし、実際に統計を取って次の施策に活かす段階になるとうまくいかないことも少なくありません。どういったことがうまくいかないのかを書いていきます。
※ ちなみに、数年間いろいろなプロジェクトに参加して今は各プロジェクトを横断してい見ている立場からの見解なので、もうすでに課題を解決しているチームや、全くこのような課題に縁のないチームもあるであろうことは念のため補足しておきます。
工数が取れない
単純な問題として、解析を行う工数が取れないという課題があります。これにはいくつかの小さな問題を孕んでいます。
- 解析結果を必要とする人が自分で元データを取得できない
- 解析よりも施策の開発に追われる
解析結果を必要とする人は大体プロデューサーやディレクターですが、システムへのアクセス権限がなかったり SQL がわからなかったりという理由でプログラマーに元データの取得を依頼することが多いです。SQL を書けるのが大体プログラマーなので、そのプログラマーが次の施策の開発に追われていると、解析に割く時間がなく、後回しになってしまうという問題があります。
解析結果を必要とする人が自分で元データを取得できないということに関して踏み入った内容は後述します。
魔法と勘違いしてしまう
ゲームの運営チームに、解析に明るい人がいなかったり工数が取れなかったりという場合は解析会社に解析を依頼することがありますが、お金を出して依頼をすれば素晴らしいデータが自動的に出てくるわけではありません。解析を行う人は魔法使いではないので、実際にゲーム運営を行っている人の感覚がなければ取るべきデータやその意味、有用性がわかりません。
解析結果を利用するというプロセスを無視してしまう
作っているものがゲームということで、「面白さ」に明確な答えが無い以上は経験や感覚に基いてコンテンツを作ることも多いです。しかし、ソーシャルゲームの場合、長く運営していく中で全く新しい施策ばかり作ることは運営側のリソースや諸々の都合でできないません。新しいキャラクターを出す・イベントを開催するなど、繰り返し行う施策に関しては解析結果をもとに施策とタイミングを決定します。
ソーシャルゲームは売り切りのゲームと違い、ログを見ることでユーザーの動向がわかってくるのでそれを使わない手はないのですが、経験や感覚でうまくいくという考えから、そのプロセスが無視されてしまうことがあります。
そこで生じる問題の一つは、経験や感覚だけでは視野が狭くなってしまうということです。例えば運営側がヘビーユーザーと同じ思考になってしまうので、ヘビーユーザー向けの施策が多くなるということは往々にしてあります。
また、先入観が正しい判断を邪魔するという問題もあります。「こういう施策を出せばこうなるだろう」ということを予想しますが、実際には全く逆の効果だったという可能性もあります。それを「センスがない」と片付けるのではなくきちんと過去のデータを見ることが重要だと考えます。
必ずきれいな解析結果が出ることを期待してしまう
データの取得を依頼されるとき、大体はきれいな解析結果が出ることを求められます。きれいな解析結果が出ることを前提にスケジュールだけが先行することもあります。しかし、これは本当にもどかしいのですが、必ずしもきれいな解析結果が出るとは限りません。あることを証明したくて実際にデータを取得してみると、全く逆のことが証明されてしまったという例もあります。何か相関関係のある情報が取得できても、どちらが要因でそうなっているのかがかわからないこともあります。
このことで解析の意味がないというイメージを持ってしまうかもしれませんし、データを出すまでに試行錯誤して時間がかかるので、前項目の「解析結果を利用するというプロセスを無視してしまう」ことにつながる可能性があります。
重要ではない情報を重要視してしまう
自分がこの業界に入った頃からずっと目にしていた指標が DAU (Daily Active Users) で、１日にサービスにアクセスしたユーザー数です。これはいろいろなソーシャルゲームで、それぞれを比較する基準に使われたり施策がうまくいっているかの判断材料として使われたりということで重視する人も多いです。もちろん重要な指標の一つではあるのですが、この「DAU教」がときには失敗の種となることもあります。
例えば、ユニット（カードやフィギュアと呼ばれるもの）の経験値をたくさん得ることができるイベントを行うと DAU が増えるというデータがあったとします。 DAU教では DAU を増やすことが重要だと考えられているので、このイベントを頻繁に行うようになります。するとユーザーの所有しているユニットレベルが飽和してきて、次にやりたいことがなくなってきてしまいます。やりたいことがなくなるとユーザーがゲームにアクセスするモチベーションがなくなるため、DAU が減少します。 DAU が減ってユニットレベルが飽和していることがわかると、ガチャで新しいユニットを排出して、さらに経験値獲得イベントを行うという悪循環になり、どんどんゲームの寿命が短くなっていきます。こういったイベントを行うことは即効性があるのですが、ゲーム運営時にはこのような麻薬だけに頼らず、もっと総合的に判断する必要があります。
話は少し逸れますが、逆にあえて重要ではない情報を重要なように見せることで人を説得することもできます。有名な例ですが、「吸引力が変わらない」ことをアピールしているダイソンは、あるネット上の情報では「吸引力は変わらないが決して強いわけではない」と言われています。「吸引力が変わらない」などで調べると情報が出てくると思います。これは、決して嘘ではないものの重要ではない情報を重要であるかのように見せている良い例です。
非技術者が解析を扱うときの幾つかの壁
前述の、「工数が取れない」という項目の中で、「解析結果を必要とする人が自分で元データを取得できない」と書きました。いくつかの課題は実際に解析結果を必要とする人が直接解析を行うことで解決できるものもあり、実際にそれをやっている人もいます。しかしそれは一般的な例ではなく、通常は乗り越えなければならない壁があるのではないかと思います。
権限の壁
= 権限がない
ほぼ技術者だけが扱うシステムではそもそも権限が技術者しかありません。
技術の壁
= やり方がわからない
SQL の書き方・ R の使い方など、非技術者からは難解に見えているかもしれません。しかし、SQL の書き方などは数日間勉強すればある程度身につきます。とくに BigQuery の場合は一般的な RDB では効率の悪いクエリでも BigQuery が力技で結果を返してくれるのでハードルは低いはずです。
恐怖の壁
= 課金が怖い
「BigQuery はクエリの実行で課金される」という知識だけを持っていたり、BigQuery で検索すると「BigQueryで150万円溶かした人の顔」という記事が上位に表示されたりということで、料金に対する恐怖を持つ人もいるようです。実際には普通に解析で使う場合 BigQuery の料金は安いのでそこまで恐怖を抱く必要はありません。
未知の壁
= 何かやらかしそうで怖い
SQL を入力するフォームや「黒い画面」は色々できてしまうからこそ、何かやらかしそうで怖いという壁もあると思います。BIツールの導入やシステム化するとその壁も低くなると思います。
解析担当技術者のミッション
これまで何度か解析チームを作ろうとしたり、解析専門の会社に依頼したりということはしてきましたが、まだまだ「解析結果をうまく利用できている」と強くは言えません。やはりゲームを熟知している開発者自身が過去のデータの解析に理解を示すことが重要です。
そのためには教育だったりシステム化だったりとお膳立てする仕組みも必要でしょう。解析担当者技術者は実際の解析業務だけでなく、そういった仕組みを作り、壁を取り除いてあげることがミッションなのではないかと思います。