23卒エンジニア職内定者の稲葉です。2022年10月から3ヶ月間、AI事業本部小売DXディビジョンのアプリ運用センターでアルバイトをさせていただきました。私は、今までデータサイエンティストやバックエンドエンジニアなど幅広く技術に関わってきましたが、今回はアナリティクスエンジニアとしてデータ基盤の改修を行いました。
本稿では、Snowflake上で構築されているデータ分析基盤を dbtやgithub actionsのCI/CDを用いて改修を行った経験をレポートにしてまとめます。

アプリ運用センターとは

サイバーエージェントでは現在、小売/行政/医療などのドメインにおいて様々な企業様と提携し開発を行うDX事業に取り組んでいます。アプリ運用センター（通称アプ運）はその中でも小売事業を展開されている企業様向けにアプリ開発/データ基盤構築をはじめとした開発から運用、コンサルティングなどを行う事業部です。POSシステムやAIカメラ、ビーコンなどの多岐にわたるテクノロジーを連携し、アプリ単体ではなく購買体験全体のUXを高めるアプリ開発を実現して行きます。（詳しくはこちらでご確認ください）

取り組んだことと目的

今回のインターンでは、小売店における購買やアプリ行動ログを集約するデータ基盤にdbtとCI/CDの導入を行いました。dbtとCI/CDを導入することで、データに対する継続的な信頼性を担保することやgithub, ER図と実際に動作しているコードの同期をとることでデータ基盤内を整備することを目的としています。

dbtとは？

dbtとは、ELTデータパイプラインのTの部分を担っているツールで、既にデータがロードされている状態で、データを分析者が利用しやすい形に加工・変形することができます。また、select文だけで テーブル や ビューを作成することが可能で、データエンジニア以外でもテーブルやビューを簡単に作成し分析に活用できるメリットもあります。

dbt導入でのシステム構成とデータ基盤管理について

dbtには、有償のdbt cloud とdbt cli の2つがあり、それぞれ下記のようなメリット・デメリットが存在します。

今回は、dbt cloudとcliの両方を導入し役割を分担する環境を整備しました。データの定期更新については、諸事情でワークフローエンジンを使いにくい状態にあったため、dbt cloudを使用しました。一方、データサイエンティストが頻繁に作成するようなクエリのコード管理については、dbt cliを使用しました。この後、データベース内の構造を簡単に紹介した後に、データベース内で管理する役割、dbt cloudとcli 両方を導入するメリットの詳細を説明します。

データベース内の構造

データベース内は、 rawデータを扱うDataLake層、rawデータをリキャストしたデータやそれらから作成された1次集約を扱うDWH層、特定のビジネスKPIをはじめとしたBIツール等で可視化するために集計処理をしたテーブルやビューを扱うMarts層の３層構造になっています。これらに加え、自由な分析環境を提案するためのSandboxが別に設定してあります。

dbt cloud, cliを両方導入するメリットとそれぞれの役割

dbt cloudでは、定期実行処理の管理を行うだけでいいDataLake、DWH、Martsを管理し、dbt cliではデータサイエンティストが自由なモデリングを行うSandboxを管理しています。それぞれ、dbt cloudの運用はロール権限が高いデータエンジニアが担い、dbt cliは誰でも自由に利用できるような構成になっています。
このようにdbt cloud, cli 両方を導入し開発環境を分離することで、dbt cloudを利用する人数を絞ることができ、金銭的コストを抑えられるといったメリットがあります。またロール権限を dbt cloudとcliで分離することもできるので、Sandboxに変更を加えてもdbt cloudの管理している領域には影響がありません。そのため、間違えてデータを消してしまったなどの事故を事前に防げるので、安全な開発環境を整備できるといったメリットもあります。

dbt cloud × snowflake × CI/CD

