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ヶ月で身につけたことや学んだことはこれからも活かして自分の成長に繋げたいと思います。短い間でしたがお世話になりました。本当にありがとうございました。

今回はAIR TRACKというプロダクトにて内定者アルバイトをしていた七海くんが

ブログを執筆してくれました！ぜひ一読ください！

↓↓↓

はじめまして、2020卒エンジニア職内定者の七海と申します！

CyberAgentのAI事業本部にあるAIR TRACKというプロダクトチームで約1ヶ月半の間、

サーバーサイドエンジニアとして内定者アルバイトをしていました。

内定者アルバイトとして学生エンジニアが１ヶ月半働いた結果、

 ” スクスク ” で “ すくすく ” 成長した話を共有したいと思います！

少し長くなってしまいますが、内定者アルバイトや長期インターンに興味がある方は、ぜひ読んでみてください！

( スクスク = 渋谷スクランブルスクエアです… )

我ながらいい写真だ・・・

1ヶ月半働いて何が成長したのか

結論から書きます！

下記が僕がこの１ヶ月半の学びです！

• 未経験のScalaを”完全”に理解 (完全に…^ ^)
• 拡張性を考えた実装
• レビュアーを意識したプルリク，コミット
• テストの重要性
• スクラム開発の流れ

正直，僕の学生人生の1年半ぐらいの成長を凝縮したような1ヶ月半でした。

どうやって、１ヶ月半でこんなに成長したのか、

内定しているのにアルバイトをした理由などを書いていこうと思います！

なんだか、１ヶ月半で太った気が・・・

内定したのにアルバイトするの？

どうなんでしょう？皆さんの周りでは、入社するまでの間に内定先でアルバイトをする文化はありますか？

少なくとも，僕の周りでは内定者アルバイトという言葉はあまり聞かないように感じます。

僕は地方出身なのですが、地方といえど情報系学生は都心への就職がメインです。

でも地方からだと学生は気軽にアルバイトとかできないんですよね・・・。

CyberAgentでは、地方学生がアルバイトやインターンをしやすいように様々なサポートをしています。

詳しくはこちらを見てみてください。

今回、僕が内定者アルバイトをした理由は、”入社前に周りよりも一歩成長したい！” という理由です。

まだ詳しく知らない2020卒新卒の同期たち

ただきっと、めちゃくちゃ強いエンジニアたちがたくさんいることだけは想像できます・・・。

田舎者の僕が、同期と同じスタートを切るには経験値が足らなすぎると感じました。

そこで，入社前に少しでも多くの経験を積んで成長しようということで、

短期間ですが内定者アルバイトとして受け入れてもらいました！

アルバイトが始まるまでの流れ

AIR TRACKとは

今回僕が配属させてもらったAIR TRACKについて少し紹介します。

このサービスは ” 実世界の販売促進のための広告配信プラットフォーム ”です。

メインでは、DSPと呼ばれる広告プラットフォームを開発しています。

DSPをはじめとした広告配信に関わるアドテクノロジーに関しては

こちらに良くまとまっているので、気になる方はぜひご覧ください。

【環境について】

AIR TRACKでアルバイトを進めていく上での環境について紹介します！

• メンターとして２名にメインでサポートしてもらった
• core i7,メモリ16GB,2018年製のMacBook Proを貸してもらった
• モニターも貸してもらえる
• なんかめっちゃいい椅子
• 飲み物の自販機がタダ
• 10時出社19時退社 (残業は無し！！)

正直、かなりストレスフリーで働くことができました。

メンターが会議などで、席を外している場合でもAIR TRACKでは

チームとしてプロダクトの知見が溜まっているため、

他のエンジニアの方に質問すれば大体の問題は解決しました。

また結構こういった開発系のアルバイトでは最初の開発環境の構築にかなり工数が取られることが多いのですが、

” 新しく来た人向けのドキュメント ” がしっかり用意されていたため、

