一言でまとめると

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

ハイライト

• TinyPilot Proに継続課金サブスクリプションを追加するには何が必要かを考えました。
• 開発環境の管理にNixを使う方法について、さらに探求しました。

目標の成績表

毎月のはじめに達成したい目標を掲げています。その目標に対して今月はこうなりました。

売上9万8000ドルを達成する

• 結果: 売上は10%減の8万4000ドルに落ち込みました
• 評価: C

いくつか新しい好意的なレビューがあったにもかかわらず、売上は落ち込みました。

• RaidOwl
• Home Network Guy（および関連するブログ記事）
• Network Profile
• Botio Studio（中国語）

Amazonの不可解なアカウントヘルスポリシーによって掲載順位が下げられたため、売上の大きな部分を失いました。現在は信頼を回復し、売上も再び上向き始めています。

他の創業者からも、この時期は毎年夏枯れで売上が落ち込むと聞いています。実際、TinyPilotも2022年7月に11%の売上減を経験しています。

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

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

製造スケジュールが遅れたのは、委託製造先の下請けベンダーが電源アダプターやUSBケーブルなどの部品製造により時間を要しているためです。移行期間中に在庫が尽きるまでまだ約3週間のバッファがありますが、状況はかなりぎりぎりになってきています。

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

メールに費やす時間を40%未満に抑える

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

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

結局、今月は大半の時間をメールへの返信とチームメンバーの仕事のレビューに使いました。

TinyPilotの数字

売上が落ち込んだにもかかわらず、利益は依然として2万〜3万ドルの範囲にあります。この数字は経費が人為的に低く抑えられているため、やや水増しされています。委託製造への移行に伴い自社での生産を縮小しているため、新たな材料の購入を止めているのです。

これだけ新しいレビューが出たのにサイト訪問者数が減っているのは意外でした。しばらくの間、ホームラボ系レビューというマーケティングチャネルは飽和状態にあるのでしょう。他の販売・マーケティング手法に注力すべきだと感じています。

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

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

いつか、TinyPilotを欲しがる人全員がすでに持ってしまったらどうなるのだろう、と考えるだけで気が重くなります。そのとき私はどうすればいいのでしょうか？

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

問題は、私が一度も継続収益を回収する仕組みを整えてこなかったことです。3年が経った今も、一部の法人顧客を除けば、継続収益はほとんどありません。

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

TinyPilot Proのライセンスが現在どう機能しているか

私は2020年に最初のDIY版TinyPilotキットをリリースしてから数週間後に、TinyPilotソフトウェアのプレミアム版の開発を始めました。

TinyPilot Proで最初に着手した機能の一つが、ライセンスチェックでした。有料版のソフトウェアを販売するなら、ユーザーのライセンスが有効かどうかを確認する手段が必要だったからです。

ライセンスチェックの仕組みを設計し始めて気づいたのは、創業者としての他の業務を抱えながら、そのコンポーネントだけで数ヶ月かかってしまうということでした。仮にライセンス管理の実装に3ヶ月かかったとしても、顧客がTinyPilot Proを買いたくなるような魅力的なプレミアム機能を実装するために、さらに2ヶ月は必要になります。

会社はまだ創業数ヶ月でした。次のリリースまで5ヶ月もユーザーに待たせて、勢いを大きく落としたくはありませんでした。

Basecampのブログ記事で、まだ課金システムすら作っていない段階でSaaS製品の販売を始めた経緯を語っているものがあります。（追記：Nathan Colemanさんが見つけてくれました。Basecampの書籍『Getting Real』の章です）。彼らの論理は、ソフトウェアの請求書は1ヶ月のサービス提供後に支払期限が来るのだから、最初の販売から1ヶ月は集金方法を考える時間がある、というものでした。

私もTinyPilotで同様の戦略を取りました。ライセンスの強制は性善説（オナーシステム）に頼ることにし、本格的なライセンス管理の仕組みを実装するまで1年の猶予があると考えたのです。

あれから3年が経ちましたが、TinyPilot Proのライセンス強制については今もまったく進展がありません。

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

私たちはTinyPilotデバイスには12ヶ月間の無料アップデートが付くと宣伝しています。しかし裏を返せば、デバイスに一度TinyPilot Proをインストールしてしまえば、ウェブインターフェースから永久にアップデートし続けられるというのが、不都合な真実です。

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

大多数の顧客は、そもそもライセンスが切れていることに気づいていません。TinyPilotがデバイスにアップデートを配信し続けるなら、ライセンスはまだ有効なのだろうと考えるのは、無理もありません。

