TinyPilot: Month 27

Michael Lynch

TinyPilot:27ヶ月目

原文は Michael Lynch により に公開されました。 このブログを購読する

一言でいうと

完全にリモート化したTinyPilotはどんな姿になるだろうか?

ハイライト

  • TinyPilotが物理的なオフィスなしで機能できるかを思考実験している。
  • アウトソースについて考えることで、現在のワークフローの非効率に気づかされる。
  • E2EテストツールのPlaywrightにすっかり魅了された。

目標の達成度

毎月のはじめに達成したい目標を宣言している。目標に対してどれだけ達成できたかは次のとおりだ。

TinyPilot Proを次世代アップデートシステムへ移行する

  • 結果:新アップデートシステムを含むTinyPilot Pro 2.5.0をリリースした。
  • 評価:A

今回のリリースでの大きな変更点はアップデートの仕組みだ。以前のTinyPilotはgitサーバーにアップデートを問い合わせ、常に最新バージョンへアップデートしようとしていた。現在は、TinyPilotが次のバージョンを問い合わせるためのカスタムウェブサービスを用意している。新しいアップデートシステムにより、アップデートプロセスをより細かく制御できるようになり、新バージョンのテストも容易になった。

今回のリリースには5ヶ月を要し、想定よりも長くかかった。通常のリリースサイクルは約2ヶ月だ。今後は新しいバージョンによって、より迅速なイテレーションとテストが可能になることを期待している。

TinyPilot VoyagerをYouTubeクリエイターまたはブロガー2名にレビュー用に送付する

  • 結果:採用を優先するため、この目標は中止した。
  • 評価:対象外

サポートエンジニア1名を手放すことになったため、代わりに後任の採用に注力した。その結果、10月初旬に新しいエンジニアを採用できた。

ケースの新たな製造方法を検討する

  • 結果:金属製ケースの試作品を発注した。
  • 評価:A

現時点ではまだ検討段階なので、やや曖昧な目標だ。以前は射出成形ケースを検討したことがあり、単価は安くなるものの初期費用が高額だった。現在は金属ケースを検討しており、初期費用を抑えつつ効率的にスケールできる。

TinyPilotの統計

指標2022年8月2022年9月増減
ユニークビジター11,9039,040-2,863 (-24%)
総ページビュー23,21417,608-5,606 (-24%)
販売収益$76,082.06$68,640.50-$7,441.56 (-10%)
エンタープライズサブスクリプション$290.70$242.95-$47.75 (-16%)
ロイヤリティ$3,264.23$3,440.90+$176.67 (+5%)
総収益$79,636.99$72,324.35-$7,312.64 (-9%)
利益$21,580.82-$8,764.28*-$30,345.10 (-inf%)

* この利益の数字は、月中旬に正式な帳簿処理を行うまでの、手元資金の変動を単純に計算したものに過ぎない。

数字はどれも真っ赤で恐ろしいが、実際には堅調な月だったと思う。収益が再び7万ドルを超えたことを嬉しく思っている。

利益が減少したのは、半年前に遡る原材料費として1万1千ドルの想定外の請求があったためだ。それでも、これほど赤字になったのは少し意外だった。請求書のタイミングによるものが大きく、今後数ヶ月で平均すればプラスに落ち着くだろう。

金属ケースはTinyPilotにとって何を意味するのか?

現在、生産における残されたボトルネックのひとつがケースだ。ケースは3Dプリントで製造しており、プレミアムな素材を使っているため印刷に時間がかかり、月産は約160個に限られる。さらに、マサチューセッツ州の補助金を利用している関係で、特定の1社にしか印刷を依頼できないという制約もある。

一方で、販売台数は月200台以上なので、ケースが近いうちにボトルネックになる。販売数が製造能力を下回っていた時期にケースを備蓄していたため、現在のペースでもあと数ヶ月は出荷を続けられる。

ハードウェアパートナーからは、一般的なコンシューマー向けネットワーク機器のような金属ケースを提案された。

金属製のTP-Link TL-SG1005P 5ポートスイッチの写真

もしTinyPilotをこのような金属ケースに切り替えたらどうなるだろうか?

金属ケースにすればコストを削減でき、月産160個という制約もなくなる。月に数千個の製造が可能になるからだ。

ハードウェアパートナーが何気なく口にしたことで、さらに考えが広がった。ケースを中国で製造するなら、組み立ても中国でできるのではないか、というのだ。

当初、中国での組み立てにはあまり魅力を感じなかった。マサチューセッツでうまく回っている組み立てプロセスがあるのに、なぜ変える必要があるのかと思ったからだ。

