一言でまとめると

TinyPilotはどうすれば継続収益を増やせるか？

ハイライト

• TinyPilot Proに継続課金（サブスクリプション）を導入するには何が必要かを検討しました。
• 開発環境の管理にNixを使う検証をさらに進めました。

目標の達成度

毎月初めに、その月に達成したいことを宣言しています。結果は次のとおりでした。

販売収益で9万8000ドルを達成する

• 結果: 収益は10%減の8万4000ドルでした
• 評価: C

いくつか好意的なレビューが新たに公開されたにもかかわらず、収益は減少しました。

• RaidOwl
• Home Network Guy（あわせてブログ記事も公開）
• Network Profile
• Botio Studio（中国語）

Amazonの不可解なアカウントヘルスルールによってリスティングの順位が下げられ、販売の一部を失いました。現在は問題が解消し、販売は再び持ち直しています。

ほかの創業者からも、この時期は毎年夏枯れが起きると聞いています。実際、TinyPilotも2022年7月に11%の減収を経験しています。

委託製造への移行をスケジュール通りに進める

• 結果: スケジュールが3週間遅れました。
• 評価: D

委託製造先の協力会社が電源アダプターやUSBケーブルなどの部品製造により時間を要したため、製造スケジュールがずれ込みました。切り替え期間中に在庫が尽きるまであと3週間ほど余裕はありますが、かなり綱渡りの状況です。

この目標は設計がよくありませんでした。期限を自分で決めたわけでもなく、自分でコントロールできる範囲も限られているからです。私にできるのは、TinyPilot側で停滞を防ぎ、委託製造先にスケジュール遵守を求めることくらいです。

メール対応の時間を40%未満に抑える

• 結果: ほとんどの時間をメール対応に費やしました。
• 評価: F

結局、想定をはるかに上回る時間をメールに費やしました。7月に休暇で旅行したのですが、休み中にどれだけメールが溜まるかを考慮していませんでした。

結果として、今月は大半の時間をメールの返信とチームメンバーの成果物のレビューに使いました。

TinyPilotの数値

収益は落ちましたが、利益は依然として2万〜3万ドル台を維持しています。この数字は経費が一時的に低く抑えられているため、やや上振れしています。委託製造への移行に伴い自社での生産を縮小しているため、新たな資材の購入を止めているのです。

多くの新しいレビューが公開されたにもかかわらず、サイト訪問者数が減ったのは意外でした。しばらくは自作ラボ（homelab）系レビューという集客チャネルは飽和したのかもしれません。今後は別の販売・マーケティング施策に注力すべきでしょう。

TinyPilotはどうすれば継続収益を増やせるか？

TinyPilotの売上が落ち込むたびに、継続収益のことを考えます。新規顧客を探し続けなくても安定した収入があれば、どんなに楽だろうと思います。

いつかTinyPilotを欲しい人全員がすでに持っている、という日が来るのが怖いのです。そのとき私はどうすればいいのでしょうか。

当初からの計画では、TinyPilotは継続収益を持つはずでした。顧客はハードウェアを一度購入し、その後はソフトウェアライセンスを年ごとに更新することで、継続的なソフトウェア開発と技術サポートを支えてもらう構想でした。

しかし実際には、継続収益を回収する仕組みを一度も整えてきませんでした。創業から3年経った今も、一部の法人顧客を除けば、継続収益はほとんどありません。

この振り返りでは、TinyPilotの継続収益を増やすために考えられる道筋を整理したいと思います。

TinyPilot Proのライセンスは現在どうなっているか

有料版ソフトウェアであるTinyPilot Proの開発は、2020年にDIY版TinyPilotキットを公開してから数週間後に始めました。

最初に着手した機能のひとつがライセンス照合でした。有料版を販売するなら、ユーザーのライセンスが有効かどうかを確認する手段が必要だったからです。

ライセンス照合の仕組みを設計し始めて気づきました。創業者としてほかの業務も抱える中で、この部分だけで数ヶ月はかかるということに。ライセンス管理の実装に3ヶ月かけたとしても、顧客にTinyPilot Proを買う動機を与えるためのプレミアム機能をさらに2ヶ月かけて実装しなければなりません。

