作りかけの墓場をいくつ作ったか
一時のモチベーションで作りはじめたものの、その日のうちに形にならず、1日経ったらあの時のやる気はどこかへ消えていた。そんな経験はありませんか？
私は数年前から個人開発をしていて、iOSアプリやChrome拡張機能、Webサービスなどをいくつか作ってきました。アイデアは日々Notionに溜めています。けれど、時間が経つと「やらなくてもいいか」と思えてきたり、「これを作って意味があるのかな？」と立ち止まったり。次に何をすればいいのか選択肢が多すぎて、モチベーションが一気に0になることもありました。アプリを公開する前に辞めてしまったことも、一度や二度ではありません。
これは私がNotionに書き溜めているアイデアメモです。300個以上あるうち、実際に作れたのは12個。それ以外に、作る前にボツにしたものが36個ありました。カテゴリごとにボードで管理しています。完成までたどり着く割合は、だいたいこんなものです。
ここからは、そうやって何度も心を折ってきた私が経験した失敗パターンと、続けるために意識すると良かったことを紹介します。
やりたいけどやる気がない――モチベは「気合い」ではなく「燃料」
「やりたい気持ちはあるのに、なぜか手が出ない」。個人開発で一番やっかいなのは、この状態だと思います。やる気が完全に消えたわけではありません。作りたいアイデアはずっと頭の中にあるのに、エディタを開く手だけが動かないのです。
理由を掘っていくと、だいたい次の2つに行き着きます。
- ハードルが勝手に上がっている：頭の中で完成形を膨らませてしまい、「ちゃんと作らないと」「中途半端なものは出せない」と最初の一歩が大ごとになる。考えるほど着手が重くなる
- 何から手をつけるか分からない：設計・技術選定・デザイン・優先順位と、何もかも自分で決める。入口で選択肢の多さに圧倒され、そのまま固まってしまう
この「手が出ない」を、私は長いあいだ気合いの問題だと思っていました。でも、続かない原因の多くは意志の弱さではありません。モチベーションを、根性で振り絞るものではなく、外から供給される燃料だと捉え直すと見え方が変わります。
モチベは外から供給される「燃料」
ここで言う燃料とは、手応え・反応・前に進んでいる感覚のことです。コードが動いた、誰かが使ってくれた、小さく一区切りついた。そういう瞬間に燃料が補給され、次へ進む推進力になります。逆に、この供給が途切れると、どれだけ最初のやる気が高くても失速します。
燃料切れは、だいたい決まったパターンで起きます。
- ゴールが遠すぎる問題：完成までの距離が遠く、手応えが返ってくるまで何週間もかかる
- 誰にも見られない無風期間：公開していないので、反応がゼロのまま作り続けることになる
- 環境構築で力尽きる：本題に入る前に、設定やボイラープレートで一番元気な時間を使い切る
- ローンチ直前の飽き：あと少しで出せるのに、なぜか手が止まる
並べてみると、共通点が見えてきます。どれも「完了」と「反応」がもらえるまでの距離が遠いのです。つまり燃料切れは、根性の問題ではなく、燃料が届きにくい作り方をしているという構造の問題です。
「お金」を燃料にすると、まず続かない
作るものでお金を稼ごうとすると、この燃料切れはさらに加速します。個人開発で収益を上げるのは、ほとんどの場合とても難しいです。お金を目標にすると、お金にならない期間がとにかく長く、その間ずっと燃料が届かないまま走り続けることになります。
お金は、供給が遅すぎる燃料です。最初の1円が入るまでに心が折れます。それよりも、自分がそれを欲しい、作りたいという情熱のほうが、はるかに早くて太い燃料になります。
お金よりも自分の情熱をモチベーションにしたほうがやる気も生産性も全然違う
武器その1：最速デプロイ――コードより先に「URLがある」状態を作る
ここから、燃料を切らさないための2つの武器を紹介します。
1つ目は最速デプロイです。コードを書き込む前に、まずデプロイのパイプラインを通し、中身が空でも本番URLが存在する状態を作ってしまう、という考え方です。
多くの記事に書いてありますが、とても重要だと思っています。
「公開してから作る」に順番を逆転させる
多くの人は、作る→完成する→公開する、の順番で進めます。この順番だと、公開は一番最後なので、そこに辿り着く前に燃料が尽きるとすべてがお蔵入りになります。
最速デプロイでは、この順番を逆転させます。先に公開の箱を用意して、あとから中身を足していくのです。最初の中身はHello Worldでも構いません。大事なのは、本番URLが存在し、いつでも人に見せられる状態を最優先で確保することです。
反応をもらえる入口を常に開けておく
デプロイ済みであるということは、反応という燃料が入ってくる入口が常に開いている状態です。
公開してあるだけで、自分のアクセスログを眺める、知人に一言もらう、SNSに貼って反応を見る、といった小さな燃料を、作っている途中でも受け取れます。ローカルだけで開発していると、この入口がずっと閉じたままなので、完成するまで一切燃料が入ってきません。
最初の箱づくり
私の場合は、CloudflareやVercelに最小構成をデプロイし、ドメインをつなぎ、まず1画面だけ表示されるところまでを最初に作ります。中身よりも先に、出ている状態を作ってしまいます。
逆にやりがちな失敗は、ローカルで完璧にしてから公開しようとして、結局公開しないまま墓場行きにするパターンです。作り込みすぎてからデプロイすると、いざ公開という段になってビルドエラーや環境差異でつまずき、そこで一気にモチベが下がります。先にパイプラインを通しておけば、作業中のどの変更がエラーの原因になったのかも切り分けやすくなります。
当時はAIがありませんでしたが、今は事情が違います。たとえばGitHubでリポジトリを作成するときに選べるJumpstartを使えば、リポジトリを作るのとほぼ同時に、ある程度の土台まで出来上がります。
よくやる構成が決まっているなら、リポジトリをテンプレート化し、いつもの実装や好きなデザインをskill化しておくことで、自分好みのJumpstartが組めるようになります。最初の箱を作るコスト自体を、どんどん下げていけます。
「綺麗に作る」より「速く出して問題をあぶり出す」
最初から綺麗に作ろうとすると、ここでも完璧主義が燃料を食います。コードを丁寧に整える時間は、必ずしも前進ではありません。むしろ速く出して、現実の問題を早くあぶり出すことのほうが、プロジェクトを前に進めます。
そして、ユーザーが見ているのは完成度ではありません。ちゃんと動くか、表示が速いか、使えるか。気にされているのはその程度で、作りたての段階で隅々まで完璧である必要はないのです。
「高速で作り、問題をあぶり出すこと」こそがプロジェクトを前に進める唯一の方法
最初から綺麗に作ろうとしない。結局作り直すのできれいに作った時間が無駄になる。
ユーザーが気にするのはUI, サイト表示速度、サイトがちゃんと動くかの3点だけです。UIすらも出来たばかりのサイトなら完璧を求める必要性はありません。
武器その2：スモールスタート――「1回の作業で終われる大きさ」に割る
2つ目の武器はスモールスタートです。作りたいものを、ひとまとまりの作業で一区切りつくサイズまで小さく割る、という技術です。
MVPのさらに手前、「最小の完了」まで割る
よくMVP(最小限の製品)を作ろうと言われますが、個人開発の燃料管理の観点では、MVPでもまだ大きいことが多いです。狙うのはその手前、1回座って終われる最小の完了単位です。
小さく割れていれば、完了が頻繁に訪れます。完了するたびに燃料が補給されるので、長い無風期間を作らずに済みます。
何を削るか：最初の1機能の選び方
では何を削るか。基準はシンプルで、なくても価値が成立するものから捨てます。ログイン機能や管理画面、設定の細かさなどは、たいてい後回しにできます。
最初に作る1機能は、一番見せたい体験の芯だけに絞ります。そのアプリで一番やりたかったことが1つだけ動く、という状態をまず目指します。私自身、当初は機能を盛りだくさんに構想していたものを、最初のリリースでは芯の1機能だけに削って、ようやく公開まで漕ぎ着けたという経験が何度もあります。
躓かない個人開発５か条
- 作らずに済むものをできるだけ作らない
- 小さく産んで大きく育てる
- 技術習得を目的にせず作れる範囲のものを作る
- 最低限自分、もしくは知人が絶対に使うモノを作る
- プラットフォームでなく一人でも使えるツールを目指す
挫折確率を下げるやり方として、なんでも適当におおざっぱに進めていくのがよい。細かい部分は後から修正するという信念で、とにかく最小限の機能に絞って動くものを、デザインはひどくてもよいから早く作る
作るものは「自分が一番のヘビーユーザー」になれるものを選ぶ
スコープを小さくしても続けられるかどうかは、題材選びでかなり決まります。おすすめは、自分が一番のヘビーユーザーになれるものを作ることです。
自分が毎日使うものなら、反応という燃料を自分で供給できます。誰も使ってくれない無風期間でも、少なくとも自分という1人のユーザーがいます。これは、お金を目標にすると続かないという話の裏返しでもあります。
自分が一番のヘビーユーザーであること
2つの武器を1つのループとして回す
ここまでの2つの武器は、別々の技ではなく、1本のループとして回すと効きます。
スモールスタートで小さく割り、最速デプロイですぐ出す。出したものから反応や手応えという燃料を受け取り、それを元手に次の小さな1個を割る。この、小さく割る→作る→すぐデプロイ→燃料を受け取る→また割る、という輪を回しつづけるイメージです。
小さく出して反応を見てから次を足すので、作りすぎや要らない機能も自然に防げます。1サイクルを短く保つコツは、締め切りではなく次に出せる単位で区切ることと、完璧主義が発火しそうな手前で一度デプロイしてしまうことです。
個人開発は短距離走ではありませんが、長距離を短距離の繰り返しに分解することはできます。
個人開発は長距離走。自分でコースを分割しよう
アウトプット至上主義で数撃ちゃ当たる戦略に沿っていくべし
燃料を足すその他のスイッチ
2つの武器に乗り切らない、細かい燃料補給のスイッチもいくつか紹介します。
見た目が良いだけでモチベは伸びる
見た目が良いだけで、モチベは伸びます。
UIの案がまったくない状態で「いい感じに作って」とお願いして、思ったよりいいものが出てきたとき、私はモチベーションの持続がはっきり長くなります。自分の作っているものの見た目が良いというだけで、それ自体が燃料になります。なので、序盤から見た目にこだわってしまうのも、続けるための立派な戦略です。
判断疲れはAIに肩代わりさせる
個人開発は、すべてを一人でコントロールします。裏を返すと、考えること・判断することが全部自分にのしかかります。次に何をやるかを決めきれず、そこで止まってしまうことも珍しくありません。
決めること自体が、地味に燃料を食います。だから、次の一手を決めきれないときは、AIに決めてもらいましょう。選択肢を出してもらって、最後の決定だけ任せるだけでも、止まらずに進めます。
モチベが折れそうな自分にかけてあげたい言葉
最後に、燃料が尽きかけたときに効く、気持ちの面のスイッチです。
頑張っている人を眺める
他の個人開発者をフォローして、Xを眺めるだけでも燃料になります。タイムラインには「○○をリリースしました」「○○円の収益が上がりました」といった投稿が流れてきます。それを見ているだけで、自分もやろうという気持ちが戻ってきます。頑張っている人をフォローするというのは、モチベーションを上げる方法としてもよく挙げられます。
そして、頑張っているのは同じ個人開発者だけではありません。
プロフェッショナル仕事の流儀より引用
あの宮崎駿ほどの人でも、仕事を前にして「めんどくさい」と嘆くことがあります。それでも手を動かしている。そう思うと不思議とこちらも頑張れるので、私は定期的にこの映像を見返しています。
まとめ
個人開発を止めてきたのは、意志の弱さではなく燃料切れです。それを防ぐ武器が、最速デプロイとスモールスタートの2つです。先に公開の箱を作り、小さく割って出し、反応を燃料に次を回す。このループを設計することが重要です。
もしここまで読んで少しでも燃料が溜まったなら、次の一歩は決まっています。中身はゼロでいいので、今日、デプロイの箱だけ作りましょう。まずはリポジトリを作るところからです。