Web制作からデータ基盤を作る仕事を始めて1年以上経った

Web制作をしていたつもりが、気付いたらデータ基盤の構築や運用をやるようになっていました。時系列に並べて見るとこんな感じです。

Year	会社分類	役割
2006-2009	事業会社	デザイナー兼社内SE
2009-2013	制作会社	デザイナー・フロントエンドエンジニア・ディレクター
2013-2014	フリーランス	デザイナー・フロントエンドエンジニア・ サーバーサイドエンジニア・ディレクター
2014	制作会社	既存サービスのIA兼PM（エンハンス）
2015	制作会社	大手サイトのリニューアルプロジェクトのIA
2016	制作会社	既存サービスのフロントエンドエンジニア（エンハンス開発）
2016	制作会社	新規サービスのフロントエンドエンジニア
2017	制作会社	10人弱規模のマネージャー
2017-2018	制作会社	既存サービスのフロントエンドエンジニア （運用＆エンハンス）
2018	制作会社	新規サービスのディレクター
2018-今	制作会社	新規データマート構築のデータエンジニア

今日は最近のお仕事的なことでも。

今やっていること

今主にやっている仕事は、データ基盤の構築＆運用です。 データ基盤をかなり雑に説明すると、アクセスログやWebシステムのデータベース、受発注などの基幹システムを一つのデータベースにまとめたテーブルの集まりです。これまでもユーザーが意図通りに導線を辿っているのかどうか確認しようと思えばできましたが、扱うデータが膨大なため、直接分析用にSQLを実行すると事業システムに膨大な負荷がかかってサービスが落ちる心配を秘めていました。

そのため分析したり可視化したり、機械学習の下地としてのデータ基盤を作り、業務として使われているデータベースにアクセスせずに分析可能な状態にするのが今のお仕事です。

「データベースをエクスポートすればいいだけの話でしょ？」と思う人もいますが、実際には分析に不要となるような個人情報をそぎ落としたり、テストユーザーとして会員登録したような分析対象外となる人を除外したりといくつかフィルタリングを行います。

SQLとも戦うけれど、クラウド全般の知識も頭に入ってきた

Web制作というところから、データ領域に身を置いた私が1年で新しく覚えたのは主に3つです。

• SQL
• クラウド周りのエトセトラ
• Python

今までSQLはO/Rマッパーを使ってやるみたいなことがほとんどで数行ぐらいで済むようなものでした。しかし分析用途に使うテーブルはカラム数が多いので、SQLは長いと1000行ぐらいに及ぶこともあります。慣れるまでは大変でしたが、半年経ったあたりからは何も感じずにコードを読み解けるようになりました。

データ基盤を作る上ではクラウド技術は欠かせません。今メインで関わっている案件はAWS Redshiftであったり、別案件で開発している案件はBigQueryだったりといろいろあります。それに合わせて連携しやすいストレージサービスを選んだり、それに紐付いてIAM権限を…みたいに箱を作るだけじゃなく、自動でデータがテーブルに取り込まれていく仕組みも整備しました。そうなってくるとデータベース以外のクラウド全般的なサービスも覚えました。

Pythonはデータ連携においてサービス間ののりしろ的な用途で使っています。シェルスクリプトでもできますが、そのためにVMインスタンスを立てるのもどうかということで、AWSのLambdaやGCPのCloud Functionsを実行環境にして使っています。Pythonにしたのは、周囲にPythonを書いている人が多かったからというシンプルな理由です。

データ基盤もWeb制作も「ユーザーの期待」から

Web制作の仕事からデータ基盤の開発ということを始めて、あまり変わらないなと思っているのはユーザーの期待や思考に寄り添って設計することなのだなと思っています。

使い手がいてこそのデータ基盤なので、どんな環境で閲覧するのか、どれぐらいのITリテラシーなのか、何に使うのか、何のアクションを起こせるのかを想像したり聞きながら、使い手の人が困らないようなテーブル設計をしています。

億単位のテーブルの集計はTableauでもそれなりに計算に時間がかかるので使い手にとってはしんどいです。そのため、あらかじめ集計用のテーブルを作成してそれを可視化の際には使ってもらう...みたいなこともしています。なので、「ユーザーは◯秒以上は待てない」といったWeb制作の常識的な部分の考え方は役に立っています。

次にやってみたいことはデータ基盤そのものの利用分析

ホームページ作成ブームの後に何が変わったのかと思い出すと、「ホームページが目的を達成しているかどうか」をアクセス解析を用いて検証するといったことでした。データ基盤や可視化ツールでも同じようなことが言えるような気がします。つまり「データ基盤が目的を達成しているのか」といったことです。

TableauやGoogle データポータルなどでどこかしらのテーブルが使われているのは一目瞭然です。しかし、データ基盤のどのテーブルが多く参照されているのか、使われていないテーブルはどんなテーブルなのかまでは踏み込めていません。

これがわかるようになると、障害発生時に優先的にリカバリーする必要のあるテーブルはどれか、使われていないテーブルはリソース節約のためにdropしたり更新頻度をコントロールできるのではと、運用を考えたときに役に立たせそうです。

可視化ツールであっても同じようなことが言えると思います。ダッシュボードのうち、よく使われているダッシュボードはどれで、使われていないダッシュボードはどれみたいなこと。埃を被っているダッシュボードもあると思うのです。

今は開発がメインなので運用の優先度は下げがちですが、開発がそろそろ一段落する頃にはこういうことも手を付けて人に優しい分析環境を会話しながら作って行きたいです。