Mulyu

# プロジェクト概要 依頼されてから制作という形だったワークフローを、依頼前に制作するワークフローに変えるシステム ## プロジェクト背景 このシステム開発に至る前、社内での潜在的なニーズを探すため、業務現場にビデオカメラを持ち込んで業務観察をしつつ、インタビューを重ねました。 結果、現状の現場の課題として、 1. 広告クリエイティブの生産量に現状だと限界があること 2. 媒体の入稿規定は非常に厳しく、現場で認識して制作することは困難 の2点を見つけることができ、このシステム開発で解決する課題として設定しました。 ## 機能概要 数十単位の画像・動画・テキストを情報解析し、ピクセルサイズやビットレートなどが入稿規定に合っているかチェックしました。 登録された画像・動画・テキストを組み合わせたものをプールしておき、必要になったときに入稿利用のためのCSVを出力しました。 ## 技術概要 プロジェクト開始前後の綿密なヒアリングをもとに、DDDでコードに説得力をもたせました。 動画情報の取得のため、ffmpegとexiftoolを併用して腐敗防止層でまとめました。 Vue.js, Vuexを採用し、過度に複雑化せずシンプルに実装できるように努めました。 ## 技術課題 制作・入稿部門間で同一の用語名で全く別の概念を指すものが存在し、DDDでコードに落とし込む際に苦労しました。 完全に分断されたコンテキストとして概念を分割することも可能だったのですが、複数部門が同一システムを使うために議論の場が分割できず、結果概念としての分割が難しい状態にありました。 ステークホルダーと対話を重ねその言葉がなにを意味するのか？を問い続け、一定の概念の整理をするとともに部門間を超えた協力体制を築きました。 動画の情報解析にjava標準では厳しかったので、。まずexiftoolを併用してできる限りの情報を集めましたが、後にffmpegでは音声情報が取得できることがわかったため、腐敗防止層でこれらの併用を吸収し、その後のツール入れ替えに向けた構成に変更しました また、チームがFrontendに対する経験が浅かったため、事前にReact.js, Riot.js, Vue.jsの技術比較を行い、 1. React.jsはReduxなど必要以上に複雑になる要素があり、チームでは扱いきれない未来が見えた 2. Riot.jsはコミュニティとしての勢いがVue.jsより弱くReact.jsに比べエコシステムで負けている と結論づけて、Vue.jsを採用しました。追ってVuexも採用しましたが、Reduxを使うよりはシンプルに済み、チームの経験値に合わせた選択ができました。 ある技術で困ったことをどう解決したかという話はよく耳にしますが、そういった技術を採用しないように選定することがエンジニアリングで求められていることだと考えています。

# プロジェクト概要 広告運用データの活用に向けた、データ蓄積・整備・品質管理業務 ## プロジェクト背景 日々運用される広告運用データの活用のため、そもそものデータ蓄積から活用までのETL処理の整備を行いました。 途中参加したもののプロジェクトが立ち上げ期だったため、動きはするものの品質が問題になっていました。 まずは蓄積から活用までの一通りの業務を経験し、個別の品質改善のアプローチでは顧客が求める品質にそもそも答えられているかがわからないことがわかりました。 そのため品質を可視化するためのプロダクトの開発を開始することにしました。 ## 機能概要 データ取得のログ格納と集計により、データが欠損しているか・誤差がないかを可視化しました。 ## 技術概要 マシンリソースを圧迫するEmbulkの処理をFargateを使ってスケーラブルにしました。 負荷の高いPrestoクエリをパフォーマンスチューニングしました。 データの品質のトラッキングのため、専用のDigdagプラグインを開発しました。 ## 技術課題 Embulkによるデータ加工処理はその特性上メモリにすべて展開されるのですが、別タスクが同時実行するとメモリが枯渇する問題がありました。 スケジューリングをずらすアプローチが取られていましたが、タスクの数が増えると人間が把握できる範疇に収まらなくなってきたため、スケーラブルなアプローチが必要になりました。 幸いECSにFargateというサーバレスな環境が提供され始めたことと、EmbulkをECSで実行するためのプラグインがあったためそちらを採用しました。 しかし、長時間になりがちなタスクに対してタスクの待機時間が選べなかったので、機能追加のパッチを送り、解決させました。 各ETL処理はPrestoを用いてクエリが記述されていたのですが、非エンジニアが書いたものもあり負荷が非常に高いものになっていました。 列志向らしく必要な列にしぼり、効率の良いパーティション指定を行い、カーディナリティの高い列からグルーピングしたり、地道な改善を続けました。 データを顧客に提供するにあたって、そもそも媒体都合のデータ欠損という問題があったので、まずはそれから可視化できるアプリケーション開発を開始しました。 ETL処理中には欠損したアカウントはそもそもアカウントIDが欠損することがわかっていたので、ETL開始前と開始後にアカウント別にログを出力させ、データ欠損しているか・どの処理で欠損したかを可視化しました。 ログ出力のためのクエリを都度発行させるのはリソースがもったいなく、既存のログ出力だと並列処理ができず遅かったため、専用のロガープラグインを開発して対応しました。 また、ログの書き込み先には負荷の課題がありました。時間帯の別のスパイクに対応でき、スケジュール次第でスパイクがかぶったときでも問題ないように動作する必要がありました。 ちょうどリリースされたばかりのDynamoDBのオンデマンドキャパシティを使って解決しました。 ## マネジメント課題 Scalaの仕事ができる、という理由で入社してくる方が多かったため、この時期は社内でもモチベーションの低下が問題になりました。 Scala製のDigdagプラグインで課題解決することを示し、社内にDigdagプラグインの作り方を展開することで、Scalaエキスパートによるデータエンジニアリングというモチベーションの起点を生み出しました。

