一言でまとめると

TinyPilotの売上をどうすれば持続可能にできるか？

ハイライト

• TinyPilotの収益が過去最高の7万4000ドルに達した。
• ソフトウェアのライセンス方式で最善の方法を模索している。
• 心から気に入れるWebフレームワークをまだ探している。

目標の達成度

毎月初めに、その月に達成したいことを宣言しています。目標に対してどれだけできたか振り返ります。

TinyPilotインストール用の自己完結型tarballを作成する

• 結果: 動作するtarballパッケージが完成した
• 評価: A

TinyPilotのインストール手順は、時間とともに複雑さを増してきました。複数のリポジトリやサードパーティの依存関係を取り込んでおり、それらの関係を把握し続けるのがどんどん難しくなっています。

現在、すべてを単一のtarballにまとめることで、インストール手順を全面的に見直しています。これにより、すべての依存関係を明確な場所に一元化できます。現在、無償版のTinyPilotを新しいアップデートシステムに切り替えている最中で、その後すぐにTinyPilot Proも移行する予定です。

TinyPilotのウェブサイトリニューアルについての長編ブログ記事の初稿を完成させる

• 結果: 初稿を完成させた
• 評価: A

これまでの振り返り記事で経験についてたくさん書いてきたので、ブログ記事は簡単に書けるだろうと思っていました。しかし長編記事は文体が違うため、結局かなりの部分を書き直す必要がありました。文字数は5,200ワードで、普段の記事の約2倍の長さなので、削ぎ落とそうとしているところです。

有料検索広告のROASを2.0まで高める

• 結果: ROASを1.79から1.99へ改善した
• 評価: A

TinyPilotと仕事をしているデジタルマーケティングのフリーランサーが、広告費用対効果（ROAS）を1.99まで高めてくれました。広告に1ドル使うごとに、約0.55ドルの利益が出ている計算です。

残念ながら、広告費を2倍にすれば売上が2倍になるという単純な話ではありません。検索結果での表示シェアを広げようとすればするほど、コストは上がっていきます。それでも今のところ成果には満足しており、新しいマーケティングチャネルの開拓も続けています。

TinyPilotの統計

今月はTinyPilotにとって過去最高（追記：2番目に高い、詳細は下記注記を参照）の収益を記録した月でした。そして何より興味深いのは、6月はそれ以外、特に何も目立ったことがなかったという点です。

これまでTinyPilotが記録を更新した月は、すべて新製品の発売や好意的なレビューといった一過性の出来事が関係していました。しかし6月は、実質的に何も特別なことが起きない、ごく平凡な月でした。そしてそれは素晴らしいことです。外部のイベントに頼らなくても、今やっていることを繰り返せば再現できることを示しているからです。

サイト訪問者数は前月と比べて減少していますが、これは5月が前回のブログ投稿の影響で異常に多かったためです。訪問者数全体は依然として第1四半期を大きく上回っており、新しいマーケティングキャンペーンの効果だと考えています。

TinyPilot Proユーザーはどうやってライセンスを証明するのか

私は以前から、TinyPilotのソフトウェアは新しいハードウェアを売り続けなくても、それ単体で持続可能であってほしいと考えてきました。ユーザーはTinyPilotのハードウェアを購入するとプレミアムソフトウェアを無料で入手できますが、ソフトウェアの保守を支えるために、一定期間を過ぎたら料金を支払ってもらう仕組みが必要です。

2020年12月にTinyPilot Proという有料版をリリースしました。当初はライセンスキーによるチェックを導入する予定でしたが、その機能は見送り、2021年末にライセンスの有効期限が切れ始めるまでは必要ないだろうと考えたのです。

それから18ヶ月が経った今も、TinyPilot Proはユーザーが有効なライセンスを持っているかどうかを一度もチェックしていません。推定では、約3分の1のユーザーがライセンスの期限切れに気づかないまま使い続けています。

最新バージョンへのアップグレード時に、有効なライセンスがあるかどうかをチェックする仕組みを追加する予定です。そうすれば、現行バージョンに満足しているユーザーはそのまま永遠に使い続けることができます。最新機能が欲しい場合にのみ、初年度のライセンス期間が過ぎた後にソフトウェアアップデートの料金を支払ってもらう形です。

ユーザーが最新のアップデートをダウンロードする権利を持っているか確認するには、アクティブなTinyPilot Proライセンスを持っていることをアップデートサーバーに証明してもらう方法が必要です。

現在検討している選択肢は次のとおりです。

デバイスID

TinyPilotはRaspberry Pi上で動作し、すべてのPiデバイスには次のように取得できるハードウェアのシリアル番号があります。