1営業日かからないぐらいで環境を整えることが出来ました。

今までは「ドキュメント書くの面倒だなー」と感じていたのですが、いざ自分がお世話になると、

その重要性に気付かされます・・・これからはしっかり書きます！

分からないことは、すぐにメンターさんに聞いていました！

実務だからこそ成長できること

「今回の1ヶ月半でもっとも成長したスキルは何ですか？」ともし聞かれたら、

確実に「Scalaで実装する力です」と答えます。

でも、言語の成長は配属するチームや、与えてもらうタスクに依存しますし、

僕よりもいい情報源がたくさんあると思うので、ここでは僕がアルバイト期間中にお世話になった、

一冊の紹介のみとして、残りは割愛します。

初学者にオススメの一冊

この本は、バイト開始２日目ぐらいにチームの方にお借りした一冊です。

AIR TRACKだけではなく、Scalaで開発している他のチームのエンジニアの机にも置いてあったので

間違いない一冊だと思います！これからScalaを学びたい方はぜひ読んでみてください。

ここで伝えたい実務でしか学べないと感じたことは、

たくさんありますが最も伝えたいことを下記３点にまとめてみました。

1.実はちゃんと使えていなかったGit

学生エンジニアのみなさん、Gitしっかり使えますか？

僕は、

• 何となくブランチ切れる
• 何となくコミットメッセージ書いてる
• 何となくリベースしてる
• 何となくプルしてマージもできる

だから、何となくGit使って開発できてると思っていました。

実際は結局何となく止まりの使い方だったので、業務でチーム開発をしていたらすぐにボロが出てきました。

小さいものも含めるとたくさんありますが、特に印象に残っている問題が下の２つです。

【問題１：プルリクでかすぎ問題】

この問題に関しては、下の画像をみてもらえたら一目瞭然です。

肥大化したPull Requestの様子

「お前は一つのプルリクでどこまで進むんだ・・・」

普段、[ プルリク → レビュー → 修正 → マージ  ] といった流れで開発する場面が、圧倒的に少なかったんです。

なので、大きなタスクを小さく区切って作っていくといった基礎がついておらず、

自分が作りたいところまで「どりゃ〜」と作ってしまいました。

この問題で辛いのは，もちろんレビューする人ですよね・・・

（ここまで膨らんだプルリクをレビューしていただき本当にありがとうございました泣）

ただ，肥大化したプルリクに気が付いた時，レビューをお願いする側も、

ひじょ〜〜に心苦しいのです(もはや申し訳なさしかない)、

もし、普段あまり気にせずプルリクを出してる方がいましたら、

レビュアーと自分のお互いのために必要な分だけに、小さく区切って出すことを心がけましょう！

【問題２：コミット履歴汚染問題】

コミット履歴って整理しますか？

僕は、今まで自分がしたいだけコミットして、全部そのままマージしてました。

あるとき「プロダクトのコミット履歴」と「自分のコミット履歴」を見比べた時に、

無駄なコミットが多いな〜と感じました。

例えば、「 [fix] getExampleのタイポ修正 」こんなやつとか、

コミットした後にタイポに気がつくことが、たまにあってその都度直してコミットしていたのですが、

このレベルの修正であれば一つ前のコミットに含めるように操作した方が、絶対に履歴は綺麗になります。

言われれば当たり前なことなんですけど、慣れるまでは集中してたり意識してないと結構多発してしまう気がします。

今後の人生では、しっかり気をつけていきたいです！

2.テストの重要性

実はテストが重要になるようなプロダクト開発に今まで携わったことがありませんでした。

普段の僕の開発の流れは、

「ローカルで動いてるし大丈夫！」→　本番デプロイ！　→ エラー発生 → バグ修正 → OK

こんな感じでとりあえずデプロイして、エラー出たら修正するスタンスで開発することが多いのですが、

お客様がいるサービスではもちろんそれは通用しません。

