275
170

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

個人開発でやってはいけないことを全制覇しつつもダイエットアプリをリリースできた話

Posted at

はじめに

smakと申します。
初めてWebサービスをリリースしたのでその奮闘をここに記します。

作ったもの

アプリとは言っていますがWebアプリです。
ダイエットアプリですがサボりを提案してくるようになってます。
気になる人は試してみてください〜

個人開発でやってはいけないこと

  • いきなり作り始める
  • 新しい技術を3つ以上使う
  • 開発に3ヶ月以上かける
  • 完璧にできるまでリリースしない
  • 必要以上に機能を盛り込む
  • 1人で全部やる
  • 自分が使わないサービスを作ってしまう

全制覇

上のものはすべてやってしまいまいした。
だからといって後悔してるとかは無いですし、逆になにか戦略があるのかというとそうでもないです。
成り行きに任せていたらこうなっていました。

開発スタート

いきなり作り始める

2022年5月ごろだったと思います。

そもそもの開発テーマは昔からあったので何年も前から頭の中では考えていましたが
いきなりコーディングから入りました。

テーマのきっかけは、私がすごく痩せていたのを改善したくて増量について調べて実践したら、面白いほどうまくいったのでこれは自分のパターンも逆パターンも需要が腐るほどあるだろうと考えたからです。

そして最初に考えることとは「技術選定」です。
ここでかなりの挑戦をしました。

経験もあり慣れていたのはVue。
どう考えてもVueで開発するべきですが、私が選択したのはReactでありNext.jsでした。
理由は使ってる人が多いからで、今考えてもこの選択は正解でした。
(8割くらい完成したタイミングで試しにNuxtでも同じアプリを作ってみたところ、うまく言語化できない開発体験の差を感じたのと、詰まったときの先人の知恵のなさが決め手です)

最終的に使用技術は以下となりました。

  • Next.js
  • Vercel
  • MUI
  • Firebase
  • Stripe
  • SendGrid

完璧な布陣。王道であり鉄板。流行への憧れ。

この中で経験があるものは?
そうです、ゼロです。

そして必然かの如く開発期間は数ヶ月をあっという間に過ぎました。
合計8ヶ月くらいですかね

完璧にできるまでリリースしない

これもやっていまいましたねぇ
ただこれには少々反対で、リリース時にはある程度のクオリティを持った状態にしたいと私は考えています。
理由は、第一印象で「いい感じやん」と思われたいことと、ユーザーの目は肥えていると思うからです。私ならデザインや体験がイケてるサービスを好んで使います。代わりがいっぱいあるから。
ただ、リリースもしてないくせに行間1ピクセルにこだわってた時間はまじで何やってんだとは思っていました。

必要以上に機能を盛り込む

そうやって見た目にこだわっていると機能にもこだわり出してしまいました。

ダイエットアプリなんてものは世の中には溢れているので、私のアプリを選ぶ理由を考えます。
導き出した答えは「ダイエットをサボれる設計にすること」でした。

そうすると色々と厄介な仕様がうまれました。

  • 未来の体重を予測できるようにしよう
  • 予測できるならゆとりも見えるだろう
  • 週間で統計をだしてサボりの提案をしよう
  • 週末に〇〇くらいサボってもXXくらいの成果はでるよって出したい

なんということでしょう。いかにも大変そう。
しかし謎のモチベーションによりなんとか作りました。

無駄な機能を搭載しちまったーとはもちろん思ってないですが、他の人からしたらそんなのあとから追加しろよってのが多いかと思います。

盛り込んだ機能の例

  • 未来予測
  • サボり提案
  • 無駄ににゅいんってなるグラフアニメーション
  • 予測をしてる雰囲気を醸し出すタイプライター演出
  • カロリー入力忘れ防止のリマインドメール
  • 予測体重と実値のずれを修正する機能
  • ダイエットブログ
  • サブスク

そしてもはや予想通りかと思いますが全部一人で抱え込みます。
いくら作りこんだって使われなければ意味ないのに。
そのための拡散にこれから一番注力しないといけないのに。
いまはダイエットブログの執筆に頭を抱えています。(まじでこれこそ世の中にはもう無限にある)

自分は使わない

これは一般的に最大の致命傷でしょう。
なぜ自分が使わないものを8ヶ月もかけて作り続けられたのか。
それは「このアプリのおかげでダイエットできた」って人ができればいいなと本気で思ったからです。

それだけでは持続できないのでマネタイズも考えてはいますが。
これが叶ったらその人は自信がつくでしょうし、声が届けば私にも自信がつきます。

この記事に偶然にもたどり着き、試しに使ってみてもいいよって方は是非とも宜しくおねがいします。

技術の話

こうして初めてだらけの開発をおこなったわけですが、すこしだけ技術にも触れておきましょう。

React無限レンダリングの恐怖

useEffectに慣れておらず、無限レンダリングは何回かやってしまいました。
ただ無限レンダリングする分にはやっちまったーですぐ直せばいいのですが、これがfirestoreの読み込みと絡んだら激ヤバです。
そこで万が一の対策としてクライアント側に1時間あたりの読み込み上限をつけることにしました。方法はLocalStorageでカウントアップして監視する原始的なもの。

firestoreの設計

RDBMSしか触ってこなかったので何もかもわかりませんでした。
が、mogaさんの動画をリアルに何十回と見てたら無事完全に理解できました。
感謝しかないです。firebase使うなら本当におすすめ

何度か設計しなおしが発生しましたが最終的にシンプルに実装できました。
これだけです。

users:
  documentID: uid
  # ユーザデータたち
  # 身長・年齢・基礎代謝など

  dailies:
    documentID: yyyymmdd
    # 日次の記録たち
    # 摂取・消費・予測 全部ここ

Stripeは神

本当にいい時代になってました。
拡張機能を入れて手順どおりにやったらあっという間に実装できました。Stripeがなかったら個人でサブスクサービスは作れないな。。
難しかったのはサブスク中かどうかの判定の部分なのでStripeではなくfirebaseに手こずりました。
ネットで漁ってもあまりにも記事がなく、「これで正解か・・?」と思う場面ばかりです。

フロントの出し分け方とルールの書き方。ここは気が向いたら別記事にでもしようと思います。(気は向かないかもしれない)

SendGridは特に言うことなし

すごくシンプルで簡単でした。
メール送るならこれでいいでしょう。

あとがき

大げさなタイトルにしてしまいましたが初めてなら誰しもが通る道かと思います。
しかしこの開発のおかげでモダンな流行技術を使えるようになって大満足という結果に。

一番流行ってるっぽい技術なだけあって『なんとなく強くなった気がする』などの効果も出ており、次のサービス開発の妄想が捗って夜も眠れません。

とりあえず初めてのリリースを無事終えて一安心。
ダイエットアプリはこれからじっくりコトコト育てていきます。

ちなみにSlappyの由来は、sloppyという"だらしない"とか"いいかげん"という単語と"スラッと"という語感をあわせた造語です。
ではまた!

275
170
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
275
170

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?