この記事は、人生で初めてサービスの「0 to 1」を経験したダイエットアプリ「Udada（ウダダ）」の開発振り返り記事です。（なお、現在はサービスを終了しています。)
はじめに
「Software Maestro 第15期」に合格し、その過程で単にアプリを作るだけでなく、「実際のユーザーを集め、価値を提供しよう！」という目標を立てました。
そのため、チームビルディングにおいても、技術力だけでなく「ユーザーのためにディープダイブできるメンバー」を探しました。
「今でも鮮明に覚えている「Software Maestro」の面接」
企画
アイディエーションでは様々な候補が出ましたが、最終的に「ダイエットをサポートするアプリケーション」を作ることに決まりました。
その理由は、
- チームメンバーの周囲に、ダイエットで悩んでいる人が多かったこと
- ダイエット市場の規模が予想以上に大きいこと
- ベンチマークにできるアプリケーションが豊富だったこと
しかし、これらの中でも最も強力な動機は、先ほど述べたように「ユーザーに価値を提供できるか？」という点がチームの目標だったため、素早くフィードバックを得られるという点からダイエットアプリの制作が決定しました。
MVP(Minimum Value Product)
私たちのチームは、海外で展開されている diet bet や、韓国国内のサービスである「ランボディチャレンジ」を参考に、次のような仮説を立てました。
そして、この仮説を検証するために2つの最小機能を設定しました。
- お互いのダイエット状況を共有できる「チャット機能」
- 保証金をかけたミッションを付与し、ユーザーが継続して参加できる仕組みの用意
これらの機能をいかに早く実装するかを検討した結果、私たちは「カカオトークのオープンチャット」を活用し、ユーザーが共にダイエットに励める環境を用意しました。
[カカオトークオープンチャットの「お知らせ」]
ユーザー募集
MVPの設定が完了したので、次はMVPを利用するユーザーを募集する必要がありました。
私たちは、主に以下の2つを実施しました。
- ランディングページ（LP）の構築
- Meta広告（Meta Ads）の活用
まず、ランディングページについては「SlashPage」を利用し、迅速に構築しました。
| ランディングページ（LP）トップ | ランディングページ（LP）詳細 |
|---|---|
 |
 |
プロモーションについては、Meta広告（Meta Ads）を運用しました。
このMVPを運用した結果、実ユーザー46名、計10期まで運営することができました。算出された指標を通じて、「仲間と一緒に取り組むダイエットに価値があるか」という仮説に対し、一定の手応えを得ることができました。そこで私たちのチームは、本格的な「開発」へと進むことを決定しました。
| MVP運用の様子 1 | MVP運用の様子 2 |
|---|---|
 |
 |
開発技術の選定
開発スタックを決定する前に、私たちの優先順位を改めて整理しました。
- 素早く開発し、より早くユーザーに届けられるか？
- コア機能を実装できるか？
上記の優先順位に基づき、スタックは以下のように決定しました。
- Client: Flutter (マルチプラットフォームを迅速に構築するため)
- Server & DB: Supabase (迅速なサーバー構築、PostgreSQL、Realtime機能の提供)
開発・実装
実装された「Udada」の主な機能は以下の通りです。
まず、ユーザー同士が同じルームでダイエットを進められるよう、チャット機能を実装しました。
次に、進行中のチャレンジ状況を確認できるよう、ダッシュボードも作成しました。
「チャットルームで食事内容や体重を認証すると、リアルタイムで更新される仕組みです。」
また、レポート機能も閲覧できるようにしました。
「チャットルームで認証した食事内容をAIが自動計算し、データが更新される仕組みになっています。」
多くの機能がありますが、上記の3つがコア機能となります。
再びユーザー募集
今度はマーケティング予算がなかったため、私たちのチームは Threads を活用してオーガニックにユーザーを募集しました。
「私もダイエットをしたことがあるけれど、一人でやるのは本当に辛かった…。でも、仲間と一緒にやったら元気も出たし, 実際にダイエットにも成功したよ！」といった、ユーザーが実際に抱える「ペインポイント」に寄り添った内容を中心に投稿しました。
「Threadsでのユーザー募集投稿の様子」
最も幸せだった瞬間
アプリをリリースしてから、約4ヶ月間このサービスを運営しました。
その過程で発生するチャットのバグを修正したり、プッシュ通知を実装したり、ユーザー管理のための管理画面（バックオフィス）を構築したりもしました。
しかし、最も幸せだった瞬間は、機能開発を完了した時ではなく、ユーザーの方々が「このアプリのおかげでダイエットに成功したよ！ありがとう！」というメッセージをチャットルームに送ってくださった瞬間でした。
サービス終了の経緯
ユーザー規模の拡大という側面において、目標達成までにはまだ相当な時間を要すると判断し、運営を終了することにいたしました。
実際、Threads以外にもサービスの認知度を広げるため、様々なショート動画を制作してトラフィックの確保を試みました。
しかし、それを実際のユーザー流入やコンバージョンに繋げるためには、想像以上のリソースと継続的な努力が必要であることを痛感しました。
サービスの成長にはさらなる時間が必要な状況でしたが、私個人としては「バックエンドエンジニア」としてのキャリアを本格的にスタートさせたいという強い意志がありました。
そのため、チームメンバーに正直な想いを伝え、話し合いの結果、サービスを離れる決断をいたしました。
足りなかった点
「ユーザーにより早く届ける」というチームの目標を優先したため、技術的な習熟度が不足しており、「トラフィックが増大した際の安定性をいかに確保するか」といった悩みまで深く掘り下げることができませんでした。
今後は、こうした不足している部分を補完し、学んだことをブログなどでアウトプットしながら、エンジニアとしての実力を高めていきたいと考えています。
結論
「Udada」の運営を通じて、むしろ「自分自身」についてより深く知ることができたと感じています。
単にアプリケーションを実装したという経験にとどまらず、
「自分」という人間がこれから人生をどう歩んでいくべきか、どのようなことに没頭し、幸せを感じるのかを再確認する機会となりました。
また、自分の不足している点についても明確に理解することができました。
要約すると、以下の通りです。
- 自分は「誰かに価値を提供すること」に幸福を感じるS
- そして、その価値を提供する手段が「バックエンド技術」である時、最も幸せを感じる
- 素早い実装は得意だが、技術的な深みはまだ足りない。再びディープダイブしよう
この記事の中で誤った情報や、より良い手法などに関するご意見がありましたら、フィードバックをいただけますと幸いです。
最後までお読みいただき、ありがとうございました。