ID:22577さん

広告クリエイティブ（画像・動画）やLPの作成を一元管理するシステムの開発・運用を行っていました。 当時の職場では主に広告代理業をしており、その一環で広告のクリエイティブやLPの作成を行っておりました。従来ではメール＋共有ドライブでデザイナー・ディレクター・営業・クライアント間のレビューや確認作業を行っており、月に数千本にも及ぶ制作作業のコミュニケーションコストは膨大なものでした。またメールのため履歴も追いにくく、過去の成果物も使いまわしにくい状態になっていました。そういった状態を解消するためのシステムになっています。（※：他社様のサービスだとAdFlow[ https://adflow.jp/ ] が近い） 主な機能は以下の通りです - クリエイティブ作成の案件管理 - クリエイティブのバージョン管理 - レビュー・差し戻し・コメント記入 - クリエイティブ作成に必要な素材の共有 - 成果物の保存・管理 当時は社内でおよそ約700名に加えてクライアントも500名程に使って頂いているシステムで、現職ではクリエイティブ作成のインフラのような状態でした。 2014年10月〜5月の開発期間を経てローンチ、2016年4月に先輩社員からリードエンジニアを引き継ぎ2021年6月まで追加開発をしつつ運用を行っていました。現在のチーム構成は以下の通りでした。 - プロダクトオーナー - 2名（内1名アドバイザー的立ち位置） - スクラムマスター - 1名 - 開発チーム - 5名 開発フローはスクラム開発を採用しており、日常的にモブレビュー（全員で一つの画面を見てレビュー）や、モブプロ・ペアプロなども行いました。 リードエンジニアとしては主に以下の業務を行いました。 - 追加機能開発 - 新規API作成 - インフラ（AWS）保守・運用 - ミドルウェア構築・保守・運用 - 技術的負債の返済活動 - 相談対応 - MySQLのクエリチューニング ## DDD導入 肥大化するシステムをRoRのアーキテクチャのみ（MVC）では保守が困難になってきました。 - Fatモデル - 大量のCallback そういった問題を解消するためにDDDおよびレイヤードアーキテクチャを導入して保守しやすい形の設計を行いました。Rubyにはinterfaceが無いなど、書籍で紹介されている方法通りの構築は難しいためアレンジした形で導入されており、「Repositoryをどこに置こう」などといった会話する際の共通言語として役立ちました。 ## 開発環境のDocker化 ImageMagickなど、開発環境でシステムを稼働させるために必要なソフトウェアなどが多いため準備にとても時間がかかるという問題があり「コマンド一発で出来るようにしたい」という思いからDockerコンテナ上で環境環境が動作するように構築を行いました。 チームにあまりLinuxやRuby周りに詳しくない人がジョインする際にも環境構築に詰まることがほぼなくなりました。また、新しいライブラリ導入時も共有のコストが格段に抑えられるようになりました。 ## フロントエンド ### フレームワーク導入 従来ではRoR＋jQueryによって開発を行っていましたが、DOMの操作だけではリッチになっていく機能や増えるajaxの処理についていけませんでした。そこでフロントエンドエンジニアにジョインしてもらい、新しいフレームワークの導入を行いました。 - Webpack - TypeScript - Vue.js - RxJs 私は環境構築を行い、後々フロントエンドエンジニアの人たちに教わりながら開発も行いました。 ### Renovate導入 フロントエンドにおけるライブラリの更新速度はとても早く、手動で対応していては追いつかないという問題がありました。 これを解消するべくRenovateというツールを導入してライブラリのバージョンアップのmerge requestまでの自動化を行いました。TypeScriptのビルドと自動テストがあったため、稼働することを担保した上で手軽にアップデートする環境をチームに提供することができました。 本当はGithub上で動くAppでしたが、現職の環境は自社運用のGitlabだったため通常のやり方では導入ができませんでした。そこでdockerhubで提供されているImageを見つけ、gitlab-ci上でうまく動くよう設定を行い運用に乗せることで解決しました。 以下私が書いたブログの記事になります。 https://blog.engineer.adways.net/entry/2019/01/11/160000 ## RubyやRailsのバージョンアップ RubyやRailsのバージョンが古いことによって以下の問題が発生していました - 遅い - 新機能が使えない - サポートが切れている - セキュリティに問題がある - 新しいライブラリが使えない - ライブラリのアップデートができない その問題を解決するためにアップデートを進めました。 - Ruby - `2.1.5`→`2.3.10`→`2.5.7` - Rails - `4.1.5`→`4.2.11.1` アップデートを行うと動作しなくなる箇所が出てくるため、アップデート後にもシステムが動くことを担保するために、リリースノートを見た上での調査やテストの自動化を行う事でなるべく安全に効率よくできるように努めています。 ## オンプレ→AWS移管 2020年8月~2021年1月で、オンプレミスで運用していたサービスのAWS移管を行いました。 IaC化も同時並行で進め、Terraformとansibleによる構築をしました。 Terraform導入の理由は勉強の結果、コンソールをポチポチするのが発狂するくらい面倒だったのと、保守性の向上からです。 ansibleは元々使用しておりましたが、あまりメンテされていなかったので過去のものを参照しつつ、ベストプラクティスを参考に刷新をしました。 使用したサービスは主に以下の通りです - VPC - Route53 - ELB - EC2 - RDS - Elasticache - EFS - SES - CWL - S3 チーム全員がAWSおよびTerraformは未経験のところからの開始でした。（ansibleは元々使っていました） ネットワーク設計も初めての経験でしたが、他チームの人にハンズオンをしてもらい、練習用の環境で勉強・練習を行うことで、調べながら少しずつだと進められるようになりました。最終的に移行自体は完了し、問題なく動作させることができました。

# 概要 当時の全社員500名が用いる360度評価の支援ツールの開発を1年目の春〜秋にかけて同期と2名でユーザヒアリングから開発、運用までを行いました。同時は研修が終わったばかりで、かつ上司はサポートをしない方針だったため、ほぼ全ての作業を手探りで行うこととなりました。 当時は研修が終わってすぐだったので、出来ることは以下の通りでした。 - Perlである程度の処理がかける - Catalystで簡単なアプリケーションを作ることができる - MySQLの簡単なクエリが書ける ほぼ経験のないヒアリングから画面設計、テーブル設計と順に行っていたため、普通に行っていたのでは納期に間に合わない事は明白だったため、チームメンバーと完全に役割分担を行いました。また、プロジェクト外の先輩社員に交渉を行い、テーブル設計のレビューやセキュリティのテストを行ってもらうことで出来るだけコストを抑えました。 実開発に入ってからはインフラの部署とのやりとり（サーバ構築など）やデプロイ環境の構築をチームメンバーに任せ、それ以外の開発業務やミドルウェア構築を担当しました。その開発を通じてほぼ全ての工程を経験することができました。また、開発したシステムにおいては以下の点が評価され新人賞をいただくこともできました。 - 約500名の360度評価がシステムを通じて効率よくできたこと - 不具合がほぼ出なかったこと - 評価データの漏洩に対してのセキュリティがしっかりしていたこと - ソースコードの可読性の高さ