ビジネステクノロジー開発部の開発事例として、Edikariというプロダクトについて簡単に紹介します。
あいさつ
こんにちは。Opt Technologies の石井です。Opt Technologiesで開発・運用・保守を行っている「Edikari」というプロダクトについて概要を紹介します。
Edikari とは
広告入稿サポートツールと呼ばれるプロダクトの1つです。
業務効率化のために開発されており、以下のような狙いがあります。
- 様々な広告媒体へ広告を入稿する際、統一された業務フローで作業できる (媒体ごとの違いを意識せずに済む)
- 部署間で行われる入稿関連の情報 (画像・動画ファイルやフォーマット指示など)の受け渡しコストを減らせる
オプトでは既に各媒体への入稿サポートを担うプロダクト群が運用されているため、Edikariは関連する既存プロダクト群の利用者としての位置づけです。先の記事でご紹介した アムズAPIや CreativeDriveとも連携しています。
使用している技術
アーキテクチャ面における位置づけは「マイクロサービスを意識したプロダクトの1つ」です。
フロントエンド・バックエンドは、それぞれこのような技術スタックで開発しています。
- フロントエンド (SPA)
- TypeScript
- Vue.js (version 2) with Composition API
- Vuetify (version 2)
- APIサーバ (GraphQL API)
- Scala
- Sangria (sangria-graphql)
- Slack通知
- Python
- インフラ
- Terraform
- AWS
- CloudFront
- ECS Fargate
- Lambda
- RDS (MySQL)
- ...
技術的な特徴としては、当時のチーム内や社内において比較的新しい (利用実績が少ない or 無い)フレームワークや個別ライブラリを大胆に取り入れた、という側面があります。
たとえば当時の開発チーム内で運用していたプロダクトはAPIサーバがREST API (Clojure with Duct + Pedestal)とバッチ処理 (Scala)の構成でしたが、EdikariではGraphQL API (Scala + Sangria)を採択しています。
またフロントエンド側も、当時の開発チーム内ではVue2 + vue-class-componentを利用していましたが、EdikariではComposition APIを早期から取り入れる試みが行われています。APIサーバ側がGraphQL APIであることに関連して、フロントエンド側でクライアントライブラリapollo-clientも導入されました。
もちろん、これまで蓄積していた経験を活かして同じ技術スタックを採択した箇所も多くあります。たとえばAWS Lambdaで起動するSlack通知にはPythonを採択しており、APIサーバはECS Fargateコンテナで起動する構成としています。各種インフラ構成をTerraformコード化していることも同様です。
主要機能とそれを実現する技術
Edikari利用ユーザが画面上で行う作業は、おおむね以下の通りです。
- 自分の担当範囲について、広告と広告グループの紐付け条件 (どの広告をどの広告グループへ紐付けて入稿するか)を設定する
- 実際の紐付け結果を確認し、ファイル出力する (
.xlsx,.csv) - 後続の作業を別部署へ依頼する (ファイル内容を活用して、対応する広告媒体へ入稿作業を行う)
※ 広告グループとは広告に関する階層構造の要素のことで、複数の広告をまとめる概念です*1。
cf. https://ads-promo.yahoo.co.jp/online/ssday_6.html
たとえば、こちらは開発用のダミーデータを使って画面操作している例です。
Edikariは広告と広告グループの紐付け自動化を担っており、社内の業務標準化 (業務フローや名称ルールなどの統一)と組み合わせることでユーザの作業工数を削減します。
広告と広告グループの紐付け
広告と広告グループを紐付ける時、Edikariは「これから入稿しようとする広告データ」を「条件に当てはまる広告グループ」の配下へ全て紐付けます。
作業の詳細としては、
- 広告データを絞り込む
- 広告グループを絞り込む
- 広告を広告グループ配下へ紐付ける
という動きを繰り返します。
これらの動きは、プロダクト内ではEdikariが他プロダクトと連携しながら実現しています。たとえば広告データをその種類で絞り込む時はCreativeDriveのAPIサーバを利用し、広告グループを名称で絞り込む時は各種入稿サポートツールのAPIサーバを利用しています。Edikari APIサーバはEdikariフロントエンドと各種プロダクトとの間に立ち、媒体ごとの違いを吸収してデータ表現を合わせたり、Edikariフロントエンド側が扱いやすいデータ構造へ加工・変換したりする役割を担っています。
最後の自動紐付けは、Edikariのフロントエンド側で行っています。特別な技術は利用せず、クライアントサイドでJavaScriptを使った素朴な紐付け処理に頼っています。複雑で多層にネストしたオブジェクトを扱うため、TypeScriptによる型定義がのちの保守にも役立っています。ソースコードとしてはオブジェクト指向を意識した書き方が活用されていると感じます。
入稿用ファイルのダウンロード & 後続作業の依頼
広告と広告グループの紐付け結果はファイルとしてダウンロード可能です (Edikari画面上でも確認できます)。
ファイル形式は用途によって異なります。後から加工しやすいようにxlsx形式でダウンロードする場合と、そのままアップロードしやすいようにcsv形式でダウンロードする場合があります。ファイル作成とダウンロードもEdikariフロントエンド側で行っています。
また、後続作業を別部署へ依頼する作業 (画面上での最後の作業)についてもEdikariが一部サポートしています。社内のタスク管理プロダクトと連携しており、「Edikariで紐付け作業を終えた後に、その後続作業を依頼するためタスク管理プロダクトへ遷移したら、入力欄の一部を自動入力しておく」という動きをします。
技術的な側面では、ファイル作成にSheetJSを利用しています。紐付け処理と同様、ファイル作成時のデータ再配置もできるだけJavaScript, TypeScriptの標準機能が活用されています。
おわりに
今回はEdikariの役割や実現するための技術について概要を紹介しました。今後もプロダクト間や外部サービスの変化に対応しながら改善・保守運用を続けていく予定です。
Opt Technologies ではエンジニアを募集中です。カジュアル面談も可能ですので、下記リンク先よりお気軽にご応募ください。
*1:細かな仕様は広告媒体によって異なります
