完成させてから止めた1本——個人開発の撤退基準を、実際に凍結したプロダクトの記録から

個人開発の撤退基準とは、作ったものを続けるか止めるかを、そのときの気分ではなく事前に決めた条件で判断するための取り決めです。私たちはプロダクトを5本作り、4本を公開し、1本は完成させたまま一度も公開せず、完成の41日後に止めました。止まった理由は「売れなかったから」ではなく、「作る前に決めていなかったことが、最後まで決まらなかったから」でした。この記事では、その1本に何が起きたかを日付と数字で公開し、そこから逆算した撤退基準の書き方を残します。

結論：撤退基準は「売れないとき」ではなく「決まらないとき」に引く

新規事業の撤退基準を「設けている」と答えた企業は14.6%、「設けていない」が63%という2024年の調査があります（出典: 株式会社Relic「新規事業の撤退基準とは？」(新しいタブで開く)が引用する株式会社unlockの調査）。会社でも7割近くが決めていないのですから、1人で作る個人開発ならなおさらです。

ただし、企業向けの記事が挙げる撤退基準はたいてい「投資回収期間」「KPI未達」「市場の縮小」です。個人開発だと、この物差しはそもそも使えないことがあります。

理由は単純で、売上を測る前に止まるからです。私たちが止めた1本は、ユーザー数もKPIも一度も観測していません。公開していないので、測る対象が存在しなかったのです。

実際に止めた1本に何が起きたか

止めたのは「市場価値の診断」をテーマにしたプロダクトです（社内コード名 worth）。何を作り、いつ止めたかを時系列で置きます。すべて自分たちの開発ログからの実数です。

技術的には終わっていました。動くMVP（最小限の製品）があり、LP（紹介ページ）があり、利用規約とプライバシーポリシーまで用意されていました。完成度は問題ではなかったのです。

止まったのは、完成と出荷のあいだにあった4件の未決事項でした。価格を決める、実費を出す、公開に踏み切る、データの使用条件を確認する——いずれも作業ではなく決断で、しかも決める人は1人しかいませんでした。

4件目の「データの使用条件」は、公的統計を診断のもとに使う場合の話です。政府統計のポータル e-Stat では、掲載データの利用ルールが利用規約(新しいタブで開く)として公開されています。読めば済むことでも、読んで判断する時間を誰も予定に入れていなければ、未決のまま残ります。

なぜ「完成したのに出荷されない」が起きるのか

個人開発では、手を動かす人と決める人が同一人物です。だから「実装を進める」ことは、決断を先送りしたまま無限にできてしまいます。

私たちの他のプロダクトと比べると、この差がはっきり出ます。Tsumu は着手から6日で本番公開まで到達しました（6日でプロダクトを作った開発体制の話）。メヤスは着手したその日のうちにデモを本番URLへ置きました。

止めた1本は、この左側そのものでした。作業は前に進み、決断だけが動かないまま、41日が過ぎました。

着手前に紙へ書く3行

上の経験から逆算すると、個人開発の撤退基準は3行で足ります。長い規程は作っても読み返さないので、着手の日にリポジトリのREADMEへ書くのが現実的です。

1行目がいちばん効きます。私たちの記録では、未決の4件は完成した日にはもう全部見えていました。見えていたのに期限がなかったので、判定の日が来なかっただけです。

止める合図はどこで見るか

「やる気が落ちた」は合図になりません。気分は上下するので、翌日には戻ってしまうからです。かわりに、外から観測できる3つの指標を使っています。

• 出荷までの距離：完成度ではなく「公開に必要な残り作業」で測る。残りが決断だけなら、それは技術課題ではなく判断課題
• ログが止まった日数：開発ログの最終更新が2〜3週間動かないなら、実質は止まっている（私たちの止めた1本は、最終更新が完成した日のまま動きませんでした）
• 未決の担当者の偏り：決める人が1人に集中し、その人の時間が別の案件に使われているなら、期限を延ばしても結果は変わらない

止めたあとにやること——コードは消さない

私たちは凍結したフォルダを削除していません。社内のドキュメントにも「フォルダ・コードは履歴として存置（削除しない）」と明記しています。

