一言でまとめると

「緊急モード」からの脱却

ハイライト

• TinyPilotのフルフィルメントを外部の物流委託先へ移管し終えました。
• 現地チームは、数ヶ月続いた「緊急モード」から抜け出しつつあります。
• 生産スピードがボトルネックではなくなったため、収益性を最大化する価格を設定できるようになりました。

目標の達成度

毎月初めに、その月に達成したい目標を掲げています。結果は次のとおりでした。

すべての製品を3PLベンダーへ移管する

• 結果：3PLベンダーがすべての製品の出荷を担うようになりました。
• 評価：A

移管はスムーズに進み、会社にとって大きな前進になりました。3PLが日々の受注発送を担うことで、柔軟性が大きく高まりました。週6日オフィスに人員を配置する必要がなくなったのです。従業員は今も定期的に出社していますが、その日の集荷に間に合うようすべてを終わらせなければならないというプレッシャーはなくなりました。

TinyPilotのデバイス組み立てを引き継ぐ製造委託先を選定し、移管を開始する

• 結果：まだ協議中で、正式には決定していません。
• 評価：B-

気に入った製造委託先は見つかりましたが、まだ正式な契約には至っていません。正式な見積もりとスケジュールを待っているところです。先方からの楽観的な非公式の見込みでは、最初の生産ロットは2023年10月とのことです。

TinyPilot Proの新バージョンを公開する

• 結果：TinyPilot Pro 2.5.4を公開しました。
• 評価：A

機能面で目立ったリリースではありませんでしたが、レガシーOSとなったDebian Busterからの移行をユーザーが進められる道筋を作りました。Busterのサポートを終了することで、そのOSバージョン向けに分岐していた条件分岐など、コードベースの複雑さを大幅に削減できます。

TinyPilotの数値

数字だけ見ると落ち込んでいるように見えますが、実際の落ち込みはわずかです。総売上は4%減にとどまっています。利益は減っていますが、これは経費の計上タイミングが月によって偏るためです。月あたりの平均利益は2万〜3万ドル程度で推移すると、前向きに捉えています。

3PL移行のヤマを越える

ここ数ヶ月、TinyPilotの現地チームはほぼ100%の稼働率で働いてきました。そのため、最優先事項は彼らの負荷を減らす方法を見つけることでした。

負荷削減に最も費用対効果が高い施策の一つが、サードパーティロジスティクス（3PL）ベンダーへの移行を完了させることだと考えました。TinyPilotでは創業以来、オフィスから直接注文を発送してきました。3PLを利用すれば、製品を倉庫へ一括で送り、日々の受注発送を3PLに任せることができます。

3PLにフルフィルメントを委託すれば確実に作業量は減りますが、切り替え自体に手間がかかるというジレンマがありました。

製品を3PLへ発送してから、3PLが注文処理を開始できるようになるまで約1週間かかります。つまり、1週間分の在庫を余分に積み増す必要がありました。既存の注文量をこなすだけで手一杯な状況では、決して楽なことではありません。

1週間休業して移行に充てることもできましたが、それは1万〜2万ドルの売上を諦めることと同義です。そこで、現地チームの負荷を減らすためにいくつかの対策を取り、彼らが在庫の積み増しに集中できるようにしました。

まず、広告費を削減しました。これは考えるまでもありませんでした。すでに需要が供給を上回っているのに、お金をかけて新規顧客を集める意味はないからです。

次に、価格を引き上げました。TinyPilotの価格を段階的に引き上げて、販売数を抑えつつ売上への影響を最小限に留めました。

最後に、私自身がカスタマーサポートを担当しました。現地スタッフは組み立て、発送、カスタマーサポートを兼務しています。サポートで1時間でも彼らの時間を節約できれば、その分デバイスの製造に充てられるからです。

幸い、これらの取り組みはうまくいきました。5月初めには、現地チームが1週間分の在庫を3PLへ送れるだけの余剰在庫を確保できました。3PLが稼働し始めると、現地チームの作業量は約15%減少しました。

3PLへの移行自体はかなりスムーズでしたが、もう一度やるならもっとうまく計画したい点もあります。初めて3PLを検討する方（あるいは将来ベンダーを切り替える自分自身）のために、3PLベンダーに確認すべき質問事項をまとめました。

「緊急モード」からの脱却

フルフィルメントを3PLに委託した後も、思ったほどは落ち着けませんでした。倉庫にある在庫は数日分しかなく、チームは新しいデバイスを急いで製造し、3PLの在庫を補充するのに追われていました。

1年前、現地チームにまだ余裕があった頃を懐かしく思い出しました。あの頃の最大の悩みは、彼らにもっと責任を任せる機会を逃していることでした。

今年は状況が逆転しました。本来は現地チームが担うはずの業務を私が引き取っていました。そして、業務を落ち着いてこなすというより、なんとかこなし切っているという感覚が常につきまとっていました。ドキュメント整備や在庫計画といった長期的な業務は後回しになっていました。

最もつらかったのは、売上が好調な日にも喜べなかったことです。Shopifyで1日に10台以上売れたとわかっても、喜びよりも先に「ああ、これで倉庫の在庫を積み増すのがまた大変になる」という思いが浮かんでしまうのです。

