個人開発のアプリを5年間で40万ダウンロードさせた話
この記事は CyberAgent 22 新卒 Advent Calendar 3日目の記事です。
はじめに
みなさんは個人開発をすることはありますか？ また、1つの制作物についてどのくらいの期間開発を続けていますか？ この記事では、個人で開発したアプリを継続的にアップデートし、5年間で40万ダウンロードを達成した事例について紹介します。
自己紹介
この記事を書いているのはこんな人です。
- 情報系の大学に在籍
- 中学生の時に Java に触れ、高校生の時にアプリ開発（Android）を始める
- その後、その時々の作りたいものに応じて、 iOS, Unity, Laravel, Next.js... での開発を経験
- Android エンジニアとして働く予定
開発しているアプリ
「暗記メーカー」という学習支援アプリを開発しています。
このアプリは、問題集の「作成」「解答」「共有」に特化しており、テスト勉強や資格習得のための勉強の効率化を目的としています。
複数の問題形式に対応しているところや、問題集の「作成」「解答」だけならアカウント登録不要（オフライン）ですぐに使い始められる点などが類似のアプリとの差別化点となっています。
| 紹介画像1 | 紹介画像2 | 紹介画像3 | 紹介画像4 |
|---|---|---|---|
 |
 |
 |
 |
Android：
iOS：
紹介ページ（ブラウザ版）：
技術的な要素
「暗記メーカー」を支える技術を紹介します。開発が長期間続いていることもあり、新旧の技術が入り混じった状態となっています。定期的に最初から作り直したくなる衝動に駆られる...
-
Android
- Kotlin, Jetpack Compose, Coroutines, LiveData, Databinding, Epoxy, Navigation, Koin, Realm...
-
iOS
- Swift, SwiftUI, SnapKit, Realm, RxSwift, Combine...
-
フロントエンド
- TypeScript, Next.js, Tailwind CSS
-
バックエンド
- Firebase
- Authentification, Storage, Firestore, Cloud Functions, Crashlytics, DynamicLinks
- Firebase
-
その他
- Bitrise： CI， CD
- AppFollow： レビュー管理， ASO 周りのサポート
- RevenueCat： 課金周りの実装をサポート
- IFTTT： Twitter での定期的なエゴサーチ
- Figma： ロゴやストア用のスクリーンショット作成
- Slack： レビュー， 問い合わせ， エゴサーチ結果， クラッシュログの集約
いろんなサービスを行ったり来たりするのが面倒なので、 流れてくる情報を Slack 上にまとめることを意識しています。
開発を続けていく中で
開発を続けていく中で、やって良かったことや後悔していることをいくつか紹介します。
複数のモチベーション
自分は飽きっぽい性格なので、複数のモチベーションをもってアプリ開発に取り組めたのは結果的に良かったと感じています。具体的には、以下の要素が開発のモチベーションになっています。
- 自分のテスト勉強を効率化したい
- 新たに知った技術やツールの素振りがしたい
- 「ユーザ数」や「収益」といった数字を伸ばしたい
ただ2番目については注意が必要で、その技術が本当に自分のアプリにとって必要なのかを考えてから取り組むべきだと思います。（例：大人数の（大規模な）アプリ開発を前提としたアーキテクチャを採用しようとして、ただコードが冗長になるだけで終わる等）
維持コスト
せっかくアプリを公開しても、赤字を垂れ流しながら開発し続けるのは精神的にしんどいです。自分のアプリでは、「ほったらかしでも（経済的に）問題ない」を意識しながら開発しており、維持コストを気にしなくても済むようにしています。具体的には以下のような取り組みで維持コストを削減しています。
- Android 版の広告収入の推移を見ながら、App Store の年会費を払っても問題なさそうなタイミングで iOS 版をリリースする。
- 基本機能をクライアントで完結させ、バックエンド部分のコストを抑える。
- 共有したい問題集のみをサーバ上にアップロードする形となっているので、従量制課金と相性が良い。
- ただ、これはユーザのデータが収集しづらいというデメリットでもある。
- アプリのタイトルを分かりやすいものにする。（テスト勉強用アプリ「暗記メーカー」）
- これにより、広告宣伝費をかけることなく検索流入でのダウンロードが見込める。
- 「テスト勉強」，「問題集」，「暗記」での検索上位をキープ。
- 特に、テスト週間の時期にダウンロード数が大きく伸びている。
- ツール系のアプリの強みはここ。世の中に「勉強したい」という需要がある限り、ユーザが勝手に見つけてダウンロードしてくれる可能性がある。
- 逆にいうと、不特定多数に紹介しても、勉強する用事がなければ「とりあえず触ってみる」的な機会は生まれにくいため、短期的にダウンロード数を伸ばすのは難しい。
- これにより、広告宣伝費をかけることなく検索流入でのダウンロードが見込める。
| Android | iOS |
|---|---|
 |
 |
