オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

新卒エンジニアが行った業務を紹介します 〜開発業務と社内勉強会〜

f:id:allabout-techblog:20210329120349p:plain

はじめに

毎年恒例オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒週間2021」を開催します。 今回は、オールアバウトメディア開発部の@chocoがお送りします。

2020年4月に入社し、7月まで研修を受けたあと、メディア開発部の運用チームに所属して業務を行っています。 本記事では実際にどんな業務を行ったのか紹介します。

誰と業務を行っているか

主にコミュニケーションをとるのは、チームのエンジニアです。

編集・企画を担当する社員ともシステムの要件を相談したり一緒に業務を行います。

どんなアプリケーションを触っているのか

既存サービスや社内CMSのメンテナンスが主な担当業務です。 必要に応じて新規ツール開発等も行います。 All Aboutも私のチームの担当サービスです。

どんな業務を行ったのか

社内向け分析ツールの構築

All Aboutの収益はプログラマティック広告に支えられています。

サイトで表示されている広告枠の表示や収益は、広告運用チームの社員が管理をしています。 収益の最大化として、日々広告数字からデータの分析をしています。

今回は、その作業の効率化を図るために収益分析用ツールを実装した時のお話をご紹介したいと思います。

開発以前では、Google Ad ManagerからレポートダウンロードしてExcelでフィルタをかけて分析したいデータを見ていました。 分析をする度にレポートをダウンロードして作業を行うのではなく、自動でデータが入り分析ができるツールが欲しいというのが広告チームから要望でした。

大まかな要件としては、以下のようなものがありました。

  • 広告枠ごとに分析ができること
  • CPMやViewable Rateといった収益関連の数値が見れること
  • アクセスしたユーザーのOSがわかること
  • データは毎日更新されて欲しい

システム構成図

実装したシステム構成は以下の通りです。

f:id:allabout-techblog:20210323172825p:plain
集計バッチ システム構成図

主な流れとしては、 バッチでAPIからデータ取得と加工をしてデータベースへ格納、Data StudioからSQLを発行してデータベースからデータを取得します。

使用技術

  • Data Studio: Googleが提供しているBIツールです。Google Analyticsなど様々なリソースを取り込んでWeb画面にデータを簡単に表示することができます。
  • GKE: コンテナ化されたアプリケーションの実行環境として使用します。
  • CronJob: 決められた時間でJobを生成します。Jobがバッチを実行するポッドを生成します。
  • Laravel: 社内で主に使われているPHPフレームワークになります。
  • Cloud SQL: Googleが提供しているクラウドデータベースです。

開発を振り返って

大まかな開発の流れを紹介しながら、振り返りをして見たいと思います。

1.要件定義

広告運用チームのメンバーがどんな数字をどう見たいのかすり合わせをします。

ミーティング中は、普段広告チームが使う専門用語が多く登場します。 先述したCPM広告数字は何で、どういった計算で求められるかといった話を聞きながら要件に落として行きます。

当時、初めて聞く用語が多く把握するのに苦労した記憶があります。

また、広告用語に加えてAll Aboutで出している広告枠はどれくらいあるのかといった社内固有の知識も必要でした。 技術的な視点とそういったビジネス側の知識が、開発に必要なことを学びました。

2.インフラ・アプリ設計と見積もり

アプリはどの環境で動かすのか、工数はどのくらいになるのかメンバーと見積もりをします。 オールアバウトでは、クラウドインフラをSREチームが管理しています。SREチームに依頼する必要があるタスクの洗い出しもここで行います。 どういった工程が必要か、感覚が掴めずこのフェーズはチームメンバーに決めてもらった部分が多くありました。

3.実装

基本的に実装はペアプロかモブプロでした。 組んでいたロジックが破綻して、私が崩れ落ちそうになったのをペアプロしていた先輩が解決策を見つけてくれたのをよく覚えています... PRでもレビューを受けますが、コードを書きながら仕様に漏れがないかお互いに点検できていたという点で良い進め方ができたと思います。 またAPIから取得したデータの単位がマイクロ円(100万倍した桁)だったり、実装フェーズはやはり記憶に残っていることが多いです。

設計の面だと、このクラスはどこに実装するのが適切か、といった設計の部分で先輩エンジニアと頻繁に意見交換しながら進めました。 個人開発のように自分だけで開発する時はレビューを受けることがないので、多くのフィードバックをもらえたのは嬉しい経験でした。 サービス層・モデル層で何を処理するのか、徐々に先輩エンジニアと認識があって質問、実装でトライができた時成長できている実感を持てました。

また、保守性の高いアプリにするために、妥協せずにレビューを受けずに進めていく反面、 締め切りから逆算して、もらったレビューを採用しない判断も必要になっていくことを学びました。

4.結合テスト

成果物に対して要件を満たしているか、バグがないかテストします。

今回の場合、バッチでCloud SQLへ格納したデータを、Data Studioから取得するようにします。 要件にあったデータが表示されているか確認するために、用意しておいたテストケースを元にData Studioの画面を操作します。

5.リリース

実装・テストが終わったあとはいよいよリリースです。

リリース後、広告チームで実際に使用されて便利になったという話を聞いた時はやはり嬉しかったです。

技術的につまずいた話

開発中につまずいて、知見になった話を少しだけ紹介したいと思います。