$ cat /proc/cpuinfo | grep Serial | cut -d ' ' -f 2
10000000ecf8821b

顧客に販売する前に、各PiのデバイスIDを記録しておくという方法が考えられます。ユーザーがアップグレードを試みた際に、デバイスIDが事前登録されているかを確認し、それに基づいてアクティベーションします。

• メリット
  • ユーザーにとって簡単 — デバイスIDをなくしたり忘れたりすることがない
• デメリット
  • すべてのデバイスIDを管理する必要がある
  • 製造工程にひと手間増える
  • デバイスIDの記録を始める前に購入したユーザーへの対応が別途必要になる

注文情報

現在、顧客が公式のTinyPilotディスクイメージをダウンロードしたいときは、注文番号と購入時に使ったメールアドレスの入力をお願いしています。

TinyPilotのWebアプリ内でアップグレードを制限する際にも、同じロジックを使えます。

• メリット
  • 注文情報はすでに保存しているため、キーやデバイスIDを別途管理する必要がなく、事務作業を最小限に抑えられる
  • 注文情報をすでに持っているため、過去のすべての顧客に対応できる
• デメリット
  • エンドユーザーが必ずしも注文情報を把握しているとは限らない
    • 再販業者から買っていたり、社内の別の人が購入していたりする場合がある
  • 新しい販路（例：Amazon、eBay）で販売を始めるたびに、その販路から注文情報を取得するためのカスタムコードを書く必要がある

印刷されたアクティベーションキー

Microsoft WindowsやOfficeのようにアクティベーションキーを生成し（例：1F9PA-V4JD5-4JPOM）、印刷して各デバイスに同梱する方法も考えられます。ユーザーはそのキーを入力してライセンスを証明します。

• メリット
  • ユーザーから直接購入した場合でも、AmazonやeBay経由でも同じように機能する
• デメリット
  • ユーザーが注文に同梱された紙切れをなくしたり、無視したりしがちである
  • アクティベーションキーの同梱を始める前に購入したユーザーへの対応が別途必要になる

ソフトウェアにライセンスを埋め込む

顧客のデバイスにはこちらでイメージを書き込んで出荷しているので、理論上は各デバイスにTinyPilot Proライセンスを付与する固有のキーファイルを配置することも可能です。

• メリット
  • ユーザーから直接購入した場合でも、AmazonやeBay経由でも同じように機能する
  • ユーザーがキーをなくすことがない
• デメリット
  • 極めて非現実的で実装が複雑
    • 顧客ごとにカスタムのディスクイメージを生成し、顧客が常に自分専用のイメージをインストールするようにしなければならない
  • アクティベーションキーの埋め込みを始める前に購入したユーザーへの対応が別途必要になる

組み合わせる

できる限り自動的な方法を使いつつ、例外的なケースではより手作業の方法にフォールバックする、混合アプローチに傾いています。

1. デバイスのハードウェアIDが事前登録されているかを確認する。
2. 事前登録されていない場合は、ユーザーに注文IDとメールアドレスの入力を求め、注文を自動的に探す。
3. 注文IDとメールアドレスで注文を自動的に見つけられない場合は、カスタマーサポートにメールするよう案内し、手動でライセンスを付与する。

思いつく選択肢の中では、これが最もエラーが少なく、エンドユーザーへの負担も最小限に抑えられると思います。

Amazonセラーセントラルに入らんとする者は、一切の希望を捨てよ

長い間、多くの人があらゆる買い物をAmazonで済ませていることから、TinyPilotをAmazonでも販売することを考えてきました。ただ、Amazonの出品者登録は面倒で退屈な手続きだろうと思い、ずっと尻込みしていました。実際に手続きを終えてみて言えるのは、想像以上に面倒で退屈だったということです。

Amazonに商品を掲載できるようになるまで、3週間もかかりました。数日おきに、新たな承認が必要だとか、身元や商品について証明しなければならないといった連絡がAmazonから来るのです。

まず、運転免許証とクレジットカード番号で本人確認をする必要がありました。次に、運転免許証を顔の前に掲げ、印刷した偽物でないことを証明するために免許証を曲げてみせるライブビデオ通話への参加を求められました。

その後、クレジットカードが確認できないという理由でアカウントが1日凍結されました。同じクレジットカードは1年前からAmazonに登録しており、それで約5万ドルもの買い物をしてきたカードです。

次に、「TinyPilot」というブランド名を使う権利があるか確認するため、アカウントが凍結されました。自分がTinyPilot, LLCの所有者であることを証明し、側面に「TinyPilot」と書かれた製品の写真を送りました。

3日以内に審査すると言われましたが、実際には10日かかりました。結論は、写真では「TinyPilot」というブランドが製品に恒久的に貼り付けられていることを十分に証明できていない、というものでした。

