はじめに
先日、個人開発のiosアプリ「life-statistics」を無事リリースすることができました。
まだまだ改善したい点は多くありますが、リリース記念で記事を残しておこうと思います。
（使ってください！！！！）
何を作ったの？
life-statisticsを紹介するとき、よく以下のような文句を使っております。
野菜を食べると肌が綺麗になるって本当？
たくさん寝ると集中力が上がるって本当？
ネットで検索しても、正しい情報に辿り着けるとは限りません。
自分自身で実験して、本当に役立つ結論を導きましょう。
以下の例を見るのがわかりやすいと思います。
「睡眠時間」「肌の調子」の２データを独立に入力していき、
データが蓄積された段階で「肌の調子と睡眠時間」という名前の実験を作成しています。
これによって、ただ漫然と記録していたデータから、例えば以下のような疑問に答えることができるようになります。
- 「たくさん寝れば肌が綺麗になる？」
- 「たくさん寝た次の日は肌が綺麗に見える？」
一部のマニアたちは、これらをexcelやスプレッドシートなどを使って実現しているそうですが、
life-statisticsはモバイル端末でこれらを行うことができます。
背景
かくいう私も、以前はスプレッドシートを使って解析することに挑戦したことがあります。
以下のように色々とスプレッドシートにつっこんでおりました。
これはこれで良かったのですが、以下のような課題がありました。
- データ入れるだけ入れて、活用しない
- PCがないとデータがいじれない&見られない（スプレッドシートをスマホで操作するのはややしんどい）
課題
以上より、課題を整理すると以下のようになります。
- 分析するまでのハードルを下げる
- PC以外からのデータ入力・確認をできるようにする
また、追加でやりたいこととして
- 分析結果を共有できるようにする
ことを考えております。
共有機能を使っていわゆる「見る専」の層、自分で長期間データを記録するような(我々)ヲタクだけでなく、ただ正しい知識を得たいという方々にも、データを使うという選択肢を届けられたらなあというモチベーションです。
他じゃダメだったの？
以下が候補としてありましたが、最終的には自分で開発することにしました。
1.スプレッドシート（またはexcel）
上で色々と言いましたが、やはりlife-statisticsを作るにあたって、一番の競合(?)となるのはこれだと思いました。
私の大好きな本である「人生が本当に変わる87の時間わざ 時間術大全」にも以下のような記述があります。
ジェイクはといえば、1日のエネルギーレベルをまる1年にわたってスプレッドシートに記録し、コーヒーと緑茶のどっちを飲むべきか、運動するのは朝と夕方のどっちがいいのか、自分は人付き合いが好きか嫌いか（答えは……ほとんどの場合好きだった）にまで答えを出そうとした。
こんなことができたらかっこいいですよね。
生活のデータを全て記録しようと挑戦した身としては、憧れるばかりです。
これができるなら、スプレッドシートの方が明らかに自由度が高いし、life-statisticsなんていらないです。
しかし、このレベルのことを継続するのは多くの人にとって難しいのではないかと思います。(私はダメでした)
上述したように、記録・結果確認のたびにPCが必要になるのは不便だし、分析するためにも自分でグラフや関数を作らないといけません。
結果、データを入れても活用できない・そもそも記録することをやめてしまう。ことになってしまっては意味がありません。
「スプシでいいじゃん」という意見は至極真っ当だと思いますし、私も「スプレッドシートよりも絶対にlife-statisticsがおすすめ！」とは言い切れませんが、拡張性を犠牲にしてでも手軽さを高めた別のプロダクトを作ることには価値があると考えました。
2.ライフログアプリたち
app storeなどで「ライフログ」や「記録」と検索すればたくさんのアプリがヒットします。
これらは、上記課題の「PC以外からのデータ入力・確認をできるようにする。」については要件を満たしますが、その他２つ（分析するまでのハードルを下げる・分析結果を共有できるようにする）を満たすものは見当たりませんでした。
やったこと
スコープ定義
課題である３つ。
- 分析するまでのハードルを下げる
- PC以外からのデータ入力・確認をできるようにする
- 分析結果を共有できるようにする
のうち、「分析結果を共有できるようにする」に関してはサーバーサイドの実装が必要になり、他２つに関してはローカルのみの実装で実現できると考えました。
そのため、「分析結果を共有できるようにする」部分に関しては今後の機能追加にとっておくとして、前２つのみを実装することにしました。
また、プラットフォームとして将来的にはandroidにも対応したいものの、後述しますが想像以上にビルド・配布周りで苦戦したため、一旦iosのみに絞ることにしました。
技術選定
最終的には、Flutterでネイティブアプリを作ることにしましたが、理由は以下の通りです。
- web vs.ネイティブ
ローカルにデータを保存するという要件から、webは不向きだと判断しました。 - swift(Kotlin) vs. クロスプラットフォーム
ネイティブアプリとなると、swiftやKotlinで直接書くか、flutterやreact-nativeのようなクロスプラットフォームができるフレームワークを使うかになると思いますが、将来的にはandroid向けにも公開したく、一人で２重にコードを書くほどの工数は取れないので、後者を選択しました。 - react-native vs. Flutter
クロスプラットフォーム開発ができるネイティブアプリケーションフレームワークで、ある程度の知名度があって知見が溜まっているものだと、flutterとreact-nativeが候補に上がってくると思います。私は普段はフロントエンドエンジニアをしており、reactに関しては日頃から触っているので、せっかく作るなら新しいものを触りたいなということで、flutterを選択しました。
実装
完全に要件や機能がfixした状態でスタートしたわけではなかったのですが、流石にコードを書きながら要件を考えるのは非現実的だったので、デザインで画面を作りながら要件については固めていきました。
したがって、figmaでデザインしながら機能を固める→実装する のフローをたどりました。
Flutterでの開発経験もなかったため技術的に苦戦したことは多かったですが、意識していたのはとにかく「やりたいこと主導で進める」ことでした。
Flutterの勉強については最初の数日でチュートリアルをなぞるだけにとどめ、そこから先は
- タブ切り替えしたいなあ → BottomNavigationBar
- ローカルにデータ保存したいなあ → Isar,Drift
- っていうかColumnだと画面スクロールできないじゃん → Sliver,CustomScrollView
のように、やりたいことを実現するための手法をその都度検索するという手法をとっていました。最初にFlutterの勉強をしてからlife-statisticsの開発をしようとすると、そもそも開発を始めるのが遅くなったり、勉強の段階で挫折する可能性が高いと考えたからです。
実装にあたって特に苦労した点は以下です。
1.ビルド・配布まわり
そもそもネイティブアプリ開発が初めてだったのもあり、かなり苦戦しました。
バージョンってどこに書くの？
ビルド番号ってなに？
(destributionを選ぶ際に)App Store Connect,Debugging,Custom...？
なんかビルド失敗してるっぽいけど、そのログはあるんだ？
Identifier,Provisioning Profile...？
など、フロントエンド書いてるとなかなかお目にかからない沼にハマりました。
2.デザインできない
いつも、デザイナーさんが美しいデザインを作ってくれます。
いつもはそれをcssで再現すればよかったんですが、今回は自分でデザインから作成する必要がありました。
デザインの確認にしか使ったことのないfigmaをぎこちない手つきでぽちぽちして、何とか（自分的には）見られるデザインになったのではないかと思っています。
3.要件定義むずい
「なにをやればいいのか」が決まっている業務と違って、どの機能の優先度が高いのか。どの程度の影響範囲になるか。どれくらいの工数がかかるか（どのくらいリリースが遅れるか）などを考えてタスクのやる・やらないを選択する必要がありました。
普段リーダーの方や、PMさんがやってくださっている作業の重要性を改めて実感することになりました。
4(番外編).apple developer program
たっかいです。
5.その他
実装にあたって苦労した点についてあげればキリがないので、以下は箇条書きに留めておきます。
- アプリの審査を通す
- sign in with apple
- 広告を貼る
- DB設計
- 技術選定
- ライセンスに気を配る
結果考察
自分としては、最初に定義した要件は満たすものができたんじゃないかなあと考えております。しかし同時に、現段階ではまだ構想時にイメージしていたものには及んでいないとも感じております。
どのプロダクトであっても、おそらく構想を完全に形にするのには膨大な工数がかかるし、個人開発なら尚更だと思います。
だから、機能にも優先度をつけて「コア」となる機能から実装していくというのがセオリーだと言われているんだろうし、「小さく始めて大きく育てる」っていうのはこういうことなんだなと、実感することができました。
学び
1.figmaの見方が変わった
デザイナーさんからデザインが降りてきた時、
- gapを操ってgrid-template-columnすればいい？
- marginを当ててやればいい？
- 中央に寄せかな？
など、今までは何となく感覚で汲み取っていました。しかし自分でデザインする側をやってみることで
- ここはAuto layoutがあたっているからそれをcssで再現してやればいいんだな
- 数値に意味がありそう(2の累乗になっているなど)だからこれは、marginを当てて欲しい場所なんだな
- これは中央にあるのが目的というよりは、他の要素と先頭が揃っているのが大事なんだな
というような考えをすることができるようになり、業務においてもfigmaを見る時の解像度がかなり上がったと思います。
その結果、実装した画面をデザイナーさんに確認してもらった時に、ご指摘いただくことが減ったかなと感じております。
2.PMさんの気持ちがわかってきた
普段、assignされたタスクをもらう側にいると意識する機会が少ないですが、「苦労したこと」にも書いた通り、着手するタスクを選ぶことは非常に難しいです。
- 機能を追加するべきなのか、それとも今ある機能のブラッシュアップをするべきなのか
- 追加するとして、どの機能を実装すればユーザー体験を良くすることができるのか
- そもそも現状のプロダクトに足りない機能とは何なのか？
- それぞれどれくらいの工数がかかるものなのか
これらをただの知識ではなく、実体験を伴って理解することができたことはlife-statisticsを開発する中で得ることのできた学びの一つだと考えております。
擬似的にではありますが、PMさんの立場・気持ちを経験することができたので、今後MTGやプロジェクト提案の際にはより中身のある話ができるよう努めていきたいです。
3.CI/CDは大事
実はlife-statistics、初回リリースまでは何とかやり遂げることができたのですが、現在は開発が止まってしまっております。
その原因として一つ大きいのが、「リリース作業がめんどくさい」ことだと感じています。
CI/CDと書きましたが、特にCDの大事さを実感しました。
ネイティブアプリだから、審査フォームを書かないといけない。というのもあると思いますが、アップデートのリリース作業がかなりめんどくさく、手順が複雑というのもあり、毎回アップデートのたびに手順を検索する必要があります。
結果としてアップデート作業が負担になり、開発ペースが落ちているというのが現状です。
開発自体はやりたかったのですが、その後のリリース作業が億劫で先伸ばしにしているうちに、開発全体のモチベーションが低下してきてしまいました。
「自動化できる部分は自動化するべき」的な発想と近いかもしれませんが、アップデートのリリース作業のような、本質ではない部分に関してもっと積極的に自動化を図って良かったのかなと感じております。
一念発起してCDさえ実装できれば、開発モチベは戻ってくると信じているので、時間を作ってCDの実装を進めていきたいです。
最後に
「業務を経験した後に個人開発をする」ことで、業務を経験する前に個人開発をしていた頃は全く考えもしなかったようなことを学ぶことができました。
総開発期間としては6ヶ月で、個人開発としては大きめのプロジェクトでしたが、かけた時間に見合うだけの学びはあったと思います。
最後まで読んでくださり、ありがとうございました.