バックエンドエンジニアがFlutterで「お気に入りのWebコンテンツ」を管理するアプリを作ってリリースした話
1年ほどかけて作ったアプリをリリースしたので、記事にしました。
普段はバックエンドエンジニアとして仕事をしていてアプリ周りの作業に関わることが全くなく、その分個人開発では苦労と学びをたっぷりと得られたので、それを共有できればと思いました。
リリースしたアプリ
ダウンロードはこちら
（現在はiOSのみ対応です）
作ったきっかけ
アニメを観るのが好きで、日頃から1作品視聴してはiOS標準のメモ帳に作品名を入力し、視聴済みの作品を箇条書きで蓄えることをしていました。
こんな感じです↓
箇条書きをしていた理由は、「自分のコレクション欲を刺激したい」、「人にお薦めするときとかのために頭を整理したい」ですが、次第にもっとこう管理できたらいいのにという改善案が湧いてきました。
- 見やすい一覧リストにしたい
- もっと手軽に登録したい
- 見ててなんとなく楽しい一覧リストにしたい
- 人に推しやすいように特にお気に入りの作品を優先表示したい
上記を実現するために、アプリを作るに至りました。
どんなアプリ？
アプリのタイトルはOshili。少しふざけた感じのタイトルに見えるので、ストア申請でリジェクトされるんじゃないかと不安になってました。笑
Oshiliには主に以下の機能があります。
- リストの一覧・登録
- リスト内のアイテムの一覧・登録
- 検索（ユーザー検索、リスト検索）
| マイページ | リスト | アイテム | 検索 |
|---|---|---|---|
 |
 |
 |
 |
特徴的なポイントは、以下の通りです。
- ヘッダーに画像やタグを設定したり、アイテムの優先順位を設定してリストのカスタマイズができる
- ShareExtensionを実装しているので、他アプリからのシェアで簡単にアイテムの登録ができる
| 手順1 | 手順2 |
|---|---|
 |
 |
技術スタック
Figma
デザインの作成にはFigmaを使用しました。
頭の中のデザインをサクッと目に見える形にでき、ナビゲーションも簡単につけられるのでよかったです。
ただ、実際に画面実装が進むにつれ、Figmaではなく実機で実装→確認を繰り返すようになり、最終的にはFigma上のデザインと完成版のデザインがけっこう大きく異なってしまいました。
デザインガイドラインをきっちりと定めたり、デザイナーや他のエンジニアを含むチーム開発だと、よりFigmaを使う意義があったかもしれません。
Flutter
クライアントはFlutterで実装しました。
Flutterを選んだ理由は、できるだけ学習コストをかけずにマルチプラットフォーム開発をしたかったのが大きいです。今までアプリ開発をしたことがなかったので、iOS向けにSwift、Android向けにKotlinみたいに学習するよりかは遥かに楽だと感じました。
ただ、結果的にiOS向けにしか初期リリースしていません。マルチプラットフォーム開発ができるといっても、Android用やWeb用に実装するとなると、UI的にも分岐の実装が増え、リリース前にモチベーションがもたなくなりそうだったので、初期リリースはiOSに限定することにしました。
Firebase
バックエンドは全てFirebaseの以下の機能を使って実装しました。
- Firestore Database
- Authentication
- Functions
Firestore Database
アプリで使用するデータの永続化は全てFirestore Databaseを使用しています。
サーバー実装でのバリデーションやRDBに慣れているので、Firestore独自のセキュリティルールやデータ構造設計に最初戸惑いました。
学習は、公式ドキュメントと併せて以下の書籍で行いました。
Firestoreを使用する上で、知っておいた方がいいことを体系的知れるので重宝しました。
Authentication
Google認証とApple認証をAuthenticationで使用しています。
Functions
Functionsでは以下のようなユースケースで使用しています。
- 読み込み最適化をしたい + 書き込み結果をユーザーにリアルタイムにフィードバックしなくてもいい
- ユーザーの各リストに保存されているアイテム数の保存
- 各タグが使用されている回数（人気のタグを算出するために使用）の保存など
- 処理時間のかかるタスク
- 退会処理など
大変だったところ&学んだこと
一人でこなすタスクの幅が広い
企業でエンジニアの仕事を行う場合、「設計・開発中心。バックエンドを担当」といった感じである程度自分の担当範囲が狭められ得意領域にフォーカスすることが多くなりますが、一人で個人開発をする場合、普段の何倍もの種類のタスクに手を出す必要があります。
参考までに、以下が開発に関わるドキュメントの大項目です。（Notionで管理していました）
- 企画
- 設計
- デザイン作成
- 開発
- 開発・運用の費用見積もり
- 規約やプライバシーポリシーの作成
- リリース作業（ストア申請など）
といった感じで、開発と同等かそれ以上に開発以外のタスクをこなさなければなりません。
中には苦手だったり経験がないものもあるので、質の担保やモチベーション維持が難しくなる場面がありました。
リリース作業に関しては、「リジェクト→アプリ修正→再申請」という流れが何回か続き、特に以下のリジェクト理由は対応が大変で少し面食らってしまいました。
- サードパーティーのログインサービスを使用する場合、Apple認証を入れる必要がある
- UGCが含まれるコンテンツはレギュレーションを厳しくする必要があり、ユーザーによる通報、ブロックができる機能を入れ、アプリ使用前に利用規約に同意させる必要がある
アプリエンジニアの方にとっては常識かもしれませんが、初見でこれらを見越すのはなかなか難しいと思うので、やはり経験がものを言うかなという気がします。
開発以外にやることが多いので、せめて開発では負担を減らすように、自分の使い慣れた技術スタックで開発をするという工夫が必要だと痛感しました。
モチベーションの維持
今回の個人開発はほぼ自分のモチベーションとの勝負でした。開始から1,2ヶ月はモチベーションを高く維持させることができますが、それ以降はモチベーションがどんどん低下していきました。仕事が忙しくなると個人開発が面倒くさくなってしまったり、他のものを作りたくなってしまいます。
開発期間は1年ほどですが、開発を進めていた実質の期間はずっと短いと思います。
次に個人開発をするならば、1,2ヶ月の短期集中で開発・リリースを目指すだろうと思います。機能もその期間に収まるように厳選して、ベータ版をリリースしながらユーザーの反応を見て開発・運用するのが理想なのかなと思いました。
今後
Oshiliは自分自身が使いたいアプリなので、Firebaseの無料枠内に収まっているうちは細々と運用を続けていこうと思います。
もし、ユーザー数が増えてFirebaseの無料枠内に収まらなくなることがあれば、最初から想定していた以下のような機能を入れ、サブスクリプション&買い切り型のマネタイズも考えたいところです。
- Android版をリリース
- Webサービスをリリース（リストのシェアができるようになる）
- リストの種類を増やす（場所や映画など）
Discussion