アプリ売却はどこでするのが正解か

アプリ売却はどこでするのが正解か
アプリ売却で本当に効くのは、売り場の料金や評判ではなく、技術資産を正しく値付けしてもらえるか、引き継ぎ実務まで見てもらえるか、揉めたときに守られるか、という三つの保全のどれが付くかである。個人間の直接取引・ストアの譲渡機能・仲介やマーケットという三つの型は、この保全の有無がまるで違う。売り場を探す前に、自分のアプリに必要な保全がどれかを見極め、手元の技術資産を棚卸ししておくことが、どこで売るかの判断を分ける。

アプリを手放すと決めた開発者が最初に打ち込む検索語は、だいたい「アプリ売却 どこで」です。返ってくるのは、仲介会社やマーケットの名前を並べた比較記事で、比べる軸は手数料が何パーセント、成約実績が何件、担当者の対応はどうだったか──料金と評判のあたりに落ち着きます。どこが一番お得か、という順位表を求めて検索したのに、出てくるのはやはり順位表です。

ところが私たちがアプリの売買を数多く見てきて痛感するのは、「どこで売るか」で本当に変わるのは料金でも評判でもない、ということです。変わるのは、あなたの技術資産が正しく値付けされるか、引き渡しの実務まで面倒を見てもらえるか、そして途中で揉めたときに守られるか、というもっと手前の三点です。同じ「売る場所」でも、この三つがまるごと付いてくる型もあれば、一つも付いてこない型もある。料金表だけを見比べても、この差は絶対に見えてきません。

「どこで売るか」は場所ではなく、三つの保全のどれが付くかで決まる

「どこで売るか」は場所ではなく、三つの保全のどれが付くかで決まる

アプリの売却先は、名前で並べると無数にあるように見えますが、構造で分けると三つの型に集約されます。一つは、売り手と買い手が直接つながって取引する個人間の直接取引。もう一つは、ストアが公式に用意しているアプリの譲渡機能。そして三つ目が、あいだに事業者が入る仲介・マーケットです。名前ではなく、この型の違いこそが、さきほどの三つの保全の有無を決めています。

三つの保全とは、具体的にはこうです。一つ目は技術資産の評価──署名鍵やソースコード、外部サービスへの依存といった、売上の数字には現れない資産を、値付けの段階できちんと見てもらえるか。二つ目は引き継ぎ実務の伴走──契約が成立したあと、アカウントや鍵やデータを買い手名義へ結び直す地味な工程を、誰かが手順として面倒を見てくれるか。三つ目はトラブル時の保全──着金と引き渡しがすれ違ったときや、あとから不具合が見つかったときに、あいだで守ってくれる仕組みがあるか。

この三つを一本の軸として頭に置くと、「どこで売るのが正解か」という問いは、「自分の案件では、この三つのうちどれが欠けると致命傷になるか」という問いに置き換わります。技術的に単純で引き継ぎが軽いアプリなら保全が薄くても崩れませんが、外部依存が多く署名鍵の扱いが重いアプリを保全ゼロの型で売れば、金額が決まったあとに崩れます。以下、型ごとに三つの保全がどう変わるかを一つずつ見ていきます。

個人間の直接取引 ── 三つの保全がすべて自分の肩に乗る型

個人間の直接取引 ── 三つの保全がすべて自分の肩に乗る型

SNSの募集や知人づて、開発者コミュニティでの声かけから、売り手と買い手が直接つながって話を進める型です。あいだに誰も入らないぶん手数料はかかりませんが、その代わりに三つの保全がまるごと当事者二人の肩に乗ります。技術資産の評価をしてくれる第三者はいないので、値付けは「なんとなくこのくらい」で決まりがちです。署名鍵が個人名義のままか、ソースコードの権利が外注先に残っていないか、といった論点は、買い手が自分で知っていて聞かないかぎり、そもそも話題にすら上りません。

引き継ぎ実務も全部が手作りになります。App Store Connect のアカウント、署名に使う証明書と鍵ファイル、コードのリポジトリ、決済や分析や通知の各APIキー──これらを何のチェックリストもないまま口頭とチャットで受け渡すと、必ず取りこぼしが出ます。売り手が「一式渡した」つもりでも、買い手が起動してみたら通知が飛ばない、決済が旧オーナー口座に流れ続ける、という事故は、この型でいちばん起きやすいものです。引き渡しの実務そのものの重さはアプリ売却の事例が語らない移管作業で詳しく扱っていますが、直接取引ではそれを丸ごと素人二人でやることになります。

