一言でまとめると

“緊急モード”からの脱出

ハイライト

• 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時間でも彼らの時間を節約できれば、その1時間をデバイスの製造に充ててもらえるからです。

そして幸い、これらの取り組みは功を奏しました。5月初旬、現地チームは1週間分の在庫を3PLに送れるだけの余剰在庫を積み上げることができました。3PLが稼働し始めてから、現地チームの作業負荷は約15%減少しました。

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

“緊急モード”からの脱出

フルフィルメントを3PLにアウトソースした後も、期待したほどは楽になりませんでした。倉庫にある在庫は数日分しかなく、チームは依然として新しいデバイスを急いで組み立て、3PLの在庫を補充するのに追われていました。

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

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

最悪だったのは、売上が好調な日を素直に喜べなくなったことです。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のような製品を見つけていたら、「399ドルなら自分のhomelab用に買う価値がある」と思ったはずです。

サイドプロジェクト

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名見つける。