現状、github上でコードを管理しているが実際に動作しているコードはsnowflakeで実行して変更を反映しているため、正確にgithub上のコードと実際に動作しているコードの同期が取れていないという課題があります。この問題から生じる弊害としては、以下があげられます。

• snowflake上のコードに変更を加える際の信頼性の低下
• 動作しているテーブル、ビューの正当性の欠如

また、上記に付随しdbtとCI/CDを組み合わせて導入することにより、dbtのtestを実施できることやレビュー体制を整えることができ、データの正常性を十分に担保した状態でsnowflakeに反映させることが可能になります。具体的にCI/CDが動作するのは、以下の2つのタイミングです。

1. プルリクエストが作成されたタイミング
2. それらのプルリクエストがmainブランチに merge されたタイミング

1. プルリクエストが作成されたタイミングでの CI/CD

プルリクエストが作成されたタイミングでは、以下の3つの動作を行います。

• dbtに対応したsql formatterでのformat check
• ステージング環境へのdeploy
• deployされたデータに対するテスト

また、プルリクエスト作成時にステージング環境でのテストを行う主な目的としては以下の3つです。

• 本番環境のデータ/構成で本番環境を破壊する心配なくテストができる
• テストをすることでデータの信頼性を確認できる
• 実際に動作させることで、それらの動作結果がレビュアーの補助になる

ステージング環境への本番環境データのcopyには snowflakeのzero clone copyを利用します。zero clone copy はデータの複製は行わないため、時間や容量を節約してデータの信頼性を担保することが可能になります。

2. プルリクエストがmergeされたタイミングでのCI/CD

プルリクエストがmergeされる直前にもCI/CDと同じ動作を実行します。これらの動作を2度行う理由としては、プルリクエストがmergeされる直前の変更により生じたバグをmainに取り込まないためです。最終的に問題があった場合は、mainにmergeされませんが、なかった場合はmainにmergeされsnowflake上の本番環境に変更が反映されます。

実際にCI/CDを導入したときの課題

実際にCI/CDを導入すると1次集約を作成するために膨大な量のデータをフルスキャンするため、プルリクエスト時とmerge時のCI/CDの実行時間が合計で4時間程度かかってしまうという課題がありました。
今回 導入するCI/CDの主な役割としては、過去から現在までのデータ全てに対する品質担保ではなく、クエリが想定した通りの出力をしているのかどうか？を確認することです。そのため、実際に用いる1次集約を作成するためのデータは、直近1週間程度に絞りました。このようにすることで、CI/CDの実行時間を大幅に短縮しつつ、直近のデータのみでクエリ出力が想定通りか判断することが可能になります。

内定者バイトを通して

1. 実運用を想定した設計・検証の重要性

内定者バイト期間で学んだ一番のことは実運用を想定した設計・検証の重要性です。現状、タスク間の依存関係をワークフローエンジンで管理しているわけではなく、定期実行で管理しています。その中でデータの連携漏れがないか、またデータを変換する上で制約条件を満たしているかなど本番環境と同様の環境で検証を実施していかないと実運用を想定した設計にはなりません。そのため、それらを意識しつつ制約条件の洗い出しをドキュメントにまとめ検証していきました。実運用を想定し続けることは考える項目がとても多く難しかったのですが、信頼できるデータからユーザごとに最適化されたクーポン配布やプッシュ通知、UI/UXの改善などを行うためにとても重要だったと感じています。

2. 小売DXでの運用・施策をするための分析力や知識の広がり

私のチームでは分析を共有するタイミングが多くあり、専門的な知識を有するメンバーが積極的に自身の分析結果を発表している環境でした。 また、今回の業務ではデータ基盤の改善を中心に行っていましたが、A/Bテストや経済学的なアプローチ・統計的手法を利用しながら分析する技術に触れる時間が豊富にありました。施策を行った上での効果検証の重要性に関して知ることができ、小売における分析知識向上につながったと思います。

3. 小売DXの魅力

