一言サマリー

外部委託へのゆっくりとした移行

ハイライト

• TinyPilotのフルフィルメントを外部ベンダーへ移行するプロセスを開始しました。
• TinyPilotの顧客は、私が予想していたよりも価格に敏感ではないことがわかりました。
• TinyPilotの下取りプログラムに多くのリソースを投じましたが、それが見合ったのかは定かではありません。

目標の自己採点

毎月のはじめに達成したい目標を宣言しています。結果は以下の通りです。

低ボリューム製品のフルフィルメントを新しい3PLに移行する

• 結果：3PLベンダーがPower Connectorの注文のフルフィルメントを3週間にわたって担当しています。
• 評価：A

いくつか細かな問題はありましたが、最初の製品の移行は無事に完了しました。

NERD Summit 2023で登壇する

• 結果：登壇して手応えを感じました。
• 評価：A

2019年以来初めてNERD Summitに現地で参加できて楽しかったです。素晴らしいトークが多く、廊下での会話も盛り上がりました。

フルフィルメントチームの負荷を軽減し、突発的なタスクが占める時間を80%未満に抑える

• 結果：おおむね成功しましたが、測定が困難でした。
• 評価：B

3PLへ移行するために、現地チームが1週間分のデバイスを追加で組み立てられるよう、業務量を空ける必要がありました。負荷軽減のためにいくつかの対策を講じましたが、チームはいつもより長時間働くことにもなりました。

TinyPilotの統計

TinyPilotのケースをプラスチックから金属に切り替えたことで、需要が劇的に増加しました。価格を引き上げ、マーケティングをほぼゼロにまで絞っても、販売数は増え続けています。

今年の目標は利益10万ドルを達成することですが、すでに75%まで到達しています。このペースなら4月末までに年間利益10万ドルを達成しそうです。

3PLベンダーへの移行で起きたトラブル

最優先事項は、TinyPilotのフルフィルメントをサードパーティロジスティクス（3PL）ベンダーへ移行することです。3PLの役割は、完成品を倉庫で保管し、注文が入るたびにピッキング、梱包、発送を行うことです。

まずは最も販売数が少ない製品であるTinyPilot Power Connectorを3PLに任せることから始めました。これは自分でTinyPilotデバイスを組み立てるユーザー向けの製品で、ウェブサイト上でも積極的に宣伝していません。月間販売数は20〜30個程度です。

Power Connectorは、すべての注文を移行する前に新しい3PLの対応をエンドツーエンドでテストする、ローリスクな方法でした。この試行でいくつかの問題が見つかったので、まずは小規模に始めてよかったと思っています。

「みなさん普通に管理者パスワードを渡してくれますよ」

最初の課題は、TinyPilotの注文システムと3PLのシステムを同期させることでした。TinyPilotは米国で最も人気のあるECプラットフォームの一つであるShopifyを使っています。一方、3PLは注文管理にShipStationを利用しています。ShipStationもかなり普及しており評判も良いので、ShopifyとShipStationの連携は簡単だろうと思っていました。

以前の3PLも似たような注文管理システムを使っていました。そのときはShopifyにアプリをインストールして3PLのアクセスキーを貼り付けるだけで、簡単に連携できました。

ところが新しい3PLからShipStationとShopifyアカウントを連携させる手順が送られてきたとき、Shopifyのルート管理者アカウントの認証情報を渡すか、彼ら用に新しい管理者アカウントを作るように言われました。

まさかそんなはずはないと思いました。

ShipStationのドキュメントを確認しても、2つのアカウントをどう連携させるのかわかりませんでした。ShipStationはShopifyアカウントとShipStationアカウントの所有者が同一人物であることを前提に作られており、私たちのケースには当てはまらなかったのです。

ShipStationの設計のせいで、私たちは行き詰まってしまいました。私は3PLのShipStationの管理者認証情報を持っていないので彼らのShipStationアカウントに連携できず、3PL側も私のShopifyの管理者認証情報を持っていないのでTinyPilotのShopifyストアに連携できないという状態でした。

TinyPilotのShopifyで3PLに完全な管理者権限を与えたくありませんでしたし、ましてや自分のアカウントの認証情報を渡すなんてもってのほかでした。

そこで、代わりに自分でShipStationアカウントを作り、権限を絞ったダミーのShopifyユーザーアカウントを用意しました。そして、そのダミーアカウントを使ってTinyPilotのShopifyアカウントとテスト用のShipStationアカウントの連携を何度も試してみました。

試行錯誤の末、ShipStationアカウントを連携させるために必要なShopifyユーザーアカウントの最小権限を突き止めました。それがわかってからは、TinyPilotのShopifyに3PL用の権限を最小限に絞ったアカウントを作成しました。

