Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

社内だからこそ「現場の課題」に寄り添える――gumiのゲーム開発を支えるデータ分析チーム、その組織と技術とは?【デブサミ2018夏】

【B-6】ソーシャルゲームを分析せよ!~社内分析チームの立ち上げから学んだデータ分析のための組織と技術

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2019/01/24 11:00

 企業が本格的にデータ分析に取り組み始める際、データ分析を専門とする会社にアウトソースするか、あるいは内製化するかといった選択肢がある。ソーシャルゲームで多くの人気タイトルを手がけるgumiでは、内製化の道を選択。2017年に社内データ分析チームを立ち上げ、「データ分析」という新しい業務を「ソーシャルゲーム開発」という既存の業務に取り込んでいくために、試行錯誤を重ねてきた。社内データ分析チームが生み出す価値、期待される役割とは何か? データ分析のための組織作りで重視したポイントとは? また、データ分析基盤としてどのような技術を採用しているのか? データ分析チームの立ち上げを指揮した同社Technical Strategy & Development, Technical Directorの今村哲也氏が解説した。

株式会社gumi Technical Strategy & Development, Technical Director 今村哲也氏
株式会社gumi Technical Strategy & Development, Technical Director 今村哲也氏

市場のレッドオーシャン化とコンテンツのリッチ化がもたらす課題

 gumiがデータ分析に取り組むことになった背景として、昨今のソーシャルゲームを取り巻く環境の変化がある。その1つが「市場のレッドオーシャン化」だ。

 市場に多くのゲームがあふれるとユーザーが分散し、新規ユーザーが増えづらい状況になる。新規ユーザー数の伸びが離脱ユーザー数を下回ればアクティブユーザー数が減り、売上が低下してしまう。こうした厳しい環境の中で新規ユーザー獲得や離脱防止のために、より魅力的な企画や機能の提供、さまざまな改善を行っていかなければならない。結果として、ディレクターやプランナーの仕事がどんどん増えていくことになる。

新規ユーザー数が増えないとアクティブユーザー数が減少し、売上が低下する
新規ユーザー数が増えないとアクティブユーザー数が減少し、売上が低下する

 さらに、そこに拍車をかけるのが「コンテンツのリッチ化」だ。コンテンツの開発に時間がかかるようになったことで、ディレクターやプランナーが1つのプロジェクトに長期間拘束され、従来よりも各プロジェクトにアサインできるリソースが限られるようになってきた。

 「こうした人的リソースの希薄化を補うための取り組みとして、データ分析に基づいた改善が必要と考えた」と今村氏は社内分析チーム発足の経緯を話す。

社内データ分析チームが生み出す3つの価値とは

 では、なぜ外部のデータ分析会社に依頼するのではなく社内で取り組むことにしたのか。

 分析技術だけを考えればデータ分析会社の方が知見を持っていると考えられるが、プロジェクトによって「現場の事情」は異なり、それらを踏まえたソリューションの提供が望まれる。しかし、外部のデータ分析会社が現場の事情を把握するのは難しい。また、データ分析は繰り返し継続的に取り組むことで価値が高まる。その点においても内製化が有効といえる。こうした議論を重ねたうえで、今村氏らは「社内にデータ分析チームを立ち上げた方がより効率的である」との結論に至ったのだという。今村氏は、この社内分析チームと社外のデータ分析会社の違いを、「かかりつけ医」と「大学病院」に例えて下図のように表した。

社内分析チームは「現場の事情」や「利用頻度」において優位性がある
社内分析チームは「現場の事情」や「利用頻度」において優位性がある

 続けて、社内データ分析チームが生み出す価値として、今村氏は次の3つを挙げた。

  • 現場に寄り添ったソリューション
  • 標準化
  • 現地化

 1つめの価値について、今村氏は「どんなにすばらしい成果が期待できるソリューションであっても、現場でそれを扱えなければ意味がない。現場の意思を汲んだうえで、確実に実行できるものを提供することが重要」と説明。

 2つめの「標準化」は、分析の結果得られた知見を別のプロジェクトに横展開するなど、データを相互比較すること。そして3つめの「現地化」とは、確立した分析を現場に落とし込むことだ。分析チームが試行錯誤して生み出したノウハウを各プロジェクトチームが直接活用できるように展開することで、より効率的なデータ分析が可能となる。この現地化が「最終的に分析チームが目指すゴール」だという。

 データ分析業務の主なタスクとしては、ヒアリング、現状の診断と課題の抽出、施策の提案・実行、施策の評価とレポート提出などがある。今村氏はこれらを病院での治療に例えて説明した。

 「例えば、現状の診断と課題の抽出は『健康診断』や『人間ドック』、施策の評価とレポート提出は『治療後の経過観察』のようなもの。医師と患者が二人三脚で治療を進めていくのに似ている。継続的に取り組む必要があるところも同様」

 こうした取り組みをスタートして間もなく、gumiのデータ分析チームが直面したのが個別化と標準化の課題だ。あるプロジェクトに対して有効なソリューションを提供しようとすると個別最適化されていくが、そうなると会社全体での知見の横展開、標準化が進まない。そこで、データ分析チームではKPIを3種類にレベル分けして計測・管理する仕組みを取り入れている。

 「ほぼすべてのゲームに共通する指標をL1、ある程度共通するが意味合いや計測方法がゲームごとに異なる指標をL2、各ゲームで完全に異なる指標をL3とした。L1とL2はどのゲームでも見られるようにして知見を横展開し、個別に見るべきポイントもL3でしっかり見ていく。こうして標準化と個別化の両方に対応できるようにしている」

 なお、データ分析業務は継続して取り組むのが基本であるがゆえに、何も対策しなければ「いずれ業務があふれかえる」ことに注意が必要だと今村氏は指摘する。そうならないためには、確立した分析を現場に落とし込む現地化のほかに「やらないことを決める」ことも重要だという。

 「売れているゲームは、データ分析で改善点を探すよりもイベントなどの施策をどんどん打つ方が効率的に売上が伸びる。その段階では、まだデータ分析を必要としていないということ。また、分析チームが単なる『データの取り出し屋さん』にならないように注意していただきたい。現場から要求されるままにデータの取得に忙殺されていると、肝心の『分析』が進まなくなってしまう」