今回のインターンでは、小売に関するデータに触れる貴重な機会を得られました。小売のデータは、主にアプリのデータと実店舗から得られるデータの２種類があり、それら両視点から売り上げを伸ばすための施策を考えていくことが重要になります。データ基盤やデータ分析の業務を通して、小売DXが持つデータの特異性や応用の可能性を知ることができ、小売DXに携わる面白さを感じたとともに小売DXの醍醐味はここだなと感じました。

最後に

今回の内定者バイトでは、多くの方との繋がりを持てたとともに、協力していただきながら データ基盤の整備を進めることができました。また今回は、同じ部署でデータエンジニアとして働いている千葉さんにたくさんのレビューをいただきました。千葉さんのCA Base Next での発表も非常に面白いのでぜひこちらもご覧ください！

充実した内定者バイトの3ヶ月間はあっという間でとても楽しかったです。
メンターである河中さんをはじめ、協力してくださった方々ありがとうございました！

今年の4月から、新卒としてAI事業本部 アプリ運用センターにてバックエンドエンジニアとしてジョインした坂上一仁です。

AI事業本部に配属され、3ヶ月が経過しました。

サイバーエージェントでは入社前に実際に社内にて就業を行い、自分自身との適性を確かめる「内定者アルバイト」と呼ばれる制度があり

私は2021年12月から現在就業しているアプリ運用センターにて内定者アルバイトをしていました。

今回の記事では、内定者アルバイトを経て配属された、AI事業本部およびアプリ運用センター(通称: アプ運)について

内定者アルバイトで経験できたことや、入社後に感じた 魅力・特徴などについて紹介させていただきます!!

アプリ運用センターとは?

サイバーエージェントでは現在、小売/行政/医療などのドメインに置いて様々な企業様と提携し開発を行うDX事業に取り組んでいます。

アプリ運用センターはその中でも、家電量販店・ドラッグストア・コンビニ・大型スーパーなどの小売事業を展開されている企業様向けにアプリ開発/データ基盤構築をはじめとした開発を行う事業部です。

私は現在、小売店のお買い物アプリ(会員証・クーポンを提示するための、実店舗で使用するアプリ)を作っています。

小売業界のデータ活用は、海外ではwalmartなど先進的な事例が多く生み出されている一方で国内ではまだ距離がある状況です。

その中で私達はクライアント様の意向をヒアリングし、実際のアプリで様々な機能を実現するだけでなく

これまでサイバーエージェントが培ってきたtoCアプリ開発の経験/強みを生かしたUI/UXデザイン・データ基盤活用を提案することで業界全体に新たな事例を創出することを目指しています。

上記のような小売業界の開発プロジェクトについては、私の先輩に当たる黒崎 優太さんが去年の若手カンファレンス、CA BASE NEXTで発表されていました。

動画のアーカイブも残っていますので、是非御覧ください！

内定者アルバイトの雰囲気など

私はそんなアプリ運用センターの中でも、2021年12月から2022年3月まで大手ドラッグストア様向けのアプリ開発チームで内定者アルバイトをしました。

サイバーエージェントでは現在、非常に多くの部署が存在しており内定者アルバイトの受け入れ先でも7~8個ほどの事業部・30を超えるプロダクトに分かれています。

自分が内定者アルバイトに求めていたものとしては、

「タスク単位で仕事を渡されるのではなく、ミッションの中で自分自身の頭で『どうやってそれを解決するか？』を考えることができる」

「組織自体が新しく、部署自体の成長角度が高い」

という2点でした。

上記2軸で内定者アルバイトをするチームを選んでいたところ、

アプリ運用センターは2019年設立の組織ながら急拡大しており、事業の特色上、課題解決への意識が強い人材を求めているという説明を受け

働く環境として申し分ないのではないかと考え、内定者アルバイトをさせていただきました!

(他にも、私は法人営業としてインターンをした経験があり、クライアントに対して提案を行った経験が将来的に活かせる場面がありそうと感じました)