もしこの記事を見つけた方で、ShopifyとShipStationで同じように困っている方がいれば、Shopify側でShipStationを連携させるために必要な権限は以下の通りです。

• Orders
  • Edit orders
• View products
• Customers
• Manage settings
• Manage and install apps and channels

Shopifyと3PLのShipStationアカウントを連携させるプロセスがこれほど複雑だとは驚きました。3PLはShopifyの顧客を何十社も抱えているとのことだったので、これまでどうやって対応してきたのか尋ねました。

「みなさん普通に管理者パスワードを渡してくださいますよ」と3PLのマネージャーは言いました。彼女によると、顧客の多くはあまり技術に詳しくないため、フルフィルメントを任せるベンダーにShopifyの認証情報を渡すことを特に不自然だとは思わないのだそうです。

50ドルの注文に150ドルの送料を払うべきか？

移行における次のつまずきは、オーストラリアからの注文が入ったときに起きました。オーストラリアへの送料は、TinyPilotが配送している国の中でも最も高い部類に入ります。TinyPilot Power Connectorを米国内で発送する場合は数ドルで済みますが、オーストラリアまで送ると50ドルかかります。

3PLによると、この注文の送料は150ドルかかるとのことでしたが、顧客が支払った送料は50ドルでした。実はTinyPilotは、Shopifyが代理で交渉してくれているおかげで、DHLの国際配送を割引料金で利用できていました。3PLはDHLとの割引契約がなかったため、オーストラリアへの送料として150ドルを支払わなければならなかったのです。

もし3PLが通常料金の送料を購入すれば、その差額100ドルは私の負担になります。注文を受けなければよかったと思うほど、50ドルのマイナスになってしまう計算です。

1件の注文で損をするだけなら大した問題ではありませんが、これはより根深い問題を示していました。TinyPilotの顧客がチェックアウト時に目にしている送料は、Shopifyの送料に基づいて表示されていたのです。本来は3PLの送料を表示させる必要がありました。

またしても「他の顧客はどうしているんですか？」と尋ねました。

3PLのマネージャーによると、他の顧客は送料無料にしているか、国ごとに荷物のサイズや重量に関係なく一律料金を設定しているとのことでした。

そのようにざっくり見積もる方法でも不可能ではないですが、どこか雑な感じがしました。常に推測に頼ることになり、送料を大幅に安くしすぎたり高くしすぎたりする事態が必ず出てくるはずです。現在のTinyPilotの設定では、顧客が正確な送料に基づいて配送業者を選べるようになっており、その仕組みは維持したいと思いました。

ShipStationのドキュメントを見ると、送料をShopifyと共有できるようだったので、実現可能に思えました。3PLはこれまでやったことがないと言いつつも、調べてみることに前向きでした。数時間後、3PLのマネージャーから電話があり、ShipStation側では可能だが、私のShopifyの料金プランでは対応していないと知らされました。

Shopifyの機能ページを確認すると、「サードパーティによる配送料の計算」はShopifyのAdvancedプランでしか利用できないことがわかりました。

これによりTinyPilotのShopifyプランは月額105ドルから一気に399ドルへ跳ね上がり、ShopifyがTinyPilotで最も高額なクラウドサービスになることになります。

このことを調べている間も、まだ3PLのマネージャーと電話をつないでいました。やや衝動的に、その場ですぐにアップグレードしました。

送料の件で大騒ぎした手前、今さら引っ込むのも恥ずかしくなっていました。ただ、後で気が変わってもいいように、あえて月払いでの契約にしました。

振り返ってみても、ShopifyのAdvancedプランにする価値はあったと思っています。国ごとに送料を推定して、相場の変動に合わせて調整するようなことは本当にやりたくありませんでした。しかも上位プランではクレジットカード手数料が0.2%下がるので、多少は元が取れます。昨年のTinyPilotの売上から計算すると、手数料の割引で約2,000ドル節約できていたはずなので、このとんでもなく高額なプランに年間4,800ドル払っている分のいくらかは回収できることになります。

TinyPilotの需要の弾力性はどのくらいか？

TinyPilotの現在の制約は製造キャパシティです。いまだにデバイスの組み立ては内製ですが、注文はスタッフが組み立てられるのとほぼ同じペースで入ってきています。

すべての製品を3PLに移行するには、注文に追いつくだけでは足りません。3PLの倉庫に送るために、少なくとも1週間分の余剰在庫としてVoyager 2aを組み上げておく必要があります。販売ペースを落とすために価格を引き上げてみたところ、興味深いデータが得られました。

