一言でまとめると

さらに作り込むべきか、今あるものを最適化すべきか？

ハイライト

• TinyPilotは過去最高の売上月となり、総収益は69,000ドルに達しました。
• ウェブサイトのリデザインは予算を32,000ドル、スケジュールを5ヶ月超過しています。
• PicoShareをローンチしました。これまで公開した中で最も急速に伸びているプロジェクトです。

目標の自己採点

毎月初めに達成したい目標を宣言しています。目標に対してどれだけ達成できたか振り返ります。

TinyPilot Pro 2.4.0を公開する

• 結果: 予定通りTinyPilot 2.4.0をリリースしました
• 評価: A

最新リリースでは、以前から要望の多かった複数ユーザー対応を追加しました。頻繁にサポート問い合わせが来ていた厄介なバグも解消しています。

TinyPilotウェブサイトのデザイン刷新を完了する

• 結果: デザイン自体は完成しましたが、まだ公開できていません
• 評価: C

このプロジェクトは予想以上に時間がかかっています。デザイン自体は完了しているのですが、デザインエージェンシーの側でTinyPilotサイトへのコード反映を行うリソースが確保できていません。

TinyPilotの新しいサポートエンジニアのオンボーディングを完了する

• 結果: Diegoが戦力化し、ほとんどのサポートリクエストを独力で対応できるようになりました
• 評価: A

適任のエンジニアを見つけるのに長い時間がかかりましたが、うまくいって本当に良かったです。すでに私の時間を大きく確保できるようになっています。

TinyPilotの統計

3月はTinyPilotにとって販売額・総収益ともに過去最高の月となりました。2月と比べて販売台数は14%増に過ぎませんでしたが、その半分は新型のVoyager 2 PoEでした。新モデルは標準モデルより60ドル高く、その差が収益33%増につながりました。

利益はマイナスでしたが、これは主に経費の計上タイミングによるものです。2022年第1四半期の利益は健全な16,000ドル、月平均5,300ドル（追記（2022-04-29）: 数字が間違っていました。実際には2022年第1四半期は10,000ドルの赤字でした）となっています。

ユニーク訪問者あたりの収益は10.49ドルと過去最高になりました。参考までに、昨年の今頃の訪問者あたり平均収益は約4ドルでした。これは良いニュースです。当初の計画では、マーケティングに注力する前に、まずウェブサイトのコンバージョン率（「ファネルのボトム」）向上に集中することにしていました。この指標の伸びは、計画がうまくいっていることを示唆しています。プロダクト、価格設定、ウェブサイトの改善によって、購入に至る人が増えたのだと思います。

再び自由な時間ができた！

2月には、TinyPilotを週20時間で運営するにはどうすればいいかを考えました。まだ完全には到達していませんが、着実に前進しています。

私の時間をもっとも奪っていたのはテクニカルサポートで、週8時間かかっていました。採用プロセスだけで何百時間もかかったため、委譲するのが最も難しい業務でした。優秀なエンジニアを見つけた後も、2年分の暗黙知が私の頭の中に閉じ込められていたため、教育には時間がかかりました。

嬉しいことに、ようやく山を越えました。TinyPilot初のサポートエンジニアであるDiegoが、現在サポートフォーラムの質問すべてに対応してくれており、私のサポート対応時間は週8時間を下回っています。彼は初めてのチュートリアルとして、TinyPilotでTailscaleを設定するガイドも公開してくれました。

また、TinyPilotの現地スタッフにより多くの責任を任せるようにもしています。例えば今週、Voyager 2の組み立てに使っているネジが、どこでも在庫切れになっていることが分かりました。

本来であれば私がケースデザイナーと連絡を取り、代替品を探して新しいネジで試作するところですが、メールを送る直前で思いとどまりました。これは現地スタッフがより責任を担う良い機会だと考え、彼らに主導を任せました。

3月を通じて、時間の使い方に大きな違いを感じました。過去6ヶ月間は、ほとんどの日でやり残しを感じ、重要だが緊急ではないタスクを先送りにしていました。3月は緊急のタスクを昼過ぎまでに終え、マーケティングや自動化、権限委譲に投資する自由な時間を確保できる日が多くなりました。

