Zenn
💻

個人開発アプリをリリースしました

に公開
個人開発
読書
idea

先日、読書管理サービス「ReadMyReads」をリリースしました。

Xで、読んだ本をシェアしてくれるひたすらありがたい方々のポストを参考にしてよく本を買っていたので、
読書のアウトプットにフォーカスしつつ、読書記録やメモを集約できるサービスを作りました。

アウトプット前提の読書は記憶が定着しやすくなり、より一層読書が有意義なものになると思います。
興味があれば覗いてみてください。
https://readmyreads.com/

初めてのリリースのため、記憶が鮮明なうちに備忘の意味も含め、今回の取り組みをまとめます。

あくまで私の一例ですが、これから個人開発を始めてみたい方に参考になれば幸いです。

技術スタック

今回使用した技術要素は主に以下です。

  • Frontend
    • React (CRA)
    • JavaScript
    • Tailwind CSS
    • MUI
  • Backend
    • Springboot(Java 17)
  • DB
    • PostgreSQL
  • 認証
    • google OAuth
  • ホスティング
    • frontend: Vercel
    • backend: Railway

ローカル認証は実装しませんでした。
理由として、アカウント発行の機会損失を極限まで減らしたかったのと
DB設計を必要最低限に、極力シンプルにしたかったためです。

新規ユーザにアカウントを発行してもらう際に、IDとPWを考えさせるのは個人的に好ましくなく、それだけで新規ユーザの流入の機会を逃しかねないと思っています。ローカル認証＋OAuthの組み合わせで選択肢を提供するのであれば問題ないかとは思いますが、最低限の実装で済ませたかったので、現状はGoogle　OAuthのみ導入しています。

ホスティングに関しては後述します。

開発

リリースまで、大まかに以下の流れで開発を進めていきました。

  1. サービスのコンセプトを決める
  2. アジャイル的に開発
  3. ある程度完成してきた段階でサービス名決めとドメイン購入
  4. ロゴ作成

以下、詳しく説明していきます。

1. サービスのコンセプトを決める

コンセプトを決めれば思想が生まれるので、開発が進めやすくなります。
この段階では、具体的にどんな機能を作るかではなく、どんなサービスにしたいかということを最初に固めていきました。
ターゲットはどんな層なのか、このサービスを通してなにを実現したいのか、など。

例えば、
"本好きな社会人が気軽に読書を共有できるコミュニティを作りたい" だとか、
"普段は読書記録をつけない人でも、簡単に読書を集約できるようなサービスにする"
みたいな具合です。

2. アジャイル的に開発

コンセプトをある程度固めたら、
設計を組み立てる⇒コードを書く⇒設計を見直す⇒実装
みたいなサイクルを回しまくりました。

今回は画面のUIを考えながら同時に開発をしていったので、実現したいUIに合わせて必要なデータが取れるAPIをPostmanでテストしながら作成する、みたいなイメージです。

UIにはある程度ベストプラクティスがあるので、いろんなサービスを見て参考にすると良いと思っています。それを自分のサービスにどう落とし込むかは自分次第なので、ここで開発者の思想が出てきます。

アイデアが固まらないままにコードを書いては機能を思いついて再び進捗が停滞するといったことを繰り返していたので、（この過程が楽しいのですが）最低限完成させる機能を決め切ってしまって、追加分はリリースしてから実装する方が、だらだらとリリース日を引き伸ばさずに済みます。

設計書は必要？

そもそも複数人での開発ではないため、認識のすり合わせが必要ないのは前提として
設計書の必要性の有無については場合によると思っています。

私は今回、いわゆる業務で見られるようないわゆる設計書に類するものは作りませんでした。
強いて言えばUIデザインをパワポに描いてモックのようなものは多少作っていましたが、
複雑な機能を作っているかと言われればそうではなく、
ライフサイクルもそこまで厳密に決める気はなかった（というよりシステムの性質的に必要性があまりない）ので、ドキュメント書いてる暇があるなら実装を進めた方がいい、と判断してのことでした。