経済学でいう製品の「弾力性」とは、消費者が価格にどれだけ敏感かを示す指標です。Uberの配車は弾力的な製品の良い例です。安ければ利便性にお金を払いますが、価格が10倍になれば多くの人は公共交通機関を選ぶでしょう。

では、TinyPilotの顧客は価格にどれだけ敏感なのでしょうか？

Voyager 2a USB-C

Voyager 2a PoE

振り返り

サンプル数が少ないため断定はできませんが、データからはTinyPilotの顧客が私の予想よりも価格に敏感でないことがうかがえます。特にPoEモデルは需要が非弾力的で、80ドル（17%）値上げしてもほぼ同じペースで売れ続けました。

資本家としての自分は利益を最大化するためにもっと値上げしたいと思います。一方で、愛好家としての自分はカジュアルなユーザーでも手が届く価格にしておきたいとも思います。

最近、最初のTinyPilotプロトタイプを作ったときのブログ記事を読み返していて、次の段落が目に留まりました。

次に、商用のKVM over IPソリューションを調べてみました。DellのiDRACと似たような機能を提供するのですが…さらに高価で、1台あたり500〜1000ドルもします。

今や私自身が高い商用KVM over IPソリューションになってしまいました！

もしかすると非合理的なのかもしれませんが、2020年当時の、ホームサーバーを手軽に管理したいだけで大金をかけたくなかった自分に刺さるようなTinyPilotを提供したいと思っています。

供給も製造スピードも制約がある今は、高い価格設定にも理があると思います。ただ、いずれはまた価格を下げて、販売数でカバーできるようにしたいと願っています。

下取りは愚かなアイデアだったのか？

TinyPilotが新しいハードウェアバージョンを出すたびに、顧客から古いデバイスを最新モデルに下取りできないかと尋ねられます。これまでは下取りの仕組みはないが、新バージョンを大幅に割引すると伝えてきました。

今年、TinyPilotの最大の制約はRaspberry Piの入手性です。そのため、限られたPiの在庫から得られる収益を最大化しようとしています。

新しいデバイスを割引する代わりに、下取りを提供するという素晴らしいアイデアを思いつきました。顧客がデバイスを送り返してくれれば、できるだけ多くの部品を再利用してVoyager 2aに作り替え、返送するという仕組みです。どのTinyPilot製品も同じモデルのRaspberry Piを使っているので、新しいPiを消費せずに常連の顧客に報いることができます。

ところが下取りのプロセスは、想像以上に複雑で手間がかかるものでした。

多くの顧客は日々の業務でTinyPilotを使っているため、代替機が手元にない状態でデバイスを送りたくないと考えていました。そのようなケースでは、まず再生部品で作ったVoyager 2aを販売し、下取り品が届いてから一部を返金する方法を取りました。

さらに、複数台のTinyPilotを持っていて、すべてを常時稼働させておきたいという顧客もいました。その場合は、再生品を1台送り、顧客から旧型機を1台返送してもらい、それを最新版に作り替えて送り返し、次にまた次の1台を送ってもらう、という作業をすべてのデバイスを交換し終えるまで繰り返しました。4台すべてをこの方法で交換した顧客もいます。

すべての下取りは滞りなく進みましたが、予想をはるかに上回る手間がかかりました。

この判断のトレードオフを評価するのは難しいです。メリットは無形のもので、私たちを支持し続けてくれる顧客に報いるという点にあります。一方でデメリットは非常に具体的でした。下取りは通常の販売に比べて処理に平均2〜3倍の時間がかかり、しかもほぼ原価で対応していました。

通常販売1件あたりの利益が300〜400ドルで、下取り1件につき約2.5件分の販売機会を失ったとすると、下取り1件あたり750〜1,000ドルのコストがかかったことになります。合計22件の下取りを行ったので、下取りプログラム全体で約19,000ドルのコストがかかった計算です。

もしやり直せるとしても、やはり下取りは提供したと思いますが、次のようにやり方を変えます。

• 下取りを大々的に宣伝するのではなく、問い合わせがあった顧客に個別で対応する。
• 下取り依頼用に別のサポートキューを用意し、対応開始まで数週間かかる場合があることをあらかじめ伝えておく。

サイドプロジェクト

ZestfulのマイクロサービスをGoで再実装する

2018年にレシピ材料解析サービスのZestfulを立ち上げたとき、見込み顧客が気軽にサービスを試せる方法が欲しいと考えました。他のサービスではアカウント作成やクレジットカード登録が必要でしたが、Zestfulのウェブサイトでは手軽に試せるデモを提供したかったのです。

