Taichiro

### ■プロジェクト内容 競合であった企業の精算会社化に伴い、事業プロダクトとクライアント（主にメディア企業）の引継ぎを実施したプロジェクト Web上で動く広告（リッチ広告という）をフォーマットごとに作成することができるサービスの取り込み ・引き継いだサービス [http://richlab-corp.github.io/products/](http://richlab-corp.github.io/products/) ・上記を取り込んだ自社サービス [https://smartcanvas.net/](https://smartcanvas.net/) 引継ぎに伴い、既存プロダクトへのフォーマット取り込み開発及び、引継ぎクライアント（メディア企業）への営業活動を行う。 また、引継ぎクライアントだけでは、収益性が見込めないため、メディア企業へのリード獲得や営業戦略の立案も行った。 ### ■主な職務の概要 ・プロダクトやフォーマットを既存プロダクトへ取り込む開発 ・既存クライアントへの営業活動 ・メディア企業への営業戦略 ・リード獲得のための営業活動 ### ■ポイント ##### ＜開発＞ 精算会社化した企業のエンジニアからヒアリング及びドキュメントの共有を行い、既存プロダクトに取り込むよう要件定義・設計及び実装、そして配信テストまで行った。 **・開発言語** 管理画面取り込み 　フロント：Vue.js（webpack） 　サーバーサイド：Ruby（Ruby on Rails） 配信・計測側 　Node.js（webpack/フォーマットごとにmonorepo管理） **・自身が行ってきたことに対する技術的な詳細** 引き継ぎプロジェクトにより、基本的な仕様は初めから行われていたため、ウォーターフォール型の開発を採用 1. ソースコードの引き継ぎが行われたため、共有されたリポジトリとドキュメントの解読作業を行った。 　・フォーマットごとにpackage管理されていたため、それぞれの解読（1つのリポジトリ上に複数のpackageを管理できるlernaにて管理するmonorepoが採用されていた） 　・独自ライブラリであるdobj（コンパクトな容量で広告用JSを書くために作られたライブラリ）の解読 　・計測部分のロジック解読（インプレッションやクリック計測のタイミング） 2. 1に伴い、「自社サービスとの整合性」と「異なる部分の洗い出し」設計 　「自社サービスとの整合性」 　・広告タグ形式はHTML5での出力であったため、管理画面取り込みは容易であった。 　「異なる部分の洗い出し」 　・クリック計測のタイミングが自社サービスと異なっていたため、統一できるよう設計を行う。 3. 自社サービスの管理画面取り込み及び、それに付随する取り込み実装、デプロイ **・行ってきたことに対し、どのような問題があり、それをどのように解決したのか** ・ソースコード引き継ぎの案件だったため、引き継いだサービスの仕様と自社サービスの仕様を紐づける作業が必要だった。 特に、計測周りで、広告をクリックしたと認識するタイミングが異なっており、自社サービスに合わせられるように実装を行った。 → 自社サービスで行っているクリックリダイレクトを実装した。 ・独自ライブラリであったdobjの解読・自社プロダクトに合わせるための変更を行う必要があった。 → 頂いたドキュメントをもとに解読を行い、自社用のドキュメントに合わせるようにした。 ・今までストレージサーバーデプロイが手動であったため、自動で行う必要があった。 → CircleCIを導入し、自動デプロイできるようにした。 **・なぜその技術を選んだのか等の背後にある思考ロジック** 1. 既に他社で制作されているソースコードを変えるのには膨大なコストと手間がかかってしまう点 2. ソースコードはNode.jsで書かれており、自分にも知見があったため、そのまま採用しても問題なく取り込みできると考えた点 上記2点より、そのまま採用した。 ただし、下記の点は変更が必要であると考えたため、変更を行なった。 ・手動でストレージサーバーにデプロイしていたため、CircleCIでの自動デプロイを行うようにした。 ・クリック計測周りは、既存プロダクトと仕様が違っていたため、クリックリダイレクトができるうようにした。 **・プロジェクトの成果** 4ヶ月の開発で取り込み自体は終了し、公開することができた。 自社サービスは、リッチ広告を管理画面上で簡単に生成し、管理画面上で計測データを確認することができる点に強みがある。 引き継いだサービスでは、管理画面が存在していなかったため、管理画面に取り込めたことで、引き継いだクライアント等にリアルタイムで計測が見れること、容易にリッチ広告を生成できる点はとても喜ばれた。 **・その他、技術的なアピール、拘ったポイント** ・monorepoで管理されているサービスでpackageごとにデプロイをする必要があったため、shell上で共通化して、CircleCIで自動デプロイを行なった。 ##### ＜営業＞ 引き継いだクライアントだけでは、月150万円ほどしか売上がなく、稼働人数2名であったため、経理上赤字となってしまう。 そこで、月500万円まで売上をあげるのを目標に営業活動を実施し、2020年2月に8社企業数を増やし、売上が月500万円まで到達。 ・向上のために実施したアクション 1. テレアポ　月100件（2ヶ月間）→　2件のアポ獲得、1件の制約 2. 他プロダクト等で関わりのあった企業へのアプローチ　→　7社からの配信制約をいただいた 上記より、全社月間MVPに選出される。