新しくできたこの時間を、追加採用やTinyPilotの新機能探しといった付け加えることに使いたい誘惑に抗っています。そういったことは、最初に見えるよりも常に複雑になるのだと自分に言い聞かせています。

2021年は成長プロジェクトを抱えすぎて奔走したので、今は今あるものを最適化する時です：

• リリースプロセスの自動化
• エンドツーエンドテストの自動化
• カスタマーサポートへの問い合わせを待つのではなく、こちらから積極的に顧客と対話すること
• TinyPilotのカスタマーサービススタッフとサポートエンジニア間のエスカレーションパスの確立
• 製造パートナーとのワークフローの改善

再投資を続けるべきか、収益を得始めるべきか？

TinyPilotを始めて以来、短期的な利益は度外視し、長期的な成長に集中してきました。赤字にはしないようにしつつも、ほぼ収支トントンで、収益のすべてをプロダクト改善に再投資することに満足していました。

再投資は勢いをつけることだと考えていました。売上が月3,000ドルで、5,000ドルを投じてプロダクトを改善し月4,000ドルに届くなら、その5,000ドルは一回限りのコストですが、TinyPilotの売上ペースは恒久的に上がります。

しかし私はベンチャーキャピタルの支援を受けたスタートアップではありません。目標は永遠に成長し続けてIPOで一攫千金を得ることではないのです。どこかの時点で、すべてを成長に注ぎ込むのをやめ、収益を得始めなければなりません。今がその時なのでしょうか？

当面の主な支出は、Voyager 2の電気設計を製造しやすくするための最適化（月10,000〜20,000ドル）と、販売サイトのリデザイン（月5,000〜6,000ドル）です。数ヶ月もすればVoyager 2の基板設計が確定し、ウェブサイトをいじくるのもやめるので、コストは大幅に下がります。売上を維持できれば、新しいプロジェクトを始めないだけで月20,000ドルの収益が得られます。

当初の計画では、Voyager 2の生産が安定したらすぐに電気設計パートナーとVoyager 3に取りかかる予定でした。Voyager 3の開発には今後6ヶ月で月15,000〜25,000ドルかかり、年内の利益を飲み込んでしまいます。しかも、新製品のリリースはTinyPilotの社内ワークフローを大きく変えるため、私の時間もかなり奪われます。

現時点では、そろそろ収益を得始める時期だと思っています。新しいプロジェクトは年内の後半に始めればよく、まずは売上を70,000〜90,000ドルのレンジまで伸ばし、利益をすべて吐き出さずにプロダクト改善へ投資できるようにしたいです。

デザインエージェンシーと仕事をする前に知っておきたかったこと

9月に、TinyPilotのウェブサイト改善のためにデザインエージェンシーに依頼しました。当時は6週間で7,000ドルで終わると思っていました。6ヶ月経った今、39,577ドルを費やしてもプロジェクトはまだ終わっていません。

どうしてこうなったのか？エージェンシー側のミスを挙げることもできますが、核心的な問題は、私がエージェンシーと効果的に仕事をする方法を知らなかったことです。これまでフリーランスしか雇ったことがなく、エージェンシーによって力学がどれほど変わるかを理解していませんでした。

最初に知っておきたかったことを、自分のための備忘録として、またこれからエージェンシーと仕事を始める誰かの役に立てばと思い、書き残しておきます。

エージェンシーには、少ない管理ではなく、より多くの管理が必要になる

このエージェンシーを雇った際に犯した根本的なミスは、管理にどれだけ時間がかかるかを過小評価したことでした。

エージェンシーは月に40〜60時間稼働してくれます。これはTinyPilotの他のフリーランサーと同じ稼働時間なので、1人のフリーランスと同程度のマネジメントで済むと思っていました。もっと多くの管理時間を確保すべきでした。

エージェンシーと仕事をする場合、複数の担当者とやり取りし、彼らはそれぞれ別のサブプロジェクトを進めています。人数が増えれば、当然管理時間も増えます。

例えば、週40時間働く従業員1人に週6〜8時間のマネジメントが必要だとします。その役割を週20時間ずつの2人に分ければ、管理時間はおそらく週10〜12時間に膨らみます。従業員の総稼働時間は同じでも、1人ではなく2人とコミュニケーションを取ることで効率が落ちるのです。