ただ、実際これをすることの弊害もあると思っていて、
「あの機能にくっつけるこのバリエーション忘れてた」
みたいな出戻りは結構発生したし、リリースしてから基本的な機能の漏れみたいなのに気づいたりしたので、そこは気をつけるべき点かなと思います。
そのレベルはドキュメントを作らないにしても、適切にタスク管理していくべきです。

3. ドメインの購入

勉強目的であれば特段不要かと思いますが、
長期運用やマネタイズを見据えているのであればドメイン取得は必須だと思います。

Vercel, Railwayともにサービスに対するURLは自動で発行してくれますし、自動的にSSL認証通してくれますが、PaaSドメインだと一見して何のサービスかわからないし、サービスとしての認知度、信頼度は上がりにくいためです。

サービス名 = ドメイン名だとユーザの認知が上がりやすいので、
しっくりくるサービス名を考えられたら、とりあえずドメインは買っておいた方がいいと思います。
ただし、気に入った名前を思いついても、既に同様の名前で同じようなサービスがあるとSEOで埋もれてしまうので、このあたりは割と早い段階で気にしたほうがいいです。

私は今回、お名前.comでドメインを購入しました。
ドメインレジストラごとにドメインの価格は異なるので、
自分が購入したいドメインが比較的安く買えるところであったり、サポートが充実しているところを利用すると良いと思います。
あとは、ドメイン購入だけではなく、その後DNS設定したりするので、UIが良いとか、使い続けたいかみたいな視点もある程度考慮すべきかと思います。

4. ロゴ作成

サイトのアイコンとなるロゴを作成します。
サービス名、ドメイン購入が完了したタイミングで取り掛かることをお勧めします。

