ジモティーiOSチーム所属のエンジニアの橋本です。

普段はiOSアプリの開発に従事していますが､ Webやネイティブアプリ（iOS/Android）の各種計測データの収集や社内への展開などの業務にも従事しています。

今回は､自分が担当しているデーター活用周りでの取り組みのご紹介をしたいと思います。

組織のコンディション判断と意思決定に利用されるデータ

Webアプリやネイティブアプリ（iOS/Android）が生み出す様々なデータは

収集･蓄積・加工  ▶  分析･活用

という過程を経るわけですが､その利用目的は大きくは2つです。

ジモティーというサービスの現状がどうなのか､サービスのコンディションの善し悪しを判断するための利用
ユーザーの利用状況の傾向を把握し､次の打ち手を決める判断材料としての利用

この利用目的を達成するためにデータをどのように利用者に届けるかが重要となります。

エンジニアだけが利用するのであれば，BigQueryなどSQLが実行できる基盤・インターフェース（以下，SQL I/F）を用意しておけば事足ります。

しかし，ビジネスチーム（ビジネス企画，マーケティングなどを担当）やカスタマーサポートチーム（ユーザからの問い合わせ対応､ジモティーの運用ルール策定を担当）にSQL I/Fだけを提供すると､簡単なデータ取得・分析であればよいのですが，ある程度複雑なものになってくるとエンジニアがサポートする必要があります。

SQL作成で手間がかかっていると，ビジネスの意思決定のスピードが遅くなりますので，ある程度複雑なSQLが必要でKPIなど重要指標に関わる数値など，サービスのコンディションを確認するために必須な要素については自動的に取得してデータや分析結果を自動で必要な社員に送付する仕組みも整えています。

次の節からジモティーのデータ分析基盤の構成要素とデータがどのようにエンドユーザー(データ利用者)まで流れていくか図解しながら説明したいと思います。

データ基盤の大きな構造と利用フロー

データ基盤とSQL I/Fについては弊社のSREチームが2016年の段階で整備を進めており，その上でSQLの社内教育もあわせて進め，ビジネスチームメンバーの大半がSQLを書けるまでになりました。

Redash + Redshift + embulkでデータ分析基盤を構築した話

しかし，ある程度基盤整備とSQLの教育はできたものの，時代の変遷と共に例えば，ネイティブアプリのデータ収集・分析に使用していたGoogle Analyticsが廃止になりFirebaseに移行したり､ SQLの実行スピードやコスト面のメリットでRedshiftからBigQueryに移行するなどサービス規模の拡大と技術の進化にあわせてかなり構成が変更されています。

現在は，データ分析基盤はBigQuery中心の構成になっており､各種データは一度BigQueryに集約してからSQL I/F，Google Spreadsheetやメールを含めフロントエンドに（分析）データが供給されています。

下記にデータフローの観点での見取り図を示し，以降は図中に示した番号毎に説明していきます。

図１. 分析用データのフロー観点での見取り図　

［１］BigQuery

以前は、データ分析基盤の主軸としてAmazon Redshiftを利用していたのはこの記事の通りで､下記のメリットをかなり享受できました。

AWSで構築している既存サービスとの親和性
クエリに依存せず固定額（SQLに不慣れなメンバーも実行する前提なので）
データ量がまだそれほど多くないので安価に始められる

しかし、分析の幅を広げるため､分析対象をRailsのアクセスログまで拡張したい要望があり、大幅に分析するデータ量が増加しました。それに合わせて､改めてSQLの実行スピードといったパフォーマンス面とコストメリットの部分で検討をして､2017年にBigQueryの利用を開始しました。

当初はRedshiftとBigQueryを併用していたのですが､SQLの利用面で両方で持っているデータで JOIN（テーブルの結合）ができないデメリットがあり､2018年にBigQueryにすべてのデータが集約されました。

また､結果的にではありますがネイティブアプリのデータ収集・分析に利用するFirebaseやGoogle Spreadsheet､ Google Apps Scriptとの親和性が高かった（API連携が非常にやりやすかった）点もBigQueryに移行して良かった点です。

［２］データ転送はembulkとfluentd

データ転送にはOSS のデータ転送ソフトウェアの emublk と fluentd を使用しています。個々のRuby on Railsが動作するサーバーから出力されるアクセスログは fluentd によってAmazon S3に転送されて集約されます。

mongodbやAWS Aurora､ Amazon S3上のアクセスログから BigQuery の転送には現状は基本的に日次でデータを転送しています（アクセスログについては1時間毎に転送しています）。

embulkとfluentdのメリットは、プラグイン機構によって様々なデータベース/データストレージ/ファイルフォーマットに対応でき、結果、連携先が増えても比較的新しく覚えることが少なく、対応にスピード感が出る点だと思います。

［３］FirebaseとBigQueryを連携

Firebase の Bigquery Exportを使用して、iOS / Android のネイティブアプリのイベントデータを蓄積しているFirebaseとBigQueryを連携させています。 BigQueryの転送先のスキーマ定義もカチッと決まっているので、慣れるとSQLも素早く書けるようになります。このFirebaseのデータとRailsのアクセスログを組み合わせて分析することも多いです。

［４］Redash

弊社のSQL I/Fの要となるツールで、SQLの実行はもちろんのこと､下記のようなことも可能です。

ビジュアライズ：クエリの結果から円グラフ、折れ線グラフ、散布図などを描画
スケジューリング：保存したクエリにスケジュールを設定し定時実行できる