同じ理屈がデザインエージェンシーにも当てはまります。月に40時間分の作業を得ているとしても、1人のフリーランスが同じ作業をする場合に比べ、6人のエージェンシーメンバーを管理するクライアント側の負担は大きくなります。

スコープは徹底的に守る

このプロジェクトで最大の問題はスコープでした。6週間の予定が6ヶ月かかっていると聞けば、想像がつくかもしれません。

当初、エージェンシーとはリブランディングだけを行うことで合意していました。ウェブサイト用に新しいロゴ、カラースキーム、フォントを作り、その後次のステップを検討する予定でした。しかしスコープクリープが起きました。デザイナーたちは静かにスコープを拡大し続け、気づけばウェブサイトの全面的なリデザインの半ばまで来ていました。

もう少し待てば今月中に終わるだろうと思い続けましたが、ずるずる引き延ばされました。今振り返れば、損失を確定させ、当初の予定通りリブランディングにスコープを縮小すべきでした。しかしVoyager 2のローンチに気を取られ、エージェンシーにそのまま続けさせるのが一番楽な選択でした。

教訓を得たと思ったのに、今月またスコープクリープにやられました。リデザインの残タスクを優先順位順に並べたプロジェクトボードを作りました。3月はエージェンシーの時間を60時間確保しましたが、デザイン作業だけで埋まるか確信が持てなかったので、時間が余った場合に備えて優先度の低いバグ修正をリストの最後に追加しました。

この先どうなったか、想像がつくでしょう…

デザインエージェンシーはデザイン作業をすべて中途半端なまま残し、その一方で今月の稼働時間の4分の1を使って、優先度の低いバグをすべて修正してしまいました。

今後は、すべてのクリティカルなタスクが完了するまで、重要でないタスクに着手しないよう、より明確に期待値を設定する必要があります。

オープンループに注意する

フリーランスにタスクA、B、Cを依頼したとして、タスクAが80%終わったところで急に中断してタスクBを始めれば奇妙に感じます。タスクBの途中でやめてタスクCを始めれば、さらに奇妙です。

エージェンシーでは、複数のタスクが80%の状態で止まる状況に陥りがちです。例えば、エージェンシーのAliceは今月10時間しか空きがなく、タスクAを80%まで進めます。次にBobが担当しますが、Aliceの作業を途中から引き継ぎたくないのでタスクBを始め、30%まで進めます。気づけば39,577ドルを費やしたのに、成果はすべて80〜90%の仕上がりで、どれも使い物にならないという事態になります。

書籍Getting Things Doneの中で、デビッド・アレンは未完了のタスクを「オープンループ」と表現しています。オープンループが多いほど、それぞれが頭の中の領域を占有するため、集中力は低下します。フリーランスであれば同時に抱えるオープンループは2、3個程度ですが、デザインエージェンシーではその5〜10倍になり、しかも長期間残り続けます。

オープンループは費用対効果の面でも不利です。6ヶ月で6つのタスクを完了する必要があるとします。個人に依頼すれば、月に1つずつ納品されます。月末に支払えば、支払いとほぼ同時に成果の恩恵を受けられます。エージェンシーでは、6つのタスクを6人に割り当て、各人がプロジェクトに1/6の時間しか割かないかもしれません。5ヶ月目の時点で、エージェンシーは80%の報酬を受け取っているのに、タスクが一つも完了していないため、あなたが得られる利益は0%です。

最初は時間制で始め、次にリテイナー契約へ切り替える

私が依頼しているエージェンシーは、時間制とリテイナー制の両方を提供しています。時間制では30時間分を前払いで購入し、その時間を消化するまで作業してもらいます。リテイナー制では毎月一定時間（最低40時間）をコミットします。時間制より20%割安ですが、未使用分は翌月に繰り越されず、解約には28日前の通知が必要です。

気づいていなかったのは、時間制のクライアントは数ヶ月にわたってリソースを割り当ててもらえなくなることがあるという点です。10月にエージェンシーと仕事を始め、2ヶ月間は素晴らしい出来でしたが、12月に急激に質が落ちました。

当時は単なる休暇シーズンのスローダウンだと思っていましたが、1月になっても続いたため、オーナーに問題を提起しました。彼は、スタッフが減り、新たにリテイナー契約のクライアントを獲得したため、私が唯一の時間制クライアントであるTinyPilotにリソースを割くのが難しくなっていると認めました。そして優先度を保証するためにリテイナー契約への切り替えを勧められました。

