一言でまとめると

権限委譲に注力した1ヶ月だった。

ハイライト

• TinyPilotのEU向け販売代理店は、8月末までの販売開始に向けて順調に進んでいる。
• チームメンバーに業務を委譲することで、自分の時間を確保できた。
• 数ヶ月間停滞していた2つのタスクが、奇跡的に動き出した。

目標の自己評価

毎月初めに達成したい目標を掲げている。結果は以下の通りだ。

8月末までにEUパートナーが販売を開始できるように準備する

• 結果：月末までの販売開始に向けて順調に進んでいる。
• 評価：A

これは順調に進んだ。来週には、販売代理店がTinyPilot Voyagerデバイスを自前で組み立てるために必要な部品と手順をすべて揃えられる見込みだ。月末までの販売開始に向けて順調に進んでいる。

TinyPilotの現地スタッフがすべての業務を共有・交代できるプロセスを定義する

• 結果：スタッフがタスクを交代できる共有ToDoリストを作成した。
• 評価：A

TinyPilotではこれまで、在庫管理や発送業務を同時に2人で担当したことがなかった。2人が責任を均等に分担できる仕組みを作るのは想像以上に難しかったが、現在は2人の従業員がタスクを交代し、スケジュールを調整できる実用的な仕組みができている。さらに、自分が補っていたギャップを文書化し、現地スタッフが対応できるようにした。

TinyPilotの販売サイトを担当するデザイナーを見つける

• 結果：新しい開発者がリデザインを進めている。
• 評価：A

数ヶ月にわたる募集の末、ようやくTinyPilotのウェブサイトを担当してくれるウェブ開発者を見つけ、現在リデザインを進めてもらっている。

TinyPilot Voyager用のPoEアダプタを作成できる電気設計会社を見つける

• 結果：既存の会社がPoEアダプタの作成を可能にする部品を見つけた。
• 評価：A+

これも幸運なブレークスルーだった。世界的な半導体不足により、依頼していた電気設計会社は数ヶ月間手詰まりの状態が続き、より良いサプライチェーンを持つ大手ベンダーへの問い合わせを始めていた。そこに依頼すれば一からやり直しになるうえ、プロセスも時間がかかる見込みだった。

幸い、TinyPilotの既存の電気設計パートナーが、6〜12ヶ月分の供給を確保できる部品を、想定していた価格の10%未満で見つけてくれた。現在、PoEアダプタ用の基板設計を進めており、4〜6週間以内に試作品が完成する見込みだ。

TinyPilotの統計

EUでの販売網の構築と、発送業務の現地スタッフへの移管に注力していたため、売上は低迷が続いている。マーケティングや広告を一切行わずに2ヶ月連続で2万4000ドルの収益を維持できているのは幸運だが、今後数ヶ月で販売とマーケティングへの投資を増やす必要がある。

在庫管理のマネージドサービスへの移行

TinyPilotを始めて数ヶ月経った頃から、在庫を追跡するためのマネージドサービスを探していた。安価なソリューションはシンプルすぎて、組み立てや製造が不要な製品にしか対応していなかった。一方、ハイエンドなソリューションは複雑すぎて、数千もの製品と複数の倉庫を抱えるエンタープライズ向けに作られていた。

偶然Craftybaseを見つけたとき、ようやくTinyPilotに合うソリューションが見つかったように思えた。そしてある程度はそうなのだが、移行は決してスムーズではなかった。

Craftybaseにはよくできていてワークフローにぴったり合う部分もある。特にお気に入りなのが「レシピ」機能で、製品を構成する原材料を定義できる。例えば、TinyPilot Power Connectorはケース1つと基板1つで構成されるとCraftybaseに教えることができる。CraftybaseでPower Connectorを10個「製造」したと記録すれば、在庫からケースと基板がそれぞれ10個ずつ差し引かれる仕組みだ。

レシピには、自分で製造した別のアイテムを含めることもでき、TinyPilotの多段階製造にはうまく合っている。例えば、TinyPilot Voyagerは段階を分けて製造している。通常、Voyagerデバイスを10台以上まとめて組み立て、テストした後、それぞれを必要なケーブルや説明書、microSDカードと一緒に箱詰めする。Craftybaseでは、レシピに原材料だけでなく以前の工程で作った部品も含められるため、このプロセスの各段階で部品を追跡できる。