そして最も薄いのがトラブル時の保全です。お金を預かってくれる仕組みがないので、先に払えば「払ったのに移管されない」、先に渡せば「渡したのに入金されない」というリスクが常につきまといます。引き渡し後に不具合が見つかっても、あいだに立って調整してくれる人はいません。残る手段は当事者同士の交渉か、最悪は民事の争いです。金額が小さいアプリほど、この争いのコストが売却額を上回り、泣き寝入りに終わります。売買の綻びが引き渡しの後から表面化する構造はサイト売買の失敗は引き渡し後に始まると同じで、保全のない直接取引はその構造をむき出しで抱え込みます。

ストアの「アプリ譲渡機能」は売却先ではなく、移管の一工程にすぎない

ストアの「アプリ譲渡機能」は売却先ではなく、移管の一工程にすぎない

Apple の App Store Connect には「App の移送(App Transfer)」、Google Play にも「アプリの移行」という公式機能があります。これを「アプリの売却先」だと思っている人が少なくないのですが、正確にはこれは売却の場ではなく、移管という工程の一部を自動化してくれる仕組みにすぎません。買い手を探してくれるわけでも、価格を決めてくれるわけでも、お金を預かってくれるわけでもない。あくまで「相手がすでに決まっている前提で、ストア上の登録だけを移す」道具です。

この機能が担うのは、ストアという狭い一区画だけです。App Transfer なら、アプリのレビューや評価、ダウンロード実績、多くの場合はサブスクリプションの継続契約が、買い手のアカウントへ引き継がれます。ここはよくできていて、手作業では再現できない綺麗さで移ります。ですがそれ以外──サーバー、ソースコード、外部APIキー、独自ドメイン、そして署名に使う証明書──は、この機能の管轄外です。とりわけ署名証明書は移送されず、買い手が自分の名義で作り直す必要があります。バンドルID(アプリの識別子)はアプリと一緒に相手へ移り、元の持ち主の手からは完全に離れます。この一点の重さはアプリ売却の査定額は署名鍵で決まるで掘り下げているとおりです。

つまりストアの譲渡機能を使うということは、「ストア登録という一区画は公式が綺麗に運んでくれるが、残りの九割の資産は自分たちで運ぶ」という状態を選ぶことです。ここを取り違えて「公式機能で移すから安心」と考えると、ストアの外にある資産の受け渡しが丸ごと抜け落ちます。譲渡機能は目的地ではなく、移管という長い道のりのなかの、舗装された一区間だと捉えるのが正確です。

ストア譲渡を止める設定は、たいてい契約に判を押したあとで発覚する

ストア譲渡を止める設定は、たいてい契約に判を押したあとで発覚する

ストアの譲渡機能には、満たさないと移送そのものが実行できない条件が並んでいます。Apple の App Transfer で代表的なのは、ワイルドカードのApp ID(複数アプリで使い回す汎用の識別子)を使っているアプリは移送できないこと、他のアプリと共有している App Group や iCloud コンテナがあると引っかかること、Apple Pay を使っているならマーチャントIDの扱いを整理しておく必要があること、そして未締結・保留中の契約(有料アプリ契約など)が残っていると止まること、です。

やっかいなのは、これらの条件が契約書のドラフト段階では誰の視界にも入らないことです。譲渡契約に「本アプリをストアの譲渡機能により移送する」と一行書くのは簡単ですが、いざ実行ボタンを押す段になって「共有 App Group があるので移送できません」と弾かれる。売り手も買い手も判を押したあとで、実は構成の作り直しが必要だったと気づく。この順番の狂いが、成立したはずの取引を宙づりにします。移送を止めるのが設定だけならまだしも、開発者アカウントの名義や登録情報そのものが引っかかることもあり、その論点は個人開発の売却を止めるアカウント名義で扱っています。

加えて、譲渡の可否はストア側の規約の状態にも左右されます。規約違反の警告を受けている、審査で保留になっている項目が残っている、といった状態のアプリは、そもそも綺麗に移せません。ストアの規約がアプリの価値そのものを削る仕組みは個人開発アプリの価値を消すストア規約で詳しく述べていますが、「どこで売るか」を考えるときには、選んだ売り方が最終的にこのストア譲渡の関門を通れる構成になっているか、を早い段階で確認しておく必要があります。

仲介・マーケットは「お金の保全」を「技術の保全」だと錯覚させる

仲介・マーケットは「お金の保全」を「技術の保全」だと錯覚させる

あいだに事業者が入る仲介やマーケットは、三つの保全のうち少なくとも一つ、トラブル時の保全を構造として持っていることが多い型です。代金をいったん第三者が預かり、引き渡しの確認が取れてから売り手に渡すエスクロー(第三者預託)の仕組みがあれば、「払ったのに移らない」「渡したのに入金されない」という直接取引の最大のリスクは消えます。この点だけを見れば、直接取引より一段安全です。

