5年継続することで分かってきた、個人開発モチベーションを持続するための方法

エムスリーエンジニアリングGの宮地です。普段は、製薬企業向けのマーケティング支援を事業としているBIR（ビジネスリサーチ&インテリジェンス）というチームにいます。

私は、2018年あたりから前職の同期と個人開発を始めて、過去の記事にも書いたように、現在はWalica（ワリカ）という複数人複数回の割り勘計算をサポートする調整さん的なWebアプリをメインにいくつかのサービス開発を継続しています。

www.m3tech.blog

先日は今年7月にリリースした技術スタックのデータベース「what we use」が弊社CTOのツイートきっかけで多くの方に知っていただき、ありがたいことに、当日中に約30社から掲載依頼リクエストをいただくことができました。

エムスリー在籍のエンジニアが趣味で作ったサービスが凄すぎて凄い。便利。https://t.co/M50ijtsECn
— 山崎聡@エムスリーCTO/VPoP/前VPoE/前CDO/人事役員 (@yamamuteking) 2022年9月14日

Walica、what we useは継続開発していますが、過去にはアイデアの段階でボツになったもの、開発の段階でモチベーションが下がってリリースに至らなかったもの、リリースはしたけどユーザー数が伸びず、継続を断念したものなど多くの失敗を経験しました。

今回は、過去の経験からどうすれば個人開発を継続していけるのかを考えてみます。

個人開発モチベーションを持続するための工夫

個人開発を継続させるためには、1にモチベーション、2にモチベーション、3にモチベーションです。最新技術インプットが主目的でない開発は、途中で「本当にこれ使われるのかな...」という不安が押し寄せてきて、途中で開発をストップしてしまうケースがほとんどです。

モチベーションを持続させるための工夫としておすすめしたいのは以下の3つです。

（1）2人でやる

「それって個人開発じゃないじゃん」と言われれば元も子もないのですが、私が毎週末の開発を継続できた唯一の要因はこれで、前職の同期と毎週約束をして、開発を進めていたからです。1年に1回くらいガチでめんどくさくて仮病を使って休むんですが、99%習慣継続に成功しているので有効な方法だと思います。これは「2人」というのがミソで、3人以上になると、予定調整が難しくなったり、「自分が欠席しても2人残るからいいや」という誘惑が出てきます。

（2）できるだけ早くリリースする

しかし2人で相互に監視しながらやってたとしても、モチベーションが下がる時は往々にしてあります。そんな時は早くリリースしてユーザーの反応を確かめることでモチベーションが爆上がりすることがあります。

（これは一般的なプロダクト開発にも言えることだと思いますが...）

Walicaはリリース時、3連休を使って開発合宿をして、ゼロから一気にリリースまで持っていきました。what we useは初期リリース時にバックエンドを開発せず、フロントエンドにJSONハードコードでリリースしました。Qiitaで記事を書くと、Twitter上でポジティブな反応をたくさんいただくことができました。モチベーションだけでなく、機能に対するフィードバックももらえるのでオススメです。

そこで実際に使っているユーザーの存在を確認できると、「使ってくれる人がいるから開発ストップできない...」というある種の使命感も出てきたりします。

（3）打算的なアイデアを採用しない

これは何か新しいものを作ろうとした時のアイデア出しの話なのですが、個人開発のように週数時間くらいしか関わらないプロジェクトにおいて、自分が心の底から良いと思えるものを作らないと、段々と興味が薄れてきます。

例えば、以前に資格勉強のためのアプリを開発しようとしたことがありました。資格アプリであれば、ある程度の使い勝手が担保できれば、それに対してお金を払ってくれる人はいるだろうという考えから、受験人口の多い、とある資格の問題と解答データを集めようとしました。

しかし、自分にとって全く縁もなければ・課題感もないドメインでサービス開発すると、モチベーションを持続することが難しくなり、結局、数ヶ月くらいで開発は頓挫してしまい、別のアイデアに変更することになりました。

まとめると、「2人編成のチームで、自分が心の底から良いと思えるサービスを短期間でリリースする。」ということになります。

短期間でリリースするための心構え

普段会社でやっているような開発スケジュール管理と比べて、やはり個人開発の開発スケジュールはテキトーになりがちです。リリースが遅れたところで誰にも迷惑はかからないため、いつでも延期できますし、自分の思いつきで新しい機能を追加したり、開発の方向性を大胆に変更したりできます。

これが個人開発の醍醐味だと言われればそうかもしれませんが、個人的には、まずはMVP (Minimum Viable Product)リリースに専念することが大事だと思っています。機能の追加開発はリリース後でもいくらでもできますし、SEOからの流入を狙う場合、実際に検索結果に効果が現れてくるのは数ヶ月後になるので、一刻も早くリリースした方がお得です。

開発を始める前に、メモ帳などにMVPの要件を書き出し、それが達成され次第即刻リリースするというルールにすれば、「あれも追加しよう、これも追加しよう」という誘惑を断ち切れるかもしれません。

これも2人で開発することで、MVPにとって不要な機能開発を進めてないかという監視をすることができます。

MVPの決め方に関してはこちらの図が参考になりました。

Minimum Viable Product: Build a slice across, instead of one layer at a time. #mvp /cc @aarron @benhyphenrowe pic.twitter.com/0koefYMrpf
— Jussi Pasanen (@jopas) 2014年9月26日

MVPリリースというと、とにかく必要最低限の機能のみを実装し、デザインは後から直そうとか、使い勝手は後回しとしがちです。しかし、画像のように、MVPでは、機能性(Functional) だけでなく、情報の信頼性 (Reliable)、使い勝手(Usable)、心揺さぶられるデザイン(Emotional design)も最低限のものを用意しましょうとあります。