作って公開しなかったアイデアを捨てた話

結論

個人開発では「公開しない判断」もプロダクト開発の一部です。kimura512.dev のトップには、URL が生きている完成品だけを載せています。作りかけを並べるより、出すものを絞った方が、訪問者にも自分にも誠実だと感じています。

1. 捨てた理由

捨てた試作は、独自性が薄い・運用コストが高い・説明が書けない、のいずれかに当てはまることが多いです。作っている途中は楽しくても、公開して保守する段階で負担が一気に増えます。どの理由が強いかで、続けるか記事にして終わるかを決めています。

2. 地図系の試作例

酔愛マップ以外の地図系アイデアは、データを定期的に更新するコストが高く見送りました。コードは別ブランチに残し、ブログでは選定理由だけ共有しています。作ったものを全部公開しなくても、判断の過程を文章に残せば学びは残ります。

3. コードの扱い

試作コードは private リポジトリに残し、学びだけを記事にします。ダッシュボードのプレースホルダーには出しません。途中の状態をそのまま見せると、中途半端な印象を与えてしまいます。

4. Works の見せ方

Works には released のものだけを載せ、リンク先が 200 になるものだけにリンクしています。リンクを踏んだ人が白い画面やエラーに当たるのは、信頼を大きく損ねます。公開前に手で開いて確認するのを習慣にしています。

5. 再開の条件

週末2日で MVP が出せると判断できるときだけ再開します。それ以外の試作は、記事にして一区切りとします。再開の条件を決めておくと、なんとなく手を付け続けてしまう状態を防げます。

6. 記事化

失敗談や見送り理由はテキストとして残すと、あとから自分も読み返せます。作って捨てた経験も、次の選定の材料になります。同じ壁にぶつかる人の時間を節約できるなら、それだけで記事にする価値があります。

7. ダッシュボードの整理

Works から Coming Soon を削除し、released だけを表示するようにしました。ブログも published フラグで制御し、下書きは URL を作らない方針です。公開中のものだけが見える状態にすると、サイト全体が整理されて見えます。

8. 学びの共有

捨てた試作でも、選定理由を記事にすると他の人の時間を節約できます。実装を全部見せなくても、「なぜやめたか」は価値のある情報です。

公開しないプロジェクトのコードは、半年後に読み返しても意味が分かる README だけ残し、サイト上には完成品だけを見せています。

公開を止めたあとも、リンク切れを残すと審査や検索の両方でマイナスになります。トップから外したら、ブログに「なぜ止めたか」を短く書くか、README だけ残して URL は 404 にしない方針です。「捨てた」プロジェクトでも、技術選定の理由は README に残しています。半年後に読み返して意味が分からないコードは削除し、判断のログだけ残す方が、自分の頭の中も整理されます。トップに載せるかどうかと、git に残すかどうかは別の判断です。

新作を足す前に、トップの作品数を一度減らす週を設けました。見せ場が増えるほど、どれも中途半端に見える問題が起きやすいです。

ブログのテーマも同じで、「書けること全部」より「自分が説明できること」に絞ると、記事の厚みが一気に変わりました。捨てた案の半分は、あとから別プロジェクトの部品として再利用されています。ゼロにはなりません。見送りの理由が「技術が無理」なのか「自分の関心が切れた」なのかを分けて書くと、再挑戦の判断が楽です。関心だけが切れた案は、半年後に短いプロトタイプとして復活させることがあります。技術的に無理だった案は、記事の結論に「今はやらない」と書いて閉じ、同じ失敗を繰り返さないようにしています。トップの作品数は少なくても、説明できる記事が増えればサイト全体の密度は上がります。見送りリストを月一で見直し、まだ刺さるものだけ再検討します。刺さらなければメモごと削除します。棚卸しは負けではなく、次の公開の準備です。

まとめ

出さないことを決められると、出すものの質が上がります。何を世に出すかを絞ることは、自分の時間を守るうえでも大切です。

補足

Q. 削除したコードは？

git の履歴には残りますが、public にはしていません。

Q. 再公開は？

週末 MVP の基準を満たすときだけです。基準を満たさないまま出すと、中途半端なものが残ります。