個人開発で「完璧主義」をやめた話 — CancelNavi リリースの決断

はじめに — リリースボタンを押せない病

個人開発をしていると、「もう少し機能を追加してから」「もう少しデザインを整えてから」と、リリースを先延ばしにしてしまうことはないでしょうか。

私もそうでした。

2025年12月、サブスク解約方法を案内するサービス「CancelNavi」を Claude Code で開発していたとき、リリース日を決められずに悩んでいました。登録したサービス情報はまだ10件程度。解約方法は頻繁に変わるため、情報の正確性にも不安がある。AIの力を借りて実装自体は速く進んだのに、「こんな状態でリリースして大丈夫だろうか」という思いが頭から離れませんでした。

この記事では、「完璧主義」を捨ててリリースに踏み切った経緯と、その判断から得た学びを共有します。個人開発で「いつリリースするか」の判断に悩んでいる方の参考になれば幸いです。

CancelNavi とは — 解約方法が分からない問題を解決したい

CancelNavi は、サブスクリプションサービスの解約方法を最短ルートで案内するサービスです。

「サブスクを解約したいのに、解約方法が分からない」という問題を解決したいと思って開発を始めました。サブスクの解約方法は、契約経路（Web直契約、iOS課金、Google Play、キャリア課金など）によって分岐するため、意外と複雑です。公式サイトを探しても、解約ページがどこにあるか分かりにくいことも多い。

年末年始はサブスクの見直しを考える人が多い時期です。このタイミングでリリースできれば、多くの人の役に立てるのではないか。そう考えて、2025年12月18日をリリース目標に設定しました。

「リリースできない」理由を探し始める

リリース目標を設定したものの、日が近づくにつれて不安が増していきました。

情報量の問題

CancelNavi は「情報系サービス」です。ユーザーにとっての価値は、登録されているサービス数と情報の正確性にあります。しかし、開発と情報収集を一人で行っていたため、リリース時点で登録できたサービスは10件程度でした。

「もっとサービスを増やしてからリリースすべきではないか」

そう思うと、いくらでも先延ばしにできてしまいます。20件まで増やそう、いや50件は欲しい、いや100件は必要だ……。キリがありません。

情報の鮮度問題

解約方法は、サービス提供者の都合で予告なく変わります。「先月まではこの手順で解約できたのに、今月は画面が変わっている」ということが普通に起こり得ます。

情報の信頼性をどう担保するか。これも大きな悩みでした。

2025年12月18日の開発日記には、こう書いています。

情報の信頼性をどう担保するか悩んだ 解約方法は頻繁に変わるため、last_verified（最終確認日）とsources（公式ソース）を必須にした

Claude Code にこの仕組みの実装を依頼し、最終確認日を明示することで「この情報は最後にいつ確認されたか」がユーザーに分かるようにしました。また、公式サイトへのリンクを必ず載せることで、不安な場合は公式で確認できるようにしました。

しかし、仕組みを作っても、情報が古くなる可能性は消えません。「古い情報を提供して、ユーザーに迷惑をかけたらどうしよう」という不安は残りました。

完璧主義の罠 — 「リリースしない」という選択肢はない

リリースを先延ばしにする理由はいくらでも見つかります。しかし、ある時点で気づきました。

「完璧になってからリリースする」という選択肢は、実質的に「リリースしない」と同じだ。

情報系サービスの場合、情報量も情報の鮮度も、常に「完璧」にはなりません。サービスは日々増え続けるし、解約方法も変わり続ける。完璧を待っていたら、永遠にリリースできません。

開発日記には、こう記録しています。

情報がまだ少ない状態でリリースするか、もっと情報を集めてからリリースするか 「完璧を目指すより、まずリリースして改善していく」方針を選択 ユーザーからの報告で情報を集める仕組みも組み込んだ

このとき、発想を転換しました。

「一人で完璧にする」のではなく、「ユーザーと一緒に完璧に近づけていく」という考え方に切り替えたのです。

ユーザーからの情報提供を受け付ける仕組みを作り、「足りない情報はユーザーが教えてくれる」という前提でサービスを設計しました。

リリースを決断した3つの理由

最終的にリリースを決断した理由は3つあります。

1. 年末年始というタイミング

サブスクの見直しを考える人が多い時期にリリースすることで、最もニーズが高いタイミングでユーザーに届けられます。このタイミングを逃すと、次の「需要期」は半年後になってしまいます。

個人開発では、タイミングも重要な判断要素です。完璧な機能よりも、適切なタイミングでリリースすることの方が価値がある場合もあります。

2. 最小限の信頼性担保ができていた

情報の信頼性については、last_verified（最終確認日）と sources（公式ソース）を必須にすることで、最低限の担保ができていました。

完璧ではなくても、「これなら許容範囲」というラインは超えていたのです。

3. 改善のサイクルを回せる設計

ユーザーからのフィードバック導線を整備することで、リリース後に情報を追加・修正していく仕組みができていました。

リリースは「終わり」ではなく「始まり」です。最初から完璧である必要はなく、ユーザーと一緒に育てていけばいい。そう考えることで、リリースへの心理的ハードルが下がりました。

リリース後に得た学び

2025年12月18日、CancelNavi をリリースしました。

開発日記には、こう記録しています。

個人開発では「いつリリースするか」の判断が難しい 情報系サービスは、最初から完璧を目指すとリリースできなくなる

リリース後、いくつかの学びがありました。

学び1: 動いているサービスがあることの価値