内定者アルバイト中にやったこと

内定者アルバイト中にやったことは大きく3点です。

1. 各プロダクトにおける機能開発プロジェクト内での開発
2. ユーザーの行動ログ設計
3. CI/CDやTerraformなどの基盤改修

1. 各プロジェクト内での開発では、単純にビジネス職が考えた要件だけを開発するのではなく、

実際に「何を作るか」「どのような順番で作るか」といったミーティングにも参加させていただきました。

これが事前に自分が考えていた「自分自身の頭で『どうやってそれを解決するか？』を考えることができる」という点に非常にマッチしており、

またビジネス職/デザイナー職など他職種の方と上記のような内容を話し合う体験自体が非常に新鮮で面白いと感じることができました！

2. ユーザーの行動ログ設計は、小売アプリの骨子とも呼べる部分であり貴重な体験をさせていただきました。

実開発内容に関わるため詳細は伏せますが、アナログな世界で買い物をするお客様の行動をどのようにアプリ上で記録/活用するかということを考える経験は非常に興味深く、

オンライン上/アプリ内のみで完結する開発よりも考えることが多く大変だった一方で面白い経験だったと思います！

3. CI/CDやTerraformなどの基盤改修についても、これまでやったことがなかった技術領域にトライできたという点で技術的知見を深めることができました。

また、私のトレーナーでもあった後藤 紳さんは新卒2年目から開発責任者を務めており、エンジニアリングマネジメントの知見が豊富な方です。

※後藤さんの紹介記事はこちら

私自身もエンジニアリング・マネジメントに興味があったので、内定者アルバイト中からアジャイル/スクラムの本をいくつか紹介していただきインプットを行うことができました。

こうした各タスクやインプットを通して、プロダクト・プロジェクト・バックエンド設計それぞれの観点において品質そのものを考えることができたように思います。

自分の同期にも、純粋に技術が好きな人もいればコードのその先にあるビジネスインパクトに興味がある人もいますが

アプリ運用センターはより後者のような方に適正があり、同時にエンジニア職でもビジネスインパクトを意識した行動が求められる環境です!

余談ですが、フリードリンク・カロリーメイトあるのもよきです!

アプリ運用センターの魅力

上記のように、内定者アルバイトの経験を経たアプリ運用センターの魅力を書いてきました。

その上で「アプリ運用センターの魅力」を一つ上げるとすれば、「同じ組織にいる方の熱量」だと思っています！

アプリ運用センター内には、各プロジェクトにエンジニア職・ビジネス職が在籍しており、また横断組織「DX Design室」には各プロジェクトを横断してデザインを管理するデザイナー職の方がいらっしゃいます。

職種問わず非常に熱量が高いメンバーがいて、なおかつ職種問わず対等に議論することができるというのは非常に魅力的な点だと思います。

またそれと同じくらい魅力的なのが、「事業自体のスケールの大きさ」です。

具体的な内容はこちらには記載できないのですが、小売DX事業部では「140兆円市場を、再発明する。」というスローガンの通り、非常に大きな規模の事業を扱っています。

私自身、内定者アルバイトで入ってから始めて「サイバーエージェントって、こんな大きな仕事してるの…!?」と知ったことがいくつもあり、

これまで私が見てきた視座がいかに矮小なものであったかを痛感させらされました。

内定者バイトを経て入社してから3ヶ月、まだ開発チームや機能開発を主導できるように試行錯誤を重ねている段階ですが、

「周りの熱量の高さ」「事業のスケールの大きさ」の2点から、いずれはもっと大きな領域で、大きな仕事をしたいといつも思わされています。

(そういう意識が自然と焚き付けられる組織な気がしてます)

22卒では7名のメンバーが配属され、改めて急成長中の組織であると感じました!

さいごに

内定者アルバイトを経て入社した経験から、アプリ運用センターという部署について書かせていただきました。

