一行サマリー

サードパーティへのフルフィルメント移行はゆっくりと進行中です。

ハイライト

• 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のルート管理者の認証情報を渡すか、3PL用に新しい管理者アカウントを作成するように書かれていました。

まさか、と思いました。

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

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

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

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

試行錯誤の末、ShopifyユーザーアカウントがShipStationアカウントと連携するために必要な最小限の権限を突き止めました。把握できた後は、TinyPilotのShopifyに3PL用の権限を最小限に絞ったアカウントを作成しました。

もしShopifyとShipStationで同じ状況に陥っている方がこの記事を見つけたら、Shopify側でShipStationと連携するために必要な権限は次のとおりです。

• 注文
  • 注文の編集
• 商品の表示
• 顧客
• 設定の管理
• アプリとチャネルの管理・インストール

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のドキュメントを見ると、ShipStationからShopifyへ配送料を共有できるようでした。実現可能に思えたので、3PLはこれまでやったことはないものの、検討してみると言ってくれました。数時間後、3PLのマネージャーから電話があり、ShipStation側では可能だが、私のShopifyの料金プランでは対応していないことがわかりました。

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

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

ちょうど3PLのマネージャーと電話をしている最中にこの事実がわかり、半ば衝動的にその場でアップグレードしてしまいました。

配送料の件で大騒ぎした手前、今さら引き下がるのが気まずかったのです。ただ、後で考え直せるように、あえて月払いを選んで契約しました。

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

TinyPilotの需要はどれくらい価格弾力的か？

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

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

経済学でいう「弾力性」は、消費者が価格にどれだけ敏感かを示す指標です。わかりやすい例が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の在庫からTinyPilotが得られる収益を最大化しようとしています。

お客様に新デバイスの割引を提供する代わりに、下取りを提供するという名案を思いつきました。お客様がデバイスを私たちに送り、私たちができる限り部品を再利用してVoyager 2aへと作り替え、返送するという仕組みです。TinyPilotのすべての製品は同じモデルのRaspberry Piを使ってきたので、新しいPiを使わずに、長く使ってくださっているお客様に還元できるわけです。

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

多くのお客様はTinyPilotを日々の業務で使っているため、代替機が手元にない状態でデバイスを送ることを望みませんでした。そのような場合は、再生部品で作ったVoyager 2aを先に販売し、お客様の下取り品が届いた時点で一部を返金するという対応を取りました。

また、複数台のTinyPilotを所有し、すべてを常時稼働させておく必要があるお客様もいました。その場合は、再生デバイスを1台お送りし、お客様から旧機種を1台返送いただき、それを最新バージョンに作り替えて返送し、次にまた別の1台を送っていただく、という流れをすべてのデバイスが入れ替わるまで繰り返しました。4台分をこの方法で交換したお客様もいました。

すべての下取りはスムーズに進みましたが、想定以上に手間がかかりました。

この判断のトレードオフを評価するのは難しいです。メリットは目に見えません。私たちを支え、製品を応援してくださるお客様に報いるというものです。一方で、下取りのデメリットは非常に具体的でした。下取りは通常の販売に比べて平均で2〜3倍の処理時間がかかり、ほぼ原価で対応していました。

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

もしやり直せるなら、下取り自体はやはり提供しますが、次のように運用を変えます。

• 下取りを広く告知せず、問い合わせがあったお客様に個別に対応する。
• 下取り依頼用のサポート窓口を分け、お客様ごとに手続き開始まで数週間お待ちいただく場合があることをあらかじめ伝える。

サイドプロジェクト

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

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

デモでは1ユーザーあたり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全般への愛着はすっかり薄れてしまいました。Googleから、数か月後にPython 2.7向けのApp Engineを終了するという通知を受け取ったとき、今日の自分ならどれだけ速く同じサービスを実装できるか試してみるのも面白いと思いました。

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 Proの新バージョンをリリースする。

手伝ってほしいこと

ハードウェア製品で製造委託先と仕事をした経験がある方、ぜひお話を伺わせてください。特に年間2,000〜5,000台といった少量で電子機器を製造された方の経験に興味があります。