残念ながら、Craftybaseでのワークフローのほとんどはかなりぎこちない。最もひどい例が入荷の管理だ。Craftybaseでは各アイテムに「低在庫しきい値」を設定でき、在庫が少なくなった部品をハイライト表示してくれる。

問題は、追加で発注した後もフラグが表示され続けることだ。フラグが発注済みで入荷待ちの分を無視するからだ。上の例では、HDMIキャプチャチップを月末に入荷予定としてCraftybaseに記録しているが、他にやることがないにもかかわらず、依然として在庫少としてフラグが立ったままだ。

つまり、TinyPilotのスタッフが何を再発注すべきか判断する際、フラグが立ったアイテムを一つひとつ確認し、入荷待ちの分を考慮した上で本当に在庫が少ないのかをチェックしなければならない。

最初は簡単な回避策があると思っていた。Craftybaseの「purchased（購入済み）」列が入荷待ちの出荷を表しているのだと思い込んでいた。

ところが「purchased」は実際にはサービス開始時からこれまでに購入した総数量のことで、Craftybaseが奇妙なほど目立つ場所に表示している、あまり意味のない指標だった。

回避策として、低在庫としてフラグが立ったアイテムごとに詳細画面を開き、在庫総数を確認し、発注済みの数を足し合わせ、それが低在庫しきい値を下回っているかどうかをチェックしなければならない。低在庫のチェックは本来2秒で終わるはずの作業だが、Craftybaseのせいで数分もかかる面倒で複雑なプロセスになってしまった。

委譲によってさらに時間を生み出す

TinyPilotのほとんどの期間、時間不足に悩まされてきた。事業には多くの要素が絡み合っており、それらすべてをつなぐのは私一人だった。

6月には、研修やツールにある程度投資すれば委譲できるタスクのリストを洗い出した。うれしいことに、そのリストの半分に加え、さらにいくつかのタスクを委譲または廃止することができた。

スプレッドシート係からの卒業

TinyPilotの以前の在庫管理は、自作のスプレッドシートで行っていた。TinyPilotのワークフローにはよく合っていたが、柔軟性に欠けていた。新しい製品を追加したり部品を変更したりするたびに、場当たり的なスプレッドシートの数式をいじるのに何時間も費やさなければならなかった。

Craftybaseにはイライラさせられることも多いが、おかげで在庫プロセスのクリティカルパスから自分を外すことができた。スプレッドシートよりもはるかに細かく柔軟に在庫を追跡してくれる。ただし、残念なほど多くの回避策が必要になるが。

現地スタッフ用の共有ToDoリストを作成する

知らず知らずのうちにマイクロマネジメントしていたタスクの一つが、業務の割り振りだった。TinyPilotの現地スタッフはそれぞれ週3日、数時間ずつオフィスに出勤する。注文の発送や入荷処理など毎日発生するタスクについては、勤務中に取り組むよう指示するのは簡単だ。

週に一度や月に一度発生するタスクは、2人の従業員に分散させるのが難しい。現地オフィスでの最初の数ヶ月間、週次・月次のタスクは「必要になったらやる」「マイケルに頼まれるまで待つ」「マイケルが自分でやる」といった具合に、整理されないまま混在していた。

現地スタッフの一人が、ナレッジベースとして使っているNotionについてもっと学びたいと言い出した。これは良いNotionプロジェクトになりそうだったので、週次・月次のタスクを管理するための共有ToDoリストを作ってもらうことにした。

このToDoリストを3週間ほど順調に運用している。大きな欠点は、Notionで繰り返しタスクをうまく作成する方法が見つかっていないことだ。回避策として、数ヶ月ごとに手作業でリストを再作成している。面倒だが、四半期に1時間程度の作業で済む。

現地スタッフが原材料を再発注できるようにする