...当たり前ですが、不具合修正や OS のアップデート対応はほったらかさないよう心がけています。
収益面
費用面の話をしたので、収益面の話をここでしておきます。
「暗記メーカー」では広告収入と広告削除（課金アイテム）が収入源となっており、メインは広告収入となっています。リリース当初は収益もさっぱりでしたが、着実にユーザが増え続け5年も経った今ではアルバイトの代わりくらいには稼げるようになっています。特に試験のある時期の伸びは大きく、もし年中テスト週間なら仕事をせずとも何とか生きていけそうです。
また、前述した通り維持コストも小さく抑えられており、最低限問い合わせの対応やバグ修正をするだけでサービスを維持できるので、「（ほぼ）不労所得」としてとても優秀だと思います。
広告収入 or サブスクリプション？
アプリの主要な収益源としては「広告収入」と「サブスクリプション」があります。このどちらを使うかについては、色々考え方があると思いますが、自身のアプリでは以下の理由から「広告収入」を採用しています。
- 1回の起動あたりの滞在時間が長い
- 基本的にアプリ内でコンテンツ（問題集）を編集するため、ユーザ一人当たりの平均滞在時間が 30分 〜 1時間程度と比較的長めになり、バナー広告と相性が良い
- 長期間の利用を想定したアプリでない
- 大多数のユーザの利用期間が「テスト週間や資格試験の1週間〜1ヶ月前」なので、数年数ヶ月の継続利用を前提としたサブスクリプションとは相性が悪い
広告の方が実装が楽
両ネイティブでの開発
「暗記メーカー」では、Android → Kotlin， iOS → Swift といったように、それぞれネイティブでの開発を行なっています。
iOS 版の開発（移植）をスタートするタイミングで Flutter や React Native のようなクロスプラットフォームを利用するかどうか迷ったのですが、そもそもネイティブの知識がないとクロスプラットフォームの開発もどこかで詰まるのではないか、また、詰まった時に iOS の問題なのかクロスプラットフォーム側の問題なのかの切り分けが困難になるのではないか、と考え、勉強の意味も込めてネイティブで開発することにしました。
ただ、開発が長期化するにつれ、修正の手間が2倍になるのは個人開発としてはなかなか厳しく、「暗記メーカー」の機能的にも OS のパフォーマンスをフルに発揮するという状況はあまりないため、今振り返ると「クロスプラットフォームで開発しとけば良かったのかもしれない」と若干後悔する時もあります。ただ、今では UI デザインをそれぞれ独立して作れるのは強みの一つだと感じています。（後述）
ローカライズ
「暗記メーカー」はユーザが各自で問題集を作成するタイプのツール系アプリであり、開発者側でコンテンツを用意する必要がありません。そのため、ローカライズとの相性が非常に良いです（ボタン等の文言を変えるだけで良い）。ですので、ツール系のアプリを作成する際はとりあえず英語版も作成することをお勧めします。特に、日本以外の国では Android の方がシェア率が高い場合が多いので、Android アプリを開発する場合、ローカライズの優先度は高くなります。
（両 OS ともに英語でのローカライズを実施済み） 上記のグラフからもわかる通り、iOS 版の大半が日本ユーザなのに対し、 Android 版はアジア諸国を中心とした様々な国で利用されています。
なお、ローカライズに味を占めアプリ内の文言をひたすら Google 翻訳して多言語化を試みたこともありますが、中途半端に現地の人の目に止まった挙句「アプリ内文言の意味がわからない」等の星1レビューを連発されたことがあったため（ロシア語）、現状英語以外のローカライズは行なっていません。
ユーザの声を聞く
レビュー、問い合わせ
開発のモチベーションを維持したり、機能の改善を行う上で、ユーザの声に耳を傾けてみるのは非常に重要です。実際、現時点では送られてきた問い合わせやレビューには可能な限り返信することを心がけています。とはいえ、ユーザの要望を全て答えるのは工数的にも厳しいのみならず、アプリの方向性が曖昧になってしまうため、自分の中では 「暗記メーカー」をなんでもできるアプリにしない という考えで機能追加を行なっています。これにはいくつかの理由があります。
- 多機能になることによって、既存の動線が煩雑になることを避けたい
- アプリの目的がブレると、検索流入でダウンロード数を稼ぐのが難しくなる
- メンテナンスコストが増え、主要な機能に時間をかけ辛くなる
以下、実際にもらったレビューや問い合わせの例
- 問題に画像を添付したい → 採用 （「問題集の作成」の範囲内で多くのユーザにとって有益だと判断）
- 間違えた問題のみ出題できるようにしたい → 採用 （「問題集の解答」の範囲内で多くのユーザにとって有益だと判断）
- 日々の学習記録をつけたい → 不採用（既存の学習管理ツールと併用することで実現可能と判断）
- 英語の発音を確認したい → 不採用（恩恵を受けるユーザが限定的なため、英語に特化したアプリを利用した方が良いと判断）
ユーザテスト
レビューや問い合わせの他にも、非エンジニアの友人や家族にたまにお願いしユーザテストを行うようにしています。特に個人開発だと、開発者自身がアプリケーション内の挙動を把握しており、アプリを利用する際に「迷う」ことがないので、初見のユーザがどのような意図でアプリを使うのかを見たり聞いたりするのはアプリ内の動線を改善していく上でのヒントになります。
以下、実際にもらった感想の例
- 「何が起こるかわからないボタンをとりあえず押してみるというのは抵抗感がある」
- 自分がとりあえず色々押して試してみるタイプの性格なので、ここは盲点だった
- → アイコンだけのボタンを多用せず、主要な機能に関しては「アイコン + ボタン」で表現する
- 「iOS だと長押しで操作メニューが出ないのに違和感がある」
- Android → iOS の流れで開発しており、気づけていなかった
...
- Android → iOS の流れで開発しており、気づけていなかった
これらの結果をもとに、アプリ内の動線の改善やヘルプページの作成等を行い、ユーザの離脱を少しでも減らせるよう心がけています。
ヘルプページの例
現在の取り組み
より良いアプリケーションを作っていくために、やりたいことは無限に出てきます。
そんな中現在は「ユーザを驚かせないデザイン」を目標に、 UI デザインの改善に取り組んでいます。この取り組みは、両ネイティブで実装しているという特徴を生かし各 OS のユーザにとって使いやすいアプリを提供することを目的としています。
具体的には、Android であれば Google 製のアプリ （Material Design） 、iOS であれば Apple 製のアプリ（Human Interface Guidelines） を参考にしながら、OS にプリインストールされているかのようなアプリを目指しています。
そして、各プラットフォームが標準で提供している UI コンポーネントに準拠することによって、独自のカスタマイズによる実装コストを軽減できたり、OS のアップデートによる意図しないデザイン崩れのリスクが小さくなることを期待しています。また、この方針により SwiftUI や Jetpack Compose といった UI 層まわりの新しい技術を積極的に取り入れることができています。
| リニューアル前（iOS） | リニューアル後（iOS） |
|---|---|
 |
 |
おわりに
ここまで書いてきた通り、なんでも自分でできる（やらなければならない）のが個人開発の大変なところでもあり、面白いところだと思います。「ユーザ数」や「収益」といった数字をどうやったら伸ばせるのか、を試行錯誤しながらのものづくりはある意味ゲームのハイスコアを狙うようなものでとても楽しいです。この記事を見て、一人でも個人開発の世界に足を踏み入れてくれる方がいれば幸いです。
Discussion
個人開発で頑張っているので、とても参考にできました！✨