上記のように書くと、いい点ばかりで完成した組織のように受け取られる方もいるかも知れませんが

アプリ運用センターはまだまだ急拡大している組織で、コードも体制も日々発展中です!

まだまだ技術力をビジネスインパクトに変えられる方(あるいは、そうなりたいと思っている方)のチカラが必要です。

下記サイトから面談も受け付けておりますので、是非お待ちしております！

（サイバーエージェントの内定者の方は、採用人事までご連絡ください）

スクランブルスクエアで一緒に働きましょう!

サイバーエージェント 23年度エンジニアコース新卒採用ページはこちら

24卒の方向けインターン情報/第二新卒の方向け選考情報はこちら

小売DX 採用サイト(中途の方向け)はこちら

サイバーエージェント 小売DXチームnoteはこちら

初めまして、22卒エンジニア職内定者の松岡穂高と申します。

2021年6月1日から3ヶ月間、サイバーエージェントのAI事業本部にあるAirTrackという部署で、サーバーサイドの内定者アルバイトをさせていただきました。

今回は振り返りの意味も兼ねて、取り組んだ内容と学んだ事や知見について書き記したいと思います。

AirTrackとは

AirTrackとはAI事業本部の小売DX本部に位置し、スマートフォン端末から取得できる位置情報を活用し来店計測や広告配信を行うサービスを展開しているプロダクトです。位置情報を使って顧客属性を推測しターゲティングを行なっており、「人を動かす広告をつくる」ことを目指しています。

今回は、DSPと呼ばれる広告主向けの広告配信プラットフォームの開発に携わりました。DSP及びアドテクに関する詳しい解説はこちらの記事に書かれています。興味のある方はぜひご覧ください。

今回の目標

まず、今回AirTrackで働くにあたって成し遂げたいことは以下でした。

• 大規模なデータを扱い、パフォーマンスチューニングができるようになりたい
• 何かしらのビジネスインパクトを与えたい

学生レベルでは、どうしても事業目線で開発・運用を行う機会はないので、この内定者アルバイトではできる限り社員の方々と同じような視座を持つことを意識して取り組みました。

開発言語に関しては自分自身、特にこだわりはなく、プロダクトに適した言語を選定し利用できるのが望ましいと考えています。理由としては、サーバーサイドの言語はトレンドが激しく、現在使用している言語が必ずしも将来のデファクトスタンダードであり続けるとは限らないからです。そのため、一つの言語に固執したくない、今まで触れてこなかった技術にも触りたいと思い、Scalaでのサーバーサイドやインフラレイヤーの実装に挑戦しました。

AirTrackで行ったこと

今回私がメインとして行ったことは、既存の広告ログ集計のシステム基盤をSnowflakeに移行するというタスクでした。SnowflakeとはSnowflake社が提供するクラウド型データウェアハウスです。この移行によって、運用コストの削減、集計プロセスの安定化、より信頼性の高いモニタリングや精度の高いCTR予測が可能になり、もともと私が成し遂げたかった「大規模データを触りたい」「ビジネスインパクトを与えたい」という目標が達成できると考えました。テーブルの移行自体はクエリを書くだけで簡単でしたが、移行したテーブルが元のテーブルと同等の内容になっているか（join や where などの集計処理が等しいものになっているか）という精度の評価で苦戦し自身の成長にもつながる部分でした。この検証の部分に力を入れていたのでこのブログで紹介していきます。

精度検証と評価

まずは、試験的にSnowflakeで新しいテーブルを作成し、既存のものと同等の精度であるかを検証します。両者のテーブルから8月の1ヶ月間でデータを絞り込み、1日ごとにグループ化します。そして、既存テーブルと今回作成した新規テーブルから日ごとのidの数を算出し、抽出したcount数から両者の差分の割合を算出します。