そこで、ブランド名がよりはっきり分かる新しい写真を送ったところ、ようやく承認されました。

次の問題は、「tinypilot」と検索してもTinyPilotが検索結果に表示されないことでした。

奇妙なことに、Amazonのオートコンプリート候補は明らかに自分の製品に関するものばかりでした。

「tinypilot kvm over ip」と検索しても、2〜3ページ目まで自分の商品は出てきませんでした。

結局、Amazonで広告を購入したことで、ようやく最初の数件の売上が立ちました。

出品開始までの厄介な部分は乗り越えたはずなので、このまま続けて、評価がたまっていけばAmazonでの売上が伸びるかどうか様子を見ていこうと思います。

Amazonの顧客は一味違う

Amazonの顧客は、TinyPilotのウェブサイトから直接購入する顧客とは期待するものが大きく異なるようです。

Amazon経由で購入した最初の顧客は、「UPSの2日配送で送れ」というメッセージを注文とともに送ってきましたが、こちらではUPS配送は提供していません。メッセージには返信しましたが、次にどうすべきか悩みました。注文をキャンセルしてAmazonからペナルティを受けるべきか？ 顧客からの返信を待って、発送遅延でペナルティを受けるリスクを負うべきか？ 結局1日待ってからキャンセルしました。すると顧客は同じ注文を再び入れてきたので、今度はUSPSで発送したところ、特にクレームはありませんでした。

数日後、別のAmazonの顧客から、速達配送に10ドル払ったのにまだ商品が届かない、と「非常にがっかりしている」というメッセージが届きました。追跡情報を確認すると、USPS Priorityで1日早く発送していましたが、USPS側の遅延が発生していました。これは明らかにこちらの管理外のことですが、顧客はサードパーティの出品者から買うことと、Amazon自身の配送網で直接Amazonから買うことの違いを理解していないのだろうと思います。

直接注文の顧客からもこうした苦情を受けることはありますが、Amazonでの頻度とは比べものになりません。

今も愛せるWebフレームワークを探し求めて

前回の近況報告でも触れたとおり、WanderJestを作り直しています。これはパンデミック開始時に中断した、ライブコメディを探すためのツールです。

AngularやVueといったSPAフレームワークを何年も使ってきた反動で、「原点回帰」としてGo + VanillaJS + SQLiteという技術スタックでWanderJestを書き直しています。Chris Ferdinandi氏が記事「SPAs were a mistake.」で、私の不満の一部を的確に言語化してくれています。

今の技術スタックは、これまで試したどのWebフレームワークよりも気に入っていますが、それでも心から愛しているとは言えません。時間の大半を、ただ部品同士をつなぎ合わせる退屈な作業に費やしています。

例えば、WanderJestでユーザーが写真や自己紹介、他のSNSへのリンクを含むプロフィールを作成できるようにするには、次のことが必要です。

1. ユーザーがプロフィールを作成・編集できるWebフォームを作る
2. ユーザーからの送信を受け取るサーバー側のエンドポイントを作る
3. プロフィール情報を表すデータモデルを作る
4. データストアとの間でデータを出し入れするためのシリアライズ／デシリアライズのコードを書く
5. データストアへの挿入や取得のためのSQLクエリを書く
6. プロフィール情報を表示するWeb UIを作る

他のフレームワークと比べれば手順は少ないのですが、それでもこの作業は本当に退屈です。

Phoenix LiveViewは、この1年間ずっと気になっている存在です。fly.ioのイケてる人たちがこぞって盛り上がっている技術でもあります。Phoenixの売りの一つは、上に挙げたような繰り返しの作業の多くを自動化してくれることです。Chris McCord氏は、Phoenixを使って15分で基本的なTwitterクローンを作る素晴らしいデモを公開しています。

同時に、「隣の芝は青い」という考えに陥り、特定のスタックを深く学ばないままフレームワークを転々とすることへの恐れもあります。良い妥協点としては、Phoenixと似た開発体験を持ちつつ、より成熟したエコシステムを持つRuby on Railsがあるかもしれません。

まとめ

今月できたこと

• TinyPilotのAmazonでの販売を開始した
• 新しい長編ブログ記事の初稿を完成させた
• TinyPilotのインストールバンドル生成プロセスを完成させた

学んだこと

• Amazonセラーマーケットプレイスは、見た目以上に不快な場所だ。

来月の目標

• TinyPilotのライセンス管理計画を確定させる。
• TinyPilot Communityを次世代アップデートシステムに移行する。
• TinyPilotのウェブサイトリニューアルに関するブログ記事を公開する。