ひとりデータチームから、複数サービスの垣根を越えてETLとデータを活用できるようになるまでの道のり
dely株式会社
- 課題
- データの正確性に誰も責任を負えておらず、データ基盤に負債が発生していた
- データエンジニアがひとりしかいなかった
- データ基盤を構築し直すための社内リソースが不足していた
- 目的
- データ基盤の運用の脱属人化
- 鮮度の高いデータで、いち早く、より正しい意思決定ができる状態にする
- データ基盤に関わる社員全員が、データ活用に当事者意識を持つ
- 効果
- 新しいデータ基盤をスムーズに構築
- 毎月40時間相当のデータ基盤の運用の時間と手間の削減
- ツール同士の相性ではなくユーザー側の事情やメリットの観点からツールを選べるように
アプリのダウンロード数が4400万、SNSの総フォロワー数が1,100万を超える国内No.1のレシピ動画サービス「クラシル」を運営するdely株式会社。同社は2024年12月に東京証券取引所グロース市場に上場し、商品比較サービス「クラシル比較」やお買い物サポートアプリ「クラシルリワード」など多数のサービスを運営している。
創業当初からデータドリブンな意思決定を下すことを徹底していた同社では、以前より活用してきたデータ基盤の担当者不在の状態が続いていた。そこでデータ基盤の脱属人化を目的に「TROCCO」を導入し、新たにデータ基盤を構築することになった。「TROCCO」導入の背景にあった課題やETLツールの比較検討、データ基盤の活用状況、そして今後の展望について、ご担当者様にお話を伺った。
課題・問題
データドリブンな意思決定が根付いていたものの、データ基盤の負債に課題
張替裕矢 様(以下、敬称略):2014年の創業当時から「データドリブンな意思決定をすべきである」という文化が根付いていることが弊社の特徴であり、強みです。現場レベルから経営レベルの判断まで、何かを決める際にはまずデータを確認することが徹底されており、それを支えるデータ基盤が創業当時から構築、運用されています。
データを重視している理由は、より確実性の高い施策にリソースを割き、スピード感をもって事業を拡大させるためです。ユーザーにプロダクトを届ける際はまず仮説を立てて実行し、それが成功だったのか失敗だったのかをデータを元に判断します。さらに、その成功、失敗の原因を突き詰めて次回に活かしていくにもデータが必要です。
データドリブンで施策を実行することで、プロダクトを通じてユーザーによりよい価値を提供することにも繋がります。
張替:私が入社した2021年8月当時、必要最低限のデータ基盤が構築されている状況でした。具体的なアーキテクチャとして、データウェアハウスにAmazon Athenaを、クラウドストレージにAmazon S3を、BIツールにはRedashを使用していました。Amazon S3には、ユーザーの行動ログやアプリケーションのデータ、課金系のデータなどの分析対象のデータが格納されています。
Redashで必要な数字は可視化されていたものの、データに誰も責任を負っていない状態でした。そこから正しい情報を得るためにはデータをどのように整理すべきか誰も分かっておらず、ちょっとしたカオスが起きていました。
張替:当時はデータエンジニア職が社内に私しかいない状態でした。よりデータを活用するためにメンテナンスをしたくても、どこから着手すればいいか分からず、誰かに聞くこともできずで困っていました。
さらにいくつか具体的な問題も発生しており、たとえば日次で課金データ収集するパイプラインがなぜか動いていなかったり、データの連携処理に失敗して数字が正確なものではなかったりと、責任者の不在でデータ基盤で負債が発生していたのです。
このデータ基盤の負債を解消していくために、まずはデータ収集のパイプラインを整備していち早く正確なデータを使える状態にすること、将来的にデータ基盤そのものを新たに構築して移行することを目指し、データウェアハウスをAmazon AthenaからSnowflakeへ移行したあとにETLサービスの導入を検討し始めました。
なぜ「TROCCO」を選んだのか
決め手は、将来的な脱属人化と対応コネクタ、そして運用コスト
張替:当時はデータエンジニアが私ひとりという状況ではありましたが、将来的にデータエンジニアリングチームの人数が増え、データ基盤の運用を引き継いでいく可能性を考えていました。そのため、GUIベースで誰でも開発、管理できること、つまり「データ基盤の担当者がいなくなっても運用できるETLサービスか」という点を特に重視していました。データ基盤は脱属人化を前提に構築しないと、担当者の退職や異動によって簡単にデータ基盤に負債が発生してしまうのだと、当時のデータ基盤から学んでいたのです。
その他に重視していた要素が、対応コネクタや転送できるデータが弊社の要件を満たしていることです。最も重要だったのがアプリケーションの課金系のデータで、App StoreとGoogle Playからデータを転送できることは必須でした。社内からは課金系のデータ以外にもユーザーの行動ログやアプリケーションのデータなどをスプレッドシートからSnowflakeへ統合し、意思決定に使えるデータ活用のパターンを増やしたいとの要望もあり、対応コネクタの開発、リリースが活発であることも重視していました。
外資系のETLサービスの新規導入と既存のデータ基盤を使い続けること、そして「TROCCO」の導入で最終的に比較検討し、「TROCCO」が私たちの要件を満たし、かつ以前と比べて月額コストが10万円近く削減できることから導入を決定しました。
導入までのスケジュール・過程
複数のデータソースをSnowflakeへ。チーム機能で「TROCCO」活用を脱属人化
張替:「TROCCO」の導入に着手しはじめたのが2022年10月頃、Snowflakeによる新しいデータウェアハウスを構築してからおよそ1年というタイミングでした。当時のデータウェアハウスはAmazon AthenaとSnowflakeの2つが存在する状況であり、情報の一貫性と正確性を確保するため、信頼できるただ1つのデータソースを確立すべきという「Single Source of Truth」を実践できていなかったのです。
いち早く以前のデータ基盤で負債化している部分を解消し、新しいデータ基盤へのリプレイスを進めたいと考えていました。「TROCCO」の導入自体は、PoCを含めて1ヶ月で完了しています。
初期に設定した転送設定はApp StoreとGoogle Play、スプレッドシートです。その後、Google Search ConsoleやAmazon S3のデータをSnowflakeへ転送する設定を追加しました。
また、新しくリリースした情報サイト「クラシル比較」についてはGoogle AnalyticsからSnowflakeへデータを転送しています。現状、サービス問わずすべてのデータをSnowflakeに集約するデータフローにしていますが、Snowflakeだからこその特別な作業や設定は特にありませんでした。
張替:ワークフロー機能をよく活用しています。パラメータとして特定の日付を入れないと返ってこないデータの場合、本来は1日ごとにデータを転送する必要があります。そのような一度で転送ジョブを作成できない場合も、ワークフロー機能を活用することですべてのデータをきれいに転送することができました。
導入当初は私ひとりからスタートした取り組みでしたが、現在はバックエンドエンジニアを含めて13名が「TROCCO」を扱う規模にまで成長しました。そこで活用しているのがチーム機能です。この機能によって、チームでデータを扱う際に各個人の業務にあわせた正しい権限(管理者ロール、運用者ロール)を付与し、セキュリティやガバナンスを強化することができました。
張替:これはデータ活用全般に言えることだと思うのですが、ダッシュボードにしろパイプラインにしろ誰かがオーナーシップを持たないとすぐに負債化してしまいます。だからこそ、「TROCCO」の活用についても、担当者全員に当事者意識を持って「自分ごと化」もらうために権限を付与し、設定した本人が最後まで管理するよう徹底しています。
導入後の効果
ETLの導入でツール側の仕様ではなくユーザー側のメリットでツールを選定できるように
張替:「TROCCO」の導入によって以前のデータ基盤を同じ分析業務ができる新しいデータ基盤をスムーズに構築できただけでなく、「TROCCO」のアカウント権限を付与したメンバー全員がデータ基盤を運用できるようになったことで脱属人化も達成できています。
また、データ基盤の運用コストの削減も実現できました。もしオープンソースのツールなどを使って自分たちで構築していた場合、転送用のコネクタを定期的にメンテナンスしたり、何かトラブルやエラーが起きた際にはまずはそれを検知して適切に対応したりと、運用フェーズでも多くのリソースを割いていたと思います。
実際に、以前のデータ基盤で常にワークロードを動かすことになれば、もし何かのトラブルで動かなくなるたびにリカバリーの作業が毎日2時間は発生していたと思います。1ヶ月積み上げると40時間ものリソースを割くことになるので、「本来やらなければならないミッション」にも支障がでるでしょう。データ基盤の運用リソースを「TROCCO」にお任せすることで、弊社側で必要なリソースを最小限に抑えられています。
張替:「クラシル比較」ではバックエンドエンジニアからの要望でデータウェアハウスにSnowflakeを活用していますが、もし「TROCCO」を導入していなければGoogle Analyticsとデータの親和性があるGoogle BigQueryになっていたはずです。ツール同士のデータのやり取りや親和性といったツール側の事情ではなく、私たちユーザー側の事情やメリットの観点からツールを選べるのは、「TROCCO」を導入したことによる効果だと感じています。実際に振り返ってみると、「クラシル比較」にSnowflakeを導入したのは正しい選択でした。
張替:こちらからの質問に対して、いつも迅速にご回答いただいていると実感しています。特にユーザー数が多いSaaSの場合だと、問い合わせフォームからサポートを依頼しても当日中には返答がないことも珍しくありません。
その一方で「TROCCO」のサポートではストレスを感じたことはまったくありません。いつも相談に乗っていただいて私もメンバーもとても助かっており、ありがたく感じています。
今後の展望
複数サービスの垣根を越えた利便性を提供するため、さらなるデータ利活用に進めたい
張替:弊社では現在「クラシル」や「クラシル比較」だけでなく、「クラシルリワード」といった、消費者の生活に密着する複数のサービスを多角的に展開しています。これらのサービスのデータウェアハウスはSnowflakeやGoogle BigQueryが使われていますが、将来的にはSnowflakeに統一していこうと考えています。そしてデータウェアハウスの統一と同時並行で、データ基盤についても統一することになるはずです。その際には、今以上に全社員がさまざまな事業データを適切な権限で閲覧できる、可視化された環境を実現したいと考えています。
その一方で消費者目線では、「クラシル」や「クラシル比較」、「クラシルリワード」といった弊社のサービス同士を使用することによるメリットを感じていただけるようなサービス展開をしていきたいですね。たとえば、「クラシル」で麻婆豆腐のレシピ動画を見ていた際に「クラシルリワード」経由で麻婆豆腐を作るための商品を安く購入できるようになるようなイメージです。こうしたサービス間の垣根を越えた利便性を提供するには、やはりデータの活用がカギになってくると考えています。
張替:今回「TROCCO」を導入したデータの収集とデータ基盤への転送は、データ利活用において最優先で取り組むべき部分だと思います。そして、取り組む際のスピードも重要です。
データの利活用はビジネスサイドからはなかなか見えにくいため、データが利活用できる環境を整えることに時間がかかってしまえば、誰もデータに期待しなくなってしまうかもしれません。そうならないためにも、データエンジニアがひとりしかいない状況こそ「TROCCO」の導入は最優先で取り組むべきだと、考えています。
dely株式会社
業種 | IT業界 |
---|---|
設立 | 2014年4月 |
従業員数 | 230名 (※アルバイト含む) |
事業内容 | 【企画・運営・開発】レシピ動画プラットフォーム「クラシル」、お買い物サポートアプリ「クラシルリワード」、人材紹介サービス「クラシルジョブ」、商品比較サービス「クラシル比較」、ライフスタイルメディア「TRILL」、ライバーマネジメント事務所「LIVEwith」 |