この記事は個人で簡単なアプリ開発を行ったのでその背景、目的、機能、技術選定の理由などを紹介します。

絶賛就職活動中で、開発内容を整理したいと思ったためです。今後就職活動をする方には、技術選定の理由などが参考になると思います！

フロントとバックの連携できていないので、ソースコードだけ公開します↓

前提

学生が開発している
就職活動でスキル、着眼点などをアピールするために開発
完全に完成はしていないため、今後もアップデートしていく
勉強のために触ったことのないAWS、CICD周りを実装
学生2人でそれぞれフロントエンド、バックエンドを担当

開発者

フロントエンド：https://github.com/ASpooky
バックエンド：https://github.com/higayu624/
※この記事はバックエンド目線で書いている

開発しようと思った背景

最近の飲食店の集客サービスは飲食店が払っている金額に応じてリーチできるサービスが多くなっている。個人店は大企業に比べ資金力がないためリーチしにくく、パンデミックの影響などもあり客足が減ってしまっている。
そこで、個人店舗が活躍できる仕組みを活用したサービスがあればいいな〜と思った。

ビジネスで都市ではなく地方が注目されているため、ローカライズされたプロダクト開発をしてみたいと思った。

個人的な思いだと、約10年後は地方に住みたいと考えているため地方のさらなる活性化に貢献したいと思った。

解決したい課題

払った金額に応じてリーチされる仕組み。単純に多く払えばよりリーチできるという構造になっており小さな飲食店は大企業に必ず負けてしまう。

課題を解決するためのアプローチ

大企業はブランドイメージを大切にするため、リアル感には弱い。（店が散らかってしまっているところなど）しかし、個人店はそのような散らかっている感じなども味になり強みになる。何より店の雰囲気の一部を作っている。加工しないリアルさが重要視されるアプリなら個人店が強いのではないか。リアルさを重要視したアプリにしていきたい。

最近流行りのBeReal（ビーリール）というSNSの1日1枚のみ投稿できる機能を使えないかと考えた。さらにアプリ側が指定した時間に投稿すれば1日3投稿できるという機能をちょっと変更しても、リアルさを重要視したアプリケーションにできそう。

ホットペッパーは予約したい時に利用する。お金をかければリーチできる。instagramはお店を探すときに利用する。巧妙なアルゴリズムを理解すればリーチできる。近くの飲食店を探して、すぐに行く時に利用するようなアプリケーションはない。巧妙なアルゴリズムでもお金でもなく、リアルさがしっかり出ていることでリーチできるアルゴリズムを採用したい。

さらに、すぐにいきたいお店を選ぶ性質上、居住地域の近くで利用することになる。そのため居住地域でお金が回せるような循環を作れれば、さらにお店を利用してもらえる。
そこで、継続的に同じ人にリーチできるサービス。ここにポジションできるようなプロダクトを作っていきたい。

プロダクトの詳細

目的、戦略、競合との比較の順に紹介します！

目的

リアルさを重要視し、個人店舗をリーチし、来店につなげ、継続的な利用を促進する

戦略

一旦最低限動くB版を作って需要やフィードバックを集める
リアル感を出すために1日1投稿や、特定の時間にのみ投稿できる機能をつける
今すぐお店を探して行きたいという行動をサポート
さらに、継続的にお店を利用してもらえるような機能をつける

競合との比較

ホットペッパーは予約したい時に利用し、お金をかければリーチできる。instagramはお店を探すときに利用し、巧妙なアルゴリズムを理解すればリーチできる。このプロダクトは、近くの飲食店を探してすぐに行く時に利用する。さらに、巧妙なアルゴリズムでもお金でもなく、リアルさがしっかり出ていることでリーチできるアルゴリズムである。これにより、ユーザーの使用方法、リーチされる店舗が違う。

開発内容

開発の内容を紹介していきます。一旦最低限利用できるβ版を作るため、最低限の機能で定義していきます。

機能の洗い出し

user認証系

