ひとことまとめ

権限委譲を進めた1ヶ月でした。

ハイライト

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

目標の達成度

毎月初めに、その月に達成したい目標を宣言しています。結果は以下のとおりでした。

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

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

うまくいきました。来週には、販売代理店が必要な部品と手順をすべて揃え、自前でTinyPilot Voyagerを組み立てられるようになる見込みです。月末までの販売開始に向けて予定どおり進んでいます。

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

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

TinyPilotではこれまで、在庫管理と発送業務を常に1人で担当してきました。2人で責任を平等に分担できる仕組みを作るのは想像以上に大変でしたが、今では2人がタスクを交代し、スケジュールを調整できる実用的な仕組みができています。加えて、これまで自分が穴埋めしていた業務も文書化し、現地スタッフが対応できるようにしました。

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

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

何ヶ月も探した末、ようやくTinyPilotのウェブサイトを担当してくれるウェブ開発者が見つかり、現在リデザインを進めています。

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

• 結果：既存の外注先が必要な部品を確保し、PoEアダプタの作成が可能になりました。
• 評価：A+

これは幸運なブレイクスルーでした。世界的な半導体不足で、依頼していた電気設計会社が何ヶ月も足止めされていました。そこで、より太いサプライチェーンを持つ大手ベンダーにも声をかけ始めました。ただ、そちらは時間がかかり、一から作り直しになる可能性が高い状況でした。

幸い、既存のパートナー企業が必要な部品の供給を確保してくれました。6〜12ヶ月分をまかなえる量で、価格も想定していた金額の10％未満で済みそうです。現在、PoEアダプタ用の基板設計を進めており、4〜6週間以内に試作が完成する見込みです。

TinyPilotの数値

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

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

TinyPilotを始めて最初の数ヶ月から、在庫を管理するマネージドサービスを探していました。安価なサービスはシンプルすぎて、組み立てや製造が必要ない製品にしか対応していませんでした。一方で高機能なサービスは複雑すぎて、数千点の製品と複数の倉庫を抱える大企業向けに作られていました。

偶然見つけたのがCraftybaseで、ようやくTinyPilotに合うサービスのように思えました。実際、ある程度は合っているのですが、移行はかなり手こずっています。

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

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

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

問題は、追加発注をかけても、そのフラグが消えないことです。保留中の入荷を考慮してくれないからです。上の例では、HDMIキャプチャチップを月末に入荷予定としてCraftybaseに記録していますが、やるべきことはもう何もないのに、Craftybaseは依然として在庫不足として警告し続けます。

そのため、TinyPilotのスタッフが再発注すべきアイテムを確認したいときは、警告が出ているアイテムを1つずつ開いて、保留中の発注を考慮すると本当に在庫が不足しているのかを確認しなければなりません。

当初は簡単な回避策があると思っていました。Craftybaseの「purchased」列が保留中の入荷を表しているのだろうと推測したのです。しかし実際には、「purchased」はこれまでに購入した累計数量でしかなく、Craftybaseがなぜか目立つ場所に表示しているものの、実務上は無意味な数値でした。

結局のところ、低在庫かどうかを確認するには、警告が出ている各アイテムの詳細を開き、在庫数を確認し、保留中の発注数を足し合わせ、その合計が低在庫のしきい値を下回っているかをチェックする必要があります。本来なら2秒で終わるはずの確認が、Craftybaseでは数分かかる面倒で複雑な作業になってしまっています。

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

TinyPilotのほとんどの期間、時間不足に悩まされてきました。事業には多くの要素が絡み合っており、私がすべての橋渡し役を担っているからです。

6月に、ある程度の研修やツールの導入で委譲できるタスクのリストを洗い出しました。そのリストの半分に加え、さらにいくつかの業務について、委譲または廃止できたことを嬉しく思います。

表計算ソフトの担当から外れる

TinyPilotの以前の在庫管理は、私が管理する自作の表計算シートでした。TinyPilotのワークフローにはよく合っていましたが、柔軟性に欠けていました。新しい製品を追加したり部品を変更したりするたびに、場当たり的に作った数式を何時間もかけて修正しなければなりませんでした。