今回の実装では、GKEにデプロイされたLaravelアプリケーションに、あらかじめ定義したartisanコマンドをCronJobを使って定期実行するように実装を行いました。 実装したartisanコマンドは、オプションに日付を渡すことで取得するデータの範囲を指定することができる作りにしていました。 そのため再実行する際には、ターミナルからコマンドを打つ時に日付を渡してJobを生成する想定でした。 しかしJobをコマンドで生成する時に、オプションを渡す方法がわかりませんでした。 残念ながら、コマンド打っての再実行方法は見つけることができませんでしたが、以下に設定ファイルの一部を紹介します。

cronjob.yaml(一部)

command: ["/bin/sh", "-c"]
    args: ["php artisan `実行コマンド` {date}] // Laravelで実装されるコマンド 引数に日付を渡す

Jobをコマンドから生成したい場合には、下記のようなコマンドを使用します。 ただオプションを渡す方法が見つからない...

kubectl create job {再実行用に作成するjob名} --from=cronjob/{cronjob名} --namespace={namespace}

想定していた再実行の方法はできませんでしたが、CronJobはGCPコンソールからGUIyamlの修正及びJobの再生成が可能です。

ただターミナルからコマンド1つで再実行できるようにしたいですね...

GAS会

取り組んだ業務からもう一つGAS会を紹介します。

GAS会とは?

GASはGoogle App Scirptの略称です。

週に一度、エンジニアと編集・企画の社員が参加するGoogle App Scriptの勉強会です。

どうして始まったか

エンジニアではなくてもスクリプトを書いてデータの分析や自動化をしたい!というのが動機です。 GASは非エンジニアでも比較的馴染みやすく、社内で頻繁に使われるスプレッドシートを扱うことができるので、今回の動機とはあっていました。 私はエンジニアなので、参加者の先生役に近い立場で参加しています。

どんなことをしたのか

作りたいもののイメージをヒアリング

最初にゴールを示すために、ざっくりではありますが参加者にどんなものを作りたいのかイメージしてもらいました。 普段の業務で手間になっていることの中で、プログラムで解決できそうなものを記入用のシートを作成してもらいました。 その中でGASで解決できるか、開発規模が大きすぎないかといった観点で、振り分けを行いました。

開発規模が大きいものはエンジニアチームが手を動かして開発・保守するため、そういったものがないか確認するためにもここでヒアリングをしました。

勉強開始!

早速その後はGASの勉強に入りますが、変数や配列を知らない方がほとんどだったので、まずはGASのベースであるJavaScriptの基本的な知識を勉強してもらいました。 資料はこちらの記事に記載されているものを使用させていただきました。 https://qiita.com/sakaimo/items/4eee96ed254f42ba88c1

10分交代で資料の輪読・コードの実践をしてもらいました。 資料の中から参加者の方が作りたいものをに合わせて勉強項目を選定しました。以下に取り上げた項目を記載します。

実装スタート

一通り基本を勉強したあとは、再度作りたいものをヒアリングして実装をします。 参加者個々に作りたいものやレベルが異なるので、私と参加者の1対1でやることを洗い出しました。 「新規のスプレットシートを作成しよう」といった小さくて簡単なステップから、どんなことを調べれば良いかなど必要な作業を具体化していきます。

GASの基礎を勉強する時は輪読のスタイルを取りましたが、実装に入ってからは各自が勉強することを決めて進めるもくもく会のスタイルに移行しました。

参加者からの質問を都度受けて、必要に応じて画面共有しながら一緒にコードを書きます。

現時点で実装してもらったものとして、Webサイトのスクレイピング処理の定期実行などがありました。

進める上で感じたこと

3月末まで実施予定なので、まだ途中ではありますが今まで感じたこと書きたいと思います。

教えるの慣れてない問題

1年目は先輩に"教えてもらう時間"が多くありますが、教える側になることは基本的にないです。 そのため教える側になったのは初めてでした。その中で感じたことがいくつかありました。

1.エンジニア用語は使わない

APIを"叩く"とか、"要素をスライスして"とかは伝わりづらいです。

2.視覚的に理解できるように工夫する

図を用意したり、コードを書いて出力するまでを画面共有で見せたりしました。 変数にどんなデータ構造の値が入っているのか細かくダンプして、コードを理解するペースを合わせるようにしました。

3.ゆっくり喋れ

これはそのままですが...

参加者の方がすぐにわからなかったり、コードを書く手が止まってしまう時に私に謝られることがありました。 わからないことは全く問題ないですし、参加者の思考のスピードと同じスピードで喋る方が伝わりやすいです。

エンジニアに囲まれない時間は新鮮

普段はやはりエンジニアと会話をする時間が長いです。 そんな中、エンジニアは自分だけという時間は新鮮でした。 参加者の方がどんな業務をされているのか、技術で解決できそうなことに困っていないか聞いたりすることができる時間は楽しいです。

終わりに

新卒1年目で行った業務を紹介しました。

大学は文系で周りにプログラミングをやっている知り合いが少なかったということもあり、エンジニアの先輩に囲まれて仕事ができるのは嬉しかったです。 また、自分から聞きに行けば先輩エンジニアからはたくさんのフィードバックをもらうことができます。 今回紹介した分析ツールの話もその一例でした。

GAS会では基本的に実装作業はしませんが、要件を利用者と相談しながらプロダクトを作っていくという点で良い訓練になっています。 フルリモートワークということもあり、エンジニア目線で編集・企画職の社員が困っていることを感じにくい状況になっています。 その点で自分の持っている知識を生かしながら、社内の業務改善に繋がるような活動は続けていきたいと思っています。

お読みいただきありがとうございました。