株式会社CARTA ZEROでは、広告配信プラットフォーム（DSP: Demand Side Platform）のデータ分析基盤としてSnowflakeを利用しています。従来より、標準ダッシュボード機能におけるクエリ負荷の問題や、個人のローカル環境で行うJupyter Notebook分析の属人化といった課題を抱えていました。

今回は、同社のデータサイエンスエンジニアである榊原さんにインタビューを実施。Codatum導入により、いかにして複雑な分析プロセスの透明性を高め、専任不在の中でMLOpsの代用となる監視体制まで構築したのか。具体的な活用事例についてお話を伺いました。

「課題発見から解決まで」を一気通貫で行うエンジニア文化

――まずは、榊原さんの現在の役割とチームのミッションについて教えていただけますか。

榊原さん： 私はCARTA ZEROにおいて、主に自社プロダクトであるDSPの開発チームに所属しています。私たちのチームの特徴として、特定の役割に固定されるのではなく、個々のエンジニアが「課題を発見し、それを解く」というスタイルを重視している点が挙げられます。私自身の役割としては、プロダクトに対する機械学習やデータ分析といった広範囲な分野から自ら課題を発見し、分析して解決するというサイクルを回すことが仕事です。

チーム全体のミッションは、最終的には売上の最大化です。これには二つの側面があり、一つはインフラコストやメディアへの広告掲載費用を下げること。もう一つは、広告配信のロジックやアルゴリズムを改善して広告効果を高めることです。デジタル広告配信では配信ごとにオークションを行っており、その中で、DSPは広告主の広告在庫をSSP（Supply Side Platform）経由でメディアに向けて配信する役割を担っています。

DSPはメディアが持つ広告掲載枠に対し、オークション入札によって広告掲載権を獲得する必要があります。このため、広告配信権を得るための入札価格はDSPにおける営業利益に大きな影響を与えます。入札戦略やその最適化ロジックによって、メディアに支払う広告掲載料の金額や広告主のマーケティングにおいて最適な枠の購入アルゴリズムが変わってきます。そうした要素を最適化し、コストを下げつつ効果を上げ、顧客予算を増やしていただくことで売上に貢献することを目指しています。

――そのミッションの中で、データ分析はどのような位置づけになるのでしょうか。

榊原さん： 我々は「データサイエンスエンジニア」という肩書きで仕事をしていますが、データサイエンスという行為は分析に始まり分析に終わります。例えば、「プロダクトにこういう課題があるのではないか」という仮説に対し、まずはデータを見てその問題が実際に発生しているのかを確認します。次にその原因を特定し、解決策のアプローチを考えます。そしてABテストを行い、その結果を可視化して評価します。このようなフロー全体においてデータ分析は不可欠です。

また、弊社のエンジニア文化として「一つの課題に対し、一人が責任を持って取り組む」という、フルサイクルエンジニアリングと呼ばれる考え方があります。そのため、基本的にはデータサイエンスエンジニア一人で分析フローを回すことが多いですが、一人だけではできない意思決定が必要な場面では、PdMや他のエンジニアにデータを提示してコミュニケーションを取ることも多いです。

（榊原さん）

構造化して管理できない不便さや、分析の属人化が課題に

――Codatumを導入する前、データ分析においてどのような課題を感じていましたか？

榊原さん： 当時は別ツールのダッシュボード機能を使っていました。最低限の可視化はできるものの機能がリッチではなく、「一つのグラフを描画するのに一つのクエリが必要」という制約がありました。

例えば、ABテストの結果を確認する際、AグループとBグループの各メトリクスの増減比率や時系列推移など、様々な指標を見たい場合があります。しかし、グラフの数だけそこそこ重いクエリを走らせることになり、負荷やコストの面で課題がありました。また、クエリを構造化して管理することが難しく、少し複雑な分析や人を巻き込んだ共有を行いたい時に不便さを感じていました。

――ダッシュボードで対応できない分析は、どのように行っていたのですか？

榊原さん： 日常的なモニタリング以外で、より詳細な分析や多角的な分析が必要な場合は、各エンジニアが手元のJupyter NotebookでPythonコードを書いて分析していました。Jupyter Notebookは可視化の自由度が高く、LLMを活用すればマンパワーがなくても望んだコードが書けるため、何でもできる点はメリットです。

しかし、分析がアドホックになり、属人化してしまう懸念があります。GitHubで管理しようとしても、コードと実行結果が混在するノートブック形式はレビューが難しく、結局「誰も把握していない分析」が生まれてしまう状態でした。また、環境構築の手間や、データを見るまでのタイムラグも課題に感じていました。

ワークフロー機能で、監視体制もスムーズに構築

――そこでCodatumの導入に至ったわけですね。導入の決め手は何だったのでしょうか。

榊原さん： 最初のきっかけは社内の別の方からの紹介でした。PoC期間を経て導入を決めたのですが、最大の決め手は、我々が抱えていた課題に対して機能が必要十分であったことが大きいです。

具体的には、既存ダッシュボードツールの代替として、構造化されたドキュメント管理ができる点や、クエリの負荷問題を解決できる点です。また、Notebookのように段階的にクエリを書いていけるため、CTE（共通テーブル式）を多用するような複雑なクエリでも、何をしているかが分かりやすく、レビューがしやすいという利点もありました。

