バンダイナムコグループでGCPを用いて自動分析ダッシュボードをゼロから開発した話

こんにちは！
バンダイナムコネクサスのデータ戦略部でデータストラテジストをしている田中です。

データ戦略部ではグループ内事業の意思決定に貢献するために、様々な分析PJTを進めています。
(データ戦略部についてはこちらの組織紹介もご参考下さい)

そこで今回は分析PJTの1つである「自動分析ダッシュボード」について紹介します。

自動分析ダッシュボードとは？

自動分析ダッシュボードとは、以下のような分析を自動化する機能を持ったダッシュボードの事を指します。
・総合評価機能：ゲームタイトルのKPI状況が一目で分かる機能
・KPI比較機能：同系統の別ゲームタイトルとKPIを比較する機能
・重要KPI機能：売上に本当に影響を及ぼす重要なKPIに絞り込む機能
・危険KPIフィルタ機能：異常変化や悪化トレンドのKPIを検知する機能
・改善施策提案機能：過去に似たようなKPI悪化状態から復活した類似タイトル事例をレコメンドする機能
・レポート自動作成機能：週報や月報として利用出来るレポートを出力する機能

2021年9月現在、親会社のバンダイナムコエンターテインメントでは多くのゲームタイトルを配信しています。多タイトル展開の強みを活かすべく、これらのタイトルのノウハウを集約し、更に横断して活用できるように、このような機能群を設けています。

また実際のダッシュボードの画面は下記のような形になります。

ここまでが自動分析ダッシュボードの概要になりますが、以下では詳細を紹介したいと思います。

なぜ自動分析ダッシュボードを開発したのか？

下記図のように、自動分析ダッシュボードを開発した理由は3つあります。

ゲームタイトルの状態を直感的に判断出来ない、他ゲームタイトルと適切な形でKPI比較出来ない、重要KPIの変化や異常を見落としてしまうといった既存のKPIダッシュボードで発生していた問題を解決するために、自動分析ダッシュボードの開発を行いました。

プロジェクトの進め方

自動分析ダッシュボードプロジェクトは下記図のように4つのフェーズで進めています。

最初の要件策定フェーズでは、ゲームタイトル運営担当者に要件ヒアリングを行い、その結果を踏まえて機能要件/非機能要件とUI/UX要件とKPI集計要件の定義を行います。

次の開発準備フェーズでは、まずデザイン作成やシステム開発を行う外部開発会社の選定を行います。その後に選定した外部開発会社と共にシステム設計やデザイン作成を行います。
(後述のようにシステム設計はデータ戦略部が主体となって行います)

その次の開発フェーズでは、データサイエンティストが統計モデル開発を行い、外部システム開発会社がシステム開発を行い、開発完了後に外部システム開発会社と協力してテストを行った上でリリースを行います。

継続的な機能改善フェーズでは、自動分析ダッシュボード利用者の改善要望をもとにしてプロダクトバックログを作成し、順次機能追加開発とリリースを行っています。
(モデル改善でデータサイエンティストが関わるケースもあります)

またPJTの進め方の特徴的な点として、データストラテジストは自動分析ダッシュボードというプロダクト開発の全フェーズに関わるという点があります。
(言い換えるとデータストラテジストの裁量が大きいと言えます。)

分析手法

自動分析ダッシュボードの「危険KPIフィルタ機能」では、統計分析手法を用いています。
そこで分析手法の概要を紹介します。

危険KPIフィルタの実現方式の概要

危険KPIフィルタの実現方式の概要は下記図のような形になります。

直近変動の異常度、ゲームタイトル間の偏差、短中期変動トレンドという3つの時系列指標をもとにしてルールベースでの判定を行います。
判定後のKPIステータスは5種類にしており、下記3つのいずれかのステータスになった場合に危険KPIとして表示する形にしています。
　・今良いが悪くなる
　・今悪くてさらに悪くなる
　・異常発生

ここまでが実現方式の概要になりますが、以下では時系列指標の計算方法とルールベースの判定ロジックを紹介します。

時系列指標の計算方法

時系列指標の計算方法(日次KPIの場合)は下記図のような形になります。

ゲームタイトル間の偏差、短中期変動トレンドを計算する際にカルマンフィルタによる平滑化を行っている点が特徴的なポイントになります。

ルールべースの判定ロジック

ルールベースの判定ロジックは下記図のような形になります。

判定自体はルールベースで行っていますが、判定に利用する時系列指標の計算に統計手法を利用している点が特徴的なポイントになります。

※今回紹介したロジックは現時点のものです。現在は精度を見ながらアップデートを行っています。

システム構成

自動分析ダッシュボードのシステム構成は下記図のような形になっています。

図のようにリアルタイム処理、バッチ処理、デプロイフローの3つに分かれているので順に紹介します。

まずリアルタイム処理について紹介します。
前提事項として自動分析ダッシュボードは既存ダッシュボードからシングルサインオンでログインする形を取っています。
そのため既存ダッシュボードのWeb App Serverを介しており、かつ認証機能もAuthorization Serverに委ねています。
そしてWeb App Server経由のリクエストはGCP内のFront Endで処理され、Graph QLを用いたAPIサーバーであるCloud Runを経由してSystem DB内のKPIや総合得点といったデータを取得して、System Userに結果を返す形になっています。

次にバッチ処理について紹介します。
前提事項として、Big Query内にはData WarehouseとAnalysis Result(いわゆるData Mart)という2つの論理的な層が存在しています。
(Data Warehouseの詳細についてはこちらの記事もご参考下さい)
そのためKubernetes ClusterはAnalysis Result内のデータを参照してデータ集計や推論処理を行い、その結果をSystem DBに書き込みます。
そしてこれらの処理を管理するワークフローエンジンとしてCloud Composerを利用しています。

最後にデプロイフローを紹介します。
GitHubへのpushをトリガーとしてCloud Buildが起動し、Kubernetes ClusterやGraph QL APIへデプロイを行う形にしています。

以上がシステム構成になりますが、このシステム構成はデータ戦略部内で検討する形を取っています。
ゼロからのシステム開発だった事もあり、自由度高くGCPを用いたシステム構成を検討する事が出来ました。
この事から個人的には技術選定における自由度がかなり高いと感じました。

自動分析ダッシュボード開発後の反響

ここまで自動分析ダッシュボードの詳細を紹介してきましたが、最後に自動分析ダッシュボードのリリース後の反響を紹介します。

リリース後に自動分析ダッシュボード利用者から寄せられた意見は以下になります。
　・ゲームタイトルの総合的な状態が一目でわかるので、施策効果の影響がわかりやすくなった。
　・他ゲームタイトルとの比較が容易に出来るので、KPIの良し悪し判断がしやすくなった。
　・KPIの異常にすぐに気付けるようになった。
　・KPI目標との乖離がわかると嬉しい。

最後の意見である「KPI目標との乖離がわかると嬉しい」に関する解決策として、現在「KPIシミュレーション機能」の開発を進めています。
KPIを予測する統計モデル(実施予定の施策も考慮)を作成してKPIを予測する事で、目標値との乖離を明らかにする機能になります。