Redashについては､当初､不具合も散見されましたが、弊社SREチームの吉田が､Redash コミュニティーに不具合の修正パッチをちょくちょく送っていました。そうしたら、いつの間にか吉田がRedashのコミッターになっていて､吉田と昼休みにご飯を一緒に食べているときに聞いてびっくりした覚えがあります。

2018年に Redash へ送った Pull Request 一覧 [OSS] on @Qiita https://t.co/94dTYdnNbr
— Katsuhiko YOSHIDA (@kyoshida) December 2, 2018

弊社のRedashに保存されているSQLの量は年々着実に増えており､Redashと共に弊社のデータ分析文化も成長していっている感じがします。

［５］Google Apps Script /［６］ Google Spreadsheet /［７］ Gmail

前述の通り､ビジネスチームに対するSQL I/Fの提供だけでは、

複雑なSQLが必要な場合にエンジニアがサポートが必要な点
ある程度複雑なSQLが必要で定期的に確認する必要があるKPIなど重要指標に関わる数値が存在し、SQL I/F だけではその確認が困難な点

といったことに対応できないので、重要なデータや分析結果を自動でGoogleSpreadsheetに反映したり､メールで必要な社員に送付する仕組みも整えています。

［５］Google Apps Script

Google Apps Scriptを利用して、BigQuery・Google Spreadsheet・GmailとAPI連携してBigQueryからデータを取り出し、必要なデータをGoogle Spreadsheetとメールに出力しています。

Google Apps Script についてはGoogle Spreadsheetと紐付けて管理しており、claspというツールを利用してローカルの開発環境のスクリプトとGoogle Spreadsheet上のスクリプトを同期させます。これにより、ローカル開発環境のスクリプトをGithubで管理できるようにしています。

［６］ Google Spreadsheet

ビジネスチームのメンバーはSQL自体はRedash上で開発して、定期的に確認しなければならない分析データ（例えば、サービス上の新しい施策の状況確認等）はRedash上ではなく、Google Apps Scriptを定期実行して日次で自動的にBigQueryからデータを取得してGoogle Spreadsheetに出力して確認します。

ビジネスチームがGoogle Apps Scriptを書くわけではなく、Google Spreadsheet上に用意されたSQLタブにSQLと反映するタブ名、取得開始日次、取得終了日時を記載すると自動的に定期実行して、結果を反映するフレームワーク（Google Spreadsheet＋Google Apps Script のテンプレート）をエンジニア側が開発して、それをビジネスチームに使ってもらっています。

これらの仕組みのおかげで、ビジネスチームが自分たちの要求に応じてスピーディーにデータの分析と定期的な確認ができるようになりました。以前のBlogに記載されていた下記のような状況は遠い過去のものとなりました！

これまでは、

「ディレクターがデータ抽出を依頼→エンジニアが指定されたデータをCSVに出力して渡す」

という形になっていました。

データの抽出の依頼が週に5、6件発生し、1件毎にエンジニアの工数が数時間取られるという状況です

［７］ Gmail

弊社では、KPIメールというジモティーのサービスのコンディションを診断するためにWebアプリとネイティブアプリ（Android/iOS）の厳選された指標データを当日から30日前までの分をリスト化して毎日2回、社員に送信するようにしています。

このKPIメールにより、直近のサービスの状況を全社員が毎日、日次の変化を含めて確認することができます。何か指標に異常があった時に原因を含めて同じ数字でチーム内で議論できますので、社内での数値に対する関心を高める効果と共にコミュニケーションツールとしても非常に役立っています。

［８］Google Analytics

Webアプリに関するデータ分析に関しては、Google Analyticsを長年利用し続けています。

今後の展望

以前と比較してかなり、データ分析基盤は整ってきましたが、先進的な企業と比較するとまだまだやることがたくさんあります。

SQLを使った分析を更に容易にする

全社的にSQLの活用がかなり進んできていますが、複雑なSQLを組むときはエンジニアのサポートが必要な状況です。これは、アクセスログやFirebaseのイベントデータなど複雑なテーブルに対してそのままSQLを組むとどうしてもSQLが複雑になるのが原因です。

そのため、一度複雑なデータに関しては分析しやすい中間テーブルに分解して、自動的に中間テーブルにデータを流入させるデータフローを構築する手段が考えられます。

中間テーブルの設計がかなり難易度が高そうですが、実現できればSQLを書くのがかなり容易になると期待されます。

ストリーム（即時）データの分析

現時点のデータ分析基盤では一番鮮度が高いデータでも1時間前のデータです。現在のジモティーのサービスではそこまで即時性の高いデータは必要ないのですが、エンジニア側が障害や異常があった時に即時性の高いデータが必要になります。各種、開発者向けのモニタリングツールでも原因の推定はやれなくもないのですが、アクセスログなどのデータがすぐに参照できた方が障害・異常の原因特定はかなり容易になります。

かつてその目的で kibana を導入したことがあったのですが、サービス規模が巨大になりログ転送含めて運用がかなり大変になったため、使用をやめています。こちらも kibana の代わりにうまく大量データを非同期で投入できるようなストリームデータ分析基盤の導入が待たれます。

現状、案として出ているのが flutnd + BigQuery streaming insert なのでこちらを試すところから始めたいですね。

データの可視化、ビジネスダッシュボード

現在データを可視化するのにGoogle SpreadsheetやRedashのグラフツールを利用していますが、ストリームデータを扱えるようになったらKPIの状況などをリアルタイムに可視化できる基盤の導入なども行えるとよいと思っています。まずは手始めにGoogle Data Studioの活用などが考えられるでしょう。