SECTION 01
個人開発アプリは売れるのか？結論と売れる条件
結論から言えば、個人開発のアプリやWebサービスは売れます。ただし、すべてが売れるわけではなく、買い手が「引き継いで自分たちで回せる」と判断できるかどうかが分かれ目になります。
これまで40本以上のサービスを作ってきましたが、売却まで持っていけたのは正直ほんの一握りでした。大半は誰にも使われないまま終わるか、収益化の手前で頓挫しています。ただ、うまくいったものには共通した「何か」 がありました。
売れるプロダクトに共通する条件を整理すると、次のようになります。
- 継続的な収益がある（月額課金や広告収入が安定して入っている）
- ユーザーが定着している（登録だけでなく、実際に使い続けている人がいる）
- 運用が属人化していない（作者が手を離しても動き続ける仕組みがある）
基本的には、1円でも売り上げが継続的に上がっていれば可能性はあります。買い手が見ているのは「今いくら稼いでいるか」だけではなく、「この収益が今後も続くか、伸ばせるか」という将来性です。
逆に、売れないプロダクトの特徴 もはっきりしています。収益がゼロ、作者しかデプロイや障害対応ができない、技術負債が積み重なりすぎている——こうした状態では、買い手にとって引き継ぐメリットがありません。
売却を意識するなら、「自分がいなくても価値が残るか」 を常に問い続けることが大切です。技術的に完成しているだけでは足りず、ユーザーと収益がセットで存在していることが最低条件になります。
SECTION 02
いくらで売れるのか——価格の考え方と相場感
個人開発者が最も気になるのは、「結局いくらで売れるのか」 という点でしょう。基本的な考え方としては、月次利益を基準にして、その一定倍数が売却価格の目安になります。
ただし、この倍数は買い手のシナジーによって大きく上下します。買い手が既存事業とのセットで価値を見出せば高くなりますし、単純にプロダクト単体の収益力だけで判断されれば低くなります。
個人開発者が陥りやすいのは、価格の過大評価と過小評価の両極端 です。思い入れが強いと「もっと高くていいはず」と感じますし、逆に自信がないと「こんなもの売れるわけがない」と値段を下げすぎてしまいます。
自分の経験では、月12万円ほどの売上で運営していたサービスを数百万円で売却 したことがあります。規模としては小さく見えるかもしれませんが、継続的な収益とユーザー基盤があれば、買い手は十分に価値を見出してくれます。
金額に納得できたのは、事前に自分なりの最低ラインを決めていたから です。交渉の場で初めて考え始めると、買い手のペースに引き込まれてしまいます。
交渉で主導権を握られないために、最低限やっておくべきことがあります。
- 自分の最低売却価格を事前に決めておく
- 収益の推移を月次で可視化し、根拠として提示できるようにする
- 複数の買い手候補と同時に話を進め、比較検討の余地を持つ
SECTION 03
売却できる状態にするために整えておくこと
売却を決めてから慌てて準備するのでは遅いです。買い手が見る指標は決まっている ので、日頃からデータを蓄積しておくことが重要になります。
買い手がチェックする代表的な指標は以下の通りです。
- 月次の売上と利益の推移
- アクティブユーザー数と解約率の傾向
- 主要な流入チャネルと集客コスト
技術面では、ソースコードとインフラの引き渡し準備 が必要です。GitHubのリポジトリ整理、環境変数やシークレットの一覧化、外部サービス（決済・メール配信・分析ツールなど）の契約状況の棚卸しが求められます。
見落としがちなのが属人化の排除です。自分しか知らない運用手順、自分のアカウントに紐づいた外部サービス、ドキュメント化されていないデプロイ手順——これらが残っていると、買い手は引き継ぎコストを嫌って価格を下げてきます。
法務面も忘れてはいけません。利用規約、プライバシーポリシー、使用しているライブラリのライセンス を整理しておく必要があります。特にオープンソースライセンスの扱いは、買い手側の法務チェックで引っかかりやすいポイントです。
理想は、「明日自分が消えてもサービスが回る状態」 を作っておくことです。この状態ができていれば、売却交渉でも強い立場に立てます。
SECTION 04
どこで売るか——売却チャネルの選び方
個人開発のプロダクトを売却する場所は、以前に比べて選択肢が増えています。個人・小規模向けのM&Aプラットフォームが整備されたことで、仲介業者を通さなくても自分で売却を完結できる環境が整ってきました。
チャネルを選ぶ際の判断軸は、主に規模と金額帯です。小規模な譲渡であればプラットフォーム上で直接やり取りするのが手軽ですし、ある程度の規模になれば仲介を挟んだほうが安全に進められます。
プラットフォームを選ぶときに見るべきポイントがあります。
- 契約書の自動生成やテンプレートが用意されているか
- 法律相談やエスクロー（代金の一時預かり）機能があるか
- 過去の成約実績や利用者の評判が確認できるか
直接交渉のほうが手数料を抑えられますが、契約トラブルのリスクも自分で背負う ことになります。初めての売却であれば、多少コストがかかっても仲介やプラットフォームの仕組みに頼るほうが安心です。
大事なのは、売却チャネルを決めてからプロダクトを整えるのではなく、整えてからチャネルを選ぶ という順番です。準備ができていないまま掲載しても、買い手は興味を持ちません。
SECTION 05
売却の流れ——打診から引き渡し完了まで
売却の流れは、大きく分けると「打診→条件交渉→契約→引き渡し→入金」 のステップで進みます。最初の打診から完了まで、短くても数週間、長ければ数ヶ月かかるのが一般的です。
最初のステップは買い手との接触と条件のすり合わせです。プラットフォーム経由であれば、興味を持った買い手から問い合わせが来ます。この段階では秘密保持の意識を持ちつつ、プロダクトの概要と収益データを共有します。
条件が折り合えば、契約書の締結に進みます。ここで絶対にやってはいけないのが、口頭合意だけで引き渡しを始めてしまうことです。「後で書面にしましょう」のまま進めて、後からトラブルになるケースは実際に起きています。
引き渡しで見落としがちな実務を整理しておきます。
- 著作権の移転（契約書に明記しないと曖昧になる）
- 外部ライブラリのライセンス確認と引き継ぎ
- ドメイン、サーバー、決済アカウント、SNSアカウントの移管
税務処理も忘れてはいけません。売却益は確定申告の対象になります。個人の場合は譲渡所得として扱われるケースが多いですが、事業所得との区分など判断が分かれる部分もあるため、不安があれば税理士に相談するのが確実です。
全体を通して意識すべきは、「引き渡し完了」が本当のゴール だということです。契約書にサインした時点ではなく、買い手が問題なく運用を開始できた時点で売却は完了します。
SECTION 06
売るか続けるか——後悔しないための判断軸
売却を検討するとき、多くの開発者が「本当に手放していいのか」 という迷いを抱えます。自分が作ったプロダクトには愛着がありますし、売った後に買い手が大きく成長させたら後悔するかもしれない——そんな不安は自然なものです。
まず前提として、「売却＝失敗」ではありません。むしろ、戦略的なEXITとして売却を選ぶことは、次のプロダクトに時間と資金を集中させるための合理的な判断です。
自分が月12万円のサービスを売却した理由も、まさにそこにありました。個人開発で一人で複数のサービスを運用していると、サポートコストや精神的な負荷が着実に積み上がっていきます。売却してサービスを手放すことで、本当に集中したいプロダクトにリソースを振り向けられるようになりました。
オンラインメンターサービスMENTAの場合は、億単位での売却となりました。規模が大きくなり、チームでの開発が必要になったこと、そしてすでにグロースさせた実績のある大手資本に入ったほうがもっとサービスを伸ばせると判断したからです。
さらに、まとまったお金を得ることで生活の安定が手に入りますし、次の挑戦にも踏み出しやすくなります。いわば数年分の時間を先に買ったようなものです。
もちろん、売却の考え方は人それぞれです。
- 手放した後にさらに伸びる可能性もあれば、落ちる可能性もあります
- 自分で伸ばし続けたい人もいれば、ゼロイチが好きでまた新しいサービスを作りたい人もいます
ちなみに自分は後者でした。試行錯誤を重ねてきた中で固まった「続けるか売るかの判断基準」は次の通りです。
- 自分がこのプロダクトに情熱を持ち続けられるか
- 今の成長ペースが、自分一人のリソースで維持・加速できるか
- 売却で得た資金と時間を、より大きな機会に投資できるか
売却後に後悔する人としない人の違いは、「納得感」を持って手放せたかどうか に尽きます。金額の大小よりも、自分の中で「ここまでやった」「次に進むための判断だ」と腹落ちしているかが重要です。
売却で得た資金と時間を次のプロダクトに回す。「作って→育てて→売却」のサイクル を回せるようになると、個人開発の持続可能性が格段に上がります。一つのプロダクトに固執しすぎないことが、長く開発を続ける秘訣です。
SECTION 07
売却を前提にしたアプリ開発の始め方
最初からEXITを視野に入れて開発を始めると、意思決定の基準が変わります。「自分が使いたいもの」だけでなく、「他の人が引き継いでも回せるか」という視点が加わるからです。
売却しやすいプロダクトの条件を逆算すると、開発初期にやるべきことが見えてきます。
- 収益モデルを早い段階で組み込む（無料のまま育てすぎない）
- ドキュメントとコードの可読性を最初から意識する
- 外部サービスへの依存を最小限かつ移管可能な形にする
MENTAを振り返ると、あのサービスが売却まで持っていけたのはユーザーの声をベースに機能を積み上げていったからだと思っています。自分の思い込みではなく、実際に使っている人の課題を解決し続けた結果、ユーザーが定着し、収益が安定しました。
「売却前提」と聞くと打算的に感じるかもしれません。しかし実際には、売却できる状態を目指すことは「良いプロダクトを作ること」とほぼ同義 です。ユーザーがいて、収益があり、誰でも運用できる——これは買い手だけでなく、ユーザーにとっても望ましい状態です。
失敗を重ねてきた経験は、確実に資産になります。「このパターンはダメ」「この段階でこうなったらもう伸びない」という判断の蓄積が、次のプロダクトの成功確率を上げてくれます。売却というゴールを持つことで、作ること自体がより戦略的で持続可能な活動に変わっていきます。
SECTION 08
売却の感情的なリアル——数字だけでは語れない部分
売却の話をすると、価格や条件といった数字の話が中心になりがちです。しかし実際に経験してみると、感情面の葛藤が想像以上に大きいことに気づきます。
自分が何ヶ月、何年とかけて育てたプロダクトを他人に渡す瞬間は、合理的な判断だと分かっていても寂しさがあります。ユーザーからの感謝のメッセージを思い出したり、深夜に障害対応した記憶が蘇ったりします。
一方で、手放した瞬間の解放感もまた本物です。運用の責任から解放されることで、ようやく次のことに集中できるようになります。この解放感は、売却を経験した人にしか分からない感覚かもしれません。
感情的な後悔を減らすために意識していることがあります。
- 売却前に「なぜ売るのか」を自分の言葉で書き出しておく
- 売却後にプロダクトがどうなっても干渉しないと決める
- 得た資金と時間で「次に何をするか」を先に決めておく
売却は終わりではなく、次の始まりへの切り替えポイントです。感情に振り回されず、でも感情を無視もしない。そのバランスを保てると、売却という選択を前向きに捉えられるようになります。