### ■プロジェクト内容 受託開発案件（プロジェクト1の営業中に取得） メディアに訪れたユーザーの行動ログを記録して、ログをもとに動画化・ヒートマップ化して管理画面に表示するサービス 管理画面を含めて5つの言語を使用した中規模開発プロジェクト ### ■主な職務の概要 ・先方とのやりとり（営業） ・開発ディレクション ・設計（AWS設計、DB設計、技術選定等） ・開発（管理画面フロント、管理画面サーバー、ヒートマップツール作成、トラッキング用JS、トラッキングサーバー（少しだけ）） ・テスト その他細かなやりとり等 ### ■ポイント ##### ＜営業＞ 自分で営業を行い、獲得した案件 途中のやりとり等全てのフロント業務を行った。 ##### ＜開発＞ **・技術的な詳細** アジャイル開発/マイクロサービスアーキテクトで、 私は、設計からディレクション、実際の開発、テストまで行った。 開発が、 管理画面フロント：Nuxt.js 管理画面サーバー：Go（gin） トラッキング用JS：Node.js トラッキングサーバー：Fluentd、Lua ヒートマップツール：Vanilla JS で5つの言語を使用して開発したので、各APIでの繋ぎこみやそれぞれの言語キャッチアップにはとても苦労した。 ・AWS設計 https://user-images.githubusercontent.com/45042275/84573104-7a532800-add9-11ea-8a1e-f15ecc8435ba.jpg **・行ってきたことに対し、どのような問題があり、それをどのように解決したのか** ・サーバー間のやりとりがとても多くなってしまいそれぞれのAPIの管理をするのがとても大変だった。 → swaggerというyaml形式でドキュメント管理できるツールを使用して、API管理の見える化を行なった。 ・ログを集計して、ヒートマップ化する箇所があるが、計測時に行なってしまうと処理時間がとても長くなってしまう。 → Goサーバー側で、Aggregateバッチ処理を行い、1日1回の集計にすることで、対応 ・データベースにAWS RDSを使用していたが、運用前テストでt2.largeがバーストしてしまい、料金が運用前に跳ね上がってしまった。 → m4.largeに変更することで対応 **・なぜその技術を選んだのか等の背後にある思考ロジック** 1. サービスの役割ごとのタスクが多かった点と一部バグで全機能が停止することをサービス的にも防ぎたかったため、マイクロサービスアーキテクチャーを採用 2. 自分も含めた開発メンバーが書ける言語から選択 　フロント：Vue.js系が1番メンバーの知見があったため、採用 　サーバーサイド：ログ集計などの素早い処理が求められ、比較的容易に書くことができる静的型付け、コンパイル言語を採用 　計測サーバー、計測周り：サーバー内は計測ログをnginxで操作したかったため、FluentdとLuaを採用し、計測用のJS生成はNode.jsでの構築を採用した。 **・その他、技術的なアピール、拘ったポイント** ・集計ログやデータを整形する部分が多く、落ちた際にすぐにキャッチアップできるよう、slackに通知できるような仕組みを構築 CloudWatch → SNS → Lambda での処理を実現した点 ・計測周りがかなりのリクエスト数が想定されるため、全てリクエスト時に処理せず、保存だけ行い後で処理を行うということを行なった。 Goサーバー側で、Aggregateバッチ処理を行い、1日1回の集計にすることで、対応した点 ・集計フローと管理画面フローを完全分離することで負荷分散、リスク分散を行なった。（AWS設計参照） **・開発言語** 1. 管理画面 フロントエンド：Nuxt.js サーバーサイド：Go(gin) 2. データベース MySQL（RDS） 3. 計測 Node.js（計測タグ生成 / 計測ログ保存処理） Lua、Fluentd(計測サーバー) ・CI Circle CI ・サーバー AWS ネットワーク：VPC ドメイン管理：Route53 管理画面フロント：EC2（ロードバランサー ：ELB） 管理画面サーバー：ECS（Fargate） データベース：RDS 計測ログ保存処理：Lambda 計測タグ：S3 計測サーバー：EC2(Auto Scaling) ストレージ：S3 メールサーバー：SES 監視：Cloud Watch