株式会社Good Labでエンジニアをしている コータロー です。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。
Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
「個人開発、始めてみたけど続かない」
これは、私が一番よく聞くし、自分でも何度も味わった悩みです。最初の週末は勢いがあります。GitHubにリポジトリを作り、README を書き、環境構築をして、最初の画面が動いたときは楽しい。でも3週間後には別のことに気を取られ、半年後には「あのプロジェクト、どこまでやったっけ」になっている。
私は本業がSES（受託・客先常駐）のエンジニアで、複業として個人でiOSアプリを開発しています。潤沢な時間があるわけではありません。それでも、現在は個人開発・共同開発あわせて 8本前後のアプリ（WorkoutDiary、StudyStopwatch、脳活ピース、CHROMATIC、RoutineReel、BookSpark など）をポートフォリオとして運営し続けています。
本記事は「気合いで続けろ」という精神論の話ではありません。限られた時間の中で、個人開発を"続く状態"に持っていくための仕組みを、私自身の失敗と実践ベースで5つに整理します。初心者〜中堅で「続かない」に心当たりのある方に、そのまま真似できる粒度で書きました。
前提: まず「私の開発リソース」を正直に共有する
再現性の話をする前に、私の持ち時間を正直に出します。ここがズレると、以降の話が「時間がある人の余裕」に見えてしまうからです。
| 区分 | 開発時間 |
|---|---|
| 平日 | 平均2時間/日（週10時間） |
| 土日 | 合計約10時間 |
| 週合計 | 約20時間 |
週20時間。フルタイムの労働時間が週40時間なので、その半分です。しかもこれは「机に向かえる最大値」であって、体調やイベントで簡単に週15時間まで落ちます。
この制約の中で複数アプリを回すために、私は開発速度を上げる仕組みとして Claude Code（Max Pro プラン） をフル活用しています。体感で実装まわりの速度は 3〜5倍。ただし後述するように、速いだけでは続きません。「速さ」と「続ける仕組み」は別の問題です。
ここから本題の5つのコツに入ります。
コツ1: 企画は「自分ごと化できるか」で殺す
続かない原因の多くは、実装以前の企画選びにあります。自分が使わないアプリ、自分が興味を持てないテーマは、必ずどこかで手が止まります。締め切りのある仕事と違って、個人開発には「やめても誰も困らない」という致命的な自由があるからです。
私は企画を判断するとき、最優先の基準を1つだけ置いています。
自分ごと化できるか？（＝自分が実際に使うか・興味が続くか）
機能の多さでも、市場規模でも、技術的な面白さでもありません。「自分が毎日使いたいか」です。これを満たさない企画は、どれだけ筋が良く見えても没にします。
実際に没にした企画たち
きれいごとに聞こえるかもしれないので、自分が捨てた具体例を出します。
- 砂演出ToDoアプリ（コードネーム "Ma"）: タスクを消すと砂がサラサラ流れる演出が売り。UIまで作り込み、ビルドが通る直前まで実装したうえで、「これ、自分は毎日開かないな」と気づいて全消しにしました。
- サブスク管理アプリ（"SubLog"）: 企画段階で没。理由は「競合が多すぎて差別化が難しい」。そして何より、自分がその手のアプリを続けて使った試しがなかった。
「ビルド直前まで作ってから捨てる」のは、一見すると壮大な時間の無駄です。でも、自分ごと化できていない企画を"リリースまで"引きずる方が、はるかに大きな無駄になります。リリースすれば運用・アップデート・問い合わせ対応がずっと続く。興味のないアプリのメンテを1年やる方が地獄です。だから、早めに殺すのはむしろ節約なんです。
再現ポイント: 企画メモに「自分は週に何回これを開くか」を必ず1行書く。答えが「たぶん開かない」なら、そこで止める。
コツ2: 「止まる基準」を先に決めておく（連続却下3回ルール）
コツ1の裏返しです。「自分ごと化」を厳しく問うと、企画がどんどん没になります。すると今度は逆の沼にはまります。「どれもピンとこない」と延々と企画を出し続けて、1行もコードを書かない期間が生まれるのです。これも立派な「続かない」状態です。
そこで私は、走る基準だけでなく 止まる基準 を先に決めています。
企画が連続で3回却下されたら、いったん企画探しをやめる。
3連続でダメなときは、たいてい判断軸そのものが疲れているか、視野が狭くなっています。そこで無理に4本目をひねり出しても質は上がりません。いったん離れて既存アプリの改善に手を戻したり、日常の中で「これ不便だな」という文脈が自然に溜まるのを待ちます。
大事なのは、この基準を「疲れる前に」決めておくことです。消耗しきってから「もうやめよう」と思うと、それは"挫折"の記憶として残ります。最初から「3回で一旦ストップ」とルール化しておけば、それは"手順"になります。同じ中断でも、挫折と手順ではメンタルへのダメージが全く違う。
コツ3: 限られた時間を"実装以外"に奪われない ― エージェント分業
週20時間しかないと、時間の使い道がシビアになります。ここで効いてくるのが Claude Code の使い方です。単なる「コードを書いてくれるAI」として使うだけではもったいない。私は 開発工程そのものを分業させる 運用にしています。
チーム開発では、企画・設計・実装・レビュー・リリース・グロースをそれぞれ別の人が担当します。個人開発だと、これを全部1人の頭の中で切り替えることになる。この脳内の役割スイッチングが、実は一番消耗するんです。
そこで私は、Claude Code の サブエージェント機能 を使って、工程ごとに「担当」を分けています。イメージはこうです。
[企画] trend-researcher → 市場・競合を調べる
↓
[戦略] product-strategist → ペルソナ・MVP機能・マネタイズを設計
↓
[実装] mobile-app-builder → 技術評価・実装
↓
[レビュー] code-reviewer → コミット前チェック
↓
[リリース] release-manager → What's New・審査対応
↓
[グロース] growth-strategist → 計測・改善施策
※ 上図は私の運用イメージです。エージェント名・工程分けは各自の開発スタイルに合わせて設計してください。
こうすると何が起きるか。「今は実装者の帽子をかぶっている」「今はレビュアーの帽子」と、役割が明示的に切り替わるので、頭の中がすっきりします。レビュー担当のエージェントには「粗探しをする」役割を与えているので、自分で書いたコードに自分でダメ出しするときの心理的コスト（自己弁護したくなる気持ち）も減ります。
限られた週20時間を「実装」と「工程の切り替えコスト」の両方で削られていたのが、分業によって実装により多くの時間を残せる。これが体感3〜5倍の中身の一部です。速いというより、無駄な脳内スイッチングを外注している感覚に近い。
なお、これはClaude Codeに限った話ではありません。ChatGPTでも、あるいは紙のチェックリストでも、「工程ごとに役割を分けて、今どの帽子をかぶっているかを明示する」という考え方自体が本質です。
コツ4: ツールを作り込みすぎない ― タスク管理はNotionに一元化
エンジニアの個人開発が続かない、隠れた大きな原因があります。「開発を管理するためのツール」を自作しすぎることです。
心当たりありませんか。タスク管理を始めようとして、いつのまにか「自分専用のタスク管理ダッシュボード」を開発し始めている。進捗を可視化したくて、GitHubのAPIを叩くスクリプトを書き始めている。本来作りたかったアプリより、"管理ツール"の方が楽しくなってしまう現象です。
私も過去にやりました。そして学びました。管理は、既製品に乗る。 私はタスク管理を Notion に一元化し、独自のダッシュボードやツールは基本作りません。
これは技術的なこだわりを捨てるという話ではなく、「どこにこだわると続くか」の選択です。こだわるべきは作っているアプリの中身であって、それを管理する足回りではない。足回りを凝ると、そこがメンテ対象として増えて、結局「本体に手が回らない」に逆戻りします。
再現ポイント: 「これは本体か、足回りか」を自問する。足回り（管理・可視化・自動化のためだけの仕組み）は、まず既製品（Notion、Trello、スプレッドシートなど）で済ませられないか考える。自作は"それがないと本当に困る"ことが分かってからで遅くない。
コツ5: 目標を"現実的な数字"に固定する（年間50万円）
最後は、モチベーション設計の話です。
個人開発で燃え尽きる典型が、「アプリで一発当てて脱サラ」みたいな大きすぎる目標です。目標が大きいほど、日々の小さな進捗が「まだ全然足りない」に見えてしまい、続けるほど辛くなる。
私が掲げているのは 年間売上50万円 という、かなり現実的な数字です。月あたり4万円強。これは「見えている」数字です。アプリを1本増やし、1本を少し改善し、を積み重ねれば届く射程にある。
現実的な目標のいいところは、日々の作業が「その目標に確かに近づいている」と実感できることです。1000万円が目標だと、50万円の売上は「まだ20分の1」に見える。でも目標が50万円なら、同じ50万円は「達成」です。同じ事実でも、目標設定次第で「進んでいる感」がまるで変わる。
続けるために必要なのは、瞬間最大風速のモチベーションではなく、「今日もちょっと進んだ」を毎週感じられる目盛りの細かさです。目標を現実的に置くのは、その目盛りを自分に合わせる作業だと思っています。
まとめ: 「続く」は才能ではなく設計
個人開発が続くかどうかは、根性や熱量の問題に見えて、実は 仕組みの設計 の問題です。私が週20時間で複数アプリを回し続けるためにやっていることを、もう一度並べます。
- 企画は「自分ごと化できるか」で殺す ― 自分が使わないものは、ビルド直前でも捨てる
- 止まる基準を先に決める ― 連続却下3回で一旦ストップ。挫折ではなく手順にする
- 実装以外に時間を奪われない ― 工程を分業し、脳内スイッチングを外注する
- ツールを作り込みすぎない ― 管理は既製品（Notion）に乗る。本体にこだわる
- 目標を現実的な数字に固定する ― 年間50万円。進んでいる実感が続く燃料になる
どれも派手ではありません。でも、続かない人に足りていないのは、たいてい「もっと頑張る力」ではなく、この手の「頑張らなくても続く仕掛け」の方です。
もし今、途中で止まっているプロジェクトがあるなら、まず1つだけ試してください。「自分は週に何回これを開くか」を1行書く。 そこから、あなたの個人開発の続け方の設計が始まります。
参考
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！