一言サマリー

長期的なタスクが止まったら、要注意です。

ハイライト

• TinyPilotの月間収益が11万2千ドルに達し、初めて6桁を突破しました。
• TinyPilotのフルフィルメントチームの余力を大幅に過大評価していました。
• 長期的なタスクは、リソース枯渇が迫っていることを知らせるカナリアになり得ます。

目標の自己評価

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

TinyPilotのフルフィルメントを3PL業者へ移行する準備をする

• 結果: 取扱量の少ない1製品で、1社とのオンボーディングを開始しました
• 評価: B

現地スタッフがこの取り組みに充てられる余力を少なく見積もりすぎていました。予想外の売上急増も重なり、社内のフルフィルメントワークフローを3PL業者向けに作り替える作業は進みませんでした。それでも、不完全なプロセスのまま前に進め、3PL業者が時間を空けてくれるにつれて改善していけます。

新しいサポートエンジニアのオンボーディングを続ける

• 結果: 2名のサポートエンジニアが、サポートチケットの約80%を自力で対応できるようになりました
• 評価: A

サポートエンジニアチームは、想像以上に力を発揮してくれています。高度なサポートリクエストへの対応に加え、そもそもバグが起きないように徹底的に調査したり、TinyPilotの診断ログの改善にも取り組んでくれています。

自分がクリティカルパスに入っているプロジェクトを減らす

• 結果: 新しいプロジェクトを立ち上げたい衝動をこらえました
• 評価: B

新しいTinyPilotモデルの立ち上げには、常に自分の時間が多くかかります。このプロセスは何度も経験してきたので、作業の多くは予測できますが、どれだけ計画しても、必ず想定漏れが出ることも分かっています。余裕があると感じる日があっても、できる限り自分の時間を空けておくようにしています。

TinyPilot の統計

TinyPilotは再び過去最高の売上を更新し、総収益は11万1,916ドルに達しました。TinyPilotが月間で6桁を超えたのは今回が初めてです。

この急伸は、主にホームラボ愛好家に人気のYouTubeチャンネルであるLinus Tech Tipsで好意的に紹介されたことが要因です。レビューは主に競合製品についてのものだったにもかかわらず、チャンネルの登録者数が非常に多いため、その後2週間にわたってTinyPilotの注文が大幅に増加しました。

例年よりコストがかさむ中でも、3か月移動平均の利益がしっかりプラスを保っているのは嬉しいことです。TinyPilotは通常の生産能力を超える分について、ケースを3Dプリントするために割増コストを支払っていますが、1月に金属製ケースへ切り替えればコストは大幅に下がるはずです。

自分の時間を生み出すための時間すらない

11月の目標の一つは、フルフィルメントを外部の物流業者（3PL）へ移行し始めることでした。フルフィルメントチームのメンバーに、ワークフローを見直し、3PL業者へ引き継ぐ準備をするよう依頼しました。

翌週、Linus Tech Tipsの動画の影響で注文が急増したため、3PLへの移行に向けた調査はまったく進みませんでした。さらに2週間後も、売上急増への対応に追われ、やはり進展はありませんでした。

次にフルフィルメント担当のスタッフと話した際、こうしたイレギュラーなタスクに通常どれくらい余力があるのか尋ねてみたところ、答えはほぼゼロだということに驚きました。デバイスの組み立てや注文の発送、サポートへの対応といった短期的なタスクだけで、1週間の稼働時間はすべて埋まってしまうのです。

これはよくある状況ですが、たいてい短期的なタスクで手一杯なのは私自身です。

どんなワークフローでも、時間を空けるための明白な方法は一般的に存在します。自動化する、人を増やす、マネージドサービスに移行するなどです。ただ、ワークフローを変えることには摩擦コストが伴うのが難点です。

ここ数か月、私はアウトソーシングや委任における時間的コストを美しい グラフにしてきました。その流れで、誰かにタスクを引き継ぐ前後で、私がそのタスクに費やす時間がどう変化するかを示したのがこちらです。

最初は、自分一人ですべてをこなしているためタスクに時間がかかります。誰かを雇うと、タスク自体に加えて採用や教育の作業も担うことになるため、さらに多くの時間を要します。新しいメンバーが完全に独り立ちすれば、最終的には時間の節約につながりますが、タスクの複雑さによってはそれまでに数週間から数か月かかることもあります。