ログイン
ログインしているuserかを判別する（middleware）
(JWT認証を採用）

user情報系

user（Create, Read, Update, Delete）
Read時は、リレーション先の投稿の情報も持ってくる（SPAなフロントにするため）
Delete時は、user、リレーション先の投稿も論理削除
DBの変更がある時はトランザクションを使用

投稿系

投稿 (Create, Read, Update, Delete)
投稿を作成するとき、すでに投稿していないかチェック、1日後に投稿を論理削除
投稿を削除するときに、論理削除
DBの変更がある時はトランザクションを使用

技術選定

方針

グロースした状態を意識して開発していきたい。特にコード量が増えてきた時の変更のしやすさを重視したい。現状B版であり、α版でかなりの変更があることが予想されるためである。

さらに、自分の考えている戦略として、速さを重要視している。速さとは変更の速さで、経済力、信頼、データがない状態で、周りの企業に勝てるのは、速さのみであると考えるため。それを実装できる選定をしていきたい。

言語、フレームワーク

言語はGolang、フレームワークにはGinを採用。Golangを採用したのはインタプリタ言語ではなく、コンパイル言語であるため実行速度が速いということ。

自分がインターンシップでGolangを使用していて、勉強として採用した。

コンパイル言語には他にもJava, Cなどがある。そことの比較として、while文がなかったりして、どんな人もコードが同じような実装になるため、共同開発がしやすいためgolangを選んだ。

Ginに関しては、よくEchoと比較される。速さという面では、2トップのフレームワークだが、Echoの方が少し早いそう。それでもGinを選んだ理由としては、Echoよりセキュリティ的に強いため。Echoの方が処理が早いが大差なかったため、ユーザ情報を扱う今回のプロダクトにはセキュリティの高さが必要だと考えた。

DB、ORM

DBにはPostgreSQL、ORMにはGORMを採用した。

PostgreSQLに関しては、複雑なクエリの処理に強いため採用した。よく比較されるMYSQLは安定性とスピードという面が強いが、個人的に今後の変更やマーケティング調査など、複雑なクエリの処理をすることが多いと考えたためPostgreSQLを選定した。

GORMに関しては、GoのORMでは1番メジャーなものと言っていい。自分はSQLBoilerと比較した。SQLBoilerとは、すでに構築されているDBを操作できるコ-ドを自動生成するORMである。静的に片づけされており、リフレクションを使用する必要がないため高速に動作する。また生成されたコードを直接読めるためブラックボックスがないことがいいことで、デメリットとしては別でマイグレーションツールを使用する必要がある。

GORMは一般的なORMで少ないコードで簡単なDB操作ができる。SQLBoilerとの比較では、フィールドに入力した値の型が違っていた場合、リフレクションを使用しているため、エラーとして出力されないという点がある。逆にマイグレーションには対応している。今回はまだ難しいクエリは使わないため、簡単にかけるGORMを採用した。

後から知ったが、この記事がとても分かりやすいと思った。

アーキテクチャ

クリーンアーキテクチャを採用。修正範囲が少なく、修正しやすいという理由で選定。
大まかな説明が書いてあるこちらの図が有名

今まで、MVCで開発していた経験があった。コード量が増えてくるとモデルの処理がとても分かりにくかったりして、修正のタスクがとても大変になってしまっていた。レイヤーごとに依存関係がバラバラであるため修正の範囲がとても大きくなっていた。これがとてもストレスで修正タスクがとても嫌いだった。

他にも、テストが書きやすいというのもある。interfaceをmockするだけでほとんどのテストが書けるため、想定通り動いていることを担保でき、修正があっても安心して開発に集中できる。

AWS

アプリケーション開発に集中できるようにクラウドマネージドなサービスを積極的に使うことで開発にスピードを持たせる。構成はとても簡単で、以下に示す通りです。

ECS Fargate

Dockerのコンテナを乗せるだけで、運用管理、保守、監視などをよしなにやってくれるため採用

よくEKSと比較されるが、現状複数サービスに渡るほど大きなプロダクトではないためKubenutesを使用していない。そのためEKSは必要ないと考えた。

RDS PostgreSQL

今回RDSを採用したのは、お金の問題もあるがサブのDBを使用するほど大きい開発をしていないためである。サブのDBや環境を用意すると、サブを使用するときにスムーズに移行できるようにインスタンスのキャッシュを引き継ぎたい。これを引き継げるようにしたのがRDSのAuroraというサービスである。この利点は今回の小規模な構成には必要ないと判断してRDSを選定した。

現在の状況

現状、バックエンドは最低限の機能を実装したものがAWS上にリリースされている。フロントエンドはvercelを使用してデプロイしようとしているところ。
開発していく中でエラーが出力されないことが思っていたより苦労したため、今後はマイグレーションはGORM、ORMはSQLBoilerという形に改善していきたい。
CICDを実装途中でGithub Actionsを使用して実装している。
テストは単体テストが一部実装できたが、全体をもっとテストしていく。

まとめ

一旦最低限動くプロダクトを作成できた。しかしテストや改善点、フロントのリリースなどがかなり残っているためそこを詰めていき、β版のリリースを行いたい。

そこでのフィードバックと、本来の構想を実現させるα版をリリースするところを目標に完成させたい。

今回は自分の開発で考えていたことをまとめた。絶賛就活中で、技術力にはまだまだ自信がない。しかし自分の目指す将来像はプロダクトを牽引する存在である。実際に今回開発してみてとても楽しかったし、研究などのタスクがなければもっとのめり込んでやりたいと感じた。

自分で0からプロダクトを考えて実装していくのは当事者意識を持って開発できてとてもいい経験だった。これからも当事者意識を持って開発に携わっていきたい。