創業から数ヶ月しか経っていないタイミングで、次のリリースまで5ヶ月も待たせるほど勢いを落としたくありませんでした。

Basecampのブログに、課金システムすら作る前にSaaSの販売を始めた経緯を語る記事があります。（追記：Nathan Colemanさんが見つけてくれました。Basecampの書籍『Getting Real』の記事です。）彼らの考えは、請求はサービス提供月の月末に発生するのだから、最初の販売から1ヶ月以内に集金方法を考えればよい、というものでした。

私もTinyPilotで同じ戦略を取りました。性善説に頼ってライセンスを運用し、本格的なライセンス管理の仕組みは1年以内に実装すればよいと考えたのです。

それから3年が経ちましたが、TinyPilot Proのライセンス管理については今も何も進んでいません。

最悪のタイミングでのライセンス強制

私たちは、TinyPilotデバイスには12ヶ月間の無料アップデートが付くと案内しています。しかし実態は、一度TinyPilot Proをデバイスにインストールしてしまえば、ウェブインターフェース経由で永久にアップデートし続けられるというものです。

TinyPilot Proのソフトウェアは、有効なライセンスと紐づいているかを追跡していません。2020年8月に購入したユーザーの中には、1年間のライセンスが3年目に入っている方もいます。

大半の顧客は、そもそもライセンスが切れたことに気づいていません。デバイスがアップデートを配信し続けるのだから、ライセンスはまだ有効なのだろうと考えるのは当然です。

顧客がライセンス切れに気づくことはありますが、それはたいてい非常に困るタイミングです。

TinyPilotはストレージにmicroSDカードを使っています。microSDは特にファイルシステムの破損に弱いのです。ファイルシステムが壊れた場合、唯一の解決策はTinyPilot ProのディスクイメージからmicroSDを書き込み直すことです。

TinyPilot Proのイメージをダウンロードするには、顧客は注文情報を入力します。イメージを提供する前に、顧客のライセンスがまだ有効かを確認しています。

顧客から見れば、これはライセンス切れを知る方法として最悪です。ファイルシステムが壊れて作業が中断されているのに、問題を直すにはデバイスまで歩いて行ってmicroSDを抜き、書き込み直さなければなりません。そこへきて、さらにお金を請求されるのです。

顧客が新しいイメージを買いたくない場合、サポートに連絡いただければ古いイメージは提供しています。ただ、返信まで最大1営業日かかるため、作業が止まっている状況では困らせてしまいます。

この仕組みは私たちにとっても良いものではありません。古いバージョンを求める問い合わせがサポート業務を圧迫しますし、顧客が新しいイメージを入手すれば、デバイス内のウェブインターフェースから再び「永久無料アップデート」の状態に戻ってしまうからです。

どんな条件なら継続課金に手間をかける価値があるか

どのようなライセンス強制もコストがかかります。最低でも、顧客がライセンス情報を入力できる画面をTinyPilotのウェブインターフェースに追加し、インターネット上のサーバーでライセンスに基づきアップデートの可否を判定する仕組みが必要です。

実装コストが高いのは、数週間の開発工数がかかるうえ、注文情報を記載したメールを削除してしまいアップデートにアクセスできないという問い合わせでサポート負荷が増えるからです。

仮にそこまで苦労して実装しても、更新率に何の影響もなかったらどうでしょうか。

ライセンス更新をやる価値があるとするなら、少なくとも年間3万ドルの追加利益が必要です。ライセンスの決済手数料は約3%と見積もっているので、1件の更新でTinyPilotの手元に残るのは約77ドルです。

年間3万ドルの追加利益という目標を達成するには、毎年最低390件の顧客にライセンスを更新してもらう必要があります（390 × 77ドル = 3万ドル）。

2020年の発売以来、TinyPilotは累計で約5,000台を販売してきました。現在は年間約2,700台を新規に販売しています。390件の有料更新を得るということは、既存ユーザーのわずか7.8%に継続課金してもらえればよい計算で、十分に達成可能に思えます。

