【リモートOK／バックエンドエンジニア】今なら、アーキテクチャから自分で決めることもできる新事業！

GeoLogic Ad（ジオロジック・アド）は、スマートフォンユーザーの位置情報にもとづいた広告を配信をする、位置情報広告です。

GeoLogic Adは位置情報を活用したマーケティングにフォーカスしたサービスで、チラシ配りや新聞の折り込み広告に近い感覚で設定でき、店舗の商圏に「今いる人」「過去に訪問した人」「住んでいる人」などへインターネット広告を配信できます。
また、動画広告や広告配信結果を地図で表示するAdGIS、位置情報データを基にしたユーザーのプロファイリングなどにも対応しています。

最近では、Spotifyへ音声広告の配信にも対応しており、日経新聞に取り上げられるなど、いまインターネット広告市場で最も注目されているサービスのひとつです。

# 起案

どういったものを作っていくかという方針は経営会議などで決定します。
しかし役員陣との距離が非常に近く、エンジニアからこういったものを作りたい、作った方がいいなどの話はいつでもできます。
この段階では、機能レベルまで話し合われず、ざっくりした方向性などが決められます。

# 開発の進め方

## 要件定義

要件定義はRDRAとDDDの考え方を取り入れて行なっています。
各ステークホルダーにヒアリングし、PdM（現状社長が兼任しています）やCTO（@yabooun）、PM（@carotene）や設計担当などが集まり、モデリングしていきます。
この段階で、概念モデルやユースケースなどが作られます。
社長もエンジニアではないですが、データサイエンティスト出身でシステムへの理解は深く、同時に業界をリードしてきた存在のため、事業ドメインへの理解も非常に深いです。
そのため、一般的に課題になりやすい、ビジネスサイドとの意思疎通に労力を要することは非常に少ないです。
要件定義は大項目レベルの機能単位で行われます。

## 設計

要件定義で定められた各モデルから、実際の画面遷移や画面設計、API設計などが作られます。
PMや設計担当が手分けして行い、プロダクトオーナーのレビューも行います。
画面設計と、要件定義で作成した概念モデルやAPIと画面を紐づけ、関連性から検証可能な設計を作ります。
そのため、設計によって矛盾が発生しづらい仕組みとなっています。

## 開発

設計、開発はスクラムの中で行なっています。
基本的に２週間でスプリントを回しており、開始時にスプリント内で作業する内容を決定します。
もちろん、障害や急な差し込みなどもある可能性はありますが、そういったものをデイリーミーティングで共有し、各エンジニアが無理のないように開発を進められるよう調整しています。

## テスト・リリース

出来上がったものは開発環境、準本番環境でテストし、社内リリースを経て外部リリースされます。
基本的にはスプリント単位でのリリースをしていきますが、大きなリリースはロードマップを敷いてリリースしたり、小さな改修や障害対応などは随時リリースします。

# スクラム

基本的にはスクラム開発に則り開発していますが、ジオロジックの文化や体制にあわせて一部形が変わっています。
下記については現状のものであり、今後形が変わっていく可能性は十分にあります。
運用を始めて１年に満たない状態ですが、それでもベースからかなり形が変わっています。
今後も、よりチームに合うように、どんどんブラッシュアップしていきます。

## 戦略ミーティング

（いきなりスクラムであまり見かけないものですが）スプリントレビューを行う前に、一部のメンバーだけで今スプリントの状況を整理し、次のスプリントでどのようなことを行なっていくか方向性を話し合います。
本来はスプリントレビュー、スプリントミーティングで行うものですが、現状メンバーが７名程度の大きなスクラムになっており、効率的にミーティングを進められるようにした結果、このミーティングが誕生しました。
もちろん、ここで勝手に決めてあと実行するだけとならないように、必要に応じてメンバーにヒアリング、アサインなどを行います。

## スプリントミーティング

スプリントミーティングは、一般的なスクラムと同じく、スプリント内でやることを決めます。
そこでエンジニアが見積もりを行い、無理のないスケジュールを立てます。
戦略ミーティングで決定した内容でも、見積上不可能であれば、無理に入れません。

## スプリントレビュー

本来スプリントレビューでは、全てのタスクをチェックし、動作まで確認しますが、ジオロジックではここを２つにわけています。
まず一つ目は、このスプリントレビューにプロダクトオーナーも参加し、状況の報告及び重要な画面や設計のレビューを行います。
そしてその後、メンバーのみで詳細なタスク状況の精査を行います。
２つに分けていますが、時間としては合計１〜１．５時間程度で終わります。

## デイリーミーティング

デイリーで全メンバーが集まり、進捗報告を行います。
この場で差し込みや見積ミスなどにより、スプリントから外れてしまいそうなものがあれば、その場でPMが判断して調整します。
また、場を盛り上げるため、ミーティング前に持ち回りでアイスブレイクのような話をしていきます。ジオロジックでは、これを「前座」と呼んでいます。

以上がプロジェクトの進め方です。
いくつか特殊な点はありますが、基本的にはエンジニアに無理をさせず、成果を最大化させ、さらに楽しく仕事をするためのものです。
今後もっともっと良くなっていきます。

新しいもの古いもの関係なく、必要なものを採用します。
また、若手や業務委託メンバーからの意見も、PMやCTOの意見と同様に扱い、チームで話し合って合理的に判断します。

前にも書きましたが、設計はDDDとRDRAを組み合わせたものを採用しています。
プロダクトオーナーとエンジニアのドメイン知識が乖離していた状況から、齟齬なくすり合わせをしてストレスなく開発を進めるために導入しました。

APIやバッチなどはすべてDockerで管理し、ECSで動作しています。
そしてECSからfluentdでFirehoseを経由してParquetに変換し、S3に保存しています。
これをReDashでAthenaからログを見られるようにしています。

自動化はCircleCIでビルド、デプロイを行なっています。
現状無停止デプロイの完全自動化ができていませんが、できるだけ早く無停止で、ブルーグリーンデプロイの仕組みを整えていきたいと思っています。
他にも、プロジェクト初期でJavaScriptを採用してしまったために、TypeScriptへの移管がなかなかできていないなどの負債も残っています。

これらもスケジューリングして順次解決していきます。

チームメンバーからのメッセージです。

# 20代後半　プロジェクトマネージャー　T.K.

一年後に自分がどう成長しているのかぼんやりと予想していたのですが、
いい意味で予想外の成長をすることができたなと感じてます。
現在のチームはすこし、だいぶ、いやかなり個性豊かなパーティで、それぞれが自分の特性を最大限生かし、プロダクト開発という強大な相手に立ち向かうべく研鑽を積んでいます。
「楽しく最大の成果を出すために、個人として・チームとしてどう戦うか」を考えて戦いたい人に弊社はおすすめです。

# 20代後半　バックエンドエンジニア（筋肉担当） K.S.

個性豊かなメンバーがそれぞれの持ち味を発揮し、OneTeamとして開発を進めています!!
きっとあなたの個性もこのチームで十二分に発揮できるでしょう!!
ご応募をお待ちしてます!!

# 30代前半　バックエンドエンジニア　J.A.

事業が急成長していることを実感できる会社です。
全員参加の定期的な勉強会でお互いに研鑽しあっており、自分自身の成長も感じられます。
位置情報×広告で一緒に面白くやっていきましょう。

# 30代前半　ディレクター　S.Y.

ある人は入社１週間後、「うちの会社に入社してどうですか？」という質問にこう答えました。
「楽しんでます。」

エンジニアとして活躍するだけでなく、楽しさも追求する。
スタートアップならではのやりがいだけではないチームだということを保証しますｗ