菅澤氏の自己紹介
菅澤要平氏：グリーエンターテインメント株式会社の菅澤要平です。よろしくお願いします。では、本日は書いてあるとおり、「AWSのEKS環境でログ機能を構築／リリースしたお話」について発表しようと思います。
最初に、簡単に自己紹介します。グリーエンターテインメント株式会社、開発本部エンジニア部に所属している菅澤要平と申します。仕事の内容としては、弊社で運営しているタイトルのエンジニアリング全般のマネジメントや、所属しているエンジニアのスキルアップなどの横断的な活動を行っています。
経歴についてですが、2009年に新卒で非ゲームの主にBtoB系のWebシステムを開発している会社に入社しました。そこでは、お客さんと実際に「どのようなシステムを作るか」という要件定義から、開発、テスト、リリースとひととおりの開発業務を行ってきました。
その後、2017年にグリーエンターテインメントの前身でもある、ファンプレックス株式会社にサーバーエンジニアとしてジョインしました。ファンプレックスでは、まず大型ブラウザゲームの移管の運営を行い、その後、複数のタイトルの移管と運営を経て今に至っています。
グリーエンターテインメント株式会社の事業について
せっかくなので、まずはグリーエンターテインメントの紹介をしようと思います。弊社は2021年7月に設立された、グリーグループ内では最後発のゲーム会社です。弊社は大きく分けて、IPプロデュース事業とゲーム事業の2つの柱で成り立っています。
まずIPプロデュース事業に関してですが、こちらは国内の優れたアニメ作品に出資し、そのゲームの展開をはじめとした、国内外での事業開発と作品のグローバル展開のプロデュースなどを行っています。
続いて、私が主に所属しているゲーム事業についてですが、こちらはIPのタイトルを主軸に自分たちでゲームの開発やその運営を行い、IPゲームタイトルの再成長や長期運営を実現しています。
この2つの事業は、実はもともと別々の会社で行われてきました。ですが、IP獲得、グローバル展開という面と、IPゲームタイトルの再成長、長期運営というそれぞれの強みを組み合わせることで、IPグロースカンパニーとして、「日本発のIPとゲームで、世界を熱狂させる。」ことをミッションに設立されたのがグリーエンターテインメントです。
発表の目次
続いて、今回の発表の目次です。最初に今回の発表内容の概要を話そうと思っています。その後にシステムの概要、ログの重要性、ログ周りの構成、リリース後に発生した事象と対応と、まとめ、それぞれ発表しようと思います。
ログはプロダクトに関わる全員にとって重要なものである
では、はじめにというところですが、今回はグリーエンターテインメントで開発したゲームタイトルで、ログの機能を構築した際の話をできればと思います。
ログを大きく分けると、クライアントのアプリから送られてくるログと、サーバーサイドで出るログがあると思いますが、今回はサーバーサイドのログについての話です。
どのようなログをどのように収集して、そのログを開発と運用の時にどのように使っているかを主に話そうと思っています。
まず、一般論的な話ではあると思うのですが、ログの重要性を話そうと思います。
大前提として、ログというとエンジニアにしか関係がないものと思われがちだと思うのですが、実際にはエンジニアだけではなくて、プロダクトに関わる全員にとって、とても重要なものだと思っています。
とても重要なものではありますが、アプリのリリースの前はやはりどうしても目の前の不具合解消や品質向上に全力を注ぎがちになってしまうのが現状だと思います。
ただ、そこで一度立ち止まってアプリを運営する時のことを考えてもらうとイメージしやすいと思うのですが、特にゲームのアプリでは、1週間など、けっこう短めなスパンでイベントなどの施策がローテーションしていくと思います。
その中で売上を出していくためには、PDCAを高速で回していく必要があります。それができずに売上が立たないと、ちょっと残念ではあるのですが、アプリがクローズとなってしまいます。なので、高速でPDCAを回すということ自体がアプリの寿命に直結していると言っても過言ではないかなと思っています。
その中で、PDCAを高速に回すためには、ログの収集や分析は不可欠なものなので、結果、プロダクトに関わる全員にとってログはとても重要なものであると思っています。
取得するログの定義をプロダクトの中で認識合わせする
そこで、まず何から始めるかというところですが、まずは、取得するログの定義をプロダクトの中で認識合わせをしておくのが、第一歩かなと思っています。
（スライドを示して）書いてあるとおりですが、DAU（Daily Active Users）とかの基本KPIや、イベントなどをリリースした時に振り返るべきログの定義は、最低限しておくといいと思っています。
例えばイベントの参加率や、イベントの目玉報酬をどれだけのユーザーが獲得できたかという獲得率、あとランキングなどのイベントがあれば、ランキング帯ごとの課金額みたいなものは最低限取れると良いのかなと思っています。
一応、事前に定義するのは重要なのですが、もちろんリリース後に追加で取得したいログが出てくるのは当然だと思うので、リリースした後でも、ログの追加や収集を柔軟にできるようにしておくのも大事です。
ここまで実際に定義や実装ができたら、「意図どおりのログがきちんとプログラム上取得できているんだっけ？」みたいな検証も行っておければベストかと思っています。
ログを取得できても一部の人だけが見ているのでは意味がない
ログは「取得できた」で終わりではなくて、実際にログが取得できたとしても、そのログを一部の人が見ているだけではあまり意味がありません。ログは、プロダクトのメンバー全員に共有されて、「アプリとして今どういうところに注力すべきなのか」というプロダクト方針が、全員同じ認識になっていることがとても重要です。
そのため、ログに関しては、プロダクトに携わるメンバーがいつでもアクセスできるようにしておくのが望ましいと思っています。
「Redash」などのツールがあると思うので、そういうものを利用して、ブラウザで気軽にアクセスできる環境を整えたり、さらに、環境を一応整えるだけでは駄目で、ちゃんとそういうところを地道にミーティングなどで共有していくことがとても大事だと思っています。
「こういうことをやればプロダクトを全員に情報を共有できる」という銀の弾丸みたいなものはないので、地道に共有を続けていくのが一番大事かなと思っています。それをすることによって、データの小さい変化でも気づけるように、メンバーの関心度を上げていくのがとても大事だと思います。
グリーエンターテインメント株式会社の事例では、基本KPIに関しては、プロダクトに携わっているメンバーが毎日持ち回りで確認して、Slack上で、「昨日のDAUはこうで、おそらくこういう施策がリリースされたからこうだと思います」みたいな、そういう考察みたいなのを入れるようなこともしています。
考察をする時、純粋にログを見るだけでは考察はできないので、「実際、プロダクトでどんな施策がやっていたんだっけな？」みたいなことも、自分自身が担当していない施策のことも知るいいきっかけになるので、そういうやり方もとても良いのかなと思っています。
（スライドを示して）また、実際に、グリーエンターテインメントの中で施策リリースをする際には、このように、まずはプランナーからエンジニアに、「こういうのがあるんです」と新しく追加したいログの連絡が来ます。
その際に、エンジニアは「そのログっていったい何のために使うの？」みたいなことをプランナーと話して、「そういうログを取るんだったら、もうちょっとこういう別のログを取ったほうが集計とか分析しやすいですよね」みたいな話し合いをして、どういうログを取るかを決めていきます。その後、実装していきます。
施策がリリースされたら、プランナーがRedashなどのツールを用いて、取得したログに対して集計や可視化を行って、プロダクトの中で結果を共有していきます。
そして、また次回のリリースに向けて、分析結果や「今回はこういうログが足りなかった。こういうのを追加していこう」みたいな検討をしていくようなサイクルが、グリーエンターテインメントの中ではよく見られます。
（スライドを示して）これは、すごく簡単なRedashの例です。集計結果をブラウザ上でグラフで共有したり、あとは実際のデータをGoogleのスプレッドシートで連携したりして、メンバー全員が共有できるようにしています。
（次回に続く）
