ひとことで言うと

TinyPilotの売上をどう持続可能にしていくか、ということです。

ハイライト

• TinyPilotの収益が過去最高の7万4千ドルに達しました。
• ソフトウェアのライセンスについて、最適な方法を模索しています。
• 心から気に入れる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のデジタルマーケティングを担当しているフリーランスの方のおかげで、広告費用対効果が1.99まで上がりました。広告に1ドル使うごとに、約0.55ドルの利益が出ている計算です。

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

TinyPilotの統計

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

これまで記録を更新した月は、すべて新製品の発売や好意的なレビューといった一過性の出来事がきっかけでした。しかし6月は、実質的に何も特別なことが起きない、ごく普通の月でした。そしてそれこそが素晴らしいことです。外部の出来事に頼らなくても、今やっていることを再現すれば売上が立つことを示しているからです。

サイト訪問者数は前月より減っていますが、これは5月が前回のブログ記事の影響で例年になく多かったためです。訪問者数全体は依然として第1四半期を大きく上回っており、新しいマーケティング施策の効果だと考えています。

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

私はかねてから、TinyPilotのソフトウェアは新しいハードウェアを売り続けなくても、それ自体で持続可能であってほしいと考えてきました。ユーザーはTinyPilotのハードウェアを購入するとプレミアムソフトウェアを無料で入手できますが、ソフトウェアの保守を続けるための資金を確保するには、ある時点を過ぎたら有料にする必要があります。

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

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

最新バージョンへアップグレードする際に、有効なライセンスがあるかどうかをチェックする仕組みを追加する予定です。そうすれば、現在のバージョンに満足しているユーザーはそのまま永遠に使い続けられます。最新の機能を使いたい場合に限り、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セラーセントラルに入らんとする者

以前からTinyPilotをAmazonで販売することを考えていました。多くの人がAmazonをオンラインショッピングの万能市場として利用しているからです。ただ、Amazonのセラー登録は面倒で退屈な手続きになりそうだと感じて、ずっと敬遠していました。実際に手続きを終えてみて、想像以上に面倒で退屈だったと断言できます。

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

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

その後、クレジットカードが確認できないという理由でアカウントが1日凍結されました。同じクレジットカードは1年前からAmazonに登録し、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の顧客から、 expedited shipping（速達配送）に10ドル払ったのにまだ商品が届かない、とてもがっかりしているというメッセージが届きました。追跡情報を確認すると、USPSの優先便で1日早く発送していましたが、USPS側の遅延が発生していました。これは明らかに私たちではどうしようもないことですが、おそらく顧客はサードパーティの出品者から買うことと、Amazon自身の配送網でAmazonから直接買うことの違いを理解していないのだと思います。

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

まだ愛せるWebフレームワークを探しています

前回のアップデートでも触れたとおり、パンデミックの始まりに一時休止した、ライブコメディを探すためのツールWanderJestを再構築しています。

AngularやVueのようなSPAフレームワークを何年も使ってきた反省から、WanderJestはGo＋VanillaJS＋SQLiteという「原点回帰」の技術スタックで書き直しています。Chris Ferdinandi氏が記事「SPAは間違いだった」で語っていることは、私の不満と重なる部分があります。

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

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

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

他のフレームワークよりは手順が少ないのですが、この手の作業は本当に退屈です。

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

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

まとめ

やり遂げたこと

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

学んだこと

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

来月の目標

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