仮に米国での組み立てコストが1台あたり10ドルだとして、中国のベンダーなら1〜2ドルでできるかもしれない。1台あたり9ドルの節約では、スムーズに機能しているプロセスを変更するリスクに見合わない。

しかし、中国での製造について考えを巡らせるうちに、TinyPilotのオフィスがどう変わるかという点に思い至った。ケースやUSBケーブル、小さなゴム足といった在庫はすべてメーカー側で保管されるため、棚に積み上がることはなくなる。原材料がメーカー側にあるなら、在庫を追跡し、生産に合わせて補充を手配するのもメーカーに任せられる。

そして、そもそもTinyPilotにオフィスは必要なのか、と自問し始めた。

TinyPilotのオフィスでは何が行われているのか?

現在、TinyPilotのオフィスは主に6つの用途に使われている。

  1. 在庫の保管
  2. デバイスの組み立て
  3. microSDへの書き込み
  4. 組み立てたデバイスのテスト(品質保証)
  5. 顧客注文の梱包・発送
  6. 返品の処理

TinyPilotは自社オフィスなしでもこれらの機能を維持できるのだろうか?見ていこう。

在庫保管とデバイスの組み立て

製造を中国に移せば、在庫管理も実質的に中国へ移ることになる。

うまく機能すれば、在庫と製造をアウトソースすることで、TinyPilotのワークフローの多くがシンプルになる。一方で、問題が起きたときの影響は、メーカーが何千マイルも離れている分、はるかに深刻になる。

海外メーカーが製造を引き継げば、TinyPilotのオフィスでの作業の多くが突然不要になる。完成品だけを保管すればよくなるため、オフィスの収納スペースの大部分が空く。在庫追跡も、原材料や半組み立て部品ではなく完成品だけを管理すればよいので、はるかにシンプルになる。スタックの中で最も使いづらく品質の低いソフトウェアである在庫管理ツールのサブスクリプションも、ようやく解約できる。

輸入にかかる手間も減るはずだ。原材料のほとんどは中国産なので、ばらばらの原材料としてではなく完成品として一度に受け取れれば、管理ははるかに楽になる。

私はよく輸入のクリティカルパスに巻き込まれる。DHLがサポート用のメールアドレスではなく、荷物に記載された電話番号に連絡したがるからだ。オフィスに固定電話がないため、結局私の携帯に直接電話がかかってくる。月に数回程度の配送になれば、スタッフが事前に配送を追跡し、相手から電話が来る前に関税を支払える程度の件数に収まるはずだ。さらに、アウトソースした製造と3PLベンダーを組み合わせれば、メーカーが直接サードパーティのフルフィルメントセンターへ発送してくれるため、私たちが関与する必要すらなくなる。

デメリットは、メーカーに対して大きな信頼を置く必要があることだ。半導体不足の影響で、電子部品を数ヶ月から数年分の生産に備えて備蓄しなければならない。もしメーカーが1年分の部品を紛失したら、深刻な事態に陥る。定期的な在庫確認を依頼したり、第三者の監査人を派遣したりはできるが、もしメーカーに「すみません、2万ドル分の在庫をなくしました」と言われた場合、どのような対処ができるのか正直わからない。

TinyPilotの製品は、部品のアップグレードや設計上の問題発見に伴い、細かな調整を何度も重ねている。自社で製造していれば、部品がうまくはまらないときや部品に過度なストレスがかかっているときにすぐに気づける。海外メーカーに委託すると、フィードバックのサイクルが遅くなる。問題に気づいたときには、すでに同じ欠陥を抱えた製品が数百台製造されているかもしれない。

microSDへの書き込み

TinyPilot1台ごとに、TinyPilotのソフトウェアを書き込んだmicroSDが必要になる。現在は、書き込み後のmicroSDが一度も自分たちの手を離れないため、改ざんされていないという高い確信を持てている。私たちと顧客の間でmicroSDに手を加えられる可能性があるのは配送業者だけだが、もしUSPSが悪意を持ったとしても、TinyPilotより狙う価値のあるターゲットは他にいくらでもあるだろう。

microSDへの書き込みをどうアウトソースすべきかは悩ましい。私たちはカスタムでブランド入りのmicroSDを使っており、製造元はソフトウェアの書き込みにも喜んで対応してくれる。ただ、マルウェアのリスクが高いと感じ、躊躇している。理論上は、彼らの出力をランダムに抜き取って自分が渡したディスクイメージと一致するか確認することはできるが、それでも完全には安心できない。

