イチから収益化まで！個人開発アプリ制作コラム
個人開発したアプリを収益化して副収入を得ることは、開発者なら一度は考えると思います。
制作した1本のアプリから、収入を得るまでの一連の流れを完遂したので、全体的に感じたことを記録としてまとめてみることにしました。
「これからアプリを開発しよう」と思っている人や、「制作中だけど公開までは至っていない」人に向けて、よい刺激になればと思います。
目次
アプリ開発の背景
初めて私が個人開発したアプリは、スマ簿記3級という日商簿記3級の学習アプリです。
https://sumaboki3.nayutari.com/私自身はフリーランスなので、確定申告などで何かと簿記の必要性を感じる機会は多く、同じような事業者や学生にも需要があると思い、スマホアプリという媒体で簿記の学習が円滑にできる環境を作ってみたいというのが始まりでした。
また、アプリの個人開発を実現したかったもう一つの理由として、スタートアップからマスターアップまでの1サイクルを独りで完遂することで、自身の知識をより強固にしながら、技術面の好奇心を消化したいという面もありました。
今の時代は、時間を対価に報酬を得る労働と、資産的価値のある著作物を育むコンテンツビジネスといった自由な稼ぎ方ができるようになったと感じます。個人開発したスマホアプリはまさにコンテンツビジネスの1つといえますよね。
アプリの開発プロセス
スマ簿記3級の開発プロセスをスタートアップから時系列で振り返ると、以下のような流れでした。
- どんなアプリを作ろうかな
- どのフレームワークを採用しようかな
- フレームワークおよび言語の検証
- アプリの開発を本格的にスタート
- サーバーサイドの検証
- アプリの全体仕様をざっくりと割り出し
- サーバーサイドの設計とアプリ側への組み込み
- 仕訳問題や勘定科目などのコンテンツ作成
- コンテンツをアプリに落とし込む変換ツール作成
- 広告処理の組み込み
- 画像やアニメーション、効果音などの仕上げ
- アプリ用ウェブサイトの制作
- アプリストアにテスト版アップ＆デバッグ
- アプリストアにてアプリの審査・リリース
- 広告配信サービスの審査
- サードパーティAPIの審査
- バージョンアップ対応
少しピックアップして紹介します。
どのフレームワークを採用すべき？
フレームワークなんてものは、極論は個人の好みに尽きます。なので、私自身の経験からスマホアプリ開発で最低限知っておくべきフレームワークの判断基準を紹介します。
誤解を生まないよう補足すると、上記のフレームワークを推奨しているワケではなく、アプリの目的に合ったフレームワークを選ぶとよい、ということです。加えて、そのフレームワークで採用している言語の習得や、目的を実現しやすい機能を有しているかも含めて研究対象なので、選ぶところから開発が始まっているのだということも、開発の醍醐味かと思います。
機能的には、Unreal Engine を使って一般アプリの開発もできますし、Flutter でゲームを開発することもできてしまいます。ただ、目的と手段が適切でない環境で作ったアプリは、無駄に起動時間が長くなったり、処理落ちの改善に悩まされる未来が容易に想像できます。
スマ簿記3級は一般アプリの線で進めると決めていたので、私は兼ねてから気になっていた Flutter を選択しました。
ちなみに、本業では C++ や Python をよく扱うので、モバイルアプリ開発の経験は少ないものの、新しい技術を身につけることに苦労しなかった点では、私はゼロからのスタートではありません。アプリ開発はプログラミング初心者であってももちろん参入できる分野ですが、簡単に実現できると謳った謎サロンやサイトは鵜呑みにしない方が賢明かなとは思います。
アプリ用ウェブサイトを制作？
文字通り、スマホアプリをストアに公開するには、アプリを紹介するポータルサイトの設置も必要になります。ここで伝えたい事は、スマホアプリを収益化する工程において、アプリ開発以外の作業もあることは知っておいた方がよいという事です。
いくら簡単なサイトでもよいとはいえ、ウェブサーバーを手配したりドメインを手配したり…、何らかのCMSやWebフレームワークを用いたとしても、それなりに時間はかかるものです。ウェブサイトの制作経験がなければ、これに学習時間が上乗せされることになりますね。
また、プライバシーポリシーの定義と利用規約の定義といった小難しい文書の設置も開発者の義務になっています。個人開発において、このあたりの正解を探るのは少し高めのハードルです。特に個人情報を扱う場合、適当なコピペで済ませるのはアプリに対して責任が無さすぎるので、難しい言葉にも慣れていく必要があります。
「やることが多くて大変」というより「積める経験が多くてラッキー」という感覚で臨める人は、まさに個人開発は最高の贅沢ですよね。
収益化の戦略
スマ簿記3級における収益化戦略は「長期戦で定番化していく」という感じです。
長期戦が適切だと思った理由として、まず Android において簿記の学習支援アプリはいくつかあり、既にアプリが定番化されている状況なのは数字からも分析できたからです。後発で著名なアプリと同じ土台で戦うには、Google Ads といった広告媒体で知名度をドーピングする手段もありますが、ユーザーの声を聞きながらニーズ・要望をしっかり実現していく方法なら、後発であっても長い目で見てユーザーに認めてもらえるアプリに正統進化していけるはず、という想いをそのまま戦略とした感じです。
- 唯一の強みを見つけて育てる
- 使いやすさに敏感になる
- バグはすぐ直す
- 動作は速くて軽くあるべき
- 広告と正しく向き合う
- コンテンツの拡張を前提に設計
比較的、当たり前な内容だと思います。そしてこの当たり前こそが大変で、大手企業が開発したアプリであっても、起動が遅かったり、バグが残っていたりするわけです。
収益化の戦略に伝家の宝刀は存在しないと思っているので、特別な小技はなく、自分なりの考えと戦略を同じにしただけですね。
成功したポイント
スマ簿記3級において、総合的にうまくいったと自負できる部分は以下の3点です。
- テーマ設定と開発規模
- UI/UX
- 運転費計算
テーマ設定と開発規模
スマ簿記3級の主テーマは「日商簿記3級が学べること」で、開発規模は「個人開発」ということになります。つまり、最小規模の開発環境で実現するテーマとして、丁度よいバランスだったと感じています。
もし個人規模での実現が難しいくらいの大きなテーマだったなら、開発期間が年単位で増大し、飽きてモチベーションが尽きたりと、完成には至らない可能性が高かったです。スタートアップ時の開発は順調で、メイン部分まで作りきったのにリリース前にフェードアウトした経験はありませんか？
プロと素人の違いは、「技術力や経験値」もそうですが「スケジュールの制御力」が根本的に違います。個人開発とはいえ、通常業務のように開発のスケジュール感が意識できる規模だった、というのは1つの勝因だったと振り返ってみて感じました。
そういう意味で、個人開発では「完成させる」ことが難しいです。収益化を目指すなら、いつまでにリリースするのかを決め、時間ベースでそれを目指していくことがキモになることがハッキリわかりました。
UI/UX
アプリの使いやすさに直結する永遠のテーマですが、特に以下の2点を守ることにしました。
- フッターボタンの配列と機能を統一
- タップ頻度の高い機能は画面下部に配置
どうやら脳科学的に人間は場所を記憶する能力が他より高いらしいので、同じ部分をタップすれば、同じ結果が得られる状況をできるだけ再現しようと考えました。戻るボタンや、肯定系のアクションボタンがそれに該当します。この施策は結果的に UX の向上に貢献できたかなと感じています。
また、スマ簿記3級は縦持ち形式のアプリなので、タップ頻度の高い機能はできるだけ画面下部に配置して、片手操作で完結できることを目指しました。例えば、電車のつり革につかまりながらアプリで学べる状況をイメージしたときに、スキマ時間を有効に活用してもらえる機会の提供になるかなと思いました。
UI/UXまわりは書籍から情報を得るのが正直手っ取り早いです。2冊の書籍を紹介します。
運転費計算
スマ簿記3級も運転費（維持費）は発生し続けています。加えて、収入の保証なんてものは絶対にありません。そんな中、不安に悩まされることなく運営できているのには一応理由があります。
アプリの収入に対して、運転費が高ければ当然赤字です。サービスを安定して提供し続けるためにも、運転費の計算は念入りに確認すべきです。
- データベース・ストレージなどのクラウドサービス利用料（AWS、Firebaseなど）
- サードパーティAPIの利用料（GCP、ChatGPTなど）
- ストアのライセンス料（Appleは毎年99$、Googleは初回のみ）
- ポータルサイトの維持費（サーバー費用、ドメイン費用）
- など
そもそもクラウドサービスを使わなければその費用は発生しませんし、無料サービスを活用することで節約できる項目もあるかもしれません。ただ、節約を優先するあまり UX の低下や機能の縮小をせざるを得なかったり、SEO やブランド面でデメリットが発生する状況が起こりうるなら、目先の費用だけではないことを理解した上で慎重に選択すべきです。
アプリの品質を低下させることなく、できるだけ赤字を回避するため、データベースの運転費には特に気を遣いました。
- RDBMS系か、NoSQL系か
- 利用料の計算式は通信量か、リクエスト回数か
- 1人あたりの通信量、リクエスト回数の概算
特に、利用するデータベースがRDBMS系か、NoSQL系かで、データの持たせ方が全く違います。というより、全く違うものだと理解した上で設計しなければ、最悪の場合クラウド破産を引き起こします。
クラウドサービスの請求料金が、開発者の意図しないところで高額になってしまう事象を指す俗語です。 予期しない集中アクセスにより嬉しい悲鳴になる超レアケースもあるかもしれませんが、解釈を間違えた設計と理解の浅いコピペ実装が招く自滅がほとんどでしょう。
例えば、NoSQLのデータベースでコテコテのリレーショナル設計をして、SQLクエリのようなニュアンスで集計や絞り込みがゴリゴリ走る処理を書けば、あっという間に請求料金が跳ね上がることになるはずです。
面倒がらずに、クラウドサービスの料金形態をよく確認して、プラットフォームに最適な設計を把握し、事故が起こりにくい実装をする正攻法こそが、結局は最適解なのではと感じました。
Firebaseの料金 と aws RDSの料金 はこちらにて。
今後の展望
スマ簿記3級は初リリース時、約60%のコンテンツ完成度で公開しました。仕訳問題や勘定科目問題といったメインの機能は仕上がっていたので、まずはユーザーの反応を見つつ、改善を重ねる前提で公開に踏み切った感じです。
なので、今後の展望はひとまず完成度100%を目指すことが主になりますが、もっと長い目でみた展望は以下のような感じです。
- メンテナンスコスト（維持の手間）の最適化
- コンテンツの作業量に応じて成果が増えやすいモデルを確立
- 不具合や、要望をできるだけ実現していく
- 簿記の学習はスマ簿記が定番！といわれたい
スマホアプリを開発してリリースまで到達できた感想としては、素直に有意義な経験だったと自信を持って言えます。
技術的な面白さも有りつつ、何よりストアでユーザーのレビューをもらえることは、成果物を世に放たない限り体験することができない貴重な感覚です。良いレビューは拡張開発のモチベーションになり、悪いレビューも改善点の参考になるありがたい意見です。
大袈裟かもしれませんが、このような正のサイクルが世の中を豊かにしていくのかも、と感じています。これからはアプリのレビューを書くことも大事だなと実感しました。
応援してほしいときは、先に誰かを応援するとよいみたいです。お気に入りのアプリがあったら、レビューを執筆してみてはいかがでしょうか。この記事を見つけた皆さんも、アプリ開発がスムーズに進むことを祈っています。