顧客にライセンス更新の意思があるか、どうやって確かめるか

では、既存顧客の7.8%に更新してもらう必要があるとして、本格的なライセンス管理を実装せずに、その7.8%が現実的か確かめるにはどうすればよいでしょうか。

強制的な初期化

今年の初め、TinyPilotのベースOSをDebian BusterからDebian Bullseyeへ切り替える必要がありました。Raspberry Pi OSにはメジャーバージョンを直接アップグレードする公式な方法がないため、すべてのユーザーにmicroSDを手動で書き込み直してもらうしかありませんでした。

ユーザーに負担を押し付けるのは本意ではありませんでしたが、ほかに方法が見つかりませんでした。一方で、良い副作用もありました。「永久無料」アップデートの流れが一度止まったのです。ライセンスが切れているユーザーは、アップデートを続けるために12ヶ月分の新しいライセンスを購入しなければならなくなりました。

この変更を4月27日に展開したので、変更の前後3ヶ月間でライセンス更新数を比較しました。

一方で、アップデートに支払いを必須にしたことで更新数が67%増えたのは有望な兆しです。他方で、3ヶ月間で更新したのはわずか55ユーザーだったのは懸念材料です。ライセンス切れのデバイスは約2,500台あると推定されるため、実際に更新費用を払ったのは2.2%に過ぎません。

ただし、更新率を実際より低く見せている要因もいくつかあります。

• 最近の開発は、アップデート体験をより高速でエラーが起きにくくすることに注力してきました。これは有用ですが、将来のアップデートをスムーズにすること自体を目的にアップデートしたい人はいません。
• 初期化を伴うアップグレードは手間がかかります。20〜30分かけてデバイスをリセットするのが面倒で、アップデートを見送っているユーザーもいると考えられます。

手動での期限切れ通知

今月、顧客のライセンスが切れた際にメールで通知するアイデアを思いつきました。もちろん自動化はできますが、自動化にコストをかける前に、手動で数通送って反応や購入につながるかを試してみました。

試しに7通送ってみましたが、返信や更新購入はありませんでした。ただ、サンプルとしては小さすぎて結論は出せません。7.8%の更新率が必要だとすれば、12〜13人に1人が更新してくれればよい計算です。

この実験を続けることには躊躇があります。不利に働く要因が多いからです。

• メールが届くタイミングでは、顧客は必ずしもTinyPilotのアップデートを受け取り続けることに関心があるわけではありません。TinyPilotのウェブアプリで「Update」ボタンを押した瞬間に表示される方が、より意味のある検証になるでしょう。
• 購入時に使われたメールアドレスが、捨てアドのようなセカンダリアカウントである場合もあり、私のメール自体が読まれていない可能性があります。
• 更新費用を払わなくても新しいアップデートを受け取れてしまうことに気づいている顧客もいるため、更新する動機が働かない可能性があります。

自動更新オプションを追加する

現在、ライセンス更新は買い切りでのみ提供しています。継続課金（サブスクリプション）を検討してこなかったのは、Shopifyが標準で対応しているのが単発購入のみだからです。

Shopifyで継続課金を回収するにはサードパーティ製のShopifyアプリを使う必要がありますが、私はそれが嫌いです。経験上、Shopifyアプリは品質が低く、しかもその連携にまったく関係のない購入をした顧客の情報を含め、顧客情報への広範なアクセスを渡さなければならないからです。

それでも、ほかの実験と比べると、自動更新オプションは顧客の課金意思を試す手段として費用対効果がかなり高いと考えています。ライセンス購入ページにもう一つの選択肢として「または年間サブスクリプションを10%オフで購入」といったボタンを追加するだけで、課金に応じる顧客がいるかどうかが分かります。

サブスクリプションのボタンを追加するのは比較的簡単で、ほかのプロセスやシステムを変える必要もおそらくありません。サブスクリプションは通常のShopify注文として表示されるだけだからです。

サイドプロジェクト

What Got Done

最近Nixの検証を進めており、中でもnix developという機能に注目しています。プロジェクトのビルドやテストに必要な開発ツールを、自己完結したシェル環境にまとめて用意できる機能です。