TinyPilotブランドのmicroSDの写真

現在、microSDへのイメージ書き込みが可能なベンダーを利用しているが、懸念がある。

自分たちでmicroSDへの書き込みを続けて、それをメーカーに送るという手もある。メーカーが正直であることが前提だが、おそらくコンピュータ製品を海外で製造しているどの企業も同じリスクを負っているのだろう。

組み立てたデバイスのテスト

デバイスを組み立てた後、現在は手作業で機能が正常に動作するかテストしている。

現在のテスト環境は遅く複雑で、メーカーに引き継ぐのは難しい。新しく組み立てたTinyPilotをターゲットコンピュータに接続し、別のコンピュータのウェブブラウザからTinyPilotのウェブインターフェースにアクセスする必要がある。従業員はTinyPilotの起動を待ってから、ターゲットコンピュータの画面が正しくキャプチャされ、キーボードやマウスの入力が正確に転送されているかを確認しなければならない。

現在のテスト環境を手描きで示したスケッチ

TinyPilotの現在のQAプロセスでは、2台のノートPCと複雑なケーブル接続が必要になる。

このプロセスの自動化は以前から課題だったが、実現にはハードウェアのエンジニアリングリソースが必要で、そこが現在最も不足しているリソースでもある。

こうして書き出してみて、汎用ハードウェアとソフトウェアのエンジニアリングリソースだけで解決できることに気づいた。Raspberry Piを使えばTinyPilotのテスト機を作れるはずだ。

Raspberry PiはHDMI出力とUSB入力を備えている。Raspberry Piをテストランナーとしてプログラムし、PiのHDMI出力からの映像をTinyPilotが正しくキャプチャしているかを確認できる。PiがTinyPilotに対してキー入力を送るよう指示した際に、PiがTinyPilot経由のUSB入力で同じキー入力を受け取れば、新しく組み立てたVoyager 2の内部が正しく接続され、正常に動作していることを確認できる。

簡素化されたテスト環境の案を手描きで示したスケッチ

Raspberry Piにカスタムスクリプトを組み合わせてVoyager 2に接続すれば、QAプロセスを自動化できる可能性が高い。

あとは、テストデバイス側にTinyPilot Voyager 2が検証に合格したかどうかを示す外部インジケータがあればよい。テスト環境自体はシンプルなので、Piとネットワークスイッチをメーカーに渡し、向こうでテストする方法を教えることもできるはずだ。

これは、アウトソースする方法を考えるだけで、たとえ実際にアウトソースしなくても既存のワークフローにメリットをもたらす好例だ。

顧客注文の梱包と発送

ワークフローの中でも、注文のフルフィルメントは現時点で最もアウトソースしやすい部分だ。

私たちは常に出荷準備が整った箱を用意しているので、それをオフィスに置いておくのではなく3PLベンダーに渡すことができる。

段ボール箱に梱包されたVoyager 2の写真

オフィスでは、組み立て済みのVoyager 2を出荷準備が整った状態で箱に入れて保管している。

フルフィルメントをアウトソースするメリットは、もともと柔軟な勤務時間がさらに柔軟になることだ。現在、TinyPilotのオフィスには週6日、1日数時間スタッフを配置している。3PLベンダーがいれば、注文が滞りなく流れるだけのデバイスを組み立てておく限り、特定の日に誰かがオフィスにいる必要はなくなる。

オフィス内の物理的なスペースも空く。箱や梱包材は狭いオフィスでかなりの場所を取っているからだ。

さらに、顧客が選べる配送オプションが増える。現在は各配送業者との調整が複雑になるため、USPSとDHLのみを提供している。3PLプロバイダーなら、すでに主要な配送業者が毎日集荷に来ているため、どの大手配送業者にも容易に対応できる。

配送スピードもわずかに向上するかもしれないが、TinyPilotはすでに90%の注文を1営業日以内に発送しているため、この点のインパクトはそれほど大きくない。

デメリットは、3PLベンダーが複雑さを増すことだ。現在、カスタマーサービスが優れているのは、顧客からメールが来た際に、知識豊富なTinyPilotの従業員が直接対応しているからだ。おそらく、その従業員自身がその顧客のデバイスを組み立て、梱包、あるいは発送している。彼らは配送状況の確認、注文のキャンセル、返品の手配まで行う権限を持っている。

3PLベンダーがフルフィルメントした注文に問題があった場合、TinyPilotのカスタマーサポート担当者はまず3PLベンダーの窓口担当者に確認し、その担当者がさらに別の誰かに確認する必要があるかもしれない。

