ここ1年位、趣味として空いた時間でiOSアプリをつくっており、いわゆる個人開発をしてきた。
仕事終わりや休日などをちょこちょこつかって開発してきたが…なかなか終わらない…。なぜだろう…。
いまだリリースできていないので、どうやって開発していれば上手くいったのか?今後どうすればうまくいくのか?というのを書いてみる。
1.まず公開するべきだった
機能を削ってでもまず公開することを考えればよかったと思う。
公開せずにだらだらと時間が経ってしまうと、モチベーションを維持するのにエネルギーを使ってしまうので良くない。まず公開すると、使って貰う人の反応を見ることもできるし、機能の優先度なども決められるので、効率も上がるだろう。
まず最初に公開することを考えて、あとはそれから、くらいの気持ち。
2.期限を決めるべきだった
個人開発だし好きな時に適当にやりたい、と思っていたので、いつまでにつくるかみたいなことを決めていなかったし、進捗管理をしなかった。しかし、もしサービスを公開したいと思っているなら、リリースできないことが結局精神面で首を絞めることになるので、いつリリースするかは最初に決めておくべきだったと思う(もしくは、長期休みで作ることができるボリュームにするなど)。
アジャイルで開発し、週次や月次でスプリントを振り返り/再計画すれば、自分のスキルを過信せず、少ないリソースでどう実装を行うかというところが見えてくるはず。仕事みたいになってしまうのは気になるところだが…。最大でも3ヶ月程度で期限を決めておきたいところだなと感じた。
3.超MVPをつくるべきだった
リーンスタートアップでいうところのMVP(実用最小限の製品)をつくるべきだった。
もちろん想定よりは機能を削ぎ落としたつもりだったのだが、個人開発はとにかく時間がないので、MVPからさらに機能を削ぎ落として超MVPをつくるんだ、という意識でいると良かったのかなと思う。
そして、前述の2にもかかわってくるが、期限を先に決めた上で、その期限内でできることを実装するという方針でやるとよかったかもしれない。これもアジャイルで進めれば、何を削ぎ落とし、何を実装するべきなのかが開発を進める度に明確になる。間に合わなそうであれば、実装中であっても積極的に損切りして、あとでリリースすることにしたほうが、だらだらやって含み損(リリースできない=>モチベーションダウン)にやられるよりはいいと思う。
4.アウトプットをするべきだった
開発してゆく中で、技術的なことなどを、ブログにアウトプットするべきだった。
リリースまで何もアウトプットがないと誰も褒めてくれないので、モチベーションが折れやすいのかなと思う。Tips的な記事でも、リアクションをもらうことで継続するエネルギーが得られたかもしれない。普段仕事で書いているコードは月1.x記事くらいはブログを書いているが、それに加えて、個人開発の方も意識して時間をとってアウトプットすればよかったと思う。
5.毎日やるべきだった?
自分はリモートワークで仕事をしていて、よく海外をフラフラするのだが、1ヶ月とかの短期で旅行する場合、どうしても遊びを優先させてしまい、仕事以外でのコードを書かない日がけっこうあった。基本的に少しでもいいので毎日コードを書くという方針でやっていたが、こういう例外を許してしまうのはよくないかもしれない。ただ、ライフワークバランスを考えて、どちらが本当に自分にとって有益かというのは悩ましい。
上手くいった点
逆に、技術的なところはやってよかったなと思う。
今回は、React Native+Firebaseでつくっていたが、一通りの実装/開発フローを試すことができ、仕事でも(※メリデメ考えた上で)導入/実装できるかなと考えている。Reduxをつかって開発したが、純粋なビジネスロジックに関しては、Webでやっていることをそのまま流用できると実感できたし、仕事で作っていたSPAともベストプラクティスを共有し合うことができて(= 仕事で使ったコードを趣味に、趣味で使ったコードを仕事に)、効率に繋がった。
他のJSアプリでは、NativeScript+Angularを業務で使用したこともあったが、そこでハマったこととの比較(例えばネイティブ言語とのブリッジ)、そして、OSSコミュニティとしての比較などもできてよかった。
また、あえて大きめなboilerplateを使用したのだが、これもいい練習になった。理由としては下記のようなものである。
- エッジの効いた設計で、ライブラリの入れ替えが可能か試したかった
- モダンからレガシーに変わったコードをリファクタリングしたかった
- 仕事では0から設計することが多く、なかなかboilerplateを試すのは勇気がいる
これは両方共想定通り行うことができた。いまのフロントエンドにおいては、パーツを組み合わせて設計するスキルが必要だと考えていて、ある程度巨大なboilerplateを使って中長期で開発すると、既存プロジェクトにおけるライブラリの入れ替えを経験できるので、普段の業務にも活かすことができる。
まとめ
上記を踏まえてやっていきたいです。
※リポジトリは探せばあるので興味ある方は…。
私も似たような経験をしたことがあるので、対策の意見なども含めてすごく共感しました。
私の場合以下も意識するようにしました。
@flatfisher
コメントいただきありがとうございます。
なるほど、こうすると柔軟に開発できて良さそうですね。知見のご共有大変助かります。