――他社のツールとも比較検討されたのでしょうか。

榊原さん： はい、チームメンバーが海外ツールなどを比較検討しました。Notebook形式で機能的には近いプロダクトもありましたが、当時のチーム規模や今後の拡大を考えると、ユーザーごとの課金体系がネックになりました。

我々としては、分析情報をオープンにして多くのメンバーに見せたい一方で、コストがかさむのは避けたく、Codatumはそのあたりのバランスや料金体系が私たちのニーズに合致していましたね。

――実際に導入されてみて、特に気に入っている機能はありますか。

榊原さん： 個人的に特に良いと思っているのがワークフロー機能です。最近MLOpsに工数を避けるメンバーが減ってしまい、モデルの監視周りが手薄になりがちだという課題感を持っていました。Codatumのワークフロー機能を使えば、普段分析しているプラットフォーム上でそのまま定期実行を設定し、Slackにアラートやデータを通知する仕組みが簡単に作れます。分析業務の延長線上で監視体制を構築できるのは、非常にやりやすいと感じています。

また、ユーザー体験の改善に力を入れている点も評価しています。「機能はあるけど使いにくい」というストレスがほとんどなく、直感的に操作できます。フィードバックに対する改善スピードも早く、例えば以前リクエストした「散布図へのラベル表示」などもすぐ実装していただけたので、運用面での安心感があります。

――Snowflakeとの連携についてはいかがですか。

榊原さん： 公式ドキュメント通りに進めれば特に問題なく、非常にスムーズに連携できました。我々はデータウェアハウスとしてSnowflakeを前提としているので、Snowflakeとの連携がうまくいかないと全てが止まってしまいます。中間テーブルのキャッシュ化なども含め、Snowflakeの機能を活かしつつ、体験としてはより良いものになっていると思います。

分析スキルのないメンバーもデータを扱える、直感的な操作性が魅力

――導入後、業務の流れやチーム内での変化はありましたか。

榊原さん： 私個人としては、これまでローカルのJupyter Notebookでやっていた分析の多くをCodatum上のNotebookで行うようになりました。ローカル環境の構築や管理の手間がなくなり、ブラウザ上で手軽に分析を始められるため、分析に対する心理的なハードルが下がりました。

初期分析や全体感の把握などはCodatumで行い、そこで作ったクエリをそのままダッシュボードに転用するといった使い方ができています。また、同じツール上で分析してダッシュボードを見に行くことができるため、ツール間のスイッチングコストや「あのデータどこだっけ？」という迷いがなくなりましたね。

――チーム内での共有についてはどうでしょう？

榊原さん： 権限管理の面で非常に助かっています。例えば、以前のツールではアカウントを持っていないPdMなどにデータを見せたい場合、スクリーンショットを撮って送るなどの対応が必要でした。

Codatumのレポート機能を使えば、メールアドレス招待でそのページだけを共有できるため、今まで共有できていなかったステークホルダーにもスムーズにデータを届けることができるようになりました。これにより、「誰が見られるんだっけ？」といった細かなコミュニケーションコストや不安が解消されたと感じています。

――エンジニア以外のメンバーもCodatumを使われているのでしょうか？

榊原さん：メインのチームメンバー以外の方もABテストのダッシュボードを利用しています。ソフトウェアエンジニアリングの経験がなく、ローカルNotebook環境を構築して分析するのはハードルが高い方は、以前はエンジニアを通じてデータを見ていました。

しかし、Codatumであれば直感的に操作でき、SQLを書けなくてもダッシュボードを触れるので、データを見るためのエンジニアリングスキルがないメンバーでもデータを扱えるようになりました。これはチームとして大きなメリットです。

Codatumはとにかく「まず使ってみてほしい」

――今後、Codatumをどのように活用していきたいですか？

榊原さん： まだ活用しきれていない部分として、AIアシスタント機能の活用があります。現在はプロンプトを工夫してSlackに通知するテキストを整形する程度ですが、もっとリッチな表現や分析の補助として使えるようになるといいなと思っています。例えば、クエリ結果の表をデフォルトでLLMに渡して解釈させたり、ワークフローの結果をより見やすい形でSlackに流したりといった部分ですね。

――機能面でのリクエストはありますか？

榊原さん： 細かい点ですが、ワークフロー作成時のクエリの自動保存機能はぜひお願いしたいです。あとはSlack連携において、チャートや表を画像として直接飛ばせるようになると嬉しいです。これについてはベータ版機能をご案内いただいたので、早速試してみたいですね。

また、ワークフローからクエリのパラメータを指定できるとさらに嬉しいです。1時間前の実行結果と直近の結果を比較するような動的な分析ができるようになると、活用の幅が広がると考えています。

――最後に、Codatumの導入を検討されている企業に向けてメッセージをお願いします。

榊原さん： 一言で言うなら、「まず使ってみてほしい」ですね。Codatumの良さは、特定の機能というよりも、全体のまとまりや使用感にあります。これは実際に触ってみないと分からない部分が多いです。サポートも手厚く、トライアル期間もしっかり対応してくださるので、まずは使ってみて、その直感的な操作性やチームでの共有のしやすさを体験してみるのが一番だと思います。

――本日は貴重なお話をありがとうございました！