ところがここに落とし穴があります。お金の保全が付いていることを、技術の保全まで付いていると錯覚しやすいのです。仲介やマーケットの多くは、売上や利用者数といった財務の数字でアプリを評価します。月いくら稼いでいて、利用者が何人いるか。そこは丁寧に見ますが、署名鍵が誰の名義か、外部APIにいくつ依存しているか、ソースコードの権利が外注先に残っていないか、といった技術資産の中身は、ブラックボックスのまま値段だけが付くことがある。お金は守られても、買った中身が空っぽに近い、という事態はここで起きます。

だから仲介やマーケットを選ぶときに見るべきは、手数料率や成約件数よりも先に、「この相手は技術資産を評価する枠組みを持っているか」です。財務の数字しか見ない相手のもとでは、技術的に重いアプリの価値は正しく値付けされず、引き継ぎ実務の伴走も期待できません。エスクローという言葉の安心感で、評価と伴走という残り二つの保全の欠落を見逃さないことが肝心です。

相手が技術資産を評価できるかは、最初にどこを質問するかで分かる

相手が技術資産を評価できるかは、最初にどこを質問するかで分かる

では、目の前の売却先が技術資産まで見てくれる相手かどうかを、どう見分けるか。いちばん確実なのは、相手が最初に何を質問してくるかを観察することです。売上と利用者数だけを聞いて金額の話に進む相手は、アプリを財務の箱として見ています。一方で、署名鍵の名義、ソースコードの管理場所と権利の所在、依存している外部サービスの一覧、データのエクスポート可否、といった中身を早い段階で聞いてくる相手は、移管まで見据えて評価する枠組みを持っています。

この見分けは、買い手個人に対しても、あいだに入る事業者に対しても同じように効きます。技術資産を評価できる相手は、必ず「引き渡しのときに何を渡してもらう必要があるか」を先回りして確認します。逆に、その確認をしない相手と話が進むと、契約は成立しても引き渡しで詰まる。数字だけで合意した案件が引き渡し段階で崩れるのは、この最初の質問の差が伏線になっていることがほとんどです。

売り手の側から見れば、この質問に淀みなく答えられる状態になっているかどうかが、そのまま自分のアプリの「売りやすさ」です。署名鍵の名義を答えられない、外部APIをいくつ使っているか即答できない、というのは、どの型で売るにしても値引きと難航の種になります。逆にここが整理できていれば、直接取引でも仲介でも、相手が技術を評価できる相手でありさえすれば話は早く進みます。

「どこで売るか」を決める前に、売り手が手元でやっておくこと

「どこで売るか」を決める前に、売り手が手元でやっておくこと

ここまで見てきたとおり、「どこで売るのが正解か」は、売り場のブランドを選ぶ問題ではなく、自分の案件に必要な三つの保全を、どの型なら過不足なく満たせるかを選ぶ問題です。そしてその判断は、自分のアプリがどれだけ引き継ぎやすい状態にあるかが分かっていないと、そもそも下せません。だから順番としては、売り場を探すより先に、手元の資産を棚卸しするほうが効きます。

棚卸しの中身はシンプルです。ストアの開発者アカウントは個人名義か法人名義か、移せる状態か。署名に使う証明書と鍵ファイルはどこにあり、誰の管理下か。ソースコードのリポジトリと、その権利は自分に帰属しているか、外注が絡むなら譲渡の合意はあるか。依存している外部サービスと、それぞれのAPIキーの一覧。データはどの粒度でエクスポートできるか。この棚卸しが済んでいれば、どの型で売るかを冷静に選べますし、逆にここが曖昧なままだと、どんなに評判の良い売り場を選んでも引き渡しで足を取られます。

整理が進んで、では自分のアプリはいくらで、どの軸が評価されるのかを一度掴んでおきたくなったら、スマホアプリ売却の無料査定で想定売却額のレンジと評価される軸を確認できます(登録不要)。売り場を決めるのはそのあとでも遅くありません。

この記事の著者

黒沢 大輔

株式会社studio C 代表取締役

これまで4回の事業譲渡を実現。上場企業にてエンジニア、制作ディレクション、SEO事業立ち上げを歴任。副業で始めた複数の掲示板サイトを国内最大規模まで成長させて事業譲渡。日本のM&Aに透明性と精度をもたらすべく、デジタル事業のM&Aプラットフォーム『RIKKA M&A』を立ち上げ。