実際には、1日に使える時間には限りがあります。稼働時間の上限を考慮するとどうなるでしょうか。

おっと、今度は短期的に人を雇って教育する余力がないため、雇った後の状態にたどり着けません。自分の時間を生み出すための時間すらないのです。

長期的なタスクをリソース枯渇の早期警告にする

3PL業者への切り替えが遅れたことで、余力が尽きかけていることを早めに察知する仕組みが必要だと気づきました。

今考えている最善策は、全員の短期的なタスクと長期的なタスクのバランスをより意識することです。例えば、サポートエンジニアの緊急の責務は、TinyPilotのヘルプフォーラムやCRMプラットフォームでカスタマーサポートのリクエストに対応することです。サポートの件数は波があるため、エンジニアに余裕があるときは、サポートリクエストに共通するパターンを探し、ヘルプ記事を公開したり、より根本的なバグ修正に取り組んだりしています。

TinyPilotでは、誰もが短期的なタスクと長期的なタスクを抱えています。

長期的なタスクは、炭鉱のカナリアのような役割を果たします。あるチームの長期的なタスクの進捗が継続的に鈍ってきたら、それはキャパシティの上限に近づいているサインである可能性が高いのです。その時点で、担当範囲を減らすか、キャパシティを追加することで負荷を下げる方法を探すべきです。

長期的なタスクを警告サインとして使うことには、2つの課題があります。1つ目は、長期的なタスクを最も頻繁に後回しにしているのが創業者チーム、つまり私自身だということです。私が手一杯のときは、他のチームの長期的なタスクの停滞に気づきません。気づいたとしても、対処する時間がありません。おそらく解決策は、自分が引き受けるプロジェクトの数をより慎重に管理し、切り替えコストに充てる余力を残しておくことです。

もう1つの問題は、フルフィルメントチームの長期的なタスクが最も見えにくいことです。製造やフルフィルメントのプロセスは、毎週改善できるような類のものではありません。しかし、フルフィルメントと製造を外部業者へ移行するにつれて、フルフィルメントチームの役割はカスタマーサポートへと移っていきます。カスタマーサポートには、サポートリクエストへの対応という短期的な業務と、社内プレイブックを磨くという長期的な業務の間で、より自然なバランスがあります。

Ansibleの穴から抜け出す

Ansibleは、サーバーを自動で構成するためのツールです。私は7年前から使っており、自宅ラボの仮想マシンはすべてAnsibleで管理しています。

TinyPilotの開発を2020年に始めたとき、Raspberry Piにコードをデプロイし、TinyPilotが必要とするOS機能を設定する方法が必要でした。リモートでのシステム構成こそAnsibleの得意分野だったため、Ansibleは適任でした。

TinyPilotを公開した際、ユーザーにインストールしてもらう最も手軽な方法は、開発中に自分が使っていたワークフローをそのまま再現することでした。Ansible環境をブートストラップし、Ansible経由でTinyPilotをインストールするシンプルなインストールスクリプトを作成したのです。

当時、より一般的なインストール方法はDebianパッケージを使うことだと分かっていました。問題は、Debianパッケージの作り方をまったく知らず、とても面倒そうに見えたことです。自分でaptリポジトリを立てなければならないのか？ リポジトリの鍵は管理しなければならないのか？ TinyPilotはnginxに依存しているのに、自分のパッケージからnginxをどう設定すればいいのか？

それから2年半が経ち、開発チームは私のAnsibleという選択のツケを払っています。TinyPilotの機能が増えるにつれて、Ansibleの設定は耐え難いほど複雑になりました。インストーラーが純粋なシェルスクリプトやDebianパッケージであれば、インストールはおそらく10〜20秒で終わるでしょう。しかしAnsibleのオーバーヘッドのせいで、インストールやアップデートには6分以上かかってしまいます。

エンドユーザーへの影響だけでなく、Ansibleは開発リソースをも飲み込んでしまいます。Ansibleのコードはデバッグが遅くて面倒で、特に継続的インテグレーション環境にないOSやアーキテクチャを扱うときは顕著です。ちょっとした変更でも、1週間分の開発時間が膨らむことが頻繁にあります。

ここ数か月、開発チームはAnsibleのコードをTinyPilot用のDebianパッケージに移植する方法を模索してきました。嬉しいことに、今では足がかりができました。TinyPilotのAnsibleロールが最新のTinyPilot Debianパッケージをインストールする、ハイブリッドな解決策を作ったのです。これにより、Ansibleのコードを少しずつDebianパッケージへ移していくことが容易になります。