私がさまざまなソフトウェアプロジェクトで悩まされているのが、依存関係の管理の難しさです。プロジェクトの依存はGo 1.19やNode.js 16といった特定のバージョンに紐づいています。次のバージョンに上げるたびに、開発環境へのインストール方法を調べ、継続的インテグレーション（CI）の設定ファイルのバージョン番号を更新するのは手間がかかります。

さらに、同じマシンで複数のプロジェクトを扱っていると、一つのプロジェクトのためにNode.jsを更新したら、別のプロジェクトで想定外のバージョンのNode.jsやnpmが使われることになってしまいます。

nix developが約束するのは、依存関係を一か所、すなわちNix flakeで定義できることです。たとえばGoを次のバージョンに上げたい場合、一つのファイルを更新してnix developを再実行すれば、正しいバージョンのGoが入ったローカルシェルが手に入ります。CI環境でも同じバージョンが使われます。環境はディレクトリに閉じているため、パッケージのバージョンを変えても同じマシン上のほかのプロジェクトには影響しません。

What Got Doneでnix developを試し始めました。GoとNode.jsに依存しており、バージョン管理が悩みの種だったからです。

What Got Doneの開発環境でNixをいじってみるのは面白いのですが、これまでにいくつか壁にぶつかりました。

• Goの静的バイナリビルドをうまく動かす方法が分からず、解決策は「このおまじないを知っているべき」といった感じでした。
• 依存関係の正確なバージョンを簡単に指定する方法がありません。
  • Dockerのようにgo:1.19.3のようにバージョンを宣言できると期待していましたが、Nixはそのような書き方をサポートしていません。
  • 再現性をこれほど重視するツールなのに、これは意外でした。
  • 見つけた中で最も近い解決策は、サードパーティ製のツールを使ってパッケージバージョンに対応するnixpkgsのハッシュを探し、そのハッシュにパッケージを固定する方法でした。これがWhat Got Doneの依存関係の一つで実際にどう見えるかの例です。
  • Devboxはこの問題を解決しますが、そうするとNixを間接的に使うことになり、Nixの上にDevboxの抽象化を学ばなければなりません。
• Nixストアの準備がとにかく遅いのです。
  • CircleCIではnixos/nix Dockerイメージを比較的すぐ立ち上げられますが、私のNix+GoのflakeでNix環境を構築するのに約2分かかります。
  • つまり、CIのどのステップを実行するにも、Nixの初期化だけで2分を消費してしまうということです。
  • Nixストアをキャッシュしてみましたが、サイズが約3GBあり、CircleCIでのダウンロードと展開に約2分かかります。CircleCIのキャッシュファイルはAmazon S3に保存されていると思われ、キャッシュサイズが1GB未満でないとパフォーマンスが著しく低下するようです。

まとめ

今月できたこと

• 「Installing NixOS on Raspberry Pi 4」を公開しました
• HTTP APIのcurlベースの統合テストをhurlに置き換える方法を学びました。
• ノースカロライナ州シャーロットとカナダのモントリオールを訪れました。

学んだこと

• TinyPilotは、ブログやYouTubeのレビューから得られていたマーケティング効果を使い果たしたようです。
  • 新しいレビューの効果は、1年前に比べて明らかに鈍くなっています。2年前に1本のレビューで売上が3倍近く伸びたときのような効果は、もはや見られません。
• 自動更新のTinyPilotライセンスという選択肢は、継続収益の市場性を試すうえで最も費用対効果が高い方法です。

来月の目標

• 委託製造先への製造移管をできる限り迅速に進める。
• TinyPilotの現オフィスからの退去について詳細な計画を立てる。
• TinyPilotライセンスの自動更新オプションを試す。

協力をお願いしたいこと

• Shopify向けのサードパーティ製の継続課金アプリ、特にデジタル商品向けのものについて、良い・悪い経験をお持ちの方はメールで教えてください。
• 私がうろ覚えで紹介したBasecampのエピソードを見つけられる方がいれば、コメントで教えてください。