正直、いら立ちました。自分のプロジェクトの優先度を下げておいて、さらに大きなコミットを求めるのか、と。同時に、理解もできます。エージェンシーも小さなビジネスであり、単発の仕事よりも長期のクライアントを優先したいのです。エージェンシーからは10月の時点で、リテイナー契約なら優先されると聞いていましたが、その差がどれほど大きいかは分かっていませんでした。

もしやり直せるなら、最初に30時間分をトライアルとして購入し、その後はプロジェクトの残りをリテイナー契約に切り替えます。スケジュール上で時間が保証されていれば、月内に散発的に数時間だけ割り当てられるよりも、確保された時間を持てるため、より良い品質につながるようです。

サイドプロジェクト

PicoShare

PicoShareは、2月に私が作ったオープンソースのミニマルなファイル共有ツールです。

私はよく他の人と画像や動画、PDFを共有します。ビジネスでファイルを送る際に、imgurやmega.nzにアップロードしたファイルへのリンクを送るのは、なんだか間抜けに感じます。そういったサービスは「プロフェッショナルなビジネスコミュニケーション」という印象とは程遠いからです。Google DriveやDropboxも、UIが邪魔になったり、ファイルを閲覧する前に受信者にアカウント作成を促したりするので好きではありません。PicoShareを使えば、サードパーティのサービスに頼らずに簡単に共有できるリンクを作成できます。

3月20日にPicoShare v1.0.0を正式にリリースし、/r/selfhostedサブレディットで告知しました。反応はポジティブでしたが、センセーショナルというほどではありませんでした。その後の数週間で、徐々に勢いが増していきました。

YouTuberのDavid Burgess氏がPicoShareについての動画を作り、続いてHal Gus氏も別の動画を公開しました。セルフホスティング系のブロガーがSynology NASへのPicoShareインストール方法のチュートリアルを書いてくれました（私にとっては面白い偶然で、初めて書いたブログ記事がSynology NASでDockerイメージをセットアップする方法についてだったのです）。

PicoShareは、私がこれまで作った中で最も急速に成長しているプロジェクトになりました。最初のコミットは2月13日で、現在GitHubで664スターを獲得しています。比較すると、TinyPilotは約2年で1.8kスター、LogPasteは1年で201スターです。

オープンソースの開発者たちから素晴らしいコード貢献もありました：

• @viktorpenelski氏が共有ファイルを永久保存するオプションを追加してくれました。
• @dertuerke氏がファイルサイズの人間が読みやすい表記（例：「1.53 MB」ではなく「1530000 bytes」）を追加してくれました。
• @dertuerke氏が「クリップボードにコピー」ボタンを追加してくれました。

私はmultiarch Dockerイメージのサポートを追加したので、Raspberry PiのようなARMベースのシステムでもPicoShareのDockerイメージを実行できるようになりました。multiarchビルドの作成プロセスは驚くほどシンプルですが、手順が頻繁に変わるため、説明を見つけるのがとても大変でした。

ライブデモサーバーも作成しました。最初は、違法コンテンツのアップロードや帯域幅の枯渇への対応を避けたかったため、作るのを躊躇していました。そこで、デモサーバーでは自分自身のIPからアップロードされたファイルにしかアクセスできないという制限を設けることを思いつきました。これにより、サービスの試用は可能にしつつ、悪用の度合いを抑えられます。

まとめ

何ができたか？

• TinyPilot Pro 2.4.0をリリース
• PicoShare 1.0.0をリリース
• TinyPilot初のサポートエンジニアを育成

学んだこと

• エージェンシーとフリーランスではマネジメントの方法が異なる。
• セルフホスト型ツールでDockerイメージを用意すると魅力が大幅に増す。
  • PicoShareがこれほど速くユーザーを集められたのは、単一のDockerコマンドで実行できるからだと思う。

来月の目標

• TinyPilotを使った自宅ラボ用NASサーバーの構築について、ブログ記事と動画を公開する。
• TinyPilotウェブサイトのリデザインを完了する。
• WebRTC経由のH264ビデオのオプトインによる実験的サポートを含むTinyPilot Proのリリースを公開する。