# プロジェクト概要 広告運用データの活用に向けた、広告クリエイティブ入稿管理ツールの開発 ## プロジェクト背景 広告運用にまつわるデータを蓄積する過程で、制作情報が重要な変数になっているのではという仮説があり、制作後の入稿までをシステムにのせることで情報のトラッキングを可能にする必要がありました。 また、入稿規定の認識ミスが現場で頻発していたので、システムチェックを乗せることで工程の出戻りをなくし、全体のワークフローの高速化を目指しました。 ## 機能概要 登録された画像・動画・テキストの集合に対して、媒体の入稿規定に合うような組み合わせを自動生成しました。 管轄外の制作側システムから画像・動画の登録を連携しました。 ## 技術概要 媒体ごとに異なる広告メニューの概念を統一し、組み合わせ可能なルールを使って柔軟に入稿規定を取り入れられるよう抽象化しました。 Either,Try,Futureなどが入り混じり型変換にコストがかかっていたところを、tagless-finalスタイルで抽象化しました。 管轄外の制作側システムから登録した際の失敗に備え、連携用のマイクロサービスを通してリトライ可能にしました。 ## 技術課題 FacebookやYahooなど多数の媒体で広告メニューが微妙に異なっており、個別に実装するにはあまりにも数が多く、共通にして扱うには複雑な入稿規定となっていました。 主要媒体から共通可能な部分や規定項目などから抽象化し、小さい単位のルールと大きい単位のレギュレーションとしてモデリングしました。 結果、使い回しができ拡張しやすい設計を達成できました。 ScalaにはFutureやTryといったエラー管理のためのクラスが複数種あり、ライブラリの問題や特定用途に依り型が違い、使い回すために上長な型変換が必要が必要になり、結果コードの見通しが悪くなっていました。 cats, cats-taglessなどを使い、tagless-finalスタイルでドメインロジック・インターフェースを記述することで、型変換をアプリケーションロジックから排し、メンテナンスしやすく見通しやすいコードを実現しました。 また、制作側のシステムが管轄外でWordPressを使った簡易なシステムだったため、登録の連携時にエラーが発生するとデータ欠損が起きてしまう問題がありました。 元々のこちらのシステムにAPIと永続化を用意してもよかったのですが、コンテキストの汚染が起きてしまうことを避けるため、軽量なマイクロサービスを別に立てて連携させました。 これにより制作と入稿それぞれのシステムが別々にメンテナンスしやすく、アップデートを個別に進行していける状態にできました。 ## マネジメント課題 これまでのプロダクト開発を通して、本社のステークホルダ側と開発現場の亀裂は深くなっていました。 主に理由は意思決定の遅さによる開発遅延でしたが、業務フローが多くの部署にまたがっていたため、ステークホルダ間でも合議が困難な状況でした。 ステークホルダと開発現場を一体として進行する必要があったため、それまでのようにそれぞれが目標を立てるのではなく、まず将来に投資するための全体業務効率化という目的を明らかにし、ワークフロー全体の時間削減という共通のKPIを追っていけるように調整しました。 これにより、解決すべき課題を持ち寄るときでも見込み削減時間をもとに議論でき、スピード感を持って決断できるようにしました。