データ分析のための組織作りで考慮すべきポイント

 社内データ分析チームの位置付けを、gumiの場合は各プロジェクトから独立した共通部門としている。チームを構成するメンバーは、シニアアナリスト、アナリスト、データサイエンティストの3職種。この中で誤解されることの多い「シニアアナリスト」の役割について、今村氏は次のように説明した。

 「シニアアナリストに求められるスキルは『高度な分析』ではない。最も重要な役割は、プロジェクトチームとよく話し合って『現場の課題を抽出』し、『方針を決定』すること」

 その方針に基づいて実際に分析を行うのがアナリストだ。そして、データサイエンティストはより新しく効率的な分析手法や、より適切な指標などを模索する役割を担う。実際には、シニアアナリストとデータサイエンティストを兼務するケースも多いという。

 また、データ分析は決して分析チームだけで行うわけではない。各プロジェクトチームのメンバーはもちろん、データ分析のための仕組みを社内の共通基盤に組み込むために共通基盤エンジニアの協力を仰ぐケースも多い。分析チームをうまく機能させるためには、こうしたさまざまな関係者と連携した取り組みが重要となってくる。

 データ分析チームとプロジェクトチームの関係としては、gumiのように各プロジェクトから独立した分析チームを置くパターンのほか、各アナリストが普段からプロジェクトチームと一緒に仕事をするというパターンもある。

gumiの分析チームは各プロジェクトから独立した共通部門となっている
gumiの分析チームは各プロジェクトから独立した共通部門となっている

 前者は分析チームとして標準化を進めやすい反面、各プロジェクトの課題などを把握しにくいため、定期的なヒアリングなどのフォローが必要となる。後者はプロジェクトの状況を理解しやすいが、前者に比べて知見の横展開が難しい。今村氏によれば、「それぞれ一長一短あるので、データ分析チームを立ち上げる際にはどちらも検討する価値はある」とのこと。

 gumiの分析チームは各プロジェクトと独立した組織だが、プロジェクトごとに担当者をアサインして定例会議への出席やチャットを活用したプロジェクトメンバーとのコミュニケーションを行うことで、プロジェクトチームとの距離を縮める工夫をしているという。

gumiのデータ分析を支える「ログ収集基盤」と「ダッシュボード」

 続いて今村氏は、gumiのデータ分析を支える技術として、データのインプット/アウトプットそれぞれの仕組みを紹介した。

 gumiでは当初、Fluentdを使って各アプリケーションサーバに散在するログをAggregatorで収集し、用途に応じたストレージに保存する仕組みを構築していたが、データの欠損やデータ遅延などのトラブルが続発。原因を突き詰めていくと、ログの収集、加工、格納、障害時の一時保存など「Aggregatorが仕事しすぎ」であったことが判明したという。

 そこで対策として、ログの収集と格納を分離。収集・障害時の一時保存はAmazon Kinesis、格納・加工はLambdaで行う構成とした。これが、現在活用されているgumiのログ収集基盤だ。

Kinesisでログを収集し、Lambdaで各ストレージに分散
Kinesisでログを収集し、Lambdaで各ストレージに分散

 「この構成ではストレージ障害が起きた際にそのログのラインは止まっても、ほかのログは影響を受けずに済む。また、負荷が増大したらKinesisのシャードを増やすことで対応可能。新しいストレージが増えた場合も、Lambdaを追加するだけでよい。インプットの部分については、現在このような仕組みでうまくまわっている」

 一方、アウトプットに関してはDomoのダッシュボードを採用しているそうだ。

 「分析結果を容易にビジュアライズして見やすく表示できるものであれば、ダッシュボードのツールは何でもかまわない。目的はエンジニアの手を借りなくてもデータ分析ができる、結果を見られる環境を提供すること。最終的にはSQLが必要になるので100%は無理かもしれないが、エンジニアでなくてもできることを少しでも広げていくことが重要」

 今村氏は最後にこう呼びかけ、セッションを終えた。

お問い合わせ

 gumi

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5