Craftybaseには不満もありますが、おかげで在庫管理のクリティカルパスから自分が外れることができました。表計算シートよりも細かく柔軟に在庫を追跡できますし、多少の回避策は必要ですが、それでも大きな前進です。

現地スタッフ向けの共有ToDoリストを作る

私が無意識にマイクロマネジメントしていた業務のひとつがタスクの割り振りでした。TinyPilotの現地スタッフはそれぞれ週に3日、数時間ずつオフィスに来ています。注文の発送や入荷処理のように毎日発生するタスクは、勤務中に取り組むよう指示すれば済みます。

一方で、週1回や月1回発生するタスクは、2人のスタッフで分担するのが難しくなります。現地オフィスで働き始めた最初の数ヶ月は、週次・月次のタスクは「必要になったらやる」「Michaelに頼まれるまで待つ」「結局Michaelがやる」といった場当たり的な状態でした。

スタッフの1人が、私たちがナレッジベースとして使っているNotionにもっと詳しくなりたいと言ってくれました。ちょうど良いNotionのプロジェクトだと思い、週次・月次のタスクを管理するための共有ToDoリストを作ってもらうことにしました。

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

原材料の再発注を現地スタッフに引き継ぐ

TinyPilotのほとんどの期間、在庫管理は私のパートナーが担当し、在庫が少なくなった原材料の再発注も行っていました。彼女が6月に大学院に戻った際、業務の多くは新しいスタッフに引き継ぎましたが、材料の再発注は再び私の担当に戻ってきました。

在庫の再発注は、思った以上に外部に任せるのが難しい業務です。やり方を説明するだけでなく、仕入先のサイトのログイン情報をどう共有するか、ミスを防ぐために利用限度額を設定した新しいデビットカードを渡すといった準備も必要になります。また、在庫管理を任せるには信頼関係を築く時間も必要です。入社したばかりのスタッフにクレジットカードを渡して「これからは月1万ドルの支出を任せる」と言うわけにはいきません。

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

在庫水準の維持は一見すると大した作業ではないように思えますが、補充の発注には細かな作業がたくさんあり、誰かに引き継いでもらえると本当にほっとします。

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

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

数ヶ月前、コードレビューから自分を外してみようと試みましたが、うまくいきませんでした。私はフルタイムで対応できますが、他の開発者はパートタイムで、稼働時間もほとんど重なっていません。依存関係のある変更が連続すると、レビュー間の待ち時間が作業を止めてしまうのです。

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

自分をインディー開発者だと思っている身としては、自分でレビューしていないコードを所有するのは怖くもあります。ただ、チームメンバーを信頼していますし、会社全体で見ればこの仕組みの方がうまくいくと思っています。

イメージ作成プロセスを外部化する

TinyPilotの新バージョンをリリースするたびに、最新版をプリインストールした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を提供していますが、開発者の人件費と比べるとサーバー代があまりに安いため、 cleverな割り当てロジックを自動化するよりも、開発者1人につき1台、24時間365日稼働する専用サーバーを用意した方が安上がりだと気づきました。

サーバーの問題が解決したので、イメージ作成用のコードを整理してチームに共有しました。これでどのTinyPilot開発者でも、自分のサーバーに最新のビルドコードを配置し、TinyPilotのmicroSDイメージを生成できるようになりました。さらに重要なのは、プロセスにバグが見つかったり新しい手順が追加されたりしても、Michaelだけのタスクではなく、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つのアカウントによるものだったからです。これまで、ボリュームディスカウントの相談なくAPI利用で100ドル以上使うお客様は一人もいませんでした。このユーザーは連絡してこなかったため、非常に疑わしく思っています。RapidAPI上では8月30日に入金されると表示されていますが、実際に入金されるとは正直思えません。

まとめ

できたこと

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

学んだこと

• CEOに依存するワークフローより、不完全でも回るワークフローの方が良い。
  • CraftybaseのUIや制限には不満がありますが、複雑なスプレッドシートの数式を自分が維持し続けるよりはましです。

来月の目標

• EUの販売代理店の初回販売をサポートする。
• Voyager 2の設計を確定させる。
• Refactoring Englishのサンプル章を公開する。