個人開発が止まる原因、技術じゃなくて“モチベ”だった
個人開発が止まる理由って、技術不足でも時間不足でもないことが多い。
もちろん忙しい日もあるし、難しい実装で詰まることもある。でも、結局のところ一番強いブロッカーは別にある。
それが、モチベーションだ。
会社の仕事なら締切やレビューや評価があって、外側から背中を押される。
でも個人開発は、やらなくても誰も怒らない。止まっても、誰も困らない。
だからこそ、続ける燃料はほぼ自分の中にしかない。
モチベーションが落ちた瞬間、個人開発は簡単に止まる。
そして一度止まると、再開が一気に重くなる。これが一番きつい。
モチベーションは“才能”じゃなく“構造”
「モチベが高い人は才能がある」みたいに言われがちだけど、私は逆だと思っている。
モチベは“気分”で上下する。波があるのが普通だ。問題は、波があることではない。
波がある前提で、進められる構造になっていないことが問題だ。
個人開発は、気合で勝つゲームじゃない。
続けるために、設計するゲームだ。
ギャップモチベーションが燃料になる
モチベーションの燃料になるのは、よく言われる「やる気」そのものというより、理想と現実のギャップだと思っている。
こうなりたい（理想）
でも今はこうだ（現実）
この差分が「じゃあ少しでも埋めよう」という動きを生む。これをギャップモチベーションと呼ぶ。
ただし注意点もある。
ギャップが大きすぎると燃料にならず、絶望になる。
「理想が遠すぎて、何からやればいいか分からない」
この状態に入ると、モチベーションは上がるどころか一気に下がる。
だからギャップは、“今日の自分が触れる大きさ”にするのが大事だ。
見上げる目標ではなく、手を伸ばせば届く差にする。
少しでも進めば、どんどん進められる理由
個人開発は、0→1が一番重い。
PCを開く。リポジトリを開く。何をするか考える。
この「始めるまで」が最もエネルギーを使う。
でも一度触ってしまうと、不思議と進む。
軽く調べたら、ついでにメモを足す。
コードを開いたら、気になるところが出てきて直したくなる。
手を動かし始めると、作業のエンジンがかかる。
だから勝負は、モチベを上げることよりも、
今日最初に手を付けられるかにある。
最初の一手のハードルを、徹底的に下げる
ここからは、私がいちばん効くと思っている考え方。
モチベが低い日は「頑張る」のではなく、
最初の一手を小さくして、開始の摩擦を下げる。
おすすめはこのあたり。
タスクを“1分”にする
例：READMEを1行直す、TODOを1個書く、不要コメントを消す次にやることを前日に決めておく
「何やるっけ？」で止まるのが一番もったいない5分だけタイマーをかける
続けるかどうかは5分後に決めればいい“やる”じゃなく“触る”にする
触ったら、勝手に進むことが多い
個人開発が続く人は、気合が強い人というより、
「触れる状態を作るのが上手い人」だと思う。
モチベには波がある。下がっているときは無理しない
当然、モチベが高い日もあれば、低い日もある。
疲れている日、気持ちが乗らない日、他の予定が優先の日。全部ある。
ここで無理して「やらなきゃ」と追い込むと、
個人開発が“嫌な記憶”になってしまう。
そうなると次の再開がさらに重くなる。
だから、下がっているときは無理しない。これは大事。
ただし、もうひとつだけ守るべきルールがある。
ただし、決してゼロにはしない
モチベが低い日は無理しなくていい。
でも、ゼロにしてはいけない。
なぜなら、一度ゼロになると再開コストが跳ね上がるから。
「久しぶりに開く」って、思っている以上に重い。
だから私は、最低ラインを決めている。
これを私は「Minimum Viable Progress（最低限の前進）」と思っている。
例えば、こんなレベルでいい。
GitHubを開いてIssueを1つ書く
次にやることをメモに1行書く
仕様メモを3行だけ更新する
画面の改善点を2つ書く
ログやデータを眺めて気づきを1行残す
大事なのは進捗量じゃない。
“ゼロにしない”という状態を維持することだ。
波があるのは前提。
でも波がゼロになると、個人開発は途切れる。
まとめ：モチベーションを設計する4ステップ
個人開発を続けるために、私が意識しているのはこの4つ。
ギャップを言語化する（理想と現実を短文にする）
最初の一手を1分にする（開始の摩擦を下げる）
乗ったら加速する（上げ潮の日に進める）
下がってもゼロにしない（最低ラインだけ守る）
個人開発は、才能や気合の勝負じゃない。
続けるための設計の勝負だ。
今日、モチベが低いなら。
「やるぞ」と気合を入れるより、まずは1分だけ触ってみる。
それだけで、案外すべてが動き始めることがある。