WITH new AS (
  SELECT
    DATE_TRUNC(DAY, requested_at) AS date, 
    COUNT(id) AS count
  FROM
    new_table_log
  WHERE
   requested_at BETWEEN '2021-08-01' AND '2021-09-01'
  GROUP BY 1 
  ORDER BY 1
), 
old AS (
  SELECT 
    DATE_TRUNC(DAY, requested_at) AS date, 
    COUNT(id) AS count 
  FROM
    old_table_log
  WHERE 
   requested_at BETWEEN '2021-08-01' AND '2021-09-01'
  GROUP BY 1 
  ORDER BY 1
) 
SELECT
  old.date, 
  old.count AS old_count, 
  new.count AS new_count, 
  new_count / old_count AS rate,
  new_count - old_count AS difference
FROM 
  new 
  FULL OUTER JOIN old ON new.date = old.date 
ORDER BY 1
;

以下は、SnowsightというSnowflakeのデータ結果をグラフで可視化するツールを使用し、検証結果をグラフ化したものになります。この結果から、ほとんどの差分率が1.0に近い範囲に収まり、既存のデータと新しく作成したデータがほとんど一致している事が示されました。

新旧のレコード数の差分率を表したグラフ（8月）

実装

検証結果を評価した後は実装に入ります。試験的に作成したクエリが先程の検証で精度的に適正であることが証明されたので、これを定常的に作動させます。今回は、CloudWatch Eventsで定刻になればECSタスクを実行するようにしました。また、インフラ構築はAWS CDKを用いてクラウドアプリケーションリソースを定義しました。

学び

技術力も含めて設計力の大切さ

まず何よりもこの内定者アルバイトで学んだことは、設計の大切さです。AirTrackに来てまず驚いたことは、要件定義・システム設計のドキュメントの多さでした。私自身、これまでシステム設計を行わずに最初から実装ということが多々あったため、設計に対するスキルは皆無でした。実際に設計のレビューを社員の方々に見てもらい、改めて認識の齟齬があったり、より効率的で効果的な実装方法を提案してくださったりしていただきました。実現したい事を達成するために、どのような技術を用いて、どのように課題解決へとアプローチするかという方法を考え、文書に落とし込むことは簡単そうに見えてとても難しかったです。

仮説検証の重要性

次に学んだことは、仮説検証の大切さです。実装したものが果たして、どのような効果をもたらし、何がボトルネックであるかを明確にする必要がありました。

今回は特にSQLを使ってデータを集計することがメインでした。既存のものと刷新したデータベーステーブルを比較し、レコード数やデータの欠損率を計測。そして仮説検証を行い原因追求の繰り返し行う。そのようにして課題解決を行なっていくという経験ができたのは、私自身にとって大きな成果だと思います。少ないデータ量であれば、数字を出さなくとも、実際目で見て比較すれば良い話ですが、億を超えるレコード数を扱うため、欲しい結果を得るためのクエリを書くことは難しかったです。大規模なデータを扱えるのはとても楽しく、広告事業ならではの醍醐味だと感じました。

さいごに

このメインのタスク以外にも、サーバーサイドの開発ではScalaに挑戦しました。関数型言語は扱ったことがなく、慣れない概念が多くて難しかったですが、エンジニアとしてのレベルをより一層高めることができたと思います。また、個人開発ではなかなか使用する機会がないAWSのサービスを扱えたのも貴重な経験だと思います。

今回は、私自身初めて内定者アルバイトをさせていただきました。参画当初はとても不安でチームの力になれるか心配でしたが、AirTrackの皆さんはとても優しく働きやすい環境でした。また、わからない質問に対しては自分の成長を考えた受け答えをしていただきとても学びになりました。しっかりアウトプットを出せたのも、自分一人の力ではなくメンターさんや先輩の社員の方々のおかげであり、とても感謝しています。そして、この3ヶ月で身につけたことや学んだことはこれからも活かして自分の成長に繋げたいと思います。短い間でしたがお世話になりました。本当にありがとうございました。