スマホアプリの個人開発でつまづいたポイントが７つあったのでシェアです。
想定読者
- 個人開発でいつも中途半端で終わる人
- フロントエンドを中心の人
- 衝動的に個人開発している
記事の内容の前に宣伝です！！ 摂取カロリー・栄養素管理アプリをリリースしました！  少しでも興味がある方はインストールしてみてください〜✌️
iOS: https://apps.apple.com/jp/app/silent-flame/id1556855885
Android: https://play.google.com/store/apps/details?id=com.silentflame
使い方: https://note.com/esuke/n/n9f64c4d6c112
それでは、スマホアプリの個人開発でつまづいたポイントに入ります〜
目的があいまい
個人開発の目的と作製期間を決めないと、設計が甘くなり、再設計を繰り返すことでモチベーションが下がります。
おそらく一般的に個人開発の目的としては、この辺りになるのかなと。
- 収益
- 自己研鑽
- 概念実証(POC)
今回は、アイディアの「概念実証」のつもりでしたが、あれもこれもと欲が出て、「自己研鑽」のために、AWSをガッツリ使うアーキテクチャーにしようとしていました。
しかし、今回実証するアイディアには、AWSが必要不可欠ではなく、そして後からアイディアが追加され仕様追加がどんどん起きた結果、バックエンドの実装コストを下げるため、AWS→Realmに変更し、そしてRealmを使うほどでもなかったので、Firebaseに落ち着きました。
それぞれの検証も楽なものではなく、時間と気力をかなり持っていかれています。
個人開発では特に、自分だけで何かをやろうとする体制になりがちなので、自分の疲労がピークになると迷走しがちになります。
そのため、なるべく負担を軽減させる方が最終的なクオリティは上がりそうかなと思います🤔
目的を決めたらそれ以外のものは排除するようなディレクションを心がけるのが良さそうです。
もし、「自己研鑽」のための個人開発をする場合は、クソアプリと呼ばれる実用性を考えていないアプリを作るのが良さそうです。使ってもらうことを考えなければ、追加の機能実装しようという気が起きないので、「自己研鑽」との相性がいいと思います。
バックエンドは必要？
前提として、今回、アプリからの収益は考えていなかったので、アプリを公開しづけるために運用コストを０にしようとしています。（インストールされないアプリでも放置して数年後に収益が上がったことがあった💰）
はじめは、Firebaseでデータの永続化を意識し、設計し、実装しました。
しかし、実際に実装し、動作確認した結果を元にコストを試算すると、Firebaseを無料で使う範囲では、目指すDAUよりも低かったです。（DAUが目標に達するかは別として）
そのため、Firebaseの利用は必要最低限にまでに制限、データはローカルで保存できる容量に制限しました。
一般的にはローカルで情報を持ち続けるアプリは作らないことが多いかと思いますが、個人開発の場合、利益の見積もりがポジティブになるまではそうでなくてもいいかと思います。
運用コストやトラフィックの最適化などを考えずに済みます。
1人X役になれなかった
クライアントもエンジニアも自分の場合、注意が必要です。
エンジニアの方の中でも、「何でもかんでもクライアントの言う通りに機能を追加しようとするとキリがない！という経験をした方も多いかと思います。
個人開発でクライアントとエンジニアが同一人物の場合、自分が設定した要件通りの仕様を実現したい気持ちが勝り、いつもなら「ここは難しい」だったり、「これは時間的に無理そう」とは言いにくい状態になっていました。
その結果、追加仕様が増えて、疲弊してしまい、パフォーマンスも落ちました。
解決としては、意図的にプロジェクト管理する時間を無理作るといいと思います。
（これまでに出会った優秀なPMの人だったらどう言うだろうなど考えながら）
そうすることで、初回リリースに含む要件を絞ったり、要件をタスク化し優先度を設定したりと、プロジェクト管理が楽になり、気持ちも楽になりました。
個人開発で小規模だからとプロジェクト管理を蔑ろにしていましたが、タスク管理や要件整理などに無理が出てきたらタスク管理サービスを利用するのがおすすめです。
個人開発に疲れてきたら、プロジェクト管理を見直すといいかもしれません。
タスクをただこなす状態になったら..
個人だけの開発では、他のエンジニアからの指摘をもらえません。
実務では自分では問題ないと思っていても、他のエンジニアから思ってもみない指摘を受けて、考え直すと言うことはしばしばあるかと思います。
今回は１つの機能の設計として問題なくても、他との組み合わせに考慮漏れがいくつもあり、コードやロジックの書き換えが頻発しました。
機能単位での設計に問題があっても、そこまで負担にはなりません。
細かな修正は必要ですが、その中だけで閉じる問題になるので、
しかし、他の機能との連携が必要な場合に、その連携の設計に考慮漏れがあったなら、機能ごとの再設計と大幅なコードの書き換えが必要になることがあります。
しかもそれに気づいたのが、二つの機能を作り切って、いざ連携しようとしたときだったので、機能ごとのコードを大幅に書き換える必要がありました。
原因としては、タスクを作った際に、機能間の連携の考慮が漏れ、そのタスク通り進めたことでした。
こういった問題は発生するたびに、再設計やコードの書き換えが発生し、進捗が遅れる原因になります。ただ、やり方を見直し、２回目が絶対に起きないようにするということも難しく、完全な設計を行うことは非現実的だと思います。
完全な設計を目指すべきではなく、特定の期間で作る部分を決め、アジャイル開発を心がける方が現実的かと思います。
例えば、あらゆる機能にまたがるような重たい部分を優先的に手をつけ、そのあとから、個々の機能の細かな部分を作り込むなど。
そのため、仕様追加が起きた場合に最初に取り組むのは、他機能の連携部分の設計と実装とテスト、それが済んだら機能ごとの再設計をすべきでした。
８割りの要件・作業は削っていい
ここまでの内容通りですが、思ったよりできないことが多くあります。
そのため、８割りの要件は後々のリリースに回すのがいいでしょう。
優先すべき２割りの選定に困った場合は、日頃使っているアプリを起動し、このアプリで価値を出している２割りに意識し、利用してみると、実装コストが重そうな意外と使っていない機能が見つかると思います。
個人開発なので使われない機能を作る余裕はなく、しかも初回リリースに含める必要は全くないです。パレードの法則の考え方に則って、思い切って作る部分は絞りましょう。
作業も同様に価値を発揮しないものは削りましょう。
1人なのでコードが適当になりがちですが、そのたびに直していたら作業が進みません。
直すのは、ある程度使ってもらい運用を意識する時で遅くはないです。
メソッドや変数の命名にも時間をかけず、直感的にわかるものを付ければOKです。
今回は、デザインにこだわったり、チュートリアル機能を実装したかったですが、泣く泣く後回しにしました。
デザインは最低限、立体的なスタイリングを加えればみれるレベルになるので、要所要所、影をつけるのがコスパが良さそうでした。（一つの画面では影をつけすぎたのでやりすぎはよくない）
１人でもスクラム開発を
これまでのまとめ的な内容になりますが、個人開発だからといって、好き勝手作っていると作業が膨らみすぎてパンクし、中途半端に終わります。
そのため、個人開発にもルールを設定し、それに則って開発を進め流ことにしました。
そして、自分の中の意見や思いがクライアント、エンジニアのどちらのものなのかを意識することも大切だったと思います。
そこで、自分の意見がどのポジションのもかを意識するソロスクラム開発を行いました。
意識するポジションはこの４つくらい。
- クライアント
- アプリで実現したいアイディアを持ちかける
- 完成した機能を触って、修正点があれば依頼
- PO
- クライアントの思いを要件定義し、タスク化し、優先度を決める
- タスクがいつまでに終わっていればいいか決める
- エンジニア
- タスクをスケジュール通り進める
- エンジニアリングMgr
- タスクの進捗確認
- エンジニアの無理のない範囲で進められる方法を模索
- スケジュールの後ろ倒し
- エンジニアのパフォーマンス改善方法を試す
- 想定工数と実工数のズレを把握
- エンジニアの無理のない範囲で進められる方法を模索
- タスクの進捗確認
そのほかにもこの辺の役割があった方が良かったかなと思います。
- (優秀なエンジニア)
- タスク化されたもので技術面から考慮漏れがないか確認
- (スクラムマスター)
- それぞれの役割分担の見直し
このような役割を意識づけることによって、無理のないプロジェクト管理を行うことができ、例え進捗が遅れていようとも、それすらも「どうしたら解決できるか？」とポジティブに向き合うことができるので、1人で無理やり開発でしていた時と比べてだいぶ楽になりました。
個人開発で中途半端に終わる原因として、クライアントの自分がエンジニアの自分を苦しめるが大きいのかなと思います。
利用するフレームワークの癖
個人開発で初めのものを利用する場合、予想以上に作業が膨らむことがあります。
今回はReact Native(RN)を久しぶりに利用したのですが、前回利用してから何年も経っていることもあり、ほとんど初めて使ったようなものでした。
この内容はRNの技術的な内容になるので後ほど別記事にまとめる予定です。
こちらにまとめました。
https://qiita.com/ebiyy/items/4e51332b2d2b38eac211
後書き：今回の個人開発の感想
実務では見えていなかった開発プロセスに関わるメンバーの思い的なものの理解が以前よりも深まったので、プロジェクト管理下の個人開発を作りきることはおすすめです。
今回、個人開発してみて、個人開発では会社と競えるようなアプリの開発運用するのは無理だと思った。作りきってある程度経っても、価値が落ちず余裕を持ってマーケティングすれば利益が上がるような自信があるようなアプリじゃないと。。
今回は、ダイエット関連のアプリを作りましたが、この分野での開発は個人では無理そうですね。様々な食材や料理のカロリーや栄養素はとても個人でカバーできないので、、
よく言われていますが、個人開発でうまくいくためには、いかに会社規模ではチャレンジしにくい小規模な市場を見つけるかになりそうですねー
ただ、数人でいろんなサービスの開発をした方がそれにたどり着くのは早そう 
ここまで読んでくれてありがとうございます☺️ 記事の内容を読んでアプリの機能には興味がなくてもどんな感じなのか気になるかたのインストールも大歓迎です！！ 
iOS: https://apps.apple.com/jp/app/silent-flame/id1556855885
Android: https://play.google.com/store/apps/details?id=com.silentflame
使い方: https://note.com/esuke/n/n9f64c4d6c112