データ分析の作業が、とにかく非効率的になっていた
かつて、XFLAG スタジオではAmazon Redshift（AWSが提供するデータウェアハウスサービス）の分析基盤にアクセスできるのは分析チームだけに限られていた。ビジネスチームのメンバーがごく簡単な分析をしたい場合でも、毎回、分析チームに依頼をする運用をしていたという。そのため、分析チームだけではタスクをさばききれなくなり、作業の待ちが発生していた。
「これではお互いにとってつらい状態です。そこで、分析チーム以外のメンバーでも分析基盤を利用できるようにする方針になりました。データウェアハウスにApache Zeppelinという分析ツールをつなぎ、誰でもデータにアクセス可能にしたんです」
しかし、この施策ではデータ分析の煩雑さが解消されなかった。理由は以下の5つにある。生島氏は順に解説した。
まずは「仕様書を読まないと分析できない」という課題。例えば、ビジネスチームのメンバーが「ステージのクリア数をカウントしたい」と考えたとする。そして、その情報を得るには「striker_stages」テーブルの「state」カラムの値が2になっている行をカウントする必要があるとしよう。アプリケーションの仕様を知らないメンバーがこの作業を行えるかといえば、到底無理だ。「コードを読まないと分析できない」という課題も同様である。非エンジニアのメンバーにとって、コードを理解する難易度は極めて高い。
また、分析に用いるSQLはどうしても長く複雑なものになりがちだ。あるメンバーから「キャンペーン施策のROIの算出に必要な値が欲しい」といった要望があったため、生島氏は半日ほどかけてクエリを書いたそうだ。その結果、300行ほどもある巨大なSQL文が出来上がったという。それほど長くなったクエリは、書いた本人ですらメンテナンスは困難だ。加えて、クエリを書くには複雑なテーブル構造を理解しなければならない。
これらの課題を解決するため、集計しやすいようにデータを整えたサマリーテーブルを作る方針となった。だが、それも良策とはならなかったという。
「例えば、『○○という分析がしたい』といった要望があれば、それに合わせたサマリーテーブルを作ります。『△△という分析がしたい』といった要望があれば、そのサマリーテーブルは使えなさそうなので新しくサマリーテーブルを作ります。お察しかと思いますが、これが延々と続いていくわけです。場当たり的にテーブルを作っていった結果、使いづらいサマリーテーブルが乱立する事態に陥りました」
BIツールをデータウェアハウスにつなげば全てが解決する。そう考えていたXFLAG スタジオのメンバーたちは、誤りに気づいたという。誰もが簡単にデータを分析できるようにするにはどうするべきか、方針転換の必要に迫られることになった。
