ID:62537さん

## プロジェクトについて 会社の自社プロダクトの立ち上げから参画して開発/運用を行っています。 作っているサービスは、デジタルメディアを広告配信によって収益化するためのプラットフォームです。これを自社で運用しながらOEM提供もしています。10カ国以上で使われていて、それぞれの国やOEM先ごとに、デジタルの広告枠を買う側と売る側にシステムをカスタマイズして提供しています。 私は主には広告配信の管理画面を担当しています。 担当領域のコードベースですが、立ち上げの時点でローンチまでの時間短縮のために関連企業の別プロジェクトを適法にフォークしたものになっていました。なので2018年の時点で以下のような技術スタックで開発が始まっています。 - バックエンド - [Mojolicious (Perl web framework)](https://www.mojolicious.org/) - [MySQL v5.6](https://www.mysql.com/) - フロントエンド - [jQuery v2.1.3](https://jquery.com/) - その他 - [GKE (Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine) - その他 Fluentd や BigQuery などのデータエンジニアリング系のソフトウェア アサインされた時点で管理画面担当のメンバーは私1人、初見の画面が120程度ある状態で、最初は大変でした。 ## がんばったこと1 GoogleAnalyticsを使ったことがあるとイメージがつきやすいのですが、デジタル広告を扱うシステムはあのようなものです。広告の配信設定はなかなか仕様がたくさんあります。また前述の通りこのプロジェクトでは色々な種類のユーザがいるため、仕様の複雑さはそれらの掛け算となり、大変です。 このプロジェクトでがんばるべきことは以下のようなものでした。 - 抽象化していい部分としてはいけない部分をいちいち考える - 国の数/OEM提供先の数のコード書くわけにはいかないため - コードが仕様を把握する上で読みやすいものであること - もはやシステムの全貌を知っている人はいないので、何人もいるPdMからたくさん仕様について問い合わせがきます。少なくとも「ちょっとコードを眺めたら仕様がわかる」ようにしておく必要があります - なぜその仕様/コードが存在しているかが、いろんな手段でわかるようにしておく - 「汚いコード」よりも「目的がわからないコード」が一番重荷になるため 書いてみると、すごい普通なことばかりで我ながら驚いていますが、私はこのようなことを頑張っています。システムは大きな問題もなく立ち上げから成長し続け、会社を支えるようになっています。管掌の役員にとても恵まれているということがあり多少僭越ではありますが、自分が出しているバリューとさせていただきます。 ## がんばったこと2 前述の通り、プロジェクト開始時点で技術スタックはなかなか年季が入っていました。バックエンド側はなんとかなるとしても、フロントエンド側の技術スタックはローンチが落ち着いた時点で改善したほうがよいと考えました。 1. ここ10年での技術進歩が著しいので、巨人の肩に乗れた時の恩恵が大きい 1. 逆に巨人の肩に乗れていないと、今後他社サービスとの競争にも影響でてきそう 着手するときにはアプリは画面数が200程度の規模になっていたので基盤となるツールの移行には時間がかかりました。 優先順位を考えながら、2年ほどかけて以下のツールを導入していきました。 1. [webpack](https://webpack.js.org/) - 他のファイルからモジュールをimportして再利用できるようにするため - もともとjQueryプラグインがダウンロードされコミットされている運用でした - もともとはすべてがGlobal名前空間にあり、移行が一番大変だったところです 1. [TypeScript](https://www.typescriptlang.org/) - 簡単にテストを書けない部分がたくさんあり、型チェックの恩恵が大きいため - 移行のための洗練された[ツール (ts-migrate)](https://github.com/airbnb/ts-migrate)が登場したため 1. [Jest](https://jestjs.io/) - Jest以前のテストツールが林立していて、テストツールのメンテナンスのコストが法外に高かったため - 導入に際して工数が大きかったので後回しとなった なお、Reactの導入は最後でした。使われていた[jQuery DataTables](https://datatables.net/) の出来がよく、使い倒せば状態管理を必要とするような複雑な実装をかなりオフロードできたためです。Reactが導入されたのは複雑なフォームを実装するために[Formik](https://formik.org/)を導入する際でした。 フロントエンドのツーリングは沼です。意識していたのは以下のことでした。 - なにを、どこまでしてくれる技術なのかをわかっておくこと - そして、それは必要な技術なのかをプロジェクトにあてはめること - 必要ならば、どれくらい必要なのかで優先順位をつけること - ツーリングのためのまとまった時間はとれないはずなので、誰でも少しづつコミットできるようにしておくこと 現在は無事に移行ができて、おかげさまでメンバーともども快適に開発ができております。

## プロジェクトについて もともとは趣味からはじまって、PdMのような役回りの知り合いと2人で細々と運営しているWebサイトです。諸事情で詳細は避けますが、いちおう業界内では注目されているようで、サイトを3千万円で買いたいという話をいただく程度には運営できています。 サービス構成としては単純です。 - スクレイピングで情報を収集して - 集めた情報をETLを経てコンテンツに仕立て - Webサイトとして公開する ## がんばったこと 知り合いの趣味から始まったプロジェクトでありフルタイムではありません。工数もそこまで捻出できず、また平日昼間に問題が起きても対応できないため、徹底して手がかからないような仕組みを模索しました。 手がかからないようにするための方針と、使った技術については以下のようなものです。 - コンテンツデータのETLはすべてBigQueryの機能で行う - [BigQuery#merge_statement](https://cloud.google.com/bigquery/docs/reference/standard-sql/dml-syntax#merge_statement) - [BigQuery#scheduling-queries](https://cloud.google.com/bigquery/docs/) - ユーザがアクセスするコンテンツは静的データでホスティング - [Amazon CloudFront](https://aws.amazon.com/jp/cloudfront/)/[Amazon S3](https://aws.amazon.com/jp/s3/) - PdM用の管理画面はredashとGoogleSpreadSheetで構築 - [redash | API](https://redash.io/help/user-guide/integrations-and-api/api) - [GoogleSpreadSheet#IMPORTDATA](https://support.google.com/docs/answer/3093335?hl=ja) - ランタイムはすべてFaas - [serverless/serverless: ⚡ Serverless Framework](https://github.com/serverless/serverless) - [ACloudGuru/serverless-plugin-aws-alerts](https://github.com/ACloudGuru/serverless-plugin-aws-alerts) - CloudWatch, sns 周りの、エラーレポートに関するリソースを管理するプラグイン - その他、必要な機能は極力マネージドのサービスを使う - [Mackerel（マカレル）: 新世代のサーバー管理・監視サービス](https://ja.mackerel.io/) - [AWS Chatbot | AWS](https://aws.amazon.com/jp/chatbot/) - [Bot Designer | LINE Developers](https://developers.line.biz/ja/services/bot-designer/) とくに頑張ったのは以下のようなことです。 - 不要なことは、しない/書かない - 必要なことは、一番楽にできるようなやりかたを考える