TinyPilotの歴史のほとんどにおいて、在庫管理はガールフレンドが担当し、在庫が少なくなった際の原材料の再発注も行っていた。彼女が6月に大学院に戻った際、業務のほとんどは新しい従業員に引き継いだが、材料の再発注は再び私の担当に戻ってきた。

在庫の再発注は、見た目以上に外部委託が難しいタスクだ。単にやり方を説明するだけでなく、仕入先のサイトへのログイン情報をどう共有するか、ミスを抑えるために上限を設定した新しいデビットカード番号を渡すといったことも考える必要がある。在庫管理を任せるには信頼の醸成にも時間がかかる。入社したばかりの従業員にいきなりクレジットカードを渡して「毎月1万ドルの支出を任せる」とは言えない。

7月にようやくチーム全員分のBitwardenアカウントを作成し、認証情報を安全に共有できるようにした。さらに、各種仕入先への発注方法についての手順書も作成した。

在庫水準の維持は大した作業ではないように思えるが、補充の発注プロセスには細々としたタスクがたくさんあり、誰か他の人が引き継いでくれると本当にほっとする。

開発者同士でプルリクエストをレビューできるようにする

2月から2人のフリーランス開発者がTinyPilotで一緒に働いており、先月さらに1人が加わった。時間不足から自分はほとんどコードを書かなくなったが、それでもすべての変更のコードレビューは自分が担当していた。

数ヶ月前、自分をコードレビューのプロセスから外そうとしたが、うまくいかなかった。自分はフルタイムで対応できるが、他の開発者はパートタイムで、しかも稼働時間がほとんど重なっていない。依存関係のある一連の変更があった場合、レビュー間の遅延が作業の進行を止めてしまうのだ。

月次の開発ミーティングで、そうした連続した変更は全体のごく一部に過ぎないことに気づいた。ほとんどの変更では、レビューに1〜2日待たされても大きな問題にはならない。そこで今では開発者同士でコードをレビューするようにしている。

今でも自分をインディー開発者だと思っている身としては、自分でレビューしていないコードを抱えるのは怖い。ただ、チームメンバーを信頼しているし、会社全体にとってはこの仕組みの方がうまく機能していると思う。

イメージビルドのプロセスを外部化する

TinyPilotの新バージョンをリリースするたびに、最新版をプリインストールしたmicroSDイメージを作成している。microSDイメージのビルドにはRaspberry Piが必要なため、これまではオフィスの隅に置いた予備のPiとSSDを使ってきた。

TinyPilotの開発者たちはコードを十分に管理できる能力があるにもかかわらず、自分の家に隔離された1台のサーバーへの共有アクセスを調整するのは難しすぎた。その結果、ビルド用コードのメンテナンスは私だけが担い続けることになった。

解決策を必死に探して何ヶ月もGoogleで検索し続け、結局検索キーワードが間違っていただけだったと気づくことがある。ずっとPiのクラウドホスティングを探していて、「pi cloud hosting」や「pi cloud server」で定期的に検索していたが、自分のPiをクラウドサーバーとして使う方法ばかりがヒットして役に立たなかった。ようやく「pi dedicated server」で検索することを思いつき、それがMythic Beastsという、秒単位でレンタルできるクラウドホスト型Raspberry Piサーバーを提供する会社につながった。

Mythic BeastsはPiサーバーを動的に立ち上げるための優れたAPIを提供しているが、開発者の工数と比べるとサーバー費用が非常に安いことに気づいた。賢いサーバー割り当てロジックを自動化するよりも、開発者一人ひとりに24時間365日稼働する専用サーバーを割り当てた方が安上がりなのだ。

サーバーの問題が解決したので、イメージビルド用のコードを整理してチームに共有した。これでどのTinyPilot開発者でも、自分のサーバーに最新のビルドコードをセットアップし、TinyPilotのmicroSDイメージを生成できるようになった。さらに重要なのは、プロセスにバグが見つかったり新しい手順が追加されたりした際に、マイケルだけのタスクではなく、TinyPilotの開発者が自ら修正できるようになったことだ。

EUでの販売開始