返品の処理

オフィスなしでどうやって返品を処理するのか、まだわからない。

TinyPilotデバイスの整備を3PLベンダーに任せる気にはなれないが、返品をただ廃棄されてしまうのも避けたい。

もしかすると、返品専用の住所として私書箱を用意するという手もある。従業員が郵便局に返品を取りに行き、整備したうえで3PLベンダーに送り、整備品として販売してもらうのだ。

まだ3PLベンダーとは話をしていないので、もっと良い解決策があるかもしれない。

すべてをアウトソースしたらどうなるか?

オフィスの機能をすべて外部ベンダーや場所に依存しない代替手段にうまく移管できたと仮定すると、私や会社にとってそれは何を意味するのだろうか?

場所に依存しなくなる

現在、私たちは物理的なオフィスに縛られている。オフィスをなくせば、理論上、TinyPilotの全従業員がどこからでも仕事をできるようになる。

時間に縛られなくなる

フルフィルメントや製造がなければ、時間的な制約がある業務はカスタマーサポートだけになる。

従業員の不在に強くなる

ここ数ヶ月、TinyPilotの現地スタッフが数日間不在になることが何度かあった。予定された休暇もあれば、病欠もあった。

TinyPilotは十分な冗長性を備えていたため、顧客に影響を与えることなく業務を継続できたが、システムの他の部分には負担がかかった。

もし製造とフルフィルメントをアウトソースすれば、TinyPilotは従業員の不在にもはるかに対処しやすくなる。注文の発送において自分たちがクリティカルパスから外れるため、発送を維持するために慌てる必要がなくなる。

現地スタッフの役割が変わる

アウトソースの課題のひとつは、既存の現地スタッフの仕事への影響だ。もしTinyPilotのオフィスをなくし、製造とフルフィルメントをアウトソースすれば、現地チームの現在の業務の約75%がなくなることになる。

現地チームは素晴らしい仕事をしてくれており、オフィスをなくしても会社の中で引き続き役割を持てるようにしたい。

現地チームは今後もカスタマーサービスの業務を担う。アウトソースによって販売を拡大できる可能性が高く、顧客が増えればカスタマーサービスの需要も高まるからだ。

現地スタッフは、より多くのアウトリーチ業務を担うこともできる。これまでも、大口顧客に積極的に連絡を取り、製品の使用感についてヒアリングして良い成果を得てきた。時間的な制約からあまりできていなかったが、時間ができればその分野により投資できる。同様に、現地スタッフがより多くのレビュアーやYouTubeクリエイターと連携すれば、マーケティングにも役立つ。

煩雑な手続きが減る

現在、TinyPilotで法律上「従業員」として分類されているのは現地スタッフだけだ。それ以外の全員は業務委託だ。現地スタッフがオンサイトで働いているため、米国の雇用法上、彼らを業務委託ではなく従業員として扱わなければならない。

もしTinyPilotのオフィスをなくせば、従業員を業務委託に切り替えることができる。「福利厚生を削りたいんだろう」と思われるかもしれないが、誰にとってもメリットのある形で移行できると考えている。私の目的は報酬を減らすことではなく、ストレスや書類手続きを減らすことだ。

従業員への支払いと業務委託への支払いでは、複雑さに大きな違いがある。ほぼ毎月のように、マサチューセッツ州の役所から源泉徴収やコンプライアンス要件について難解な手紙が届くが、何をすべきなのか、そもそも何か対応が必要なのかさえ判然としない。

コンプライアンスや適切な納税を支援するサービスもあるが、これまで満足のいくものに出会えたことがない。役所からの通知を給与計算プロバイダーのGustoに転送しても、政府に直接電話して自分で解決してくれと言われるだけだ。そして州の機関に電話しても、たらい回しにされた挙句、届いた通知について何も知らない担当者につながる。結局、無視してそれが正しい対応であることを祈るしかなくなる。

業務委託なら必要な書類ははるかに少なくなる。スタッフが従業員だったときと同等かそれ以上の報酬を得られるよう給与を調整でき、誰にとっても手続きの負担は軽くなる。

コストが下がる

アウトソースはコスト削減にもつながるが、これは私にとって最も関心の低いメリットだ。

オフィスがなければ、家賃(月550ドル)、Gustoの給与計算サービス(月80ドル)、在庫追跡(月59ドル)、労災保険(月30ドル)、借家人保険(月10ドル)を支払う必要がなくなる。