理由は3つあります。第一に、設計文書9本は他プロダクトの設計にそのまま使えること。第二に、止めた判断の根拠を後から検証できること。第三に、消すと同じテーマをまた一から作ってしまうからです。

過去の労力が惜しくて止められない現象は、サンクコスト効果という心理の偏りとして知られています（使わない機能を消せない理由）。ここで大事なのは、止める判断とコードを消す判断を分けることです。前者は早く、後者は急がなくて構いません。

なお、この記事は「公開前に止めた」ケースの記録です。すでにユーザーがいるサービスを閉じる場合は、事前告知・データの返却や削除・課金の停止といった別の手順が要ります。そこは範囲が違うので、この記事では扱いません。

止める判断は、そのプロダクト1本では終わらない

想定していなかった副作用が1つありました。止めた1本は、姉妹プロダクトの設計と繋がっていたのです。

Lifefolio では「市場価値の本格的な診断は別のプロダクトに委ねる」という境界を2026-06-21に決めており、その受け皿が、今回止めた1本でした。受け皿を止めた瞬間、その境界だけが宙に浮きます。

つまり撤退の判断には、そのプロダクト単体の損得だけでなく、他のプロダクトに残った「〜に任せる」という前提の棚卸しが含まれます。私たちはこの点を事前に見落としていました。3行目の「止めたあとの行き先」に、他プロダクトへの影響確認を足したのはこの経験からです。

私たちがこの1本から得たもの

止めたこと自体は失敗ではありません。失敗だったのは、未決事項に期限を付けないまま完成まで走ったことです。作業の速さは、決断の遅さを埋めません。

止めた記録には、決定ログにたった1行だけこう残っています。

「プロダクトとしては使わない」

冷たい1行ですが、この1行があるおかげで、いま同じテーマを再び作り始めることはありません。止めた理由が言葉で残っていることが、次の判断を軽くします。

見積もりが外れ続ける現象にも似た構造があります（見積もりはなぜ毎回外れるのか）。人は作業時間を楽観的に見積もり、決断にかかる時間はそもそも見積もりません。撤退基準は、その見積もられない時間に上限を置く道具だと考えています。

よくある質問

Q. 完成しているなら、とりあえず公開してから判断すればよいのでは？

公開そのものに決断が要る場合は、その順番が使えません。私たちの例では、公開に独自ドメインの実費と課金設計の決定が含まれていたため、「公開してから考える」が成立しませんでした。逆に言えば、実費も課金も伴わない公開なら先に出す方が速いです。判断材料が手に入り、撤退基準を数字で引けるようになります。

Q. 個人開発でも、企業のような数値基準（KPI・投資回収期間）は使えますか？

公開後であれば使えます。ただし個人開発の場合、投資の大半は現金ではなく自分の時間なので、回収期間より「毎週何時間使っているか」の方が実態に合います。公開前の段階では数値基準は機能しないため、この記事で挙げた未決事項の期限で代替するのが現実的です。

Q. 撤退基準を決めると、やる前から諦めているようで気が進みません。

順序が逆で、基準があるほど早く着手できます。止め方が決まっていない挑戦は、失敗したときの損失が読めないため、着手そのものが慎重になります。基準は「ここまでは安心して突っ込んでよい」という上限を示すもの、と捉える方が実態に近いです。

Q. 止めたプロダクトのコードやドメインは、どう扱うのが安全ですか？

コードと設計文書は消さずに残し、公開していたURLがあるなら、リンク切れにならないよう扱いを決めておくのが無難です。私たちの例は未公開だったため、フォルダをそのまま履歴として残すだけで済みました。公開済みのサービスを閉じる場合は、利用者への告知や個人データの取り扱いなど別途の検討が必要になるため、一般論として言えるのはここまでです。

Q. 「止める」と「凍結する」は分けた方がよいですか？

分けた方が実務的です。私たちは「凍結（プロダクトとしては使わないが、コードと文書は残す）」を選びました。完全に終わらせると、あとから素材として再利用する道まで閉じてしまいます。凍結なら、判断は今日下しつつ、資産の使い道は将来に残せます。