みんなの数値への意識を高めるためエンジニアがやってきたこと
お久しぶりです。僕のこと覚えてますか？前回はSwift移行の話をさせていただいた @morimorimです。 現在は、オールアバウトのグループ会社である弊社オールアバウトライフマーケティングへ出向し、インフラ基盤エンジニアとして働いています。
みなさんの会社では数値分析をされていますか？ 数値分析大事ですよね。特に自社サービスを運営する上で、分析は欠かせません。 弊社では昨年から本格的に数値分析をする基盤を整え始めています。 今回はその取り組みの一部を紹介させていただきたいと思います！
はじめに
弊社ではサンプル百貨店というECサイトを運営しています。人気の商品が市場価格よりお得なお値段でお試しできるお得なサイトです。（ぜひご利用くださいませ！）
そんなサンプル百貨店を運営する弊社の行動規範の一つに「数値を意識した計画を立て、実行力を高めよう」という規範があります。何か施策を行うにしても根拠が曖昧ではどう進めて良いかわかりません。数値を根拠に示すことである程度事実に則って判断を下すことができるので、自分たちが思い描くサービス価値を提供できるようになります。弊社ではそれを一人一人が意識してできるようになることを目指しています。
今回の記事では「数値を意識した計画を立て、実行力を高めよう」を実現するために、エンジニアがやったことを紹介します。
Re:dashの導入
みんなで数値を意識するために、弊社ではまず「Re:dash」の導入を行いました。 Re:dashとはオープンソースのBI/ダッシュボードツールです。Re:dashはMySQL、BigQuery、Treasure Dataなど多数のデータソースからデータを取得することができる上、実行結果のキャッシュ、クエリスケジューリング、ダッシュボード化機能などの便利機能も備えています。
↑弊社のダッシュボードの例です。このダッシュボードでは5分ごとの当日累計売り上げと、その時間までの売り上げグラフを出しています。
Re:dash導入経緯
なぜRe:dashを導入することに決めたかといいますと、データ抽出時に気軽に重いクエリを投げられ、負荷のかかりやすい環境だったためです。
Re:dash導入前までは、サンプル百貨店のDBはMaster・Slaveの2台構成で運用されていました。マーケティング担当がデータを抽出する際は、Microsoft Accessを使ってSlaveへ直接接続していました。当時はそれほどアクセス数はなかったので、問題ありませんでした。しかしその時代からサービスは成長していき、アクセスが増えてきました。この運用が続いた結果...
Slaveが死んでしまいました。
Re:dash導入後のデータ抽出基盤
Slave死亡事件の後、弊社システム開発部ではAccessからの接続数を減らす施策を打ちました。（決してAccessが悪いわけではありません。Accessは大変良いツールだと個人的に思ってます。） Re:dashの導入がその一つです。Re:dashの導入によりクエリのキャッシュが行えるようになり、2回目以降のデータ取得がとても速くなりました。 また、一度作ったクエリはRe:dash上で他のユーザも利用できるので、二度と同じクエリを組む必要がなく、業務効率も改善されました。おかげでRe:dashは社内で大人気です。
Re:dashの導入後、システム開発部はもう一手打ちました。Re:dash専用Slaveの作成です。 Slave死亡事件はサービスで使用するDBを分析に使用しなければ起きなかった問題なので、データ抽出用にDBをもう一台用意してサービスに影響のないアーキテクチャを用意しました。それが下記になります。
Slave2台構成によりサービスへの影響がなくなり、さらにデータの抽出が活発に行われるようになりました。現在ではデータ専用の独立したDBとバッチサーバを用意したことで、以前の構成では重すぎて取得できなかったユーザと売り上げを絡めた分析データも取得できるようになったり、GA（Google Analytics）外部データもRe:dashで取得できるようになっています。
Re:dash導入により得られたメリット
先ほどRe:dash導入後のデータ抽出基盤について述べました。ここで改めてその基盤のメリットについてまとめたいと思います。
1. 実行結果のキャッシュ
1度実行したクエリはキャッシュされるため、同じ結果を得ようとした他のユーザがいたときや同じクエリを実行しなければいけない状況になったとき、2度同じクエリをDBに対して実行する必要が無くなります。意外に同じクエリを2度叩くという状況は何度か発生するものなので、DBの負荷軽減に繋がりました。
2. クエリの共有
一度作ったクエリはRe:dash上に保存されて共有されるので、誰かが作ったクエリを他の人が再利用することができます。この機能のおかげで無駄にクエリを作り直すということがなくなりました。
さらにRe:dashにはクエリに変数を埋め込む機能があり、 created_date BETWEEN "2018-05-20" AND "2018-05-21"をcreated_date BETWEEN "{{ from }}" AND "{{ to }}"とすることで fromとtoの入力フォームが表示され、フォームに入力した値をSQLへ埋め込むことができます。
この二つの機能を合わせることにより、似たようなクエリを二度作る必要がなくなるのでグッと業務効率が上がりました。
3. Re:dash専用DBの追加
Re:dash用のDB追加により、サービスのことを考えずにガンガンクエリが回せるようになりました。データ抽出、分析のできる会社へ一歩前進です！
Re:dash導入により発生した新たな課題
Re:dash導入にはかなりのメリットがあり、社内でもかなり大人気になったのですが、新たに課題も出て来ました。それは下記の二点です。
1. Re:dashが止まるとマーケティング、オペレーションを担当する部署でプチパニックが起こる
各部の業務がRe:dashを起点として行われるようになり、データの抽出を社員全員が簡単に行えるようになったため、様々な業務の効率が改善されました。しかし、一方でRe:dashが止まってしまうと、業務がまるごとストップしてしまうという自体が発生しています。業務がストップしてしまうと担当者はすごく困ってしまうので、システム開発部宛に問い合わせが入ります。その問い合わせがRe:dash停止時は何件も寄せられるので、Re:dashの安定稼働は目下システム開発部の優先的課題となっています。
2. エンジニアのRe:dashクエリ作成工数が増えた
Re:dashは一度作ったクエリは保存しておける上、パラメータを活用することで似たようなクエリを二度と組まなくて済むため大変便利です。ただ、Where条件で利用するカラムが少し変わっただけのクエリが欲しくなった場合、新たにクエリを組む必要があるため、システム開発部に依頼が来ます。Re:dash導入前と導入後でエンジニアの開発・運用タスクとクエリ作成の比率が 8:2 → 6:4 にまでなってしまい、エンジニアが本来やりたいことが行えない状況となってしまいました。
SQL講座の実施
このままではシステム開発部ではなく、Re:dashクエリ作成部になってしまう！そう危惧した私たちはエンジニアにかかるクエリ作成の負荷を下げるため、非エンジニア向けにSQL講座を実施することにしました。
SQL講座とは
その名の通り、SQLについて学ぶ講座です。selectで簡単なデータを取ってくるところから、Re:dashでクエリを作れるようになるところまでを目標に手を動かしながら覚えるハンズオン形式で実施しました。
実際の講座の様子はこんな感じです↓↓↓みんな黙々と真剣に受講してますね！Great！
講座実施の効果
講座実施後、参加者に行なったアンケートでは割と好感触な感想がもらえました。よく理解できたという感想が多くて先生（僕）は大変安心しております。
さらにRe:dashでSQL講座受講者が実際にクエリを作成するようになってきているので、今後エンジニアの負荷は下がっていくのではないかと密かに期待しています。
データ表示用のディスプレイを設置
システム開発部ではさらに、データ表示用のディスプレイを設置しました。
ディスプレイ導入経緯
ディスプレイを設置した経緯としては、サンプル百貨店の数字をRe:dashで確認できるようになりましたが、実際にその数値について話題にする人はあまりいなかったことです。週一回の朝礼で前週の売り上げを確認することはできますが、積極的になんどもRe:dashの画面を開かない限り、当日の売り上げやその時点までの累計売上額を知ることはできません。サービスの現状を把握しておくことで、より数値を意識した計画を立てられるようになるに違いないと考え、データ表示用のディスプレイを設置しました。
導入後の効果
ディスプレイに表示されるのは、先ほどご紹介したRe:dashのリアルタイムダッシュボードとGAのリアルタイム情報です。このディスプレイを設置したことによりリアルタイム情報を気にする人が増え、「平日この時間に売り上げ上がってるけどなぜだろう」、「施策打ったけどあまり伸びて来てない」、などの話題が増えてきました。きっと今後の施策に活かされていくと信じています！
おわりに
まとめ
いかがでしたでしょうか？今回は数値を意識するためにエンジニアがやったことを紹介しました。読者のみなさまの参考になれば幸いです。
弊社は数値を意識した計画を立てる会社です。必要な時に、必要な人が、必要なデータを取得できるような基盤作りに、エンジニアが貢献しています。次の三つがその実施内容です。
- Re:dashの導入
- 負荷軽減
- 一度作ったクエリの共有
- SQL講座の実施
- 必要な人が必要なデータを取得するための手段を身につけた
- データ表示用ディスプレイの設置
- リアルタイムの数値がわかるようになった
今後
ここまで読んでくださった方はお気づきかと思いますが、僕は冒頭で「分析」というワードを出しつつ、ここまで一切触れていません。まだ弊社はデータ抽出がまともにできるようになっただけだからです。 今後はデータ分析も積極的に行える会社とするため、Redshiftを用いた新たなデータ分析、抽出アーキテクチャを考えています。なんでBigQueryじゃなくてRedshiftなの？（AWSでサービス運用してるからとかそんな理由じゃないよ！）とか実際のアーキテクチャについては、また別の機会とさせていただきます。
企業と運営するサービスが続く限り、データ分析、抽出がなくなることはありません。僕達オールアバウトライフマーケティングのエンジニアたちは、数値周りの環境をより快適にすべくこれからも戦っていきます！
弊社では一緒に働ける仲間を募集中です。数字意識して計画を立てながら仕事をしてみたい方はぜひご応募ください！
ではごきげんよう〜
