これは初期からオールアバウトで独自開発していた集計システムで、編集や営業がデータを見るためのダッシュボードを含んでいます。ここからクライアントに提出するレポートの生成もできるようになっています。

今は、今後のメインとなるものをG Suiteで作っているのですが、Google Analyticsの数値をDBに保存したものをGoogle Data Studioでダッシュボード化させています。実は、これも暫定版で、いずれTableauにしようかと思っています。裏側はシステム化してあって、このままTableauでも使えるはずなので。

オールアバウトは創業16年目の会社のため、当時のシステムに支障をきたしている部分もあるので、システム部として全面的に見直しているところです。自分が入社した当時にはHadoopが運用されていたのですが、作った人が退職していて、ただ動いているだけというつらい状態でした（笑）。つぎはぎだらけの、まさにレガシーシステムですね。

そこで社内集計システムをHadoopからトレジャーデータにシステムを移行させ、さらに関連するDBも以前から使用しているSQL ServerからMySQLに切り変えることで、筋の通った設計思想でのビルドが終わったところです。
非常に拡張しやすい状態になっているので、BigQueryとGoogle DataFlowを使った機械学習のサービスへの組み込みも行っています。

苦労したことはたくさんあります。誰にも中身がよくわかっていなかった社内集計システムを、ひとつずつ紐解いてお引っ越しができる状態にするまでも大変でしたし、たくさんのツールを組み合わせていたので、それらをオーソライズした設計で一本化するのにも苦労しました。

あとは、新しいシステムと古いシステムにデータの整合性を持たせるために、トラブルが発生することを予見して、シームレスに移行できるよう、簡単に切り替えできる並行稼働の手順を作ったことも、なかなか大変でしたね。

Hadoopで運用していた頃は、ハードウェアのトラブルが月に1度は起きるような状態でしたので、インフラチームにお願いして夜間作業を行ってもらうことも多かったのですが、トレジャーデータに移行してからは安定稼働しています。それに、年次のKPI数値等、以前は1時間掛かった集計が10分で終わってしまって驚きました。

何か不可解なトラブルがあったときに、そのシステムがどういう理念で動いているのか、という根っこから考えることで、原因を見つけられた経験が何度かあるからじゃないかなと。そのときに、原因にたどり着くまで掘っていくための考え方を、ちゃんと説明するようにはしています。トラブルが起きない方がみんな幸せに暮らせますからね。

それとDMGってトラブルの最終的な火消し役になることが多いんです。なので、トラブルが発生する原因に向き合うのは習慣化していて、それをチームでも共有し、次回以降の設計に活かしトラブル回避に努めています。

他部署から相談を受けたときに、やるべきことが明確ではない場合もあるので、「会社として、なぜそれをやる必要があるのか」「それをやった場合にどんなことが起きる可能性があるか」といったように、役職的に2段階上の視点から見るように意識しています。

特に管理職を目指しているからというわけではなく、そこまで考えて動くのがお給料分かなと思っているからです。前職が社内SEだったので、社内のシステムに対する責任を持っていたこともあり、上段から物事を見る癖がついているのかもしれませんね。