人件費も理論上は1台あたり数ドル下がる。中国のメーカーは私たちよりはるかに安い人件費でデバイスを製造でき、3PLベンダーは規模の経済により私たちよりも安く注文をフルフィルメントできるからだ。

柔軟性と俊敏性は低下する

すべてをアウトソースすることは「ハッピーパス」を最適化するが、例外への対応やミスの修正は難しくなる。

これまでは、見た目の欠陥を減らしたり使いやすくしたりするために、製品を迅速に改善してきた。すべてをアウトソースすると、フィードバックループは遅くなる。数人の顧客から報告があるまで問題に気づかないかもしれない。その時点では、問題のある工程を通過したデバイスがすでに数百台、顧客や倉庫へ向かっている可能性がある。

エラー率は上がる

アウトソースすれば、エラー率はほぼ確実に上がるだろう。現在のエラー率は、限りなくゼロに近い。過去18ヶ月で約2,500件の注文があったが、誤った商品が届いた、あるいは製造上の不具合があったと顧客から報告があったのは2、3件だけだ。

経験豊富な製造・フルフィルメントのベンダーでさえ、私たちが内製で達成しているエラー率には及ばないだろう。それでも、現在のエラー率は顧客満足を維持するために必要な水準をはるかに上回っている。0.3%程度のエラー率であれば、顧客体験に大きな影響を与えずに許容できると考えている。

アウトソースは複雑さを増すのか、減らすのか?

アウトソースにおける私の主な目的は、複雑さを減らすことだ。依然として、管理時間を週20時間まで減らすことを目指している。

最も懸念しているのは、製造とフルフィルメントはTinyPilotの中でも最も管理の手間がかからない部分だということだ。つまり、アウトソースしても取り戻せる時間がないかもしれない。すべてにおいて再現可能なワークフローを構築するまでには多大な労力がかかったが、一度できてしまえば、その後はほぼ順調に回っている。

製造やフルフィルメントで私の関与が必要になるのは、部品不足や、顧客の配送に関する問題が私にエスカレーションされるほど特殊なケースといったときだ。外部ベンダーに移行しても、そうした問題への関与は続くし、会社をまたいでの管理はより難しくなる。

同時に、外部ベンダーと連携する方が、自前で製造やフルフィルメントの仕組みを維持し続けるよりも、どう考えても楽になるはずだという感覚もある。オフィスは順調に回っているとはいえ、オフィス自体やそれに付随するあらゆるプロセスを維持するだけでも、かなりの精神的負担がかかっている。

現在、私たちは複雑さという点で局所的な最小値にいるのではないかと期待している。プロセスを切り替える際の摩擦で一時的に複雑さは増すが、アウトソースが軌道に乗れば、最終的には現在よりも低い複雑さの状態に到達できると考えている。

プロセスを改善するにつれて複雑さが下がり、アウトソースする際に急激に上昇した後、落ち着けば現在の状態よりも低い水準に下がる様子を示したグラフ

サイドプロジェクト

こんにちはPlaywright、さようならCypress

私はCypressというE2Eテストツールのファンで、2018年のウェブ開発ミートアップでGleb Bahmutovのデモを見て以来ずっとそうだった。ここ数年、MicrosoftのCypressの競合であるPlaywrightについて耳にする機会が増えてきた。

1年前にPlaywrightを試したときはあまり感心しなかった。最近、Hacker Newsのスレッドで誰もがPlaywrightはCypressを超えたと口を揃えているのを読んで、再びPlaywrightを試してみた。

今では、Hacker Newsの意見に同意せざるを得ない。試しに、PicoShareのE2EテストをすべてPlaywrightで書き直してみた。ほぼすべての面で、Playwrightの方がCypressよりも扱いやすいと感じた。

CypressからPlaywrightへの移行プロセスについては、より詳しい記事を準備中だが、要するに、ウェブアプリのE2Eテストには今やCypressよりもPlaywrightを推奨したい。

まとめ

何ができたか?

  • TinyPilot Pro 2.5.0をリリースした。
  • 8月にSupport Engineerの求人に応募してくれた全員に個別に返信した。
  • 2人目のTinyPilotサポートエンジニアを採用した。

学んだこと

  • タスクをどうアウトソースするかを考えるだけで、既存のワークフローにおける改善の機会が見つかることがある。

来月の目標

  • 新しいサポートエンジニアを立ち上げる。
    • 1人目は80%、2人目は50%の質問に独力で答えられるようにすることを目指す。
  • 2つ目の金属ケース試作品の製造を開始する。
  • 3社の3PLベンダーに連絡を取り、フルフィルメント移行のプロセスについて話を聞く。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント