Atlassianプラグイン専業のSnapbytes、エコシステム最大手Appfireへ売却。「他社の庭」で育てる戦略

Snapbytesの売却は、派手な数字が公表された事例ではない。売却額は非公表、事業はJiraのプラグインという地味な領域だ。それでも記録する価値があるのは、「他社の庭で店を開く」戦略の始点(2005年頃の社内プラグイン)から出口(2021年のロールアップへの売却)までを一気通貫で追えること、そして売却の引き金が、プラットフォーム本体による方針転換という教科書的なエコシステムリスクだったことにある。

社内の困りごとから売却まで——16年のタイムライン

「困りごと→無料→有料」という立ち上がり

Senturk氏の出発点は2005年頃、勤務先のIT企業でJiraの不便を解決するために余暇で書いたプラグインだ。まず無料で公開し、利用が広がってから有料に切り替えた。本人は「有料化が、利益の出る事業の始まりだった」と振り返る。2016年にSnapbytesとして事業化し、Jiraのワークフローを拡張するEnhancer Pluginと、SLA(サービスレベル契約)管理のTime to SLAを柱にAtlassian Marketplaceで販売した。

売却時点の体制は従業員8人+業務委託4人(このほかトルコ法人Snapbytes Turkeyに別途十数人)。顧客は90カ国以上・4,000社超に広がっていた。営業チームを持たずにこの分布へ到達できた理由は、マーケットプレイスの構造にある。

大手の庭は「集客・課金・出口」の三点セット

大手プラットフォームのマーケットプレイスは「集客・課金・出口」の三点セットを提供する。顧客はマーケットプレイス検索から来て、課金はプラットフォームが代行し、出口(Appfire等のロールアップ)まで整備されている。Shopifyアプリの売却、Bubble周辺のFluskと同じ、「他社の庭で店を開く」戦略の完成形である。買い手のAppfireはAtlassianエコシステムのプラグインを多数買収・統合する「プラグインのロールアップ」企業で、売却当時すでに26カ国・750人超の規模だった。

代償はプラットフォームの規約・手数料・仕様変更への従属だ。Black Magicの教訓と裏表であり、エコシステム内事業は「早めに売る」出口意識と相性がいい。Snapbytesの場合、この教科書的リスクが実際に発生した。

トルコから世界へ——立地の意味

Senturk氏は開発拠点をイスタンブールに置いたまま、2018年に英国の「卓越人材」ビザを取得してケンブリッジに本社を構えた。顧客の大半は欧米企業だが、Atlassian Marketplaceがストアとして集客・決済・請求を代行するため、開発者の所在地は事業の制約にならない。Prowly(ポーランド)やAXDRAFT(ウクライナ)が営業チームを作って越境したのに対し、マーケットプレイス型は営業ゼロで生まれた瞬間からグローバルだ。

Appfireのようなロールアップの存在は、この立地非依存をさらに強める。買い手は世界中のプラグインを同じ基準(収益・レビュー・解約率)で評価するため、無名の個人でも数字さえあれば交渉のテーブルに載る。

売却の引き金はAtlassianの方針転換だった

エコシステム内事業の三大リスク(本体の機能内製化、手数料改定、基盤の仕様変更)は、どれも売り手にコントロールできない。Snapbytesでは3つ目が現実になった。2020年10月、Atlassianはサーバー版製品のサポートを3年かけて終了し、クラウドへ全面移行すると発表した。サーバー版前提で築いたプラグイン資産は、クラウド向けの作り直しを迫られる。Senturk氏はクラウド技術に確信が持てず、これが売却検討の直接の引き金になったと語っている。

折しも事業はコロナ禍のリモートワーク需要で伸びており、Appfireはエコシステムのプラグインを買い集めている最中だった。売り手の交渉力は「エコシステムの成長期」にピークを迎え、以後は下がる一方である。「まだ伸びるのに売るのか」ではなく、「まだ伸びるから売れる」。Snapbytesの売却は、この原則が机上の空論でないことを、実際に起きたプラットフォームリスクとともに示している。

全部は売らない——取引の構造

Appfireが取得したのは英国法人とIP(知的財産)、そしてイスタンブールの8人のチームで、トルコ法人Snapbytes Turkeyは別会社として存続した。Senturk氏自身はAppfireのプロジェクトエンジニアリング部門に加わり、2年で退社。現在もSnapbytes Turkeyの取締役を続けており、「引退して何もしないのは無理だ。何かを作っていないと」と語る。事業全体を1つの塊として売るのではなく、IPと主力チームだけを切り出す売り方は、複数拠点で運営してきた事業の出口設計として参考になる。

割り引いて読むべき点

限界も明記しておく。まず、売却額が非公表のため「16年かけた事業がいくらになったのか」という肝心の数字で検証できない。Appfireの買収は多数の案件の1つであり、個別の条件は交渉力次第と読むべきだ。また、Atlassianのクラウド移行という引き金は結果的に良いタイミングの売却をもたらしたが、裏を返せば、クラウド対応をやり切って成長を続ける選択肢を捨てた判断でもある。「方針転換=即売却」が常に正解だったかは、この記事の範囲では判定できない。確かなのは、本人がクラウドへの確信を持てないまま運営を続けるより、確信を持つ買い手に渡す方を選んだ、ということだけである。

再現の条件

この16年から持ち出せるのは3点。本業の困りごとを解決する小さなツールを無料で出し、利用が付いてから課金する立ち上げ手順。マーケットプレイスの集客・課金代行に乗ることで、営業ゼロ・所在地不問のまま世界の顧客に届く構造。そしてエコシステムのルール変更を「売り時のシグナル」として読む出口感覚だ。Atlassianに限らず、本体より小回りの利く周辺機能への需要があるプラットフォーム(Shopify、ブラウザ拡張など)では同じ構図が成り立つ。

ただし、Appfireのようなロールアップ買い手が育っているエコシステムは限られる。出口の整備状況はプラットフォームごとに大きく異なり、買い手不在のエコシステムでは「規約リスクを抱えたまま運営し続ける」以外の選択肢が細い。参入前に「その庭でプラグインを買っている企業は存在するか」を確かめることが、出口設計の第一歩になる。

関連する事例

• Order Tagger — Shopifyアプリ版の同型売却
• Flusk — プラットフォーム本体に買われた変形