過去1ヶ月で最も大きなプロジェクトは、新しいEU販売代理店との立ち上げを進めることだった。現在もヨーロッパの顧客には販売しているが、海外への発送は遅く、費用もかさみ、到着時に思いがけない関税がかかることもある。EUの販売代理店はドイツからTinyPilotを製造・発送することになるため、EU圏の消費者にとって購入体験が向上する。

パートナーシップを組む上での大きな課題の一つは、コミットメントと柔軟性のバランスをどう取るかだ。TinyPilotの数ヶ月先を予測することはこれまで一貫して難しかったため、できる限り柔軟でありたいと考えている。一方で、販売代理店は私からのある程度の長期的なコミットメントを必要としている。TinyPilotデバイスの販売を開始するには多大な労力と設備投資が必要なため、もし他からより良い条件の話が来たからといって、私に一方的に契約を破棄されたくはないのだ。

もう一つの悩みはロイヤリティだった。インセンティブを一致させる最良の方法は、利益をパーセンテージで分け合うことだという点で合意した。そうすれば、販売代理店は私への固定の支払いに縛られることなく、様々な価格を試すことができる。もしより高い価格で販売できることが分かれば、その高い価格の恩恵を私も一緒に受けられる。

利益を分け合うことの難しさは、その計算方法をめぐって難しい問題が生じることだ。販売代理店がマーケティングの一環でデバイスを無料で配布した場合、その分のロイヤリティは私に支払われるのか？ 1台あたりの利益に人件費は含まれるのか？ 製品改善に共同で投資した場合、それは利益計算にどう影響するのか？

私たちはそうした疑問を一つひとつ解消し、潜在的な対立の種を予測しようとしてきた。現時点で契約は約95%完成しており、数週間、早ければ数日で最終合意に至る見込みだ。

過去のプロジェクト

以下は、今も維持はしているが、現在は主要な開発対象ではないプロジェクトに関する簡単な近況報告だ。

Is It Keto

先月は、1月の年次ピークを過ぎてもIs It Ketoのアクセスがよく持ちこたえていることを喜んでいた。ジンクスだったのか、今月は今年最大の前月比下落となり、訪問者数が20%以上減少した。

残念なことに、この落ち込みは、より上位のディスプレイ広告パートナーとの提携を申請した時期と重なってしまった。Google AdSenseからMediaVineに切り替えることを勧められており、後者の方がパブリッシャーへの支払いがかなり高いと聞いている。MediaVineは月間10万ページビューが最低条件で、申請時はその条件を満たしていたが、現在はわずかに下回っている。どうなるか様子を見るしかない。

Hit the Front Page of Hacker News

コース自体に新しい動きはない。毎月数人が購入し、満足してくれているようだが、特に宣伝はしていない。Martin Schleissが最近のブログ投稿で好意的に紹介してくれた。今月はテック系ポッドキャストにゲストとして売り込もうと考えており、それがコースへの新たな流入につながるかもしれない。

Zestful

今月はZestfulの利用が大きく跳ね上がったが、ほぼ確実に不正利用だ。joe-84ad853のようなユーザー名のアカウントが数日以内に複数登録された。今月の収益の大部分は、そのうちの1つのアカウントによるものだ。これまでZestfulの顧客で、APIリクエストに100ドル以上を費やしながらボリュームディスカウントについて問い合わせてこなかった人は一人もいない。このユーザーは一度も連絡してこなかったので、非常に怪しいと感じている。RapidAPIによれば8月30日に入金されることになっているが、実際に入金されるとは到底思えない。

まとめ

何ができたか？

• TinyPilotの新バージョンをリリースした
• TinyPilotのウェブサイトを担当する開発者を見つけた
• TinyPilotのPoE HATとラックマウントの開発を再開した
• マネージドな在庫管理サービスへ移行した

学んだこと

• 完璧でないワークフローでも、CEOに依存するものよりはましだ。
  • CraftybaseのUIや制限にはイライラさせられるが、複雑なスプレッドシートの数式を自分が抱え続けるよりはましだ。

来月の目標

• EUの販売代理店が初売上げを達成できるよう支援する。
• Voyager 2の設計を確定させる。
• Refactoring Englishのサンプルチャプターを公開する。