倉庫に1ヶ月分の在庫があれば落ち着けるだろうと考えました。簡単な表計算で試算したところ、その水準に達するのは7月になると見込まれましたが、そこまで2ヶ月もこの状態が続くのは避けたいと思いました。

ここ数ヶ月、3人目の現地従業員を雇うことも検討していました。ただ、フルフィルメントを3PLへ、さらに生産を製造委託先へ移管すれば負荷は大きく下がるはずで、その段階では現地チームの仕事はカスタマーサポートだけになります。3人分のサポート業務はないだろうと躊躇していました。

3PL移行後も依然として作業量が多いとわかって、3人目の採用案に立ち戻りました。そこでひらめいたのです。半年後に仕事が足りなくなるなら、最初から短期ポジションとして募集すればいい、と。

Craigslistと地元のFacebookグループに求人を投稿しました。2週間で18件の応募があり、5人に面接して1人にオファーを出し、先方に承諾いただきました。新しい従業員は今週から勤務を開始します。

3人目の採用を決めてから、明らかに雰囲気が変わりました。目先のことで急ぐプレッシャーがなくなり、みんなリラックスしています。ドキュメント整備や長期的な計画にも再び投資できるようになりました。

利益を最大化する価格とは？

この2ヶ月間、TinyPilotの価格を引き上げて販売数を抑えてきました。意図的に高めの価格を設定し、総販売数を減らして在庫を追いつかせる時間を確保したのです。

ひと息つけてデバイスを製造する余力ができた今、生産スピードのボトルネックを回避するためではなく、利益を最大化するための価格を設定できます。

先月も価格で実験を行いましたが、データが増えたので、改めて数字を見てみましょう。

Voyager 2a USB-C

先月は、TinyPilotの需要がどれほど非弾力的かに驚きました。価格を上げても販売数はそれほど減らないだろうと予想していました。より多くのデータが集まった今、需要曲線は私の当初の想定に少し近づいています。120ドル（32%）の値上げで、注文数は34%減少しました。

興味深いことに、379ドルと499ドルの価格では利益がほぼ完全に一致しました（1,220ドル/日 vs 1,219ドル/日）。販売数が34%減れば長期的なサポートコストも下がるため、全体の利益は499ドルの方が高くなるでしょう。

Voyager 2a PoE

より高価格なPoE版のお客様は、478ドルから528ドルの間では価格にあまり左右されないようです。どちらの価格でもほぼ同じペースで購入されていますが、サンプル数は少なめです。

最も利益が高かったのは498ドルのときでしたが、集計期間が短かったため、外れ値である可能性も高いです。

結論：399ドル＋99ドルで販売する

価格の最適点は、ベースモデルを399ドルで販売し、PoEアップグレードに＋99ドル（498ドル）を上乗せすることにあるようです。TinyPilotの売上で最も利益が高かったのがこの価格帯でした。この期間のサンプル数は少ないものの、他の価格が示すカーブの頂点付近にも位置しています。

399ドルというベース価格が気に入っているもう一つの理由は、私のような個人でも購入をためらわない水準に収まっていることです。3年前にTinyPilotのような製品を見つけていたら、「なるほど、homelab用なら399ドルは出す価値があるな」と思ったはずです。

サイドプロジェクト

ScreenJournal

引き続き、友人と映画のおすすめを共有できるオープンソースのウェブアプリ、ScreenJournalの開発を続けました。

4月に追加した主な機能は、他の人の映画レビューにコメントできるようにしたことです。コメント用のパッケージは使わず、実装は完全に自作しました。見た目は以下のとおりです。

ScreenJournalでのもう一つの大きな変更は、エンドツーエンドテストを逐次実行から並列実行に作り替えたことです。

ウェブアプリのエンドツーエンドテストでは、共有データベースにずっと悩まされてきました。他の開発者がどう回避しているのか、なかなか答えが見つかりません。

以前は、エンドツーエンドテストのたびにデータベースをリセットすることで共有状態の問題に対処していました。その方法は遅く、同じデータベースを共有しているため一度に1つのテストしか実行できませんでした。

現在の解決策は、クライアントごとにCookieを割り当て、そのCookieをインメモリのSQLiteデータベースに紐づける方法です。これによりテスト間でデータベースの状態を共有しなくなるため、並列実行が可能になりました。これまでで一番気に入っている解決策ですが、まだ車輪の再発明をしている感覚があり、もし定番の解決策をご存知の方がいればぜひ教えていただきたいです。

まとめ

できたこと

• 3PL倉庫ベンダーへの移管を完了しました。
• TinyPilot Pro 2.5.4を公開しました。
• Microconf US 2023に参加しました。
• TinyPilotオフィスの新しい従業員を採用しました。
• 2022年分の税務でSection 174関連の対応に追われました。

学んだこと

• 短期ポジションでも構わないという候補者はたくさんいます。
  • 需要が落ち着いたときにどうするか不安で、3人目の採用を避けていました。しかし、最初から短期ポジションとして提示すればいいと気づきました。短期での就業を歓迎する、むしろ好む候補者は十分にいるのです。

来月の目標

• 新しいTinyPilot従業員のオンボーディングを行います。
• 売上9万ドルを達成します。
• TinyPilot Voyager 2aをレビューしてくれるhomelab系ブロガーまたはYouTuberを3人見つけます。