デモではユーザーごとに1日30回までの解析に制限する必要がありました。それを超えたら有料プランに登録してもらう仕組みです。有料サーバーとまったく同じAPIインターフェースを持ちつつ、1日30材料までに制限するデモサーバーを作ることにしました。

当時はApp Engineが大好きで、自分でデータベースを管理するなんて考えたくありませんでした。そこでデモアプリはPython 2.7のApp EngineとGoogle Cloud Datastoreを使って書きました。

リクエストが来ると、デモサーバーはGoogle Cloud DatastoreでユーザーのIPアドレスを照会します。そのIPがクォータを使い切っていれば、有料プランへの登録を促すエラーを返します。まだクォータが残っていれば、リクエストを有料のZestfulサーバーに転送し、クライアントのIPアドレスに紐づくクォータを1つ消費します。

2018年以降、私はApp EngineやGoogle Cloud全般への愛着がすっかり薄れてしまいました。数ヶ月後にPython 2.7のApp Engineを終了するという通知をGoogleから受け取ったとき、今ならどれだけ速く同じサービスを実装できるか試してみるのも面白いと思いました。

Pythonの代わりにGoを使いました。Goのウェブアプリは構築も保守も容易だと感じているからです。最初はSQLiteとLitestreamを使ってデータベースをどう設計するか考えていましたが、そもそも永続的なデータストア自体を省略できることに気づきました。

全員のクォータをメモリ上で管理したらどうなるだろう、デメリットは何かと考えました。新しいバージョンをデプロイしたりサーバーを再起動したりするたびに、その日の全員のクォータがリセットされ、デモサーバーに対して追加のリクエストが可能になってしまいます。

再起動のたびにユーザー1人あたり0.60ドル相当の追加クォータを与えることになっても、大した問題ではありません。特にサーバーを頻繁に再起動する予定はないのですから。

サービスの再実装には約6時間の開発時間しかかかりませんでした。オリジナルには2週間かけた記憶があったので、自分でも驚きました。わずか5年で10倍も速くなったわけです！

ところが、オリジナルのApp Engine版のコミット履歴を確認してみると、実際にはわずか1日で実装していたことがわかりました。

Mon Apr 30 00:51:48 2018 -0400  Adding badges to README (#7)
Mon Apr 30 00:51:40 2018 -0400  Adding changes to make prod API work (#6)
Mon Apr 30 00:43:55 2018 -0400  Adding support for parser config model (#5)
Sun Apr 29 23:51:03 2018 -0400  Adding deployment to Travis (#4)
Sun Apr 29 23:41:42 2018 -0400  Adding rate limiter (#3)
Sun Apr 29 18:18:37 2018 -0400  Adding coveralls.yml (#2)
Sun Apr 29 18:14:46 2018 -0400  Merge pull request #1 from mtlynch/parser-proxy
Sun Apr 29 18:11:16 2018 -0400  Fixing response handler
Sun Apr 29 17:52:28 2018 -0400  Fixing HTTP handler
Sun Apr 29 17:40:02 2018 -0400  Adding in ParserProxy and tests
Sun Apr 29 11:20:11 2018 -0400  Initial commit

とはいえコミットを見ると、日曜の朝から月曜の午前1時まで続けたマラソンのようなコーディングセッションだったようなので、オリジナルも実際には14時間程度かかっていたはずです。そう考えると、高速化は2.3倍程度ということになります。

つまり、5年前と比べてそこまで劇的に速くなったわけではありませんが、データベースを省略してシンプルにするという新たな機会に気づけたことは誇りに思います。新しい技術を学び続けることで、以前よりも多くの解決策を手にできるようになったことも嬉しく思います。

まとめ

何ができたか？

• 1つの製品を3PLベンダーに移行した。
• NERD Summitで登壇した。
• 新しい会計士を見つけ、2022年分の確定申告の準備の大部分を終えた。

学んだこと

• 重要な業務を新しいベンダーに移行する前に、限定したトライアルを行う。
  • もし一気にフルフィルメントを3PLベンダーに引き継いでいたら、非常に混乱していただろう。
  • 限定トライアルから始めたことで、最初のベンダーが不適合だと判断して切り替え、2社目のベンダーとの細かな問題を解消することができた。

来月の目標

• すべての製品を3PLベンダーに移行する。
• TinyPilotのデバイス組み立てを引き継ぐ受託製造業者を選定し、移行プロセスを開始する。
• TinyPilot Proの新リリースを公開する。

協力のお願い

もしあなた自身や、あなたが話を持ちかけてくれる知り合いで、ハードウェア製品で受託製造業者と仕事をした経験がある方がいれば、ぜひ話を聞かせてください。特に年間2,000〜5,000台といった小ロットで電子機器を扱った経験のある方を探しています。