リリース前は「情報が10件しかない」と思っていましたが、リリース後は「10件からスタートして、どんどん増えていく」と捉えられるようになりました。

何もない状態から何かを作り出すのと、既にあるものを改善するのでは、心理的な負担が全く違います。「動いているサービス」があるだけで、改善のモチベーションが上がります。

学び2: ユーザーの声は予想外の方向から来る

リリース前に想定していた「こういう問い合わせが来るだろう」という予測と、実際に来た声は違いました。

自分一人で考えていても、ユーザーのニーズは分かりません。リリースして初めて、本当のフィードバックが得られます。

学び3: 完璧主義は「行動しない言い訳」になりやすい

振り返ると、リリースを先延ばしにしていた理由の多くは、「失敗を恐れる気持ち」から来ていました。

「情報が足りない」「情報が古くなるかもしれない」という懸念は、確かに正当なものでした。しかし、それを理由にリリースしないことは、問題を解決しているのではなく、問題から目を背けているだけでした。

リリースして、ユーザーの反応を見て、改善する。このサイクルを回さない限り、サービスは良くなりません。

「完璧主義をやめる」ための実践的なアプローチ

CancelNavi のリリース経験から、個人開発で「完璧主義」を乗り越えるためのアプローチをいくつか整理しました。

アプローチ1: 「最低限の品質ライン」を明確にする

完璧は目指せなくても、「これ以上は許容できない」というラインは設定できます。

CancelNavi の場合、以下を「最低限の品質ライン」として設定しました。

• 掲載情報には最終確認日を明示する
• 公式ソースへのリンクを必ず載せる
• 情報が間違っていた場合の報告導線を用意する

この3点をクリアしていれば、「リリースしても許容範囲」と判断できます。

アプローチ2: リリース日を先に決める

「準備ができたらリリースする」ではなく、「この日にリリースする」と先に決めてしまう方法です。

締め切りがあると、「何が本当に必要で、何は後回しにできるか」を強制的に判断せざるを得なくなります。CancelNavi の場合、年末年始という「需要期」に合わせたことで、自然と締め切りが決まりました。

アプローチ3: 「リリース後に改善できる仕組み」を先に作る

リリースが怖いのは、「リリースしたら終わり」と思っているからかもしれません。

フィードバックを受け付ける仕組み、情報を更新する仕組み、問題があれば修正する仕組みを先に作っておくことで、「リリースは始まりに過ぎない」と思えるようになります。

Claude Code との協業があると、このアプローチはさらに効果的です。リリース後にフィードバックが来たとき、PMとして改善方針を決めてAIに修正を依頼すれば、素早く対応できます。「リリース後も速く改善できる」という安心感が、リリースのハードルを下げてくれました。

アプローチ4: 開発日記で意思決定を記録する

「なぜリリースするのか」「なぜリリースしないのか」を開発日記に書くことで、自分の思考を客観視できます。

書いてみると、「この理由でリリースを先延ばしにするのは合理的ではない」と気づくことがあります。CancelNavi のリリースを決断できたのも、開発日記に書くことで思考が整理されたからでした。

情報系サービス特有の「鮮度問題」への向き合い方

CancelNavi は情報系サービスなので、情報の「鮮度」が常に課題になります。この問題への向き合い方も、リリース後に整理できました。

「完璧な鮮度」は不可能と認める

どれだけ頑張っても、すべての情報を常に最新に保つことは不可能です。サービス提供者が解約方法を変更するタイミングをコントロールすることはできません。

この前提を認めた上で、「次善の策」を考える方が建設的です。

透明性で信頼を担保する

情報が古い可能性があることを隠すのではなく、明示する方が信頼につながります。

• 最終確認日を表示する
• 公式ソースへのリンクを載せる
• 「情報が異なる場合は公式サイトをご確認ください」と注記する

ユーザーは「この情報は絶対に正しい」とは期待していません。「この情報がいつ確認されたか」「信頼性を自分で判断する手段があるか」を求めています。

ユーザーを「情報提供者」として巻き込む

一人で情報を収集・更新するのは限界があります。ユーザーから「この情報は古いです」「この解約方法が追加されました」という報告を受け付ける仕組みを作ることで、情報の鮮度を維持しやすくなります。

まとめ — 「動くサービス」を持つことの価値

CancelNavi のリリースを通じて、以下のことを学びました。

1. 完璧を待っていたら、永遠にリリースできない — 特に情報系サービスは、情報量も鮮度も「完璧」にはならない
2. 「最低限の品質ライン」を設定する — 完璧は目指せなくても、許容範囲は設定できる
3. リリースは「終わり」ではなく「始まり」 — 改善のサイクルを回すために、まずリリースする
4. ユーザーと一緒に育てる — 一人で完璧にするのではなく、フィードバックを受けて改善していく

個人開発では、完璧主義は「行動しない言い訳」になりがちです。特にAIとの協業で開発速度が上がった今、「技術的にはすぐ作れるのに、リリースを躊躇する」というギャップを感じる場面が増えました。ボトルネックは技術ではなく、自分の判断力とマインドセットにある。

「もう少し機能を追加してから」「もう少しデザインを整えてから」と思っているなら、一度立ち止まって考えてみてください。それは本当に必要なことなのか、それとも「失敗を恐れる気持ち」から来ているのか。

動いているサービスがあることには、大きな価値があります。リリースして初めて分かることがあります。

完璧を目指すより、まずリリースして、そこから改善していく。その方が、結果的に良いサービスになると、今は確信しています。