Webアプリにおいて必要なアイコンは最低限以下の2つだと思っています。
・ファビコン(favorite icon）
・OG(Open Graph image)

ファビコンとは

chromeの検索結果画面で表示されるアイコンや、ブラウザタブ、あるいはブックマークに使われるアイコンを指します。
icon image
tab image
ファビコンは、Reactであればindex.htmlで次のように指定することができます。
なお、ここで指定するのは、publicフォルダに格納されている画像です。

index
<link rel="icon" type="image/png" href="%PUBLIC_URL%/example.png" />

画像サイズは、32×32px または 64×64pxがベストです。

OGとは

SNS等でURLを共有する際に表示されるアイコンを指します。
ここで指定する画像サイズは1200 × 630 pxだとうまくハマります。
for SNS image

index
<meta property="og:image" content="%PUBLIC_URL%/example.png" />

ちなみに、Zennなどのように、サイト内にもロゴがあると一気にそれっぽくなるのでおすすめです。

ロゴに関しては、ココナラとかでデザイナーさんに依頼して作ってもらうとかも選択肢としてアリかと思いますが、私はChatGPTに作ってもらいました。

ただ、ChatGPTでの画像生成はまだ割といい加減なところがあって、モデル4oで細かい部分を修正してもらうように指示してもそのまま返ってきたりするので、ある程度まで作ってもらったらPhotoshopとか使って完成まで持って行った方がいい気がします。
あるいは、最も画像生成に適したAIサービスを利用するのがベターかもしれません。

ロゴの他にも、サイトのキャプションなども指定できるので、併せて設定しておくと良いです。

リリース

実装したい機能が一通り問題なく動くようになり開発がある程度落ち着いた段階で
すぐにデプロイしたかったので、PaaSにデプロイすることにしました。

Railwayを使ってみましたが、UIが素晴らしく、使いやすいという感想でした。あまりここの選定に時間をかけたくなかったので即座にPro会員を登録しました。
※無課金のまま使いたかったのですが、そのままデプロイすると、サーバのメモリ不足ですぐにcrashしちゃってたのでまともにビルドできず。会員アップグレードが必須でした。

なお、デプロイ時に行った作業としては
・本番環境へ環境変数を設定する
・DBへDDLを流し込む
があげられます。
ローカルの開発環境で使っていた環境変数をそのまま本番で参照するわけにはいかないので、
本番環境の環境変数に対して別途APIキーやDB情報を設定しました。
あとは、CLIからSQLを流して必要なテーブルを作成するだけで、正常にビルドされました。

上記の手順でBackendは問題なくデプロイできましたが、Frontendは何度やってもサーバーサイドで動くNode.jsアプリとしてビルドされてしまい、GUIからだとReactプロジェクトを明示的にstaticなサイト[1]としてデプロイできず。

無理に一つのサーバーでデプロイを完結させる必要もなく、むしろフロントが得意なPaaSでホストするべきだと感じたので、とりわけReactが得意なVercelでホストすることにしました。今のところ無課金で安定的に動いてくれているし、こちらもUIが好きなので継続して使用するつもりです。

フロントをデプロイしたら、発行されたURLに購入したドメインを割り当てて、バックエンド側と問題なく連携できていることを確認し、リリースが完了しました。

今回利用したVercelやRailwayでは、紐づけたGithubリポジトリに対して
変更差分が検知されたら自動でリビルドされる、CI/CDな環境を内部的に構築してくれます。
つまり、本番リリース後にバグを修正したり、新機能を追加するとなった際
ローカルで作業して、mainブランチ（サーバに紐づけている）にpushしてしまえば
即座にサーバが自動でリビルドしてくれて、本番環境に反映されるといった仕組みです。

あるいは、GitHubに『GitHub Actions』という機能が備わっており、
これを使えば同様にCI/CDを構築できるので、
たとえばAWSのEC2などにホストする場合はこちらを個別に設定すると良いと思います。

リリース後の流れ

リリース後は、以下を実施すると良いかと思います。

Google Search ConsoleでURLをインデックス登録

Googleは常にクロールを行なっており、新規のURLを見つければインデックスを貼ってくれます。
そうしてインデックスが貼られれば、SEOに引っかかってくれるようになります。

しかし、それを待っているといつまで経っても検索に引っかからない可能性があるので、
こちらからインデックス登録申請しよう、というのがここでやろうとしていることです。
つまり、ここでいうインデックス登録とは、Googleにサイトの存在を知ってもらうための作業です。

Google Analyticsを利用し、ユーザ動向を把握

Google Analyticsとは、どんなユーザーが、どんな導線でサイトに訪れたのかなどを分析可能にしてくれるサービスです。
アカウントを発行して、自身の管理したいPJに指定のscriptを追記すれば、Google Analytics上で分析可能となります。
どの画面でユーザが離脱しやすいのかなども把握できるので、UI/UXの向上などに活用できます。

サービスを磨いていく

広く使ってもらいたいサービスであれば、ユーザのフィードバックなどを聞きながら、プロダクトとしてより良いものとなるよう継続的にアップデートをしていくのがベストだと思います。私も、リリースしたは良いものの、まだまだ満足のいく出来ではないので、これからもサービスを磨いていくつもりです。

最後に

業務とは異なり、サービス構築を100%自分でコントロールできるので、
あれ、開発ってこんな楽しかったっけ？ってなります。さらに、実際に人に使ってもらうことで
とてもやりがいを感じますし、技術的にはもちろん、より多くのユーザにリーチするようマーケティング的な観点が必要になってくるので、ソフトスキル面でみてもプラスに働くと思いました。良いことづくめですね。

以上、初リリースにあたってのまとめでした。参考になれば幸いです。

脚注

  1. staticなサイト（静的サイト）とは、サーバー処理を持たないHTML/CSS/JSだけで構成されたサイトのことです。
    毎回サーバで0からDOMを組み立ててブラウザに返す遅い処理ではなく、すでに出来上がったHTML/CSS/JSファイルをブラウザに送信し、ブラウザ上でReactがJSを実行して差分だけ再構築することで早いロードを実現しています。 ↩︎

Discussion