TinyPilotの開発を始めたときに、Debianについて知っておきたかったことは次のとおりです。

• 自分でaptリポジトリを運用しなくても、スタンドアロンのDebianパッケージを作成して配布できます。
• 適切なチュートリアルに従えば、シンプルなDebianパッケージの作成は15分でできます。
• Docker QEMUを使えば、x64システムからARM用のDebianパッケージをビルドできます。
• コードがPythonのようなポータブルな言語で書かれているなら、QEMUを使わずにアーキテクチャ非依存のDebianパッケージをビルドできます。
• パッケージが別のパッケージを設定する必要がある場合、典型的な方法は、相手のパッケージが所有するファイルを直接いじるのではなく、設定ディレクトリにファイルを追加することです。
  • 例えば、TinyPilotのDebianパッケージなら、/etc/nginx/sites-enabled/ ディレクトリにファイルを追加することでnginxを設定できます。

Debianを学ぶ上で最も難しかったのは、ノイズの中から有用な情報を見つけ出すことでした。多くのリソースは、基本的に「9,000ページに及ぶDebianメンテナガイドを読んでください、ただし古くなっている部分は読み飛ばしてください」と言うだけなのです。

私が最も役に立ったと感じたガイドは次の2つです。

• “Creating and hosting your own deb packages and apt repo” — Alex Couture-Beil著
• “Pragmatic Debian packaging” — Vincent Bernat著

Vincentは親切にもビデオ通話に応じてくれて、Debianパッケージに関する残りの疑問に答えてくれました。

サイドプロジェクト

ScreenJournal

私はテレビ番組や映画をよく観るのですが、友人に薦めたいと思っても、どの作品を薦めたかったのか忘れてしまうことがよくあります。

読書におけるGoodreadsのように、映画やテレビを記録できるアプリを探してみましたが、自分のイメージに合うものはありませんでした。デフォルトで公開されるソーシャルアプリに友人たちがうんざりしているように感じたので、おすすめを共有したい少人数の友人グループを作れるものが欲しかったのです。Twitterというより、Discordのようなイメージです。

友人と映画レビューを共有するためのアプリを作り始めました。ScreenJournalという名前です。

まだ本番で使える段階ではありません。レビューは非公開で、単一ユーザーにしか対応していないからです。現時点では、1人用のプライベートな映画日記としてしか機能しませんが、次に取り組む機能はマルチユーザー対応です。

ユーザー管理を正しく実装するのは悪名高いほど難しいので、これまで自分で実装することは避けてきました。ここ数年は、友人であるDavid TothのUserKitというサービスを使ってユーザー管理を行ってきました。UserKitは素晴らしかったのですが、まだ一般公開されていないため、自分のサーバーでScreenJournalを動かしたい他の開発者にとっては使いにくいのが難点です。

Go用のオープンソースのユーザー管理フレームワークを探しましたが、その大半は外部サービスのOAuthに依存しており、それは避けたかったのです。残りはあまりにも大掛かりで複雑で、使う気になれませんでした。

そこで、危険を承知で自分でユーザー管理を実装することにしました。セッション管理にはjeffを、認証にはbcryptを使って、うまくいくことを祈るつもりです。

まとめ

何が完了したか

• 3PL業者とのオンボーディングプロセスを開始しました。
• TinyPilotのDebianパッケージをいくつかの重要な点で改善しました。
• 海外の業務委託メンバー向けに、より良い決済プラットフォームを見つけました。
  • Deelは使い勝手が悪く、Remote.comもあまり気に入らなかったので、Pilotを採用することにしました。

学んだこと

• 長期的なタスクは、リソース枯渇の良い先行指標になります。
  • あるチームの長期的なタスクの進捗が継続的に鈍化しているなら、余裕がなくなりプロセスを切り替えられなくなる前に対処することが重要です。
  • 創業者は長期的なタスクのために時間を確保しておくことが特に重要です。そうでなければ、他のチームのリソース枯渇に効果的に対応できません。
• Debianパッケージングは、最初に思ったほど手強いものではありません。

来月の目標

• 3PL業者から最初の注文を発送する。
• 次期TinyPilot Proリリースをコードコンプリートさせる。
• 1月に予定しているTinyPilot Voyager 2aのローンチに向けた準備を整える。