そのためにテストを書いて、事前に期待通りの動きをするか確かめる必要があるのですが、

普段書き慣れていないため、就業中にテストを作成するたびに結構な工数を消費してしてしまいました。

ただ、テストをしっかり通ってデプロイできればその分安心感がありますし、

普段あまり考えないMockを使ったテストコードの作成もできたので、大きな学びになりました。

3.拡張性を考えた 設計 / 実装 ってなんだろう

これは、もちろんこの短期間で学びきれたとは絶対に言い切れません。

ただ、その片鱗に触れることはできたのかなと思います。

設計に関していえば、今回の就業中に僕が触らせてもらっていた場所は、

クリーンアーキテクチャを意識した設計になっている部分でした。

この辺の設計思想的なものはネットにたくさん記事がありますが、

実際にどんなコードを、どのレイヤーに書いたらいいのかを理解することは難しいように感じます。

しかし、実際の現場で作られているコードを読むことで，

なんとなく (本当になんとなく) UsecaseやControllerの書き方や，

Adapterを使った実装の大切さなどが理解できたように思えます。

これは，実際に使いこなしている人のコードを読まないと学べないことだと思うので、

アルバイトなどを通して現場のコードを読ませてもらわないと、学べないことだと改めて感じました。

また、コードを書いている時にも

前提条件が変更された時に、変更するコードの箇所を考えたり、コピペしたら抽象化できそうなど、

少しずつ拡張性を意識した実装を考えられるようになっている実感がありました。

このような成長は、自分のコードに対して真摯にレビューをしてもらうことで少しずつ成長できるものです。

学生の期間にレビューをもらえる機会というものは、正直限りなくゼロに近いので、

このような成長も実務ならではの成長なのではないかと思います。

内定者アルバイトが仕事現場にいる意味

最後になりますが、就業中に僕はよく

「自分は今、時給分の成果をちゃんと出せているのだろうか」

ということを考えていました。調べれば出るのであえて書きませんが、

地方学生からすれば、かなりの時給で働かせてもらえます。

正直、自分が任せてもらっているタスクはチームの誰かが実装すれば一瞬で片付いてしまうようなものだと思います。

自分の今の技術力では、自分が成長するのが精一杯で技術力でチームに大きく貢献するのは難しいと感じた時に、

内定者アルバイトの自分がチームにいる意味について考えるようになりました。

もちろん、こう言ったブログで経験談を書くことも自分にしかできない仕事ですが、

僕は内定者バイトとして、

「少しでも，チームに新鮮な風を吹かせることだ！」

と思いました。(ちょっとエモすぎる気がするけど・・・)

具体的に説明すると、会議中に自分が発言したり、

お昼の時間や業務時間のちょっとした休憩、終業後などに自分が発言することで、

もしかしたらチーム内に今までにない新鮮な意見や雰囲気を出すことができるかもしれないと考えました。

同じチームで動いているとやはりどこか変化のない日々が続くと思うので。

感性的な話になってくるので結果的に達成することができたのかは難しいところです。

実際、会議中に意見しようとしても理解が追いつかなくて

単なる質問で終わってしまったりする場面も多々ありました。

ただ、意識して行動することでチームのメンバーとの距離は一気に近くなった気もしましたし、

何より自分が楽しくなっていきました！

少しでもチームの日々に自分が変化を生むことができていたらいいなと思います。

まとめ

書きたいことが多すぎて、結構長々と書いてしましましたが、伝えたいことは単純に

「学生はCyberAgentで長期インターンや内定者アルバイトを絶対したほうがいいよ！」

ということです。さらにいうと、

「AIR TRACKで長期インターンや内定者アルバイト絶対したほうがいいよ！」

ということです。この記事が少しでもこれから、

学生として実務体験を積みたいと考えている方の助けになると嬉しいです。

読んでいただきありがとうございました！

チーム内成果発表の様子