はじめに
こんにちは。dely開発部でデータエンジニアしてる伊ヶ崎（@_ikki02）です。
本記事はdely Advent Calendar 2020の5日目の記事です。
adventar.org
（delyでは今年から2レーンでアドベントカレンダーやってます。）
昨日は当社デザイナーの@ysk_enが「マジで助かった、新卒1年目デザイナーの教科書的noteや便利なサービス8選」という記事を書きました。
タイトルの付け方がうまいですね。僕も見習いたいです。
ぜひこちらも一読いただけると嬉しいです！
さて、本日僕が書こうと思う内容はズバリこれです。
あまり最近のデータ基盤について外部発信できていなかったのと、
ちょうど社内でデータマネジメントの機運を高めようと動いていることもあり、
この機会に情報発信しちゃおうと思います。
（ちなみに過去の記事はこちら）
目次
- データ基盤の課題
- データマネジメント
- 取組事例：データアーキテクチャ
- 最後に
データ基盤の課題
まず、なぜデータ基盤をやるか、その目的を振り返りたいと思います。
dely（クラシル）では日々様々な施策をみんなで話し合って企画・開発・効果測定に取り組んでいます。
データ基盤はこのサイクルの信憑性を高め、加速化していく役割を担っていると考えます。
しかし、現実としてデータ基盤は完全ではなく様々な課題があります。
特にデータが取れない、異常がある、といった状況では正しい意思決定の妨げとなり、最悪の場合ミスリードしていることにさえ気づかない、という状況を誘導しかねません。
また、基盤の保守運用に際して、その構造を把握していないと、誰もが同じように開発・保守運用ができません。
このような課題感に対処する上で、その管理手法の考え方や方法論のよりどころを求めていました。
そんな時、DAMA Internationalという米国機関によってDMBOKとしてデータマネジメントの体系が整理されていることを知りました。
delyではこのデータマネジメントという考え方を自社の実態に合った形で解釈し直し、課題に取り組む活動にこの半年間取り組んでいます。
データマネジメント
まず、データマネジメントの紹介に際して、@yuzutas0さんの『データマネジメントが30分でわかる本』から抜粋させて頂きます。
データマネジメントとは、「データを資産と捉え、体系的に価値を引き出すための手法」です。 - 資産なので置き場所を決めます。 - 資産なのでどこからきて、どこへ行くのか把握します。 - 資産の価値が減らないように気をつけます。 - 資産を監督する人やそのルールを決めます。 やっていることは、他の資産、例えば預金や不動産の管理と大差ありません。資産管理のデータ版がデータマネジメントです。
僕はこの文章を見た時、発想の転換を迫られました。
様々な異常を問題と捉え正常に捉えること、アーキテクチャの理解の重要性は「資産」として捉えれば当然のことのように思えました。
なお、本家では11の項目に分かれて整理されていますが、
最初に適用を試みるには項目が多く少しハードルが高かったため、
まずは「保守運用」「セキュリティ」「品質」の3つに大別した上で、
自社のデータ基盤について管理していくことにしました。
また、こちらの考え方を四半期初めのロードマップ共有会で
マーケター、エンジニア、デザイナーなど様々な参加者に共有し、
少しずつデータマネジメントの考え方を広げて行こうという活動も開始しています。
取組み事例：データアーキテクチャ
これまで取り組んできた内容について、1つこの場で紹介したいと思います。
さきほど紹介した「保守運用」の項目の中に、「データアーキテクチャ」の項目があります。
具体的には、基盤の構成を可視化し、ビジネスの指標やKPIと紐づけることで、何の基盤がどんな役割を果たしているのか書き出しています。
理論的なメリットとしては、構成を可視化することで、継足しアーキテクチャを避け、同じ指標に対して基盤が違うから値が違う、といった問題が起こるのを避けるのに役立ちます。
実際に書き下ろしたクラシルのデータ基盤は今こんな感じになっています。
アプリの「ユーザー行動ログ」をBigQueryとAthenaの2つのラインに流しています。
メインとしてはAthenaを利用しており、行動ログ以外の外部データ（プッシュ通知、ダウンロード数、課金レポートなど）を、データレイクであるS3に転送、ETL処理してAthenaで集計できるようにしています。
BigQueryについては、Firebaseで取得しているアプリの「アンインストール数」や「地理情報等」を取得し、必要に応じてBIツールであるRedashから参照できるようにしています。
上記図の各パイプラインは別途細部まで可視化しており、
その結果、感じているメリットとして以下のような点を感じています。
- 何の役に立っているか明確になった。
- 採用活動時、現状を説明できる絵ができた。
- 各種調査の時間が減った気がする。
- 課題の特定がしやすくなった。
- Redashで実施したクエリ結果の異常について、原因がRedashなのかAthenaなのかもっと上流なのか、など
- 各リソースの依存関係が明確になり、消していいリソースを判断できるようになった。
- コスト節約に繋がった。可視化後不要なリソースを削除したことで、データ基盤・機械学習基盤について数十%もの金額的コストを削減できています（結構でかい）。
「データアーキテクチャ」の項目を意識して情報を整理したところ、「保守性」が上がったと感じています。
現在は「品質改善」を目指すべく、データを利用するステークホルダーへ品質要求のヒアリングや、異常検知の取組みも進め、「攻めのデータマネジメント」に転じ始めています。
こちらの内容はまた別の機会にこのブログで紹介できればと思っていますので、興味ある方は是非ウォッチしていただければ嬉しいです。
最後に
いかがでしたでしょうか？
delyではユーザーへの価値提供のために自分たちで企画・開発・効果測定のサイクルを日々グルグル回しています。
データマネジメントはこのサイクルを影で支えている縁の下の力持ち的役割に捉えられがちですが、ユーザーもデータも「資産」として大切にする心を忘れずに、価値創造に貢献していきたい想いです。
また、delyでは上記サイクルをさらに加速化させるために、データエンジニアの採用を募集しています。もしこれを読んだデータエンジニアの中で、興味を持っていただける方がいたら、カジュアルな会話からも可能なので是非以下のリンク先からご応募お待ちしてます。笑
明日はknchstさんの「エンジニアの僕が初めてプロダクトマネージャーをする上で特に意識したこと」です。お楽しみに！