顧客がライセンスの期限切れに気づくこともありますが、それはとりわけ都合の悪いタイミングで起こります。

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

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

顧客の視点から見れば、これはライセンス切れを知る方法として最悪です。ファイルシステムが壊れてTinyPilotが仕事を中断させたうえ、問題を直すためにわざわざデバイスのところまで歩いていき、microSDを抜いて再書き込みしなければならない。そこへきてさらにお金を請求されるのか、というわけです。

顧客が新しいイメージを買いたくない場合でも、サポートに連絡すれば古いイメージへのアクセスは提供しています。ただ、私たちからの返信に最大で1営業日かかるため、作業を止められている顧客にとっては大きな痛手です。

この仕組みは私たちにとっても良いものではありません。古いTinyPilot Proバージョンへのリクエストがサポートリソースを食い潰すからです。しかも、顧客が新しいイメージを手に入れれば、デバイスのウェブインターフェースからまた永久に無料でアップデートできる状態に戻ってしまいます。

継続課金が手間に見合うのはどんな場合か？

どんな形であれライセンスの強制を導入するのはコストがかかります。最低でも、顧客がライセンス情報を入力できる機能をTinyPilotのウェブインターフェースに追加し、さらにインターネット上のサーバーで、そのライセンスに基づいてユーザーがアップデートを受ける資格があるかを判定する必要があります。

これを実装するのが高くつくのは、数週間の開発作業が必要なうえ、ユーザーが注文情報の書かれた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ヶ月と変更後3ヶ月のライセンス更新数を比較しました。

一方で、この変化は有望とも言えます。アップグレードに支払いを必須にしたことで更新数が67%増加したからです。他方で、3ヶ月で更新したのはわずか55ユーザーだったという点は心配です。期限切れライセンスを持つデバイスは約2,500台あると推定しており、つまりアップデートにお金を払ったのはわずか2.2%だったということです。

更新率が本来よりも低く出るように偏らせる要因がいくつかあります。

• 最近の私たちの作業の多くは、アップデート体験をより高速でエラーが起きにくいものにすることに注力してきました。これは有用ですが、将来のアップデートをスムーズにすることだけを目的にアップデートしたいと思う人は誰もいません。
• 工場出荷時リセットを伴うアップグレードは手間がかかります。デバイスのリセットに20〜30分かけるのが面倒で、アップデートを見送っているユーザーもいるでしょう。

手動での期限切れ通知

今月、顧客のライセンスが期限切れになった際にメールで通知を送ってみるというアイデアを思いつきました。これは自動化することもできますが、自動化に大きく投資する前に、まずは数通を手動で送って、誰かが返信したり購入したりするかどうかを試してみました。

このアイデアを試すために7通のメールを送りましたが、誰一人として更新も返信もしませんでした。結論を出すにはサンプルが小さすぎます。7.8%の顧客に更新してもらう必要があるとすれば、12〜13人に1人が更新すればよい計算です。

この実験を続けるのには気が進みません。不利に働く要因が多くあるからです。

• メールは、相手が必ずしもTinyPilotのアップデートを受け取り続けたいと思っていないタイミングで届きます。もしTinyPilotのウェブアプリでユーザーが「Update」ボタンをクリックしたときにプロンプトが表示されるなら、より意味のあるテストになるでしょう。
• 一部の顧客は、迷惑メール用のサブアカウントと思われるメールアドレスでTinyPilotを購入しているため、私のメール自体を見ていない可能性もあります。
• こうした顧客は、更新料を払わなくても新しいアップデートを受け取り続けられることに気づいているかもしれず、そうなると更新する動機がありません。

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

現在、ライセンスの更新は一度きりの購入としてのみ提供しています。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ストアの投入は耐え難いほど遅いです。
  • nixos/nix DockerイメージをCircleCIで比較的素早く立ち上げることはできますが、私のNix+Go flake用のNix環境をビルドするのに約2分かかります。
  • つまり、実行するCIステップはどれも、Nixの初期化だけで2分を消費することになります。
  • Nixストアをキャッシュしようとしましたが、サイズが約3 GBあり、CircleCIはそのダウンロードと展開に約2分かかります。CircleCIはキャッシュファイルをAmazon S3に保存していると思われるので、キャッシュサイズが1 GB未満でない限りパフォーマンスはひどいものになります。

まとめ

何ができたか？

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

学んだこと

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

来月の目標

• できるだけ早く製造を委託先へ移行する。
• TinyPilotの現地オフィスからの移転について詳細な計画を立てる。
• TinyPilotライセンスの